Subject: RE: [Sip] Two SDP issues

From: Michael Hammer <[email-masked]>
Date: Fri, 29 Jun 2001 09:56:13 -0400

At 04:46 AM 6/29/2001 -0400, Jonathan Rosenberg wrote:

>
>
> > -----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.
>

Could you kill two birds with one stone by defining a fourth option to the 
sendonly, receiveonly, sendreceive:  neithersendnorreceive?

>-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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 15:35:45 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, June 29, 2001 9:58 AM
> To: Christer Holmberg
> Cc: Jonathan Rosenberg; 'Gonzalo Camarillo'; [email-masked]; mmusic
> Subject: Re: [Sip] Two SDP issues
> 
> 
> 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.

Right, good point.

> 
> 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.

I think that you need to have a hold attribute in addition to the sendonly
attribute since, as you say, the session may already be one way.

If we could ignore backwards compatibility, my preferred approach would be
to have an a=held attribute. If you want to put the stream on hold, you
re-INVITE with the sendonly attribute and add the a=held attribute to that
media. But, thats not going to be backwards compatible.

The only backwards compatible approach is to set the connection IP to
0.0.0.0, but include a held attribute that contains the actual IP address to
use:

a=hold 1.2.3.4

This will cause all the problems to be fixed when both sides support the new
attribute. When the answerer doesn't, you end up falling back to the current
hold mechanism. Ugly, and not my preference, but I see no other viable
alternative without sacrificing backwards compatibility.

-Jonathan R.

---