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

[Paul Kyzivat <[e-mail]>]

Iñaki,

[Changing the subject, since it was *very* off-topic.]

I've added my comments at the end.

On 6/13/17 1:08 PM, Iñaki Baz Castillo wrote:
> 2017-06-02 20:02 GMT+02:00 Roman Shpount <[e-mail]>:
>> There was a discussion regarding the setup attribute value in subsequent
>> offers when establishing new DTLS association is not desired
> 
> Hi, I've silently read all this thread. In fact I already participated
> in this exact subject in some threads in the past (so long ago). But
> it seems that problems in SDP persist forever.
> 
> I think it's time to expel SDP from our lives, specially in WebRTC
> where we, the developers, can do media signaling much better than the
> SDP-way.
> 
> All this kinds of problems are because a full SDP blob must be
> generated and consumed by the remote party for *every* minor change in
> the multimedia session. So, if I want to add a video stream on top of
> the same ICE+DTLS transport, or if I want to pause it, or remove it,
> or whatever, I must send a full SDP and the remote peer must figure
> out whether such a SDP involves a ICE change, DTLS change, streams
> change, codecs change, etc etc. This means a "full re-inspection" of
> all the parameters (ICE, DTLS, RTP, RTCP, etc) for every SDP O/A
> renegotiation.
> 
> When SDP was about simple bidirectional audio it was just fine. But
> nowadays SDP is unsustainable.
> 
> Now we have a draft that defines a new a=tls-id attribute to avoid
> DTLS re-handshake on a SDP O/A renegotiation. That's a hack IMHO. We
> may also invent a new a=ice-id to avoid inspecting remote ICE
> ufrag/passwd/candidates every time a multimedia session change is
> desired. And also a=m-id attribute (per media section) so the receiver
> figures out whether something has changed in such a media section or
> not, etc. Ah, and we have BUNDLE so the "transport" is just defined in
> the first media section (or the first *active* one, who knows?).
> 
> 1) Transport => UDP or TCP or ICE
> 2) Security => DTLS or SRTP
> 3) Media => Parameters for independent send/recv media streams
> 
> That's all we need, nothing else: a clear layers separation so we can
> signal each layer parameters independently. Yes, that's similar to
> what ORTC provides, which is far from perfect, but it becomes much
> more comfortable to work with.
> 
> IMHO it's really sad that WebRTC 1.0 has been polluted with this
> legacy "media signaling" mechanism. WebRTC was born so many years ago
> and, in 2017 with spec 1.0.0 about to be released, we still have spec
> and implementation problems when it comes to "renegotiate" something
> in the session because the remote may attempt a new DTLS handshake...
> just LoL.
> 
> I do know that my complain is slightly off-topic given that this is
> MMUSIC, which is supposed to be 100% SDP related. But I wonder why the
> MMUSIC WG is still 100% tiled to SDP rather than just defining
> multimedia related parameters as it should (IMHO). The longer this WG
> defines multimedia stuff for just SDP, the longer the developers will
> suffer the SDP re-negotiation and its inherited "full re-inspection".

Everybody who has worked with SDP realizes that it is ill-suited to the 
tasks we use it for. Quite a long time ago there was an effort called 
SDPng that tried to define a new syntax. I wasn't involved in that, but 
it seemed like it was defining something reasonable (XML based IIRC). 
But it failed because (IIUC) nobody could see a viable migration plan to 
introduce it.

I think you are suggesting to do something new but limit its scope to 
WebRTC. Such a narrow scope would ease the migration effort. There would 
still be one but perhaps people would be willing to suffer through it.

BUT, WebRTC doesn't stand alone. Interworking with SIP is still 
important, and probably will be for a long time. Also, your description 
of what is needed is simplistic. What features (functionality, not 
syntax) of SDP O/A are not needed with WebRTC? AFAICT all the stuff that 
describes codecs is needed, and much of the rest. There is a lot of 
that, spread over many RFCs. All of that would have to be re-done.

Doing something new here may well be the right thing to do. But the 
first step is to carefully define the scope of applicability, and what 
interworking requirements there are with things outside that scope. Then 
perhaps the size of the effort can be estimated and the feasibility 
doing so assessed.

	Thanks,
	Paul