> In addition, if an SDP offer contains multiple streams (one RTP/AVP and > one RTP/SAVP) those are actually *separate* streams, not alternate > offers for the same stream. > > As far as I know, the only RFC-compliant way to offer both RTP/AVP and > RTP/SAVP for the same media stream is through SDP capability negotiation. >
But there is no way to correlate those streams, you can't know the one containing RTP/AVP matches the one containing RTP/SAVP and that they are interchangeable. A weird example: a SIP based video streaming server that offers a video stream and 2 audio streams for a movie. One of the streams is in english and not encrypted and the other audio stream is in spanish and encrypted. If you choose the encrypted one you'd hear the movie in spanish, which you may not want to :-) Even if its not 100% standard RTP/AVP transport with a=crypto is widely used and sometimes referred to as 'optional' and RTP/SAVP with a=crypto referred to as 'mandatory'. -- /Saúl http://saghul.net | http://sipdoc.net _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
