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.

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?

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
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip