Subject: RE: [Sip] Two SDP issues

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 04:46:48 -0400

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 3:01 PM
> To: [email-masked]; mmusic
> Subject: [Sip] Two SDP issues
> 
> 
> Hello,
> 
> A couple of SDP issues:
> 
> 1) I recall that we discussed this issue in an IETF meeting, but I am
> not aware of the result of the discussion.
> 
> Let's say that user A sends an INVITE with two m lines. One for audio
> (PCM codec, for instance) and another for DTMF tones.
> 
> The receiver (user B), due to any reason, cannot send DTMF 
> tones, but he
> can receive them. Can user B add a=recvonly for that m line to the SDP
> that he returns in the 200 OK?

Yes. From bis-03:

If an offered media stream is listed as sendrecv (or contains no direction
attribute, in which case it is
sendrecv by default), the corresponding stream in the answer MAY be marked
as sendonly, recvonly, or
sendrecv.

> 
> 
> 2) If I want to stop receiving media (put a call on hold) I 
> send an SDP
> with c=0.0.0.0. However, I can still send media. In which 
> address will I
> receive RTCP? Should the other party remember my previous c line on
> order to send me RTCP?

Now, this is a really good question. Remembering the old IP address is a bad
thing, I think. There may not be one, and you really want each INVITE to
contain the full state for the media streams.

At the moment, the result is that you won't get RTCP or media if you put
someone on hold, even if you are still sending media. This is not
catastrophic, but is not the right thing to do. 

There are a few options:

1. don't worry about this problem
2. define an sdp attribute that indicates the address to receive rtcp
3. define an alternate "hold" mechanism that, instead of setting the
connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
additional attribute to convey "hold"

Maybe there are others. The third approach is sort-of backwards compatible,
but won't work with clients that take explicit actions as a result of
realizing that the stream is on hold.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Jun 2001 12:36:12 +0300

Hi,

I agree with Jonathan that using a SDP attribute (or use existing ones),
instead of c=0.0.0.0, could be a good idea.

That would solve the RTCP issue, without having to "remember" the old
address. There are also some other issues I can think about:

1. Media security

In this case the old address would also have to be remembered, for the
case when the media is put back again, because the application has to
know if it is a new IP address, or the one that was used before the
media was put back on hold. If it is a new address, a new security
association may have to be established, while the old SA can be used
otherwise.

2. IPv6

Since IPv6 uses different addressing, so we can't use c=0.0.0.0 there.

3. ATM

An ATM bearer doesn't use IP addresses at all, so to be able to put
media on ATM on hold we need to use some other mechanism in any case.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jun 2001 09:58:26 -0400

Since this seems to be turning into a discussion of problems with the
existing means of representing Hold, let me add one more:

The c=0.0.0.0 mechanism for specifying hold doesn't work right for
connection oriented media (the comedia I-P.) In reality it is another
manifestation of the problem here with RTCP.

Seems to me that if we were in a sendrecv session and I want to put you
on hold I should send SDP containing a:sendonly. If you receive that and
are happy with it then you should return a:recvonly. With some kinds of
transports it may be possible to also specify c=0.0.0.0 in order to free
up my transport resources for some other purpose, but that varies from
case to case.

The situation is a little more complicated if the session is already
oneway and the receiver wants to go on hold. I haven't worked that out
yet.

	Paul Kyzivat
	Cisco Systems