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

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 4 Jul 2001 12:16:40 +0100

All,

I like the option of using just a=sendonly to put an existing two-way
session on hold - it makes much more sense than c=0.0.0.0 for all the
reasons given in this thread. Is there any difference (for a two-way media
stream) between 'held' state and 'sendonly' state ? I'm sure SIP will not
save us from crappy 'music' on hold, so there may still be media in the
other direction.

Also, in a multi-media session I might want to put one media stream on hold
whilst still receiving another. I can only really listen to one person at a
time, but I can see multiple video sessions on my PC screen. So I might put
the audio of a videocall on hold whilst I make a consultation call to
another party.

In the case of a one-way session, putting this on hold basically temporarily
cancels the media stream altogether. As someone suggested, it would be nice
to have an a=neithersendnorrecv to complete the possibilities of sendonly,
recvonly, sendrecv, but would another alternative in this case would be to
set the port to zero ?

Regards,

Mark Watson

> Sent: 02 July 2001 20:43
> To: Jonathan Rosenberg
> Cc: 'Paul Kyzivat'; Christer Holmberg; [email-masked]; mmusic
> Subject: Re: [Sip] Two SDP issues
> 
> 
> Hello Jonathan,
> 
> > Ugly, and not my preference, but I see no other viable
> > alternative without sacrificing backwards compatibility.
> 
> In this situation, I believe we should have a clear idea of what we
> understand by backwards compatibility. When a new feature is added, it
> usually means that the addition of the new feature does not break all
> the implementations that already work properly (but do not provide the
> new feature).
> 
> However, in this scenario, there cannot be any implementation 
> that works
> properly right now. They just cannot send RTCP properly. Therefore, in
> this situation, an elegant brand new mechanism might be 
> acceptable. I do
> not think that it would be a big deal to "break" current 
> implementations
> that do not work properly anyway.
> 
> Regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027                   
> USA                              [email-masked]
>