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

[Gonzalo Camarillo <[e-mail]>]

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