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

[Gonzalo Camarillo <[e-mail]>]

Hi Jonathan,

Jonathan Rosenberg wrote:
> 
> 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.


If A does not support the fid attribute, we are in today's situation
(what we want to avioid), and B will have to do what you describe
(re-INVITE right after the 200 OK).

If A supports the fid attribute, it will include a fid attribute for
each m line in the SDP. Upon reception of the INVITE, B knows that A
understands the fid attribute because it appears in the SDP. Then, since
both understand it, B can add as many m lines as it wishes, since the
fid attribute will be used to align the media streams (rather than nth m
lines matching). That's why the title of the draft is "SDP media
alignment in SIP".

So, this is a general mechanism not just for demultiplexing media flows
but also for performing media alignment.

Best regards,

Gonzalo

 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
> 
> _______________________________________________
> SIP mailing list
> [e-mail]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Gonzalo Camarillo         Phone :  [phone]
Oy L M Ericsson Ab        Mobile:  [phone]
Telecom R&D               Fax   :  [phone]
FIN-02420 Jorvas          Email :  [e-mail]
Finland