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

["Culpepper, Bert" <[e-mail]>]

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
>