Re: [SIP] Deleting Media Streams section in rfc2543bis

["Brett Tate" <[e-mail]>]

----- Original Message -----
From: Igor Slepchin <[e-mail]>
To: Henning Schulzrinne <[e-mail]>
Cc: Brett Tate <[e-mail]>; SIPbell-labs <[e-mail]>
Sent: Friday, July 07, 2000 2:13 PM
Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis


> The problem with replacing SDP is that the replacement is impossible to
> detect generally. Say, I want to replace one media steam with another
> one with the same set of codecs. There is no way to do this unless you
> can match media lines in the new and old media descriptions. Mandating
> the order is one way to do this and that's how it is supposed to be done
> according to the RFC.

What's wrong with allowing a re-INVITE with a
new "o=" (or maybe the same "o=") to indicate
that all previous SDP
information is obsolete?  I think that this would
greatly increase the flexibility of 3rd party call
controllers.  It would also make it easier to attach
a SIP stack to end points which already generate
complete non-SIP specific SDPs.  It also
reduces the overhead of having to continually
store and pass around "m=" lines with 0 ports in
re-INVITEs.

>
> Generally, I see no harm caused by including "m=" lines with 0 ports. It
> is probably OK to be forgiving about receiving SDP with missing media
> lines if there is no ambiguity, but it is _not_ OK to generate such
> SDPs. In the example Henning cited, what happens if the callee later
> issues a re-INVITE with
>
> m=audio 8888 ...
> m=video 4444 ...
>
> Did the callee accept the original media stream or offered a new one?
> Besides, this clearly wouldn't work if all m= lines specified audio. So
> why create special cases if everything is already handled by the generic
> rules?

I can see potential uses for adding the "m=" lines
with 0 ports within 200 responses or "Delayed Media"
ACKs; however I'm not sure the benefits outweigh the
restriction of forcing the use of a "SIP specific" SDP.

What are the benefits of using the "m=" with port 0 in
a re-INVITE?

>
> Using the stream labeling was proposed on this list before and it works
> but gives no clear advantages I can think of. Besides, to be backwards
> compatible (i.e., if one of the parties doesn't support the extension)
> you have to be able to go back to the current algorithm so every
> implementation would need to support both anyway.
>
> BTW, note that draft-camarillo-sip-sdp-00.txt doesn't really solve the
> problem it poses, namely splitting the same media stream across multiple
> destination ports based on the codec type. SDP is the least of the
> problems here. The real issue is that doing this split will break RTP:
> real-time characteristics of RTP are almost lost since now there is now
> way to detect (and recover from) packet loss, hence there is no good way
> to adapt playout buffers; RTCP is broken so there is no way to
> dynamically adapt to changing network conditions, and, finally, no
> compliant RTP library will allow you change destination of the RTP
> stream by changing the payload type of RTP packets. All of this was
> discussed on the list, and the draft (somewhat surprisingly to me)
> references that discussion.
>
> Thank you,
> Igor Slepchin
>
>
> Henning Schulzrinne wrote:
> > <...>
> > Realistically, we can't expect that
> >
> > m=audio 4321 ...
> > m=video 5678 ...
> >
> > will be answered by
> >
> > m=audio 8888 ...
> > m=video 0
> >
> > I suspect most implementations simply reply
> >
> > m=audio 8888
> >
> > if they can't do video.
> >
>
>
> _______________________________________________
> SIP mailing list
> [e-mail]
> http://lists.bell-labs.com/mailman/listinfo/sip
>



_______________________________________________
SIP mailing list
[e-mail]
http://lists.bell-labs.com/mailman/listinfo/sip