Re: it's time to expel SDP from our lives
Iñaki Baz Castillo <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CALiegfmmSWHrseqf14Y4pMMX0B9ymY8_XdG3WR5thqSwfhUWKw@mail.gmail.com> |
2017-06-14 1:32 GMT+02:00 Bernard Aboba <[email protected]>: > sometimes it is because their builds on all platforms utilize the same SDP dialect (typically the dialect utilized in the webrtc.org implementation). > [...] > one thing I have not so far encountered is an a situation where there has > been a need for standardizing a non-SDP signaling mechanism. Just an observation about this: at least in WebRTC land, one cannot just decide whether to use SDP or not, he just needs to use it (the browser generates SDP blobs and consumes SDP blobs) but the fact is that, in complex scenarios others than P2P audio/video calls (for example SFUs), current vendors are doing very funny things that makes me worry about how the adoption of SDP in WebRTC is: I've seen that some SFU vendors (and their corresponding client's logic) just use SDP for the initial "connection" between clients and the SFU server. Usually there is just a single in-the-wire SDP O/A in which ICE and DTLS parameters are exchanged, so the transport is established. Some vendors also include some hardcoded m= sections with various hardcoded SSRCs for audio and video which don't represent a real remote audio/video, but a future one. Then, when a real participant joins the same conference, the SFU signals it out-of-band to all the others, and rewrite RTP packets (SSRC, PT, etc) from the new participant to satisfy one of the already hardcoded SSRC values in the already negotiated SDP O/A. When a participant leaves, or pauses his video, etc, that's not signaled via the SDP mechanism but out-of-band. Some other SFUs scenarios send out-of-band info to participants and those locally mangle the remote SDP (for example, to include a new SSRC or m= section) but there is no a real SDP exchange from endpoint to endpoint. So, IMHO this clearly shows the "hardcoded" way in which current complex WebRTC scenarios make use of the SDP mechanism to make the browser's SDP engine happy while still avoiding SDP renegotiation and SDP signaling features as much as possible. Said in other words: people try to avoid SDP and its semantics as much as possible. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic