RE: [SIP] draft-camarillo-sip-sdp-00.txt

[Jonathan Rosenberg <[e-mail]>]

I just thought of an issue with this approach that is worth considering.

The problem is that if A sends an INVITE to B, there cannot be more m lines
in the response from B that in the request from A. THis is needed to support
matching up of m lines. Now, lets say A is a PC, and it calls some user B
that needs to use one of these transcoders. In the 200 OK, B cannot add a
separate media stream for this codec. Rather, it will have to send a regular
200 OK, and then immediately re-invite to add a media stream for that
specific codec, and remove that codec from the original media stream. Kind
of ugly, and possibly might get you glitches in the beginning of lost media.

So, whilst I agree with the idea of what you are trying to do here (a
choose-one-of-M session feature), I am concerned about its general ability
to fit within the framework of SDP, which is widely recognized as limited
for such things. 

-Jonathan R.


> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Friday, October 13, 2000 4:30 AM
> To: Culpepper, Bert
> Cc: Michael Thomas; Rohan Mahy; Jonathan Rosenberg;
> [e-mail]; Henning Schulzrinne; mmusic
> Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> 
> 
> Hi,
> 
> I will try to summarize the discussions so far:
> 
> The issue I am looking at is: "What happens when I need to receive a
> single media stream in different ports (or even different IP 
> addresses)
> depending on the codec used at any moment".
> 
> A media stream here is, for instance, the audio transmitted 
> in a regular
> telephone call.
> 
> With this issue in mind, it is good to know scenarios where this can
> happen and, of course, possible solutions.
> 
> There are multiple scenarios where we can have this situation.
> 
> -The device receiving voice is not the same as the device that handles
> DTMF tones. Thus, the media stream will have to be sent to the device
> handling voice when the RTP packets contain PCM voice (for 
> instance) and
> to the device handling DTFM tones when they carry tones.
> 
> -I need to use a transcoder because I have a cheap client 
> that does not
> support all the audio codecs in the world. I want to receive PCM in my
> IP address, but I would like to receive GSM in the IP address of the
> transcoder. The transcoder will take care of sending the 
> stream to my IP
> address once it has been transcoded.
> 
> -Cellular terminals that have to configure radio bearers with specific
> codec information because some optimizations are applied. They want to
> receive media on different ports depending on the codec used.
> 
> Folks have pointed out more scenarios where this might happen.
> 
> The first solution I thought of was to send a single RTP stream to
> different ports (or different IP addresses). As the AVT guys pointed
> out, this would cause lots of problems. Mainly related to RTCP.
> Everybody agreed that a much better solution was to establish 
> different
> RTP sessions.
> 
> If different RTP sessions are established, this issue is 
> transparent to
> RTP and RTCP. They are thus not affected.
> 
> SDP backwards compatibility was also an issue, so a solution that does
> not break existing implementations has to be found.
> 
> The fid (flow identifier) attribute I was describing in my 
> previous mail
> would just be an identifier for the flow. That is, we might 
> have several
> RTP streams, but all of them are related, because we are dealing with
> just one flow.
> 
> So, an application receiving this parameter would know that all the m
> lines in the SDP with the same fid attribute (a=fid:12, for instance)
> are related. I believe this is useful information for the application.
> 
> If an application does not understand the fid attribute, everything
> works properly. The only issue is that the application is not aware of
> this relation between m lines.
> 
> 
> Regarding Mike's question, this was already presented as 
> input for SDPng
> in the last IETF. I am now after a solution for SDP. I agree 
> that SDPng
> will solve all these issues. The quesion is: when? Everybody 
> working on
> it is currently pretty busy.
> 
> Best regards,
> 
> Gonzalo
> 
> 
> 
> "Culpepper, Bert" wrote:
> > 
> > Hi:
> > 
> > I've only followed this thread on the SIP list and read the recent
> > discussion on the AVT WG list,  I've probably missed some 
> related discussion
> > in other WGs.  It appears to me, and as Gonzalo pointed 
> out, separate RTP
> > streams are OK.  The session description below describes 
> two RTP streams
> > with only one active at any point in time (I believe the 
> semantics of the
> > fid attribute shown indicate that I can choose to send only 
> one) vs. a
> > single RTP stream with either of two encoding schemes.  
> However, as a SIP UA
> > and having received that session description I know to send the two
> > encodings separately if I want to make the other endpoint 
> happy.  (And only
> > one at a time if I support the fid attribute.)  It does 
> seem reasonable that
> > it might complicate QoS, but I expect the benefit of the 
> separate media
> > streams is justified when used.
> > 
> > Anyway, segregating media streams (where exact 
> synchronization isn't needed
> > and RTP is good enough) enables certain efficiencies when providing
> > telecommunications and like services in an IP network.  
> This is only one
> > advantage I suspect.
> > 
> > Regards,
> > Bert
> > 
> > > -----Original Message-----
> > > From: Michael Thomas [mailto:[e-mail]]
> > > Sent: Thursday, October 12, 2000 10:22 AM
> > > To: Gonzalo Camarillo
> > > Cc: Culpepper, Bert; Rohan Mahy; Jonathan Rosenberg;
> > > [e-mail]; Henning Schulzrinne; mmusic
> > > Subject: Re: [SIP] draft-camarillo-sip-sdp-00.txt
> > >
> > >
> > > Gonzalo Camarillo writes:
> > >  > I would like my session description to look like:
> > >  >
> > >  >          v=0
> > >  >          o=John 289085535 289085535 IN IP4 first.example.com
> > >  >          t=0 0
> > >  >          c=IN IP4 111.111.111.111
> > >  >          m=audio 20000 RTP/AVP 0
> > >  >          a=fid:1
> > >  >          m=audio 20002 RTP/AVP 8
> > >  >          a=fid:1
> > >  >
> > >  > If an implementation does not understand the fid 
> attribute it will try
> > >  > to mix the audio streams. Since one is "empty" all the 
> time, doing this
> > >  > is not really a big deal. Thus, backwards 
> compatibility is not a
> > >  > concern.
> > >  >
> > >  > Do you have any concerns with this approach?
> > >
> > >    The main problem I see is with the interaction with
> > >    QoS reservations. Namely, that you'd expect the receiver
> > >    to book reservations for both flows. Doing:
> > >
> > >    m=audio 20000 RTP/AVP 0 8
> > >
> > >    on the other hand only implies that you book the ceil()
> > >    of both flows.
> > >
> > >    Why is it so advantageous to segregate these into two
> > >    streams? The implicit coupling you're after seems like
> > >    it's not well handled by SDP right now, and I'd bet
> > >    that this would be better taken up as a working item
> > >    for SDPng (if not already there) because my understanding
> > >    is that explicit audio synch with video is also problematic in
> > >    SDP right now, which is sort of similar.
> > >
> > >               Mike
> > >
> 
> -- 
> Gonzalo Camarillo         Phone :  [phone]
> Oy L M Ericsson Ab        Mobile:  [phone]
> Telecom R&D               Fax   :  [phone]
> FIN-02420 Jorvas          Email :  [e-mail]
> Finland                   http://www.hut.fi/~gonzalo
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.cs.columbia.edu/~jdrosen         PHONE: [phone]
http://www.dynamicsoft.com