Re: [MMUSIC] it's time to expel SDP from our lives

[Iñaki Baz Castillo <[e-mail]>]

2017-06-14 1:32 GMT+02:00 Bernard Aboba <[e-mail]>:
> 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
<[e-mail]>