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

2017-06-13 22:33 GMT+02:00 Paul Kyzivat <[email protected]>:
> 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.

Hi Paul,

I'm not asking for a SDP 2.0 in JSON/XML or any other format. In your
text above, you state that "all the stuff that describes codecs is
needed, and much of the rest", and I don't agree with that:

ORTC has proven to provide the *same* functionality as SDP, but
without imposing the exchange of a full SDP blob/string. Yes, codec
parameters must be exchanged between peers, but that does not mean
that a SDP (or similar format) is required. Instead, in ORTC, it's up
to the application/developer to decide how to signal parameters
between the endpoints of a multimedia session. In ORTC an endpoint can
signal ICE parameters, DTLS parameters, RTP parameters, and other
parameters in an independent way (so, if for example a new video
stream is added, there is no need to signal all the ICE/DTLS stuff to
the remote party again, but just the RTP parameters related to the new
stream). This design prevents issues such as the "SDP DTLS role
conflict" described in the previous email thread.

You say "There is a lot of that, spread over many RFCs".

And that's true, but ORTC specification [*] collects many of those
parameters and re-uses them within their own Dictionaries about ICE,
DTLS, RTP, RTCP, etc. It's true that there are tons of RFC's that
define multimedia parameters assuming SDP syntax, but IMHO the SDP-ish
is just a minor component in those specifications, nothing too hard to
circumvent IHMO (in fact, ORTC did it).


>  I think you are suggesting to do something new but limit its scope to WebRTC

Not exactly. Continue reading, please.


> WebRTC doesn't stand alone. Interworking with SIP is still important

Sure, and I understand that SIP indeed requires a wire-signaling
format/syntax because SIP requires interoperability between different
devices in both, the signaling and media, planes. But IMHO that does
not justify the fact that all the multimedia related specifications
are tiled to just SDP. SDP should not be the minimum irreducible unit
for exchanging multimedia information, and ORTC is a good example of
the opposite.

What I would expect nowadays from the MMUSIC WG is to define
multimedia parameters (including different *layers" such as transport,
security/encryption, RTP, RTCP, etc) rather than a single format(SDP)
to cover them all. Having that, WebRTC could perfectly drop SDP and
define some proper Dictionaries (as ORTC) pointing to those parameters
defined by MMUSIC so WebRTC developers are done and free to exchange
data as they wish. And when it comes to SIP, of course the SIP
protocol needs a "multimedia format". A separate WG or a different
task within MMUSIC could be responsible of producing an standardized
"multimedia format" for SIP with those parameters, let it be SDP or
SDP 2.0.

Anyhow, if so many things within the SDP are so problematic for
WebRTC, they will also be problematic for SIP (once SIP devices
implement so many advanced features such as those in WebRTC devices),
so still I consider that sending a full SDP to just renegotiate a new
codec (or remove a specific video stream) will produce real problems
as we suffer in WebRTC. But again, this is a separate concern that
should just affect to SIP devices (because SIP chose to go with SDP),
and not to WebRTC.


Thanks a lot for your response, regards.



[*] http://draft.ortc.org/


-- 
Iñaki Baz Castillo
<[email protected]>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic