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

[Bernard Aboba <[e-mail]>]

First, let me apologize for contributing to this thread.

Just as my wife has counseled me to limit my viewing of TV news programming
to under 10 minutes a day (since more than this seems to lead to ranting
and foaming at the mouth), so too would it be in my best interest not to
contribute to this thread.

However, although I will try to keep this response brief, I simply cannot
resist.  In my defense, since it is now June, this is at least one new
year's resolution that I have kept for half a year, rather than the
customary three weeks.   And yes, I listened to Jim Comey's testimony last
week and Jeff Session's today, both for more than 10 minutes.

I will however, attempt to heed Tim Cook's recent advice to MIT graduates
(see:
https://www.washingtonpost.com/national/higher-education/apple-ceo-tim-cook-to-address-2017-graduates-at-mit/2017/06/09/ee763ac8-4ccb-11e7-987c-42ab5745db2e_story.html?utm_term=.676972454c80
)

"Don't listen to trolls, and don't become one."

Overall, my observation is that applications utilizing the RTCWEB protocol
stack that require interoperability with other SIP implementations tend to
utilize an "SDP adapter" (along the lines of adapter.js) that functions
much like an "in-application SBC", so as to ensure SDP interoperability.
However, those applications only requiring interoperability with versions
of the same application running on other platforms (e.g. an application
building on iOS, Android, Mac OS X and UWP) generally do not need an SDP
adapter.  Sometimes this is because they utilize JSON signaling and
therefore do not use SIP/SDP signaling at all, and sometimes it is because
their builds on all platforms utilize the same SDP dialect (typically the
dialect utilized in the webrtc.org implementation).

Within each of the categories described above, there are applications
written to a native WebRTC 1.0 API, applications written to a "shimmed"
WebRTC 1.0 API running over ORTC, and ORTC native applications.  This is
because ORTC is not so much an API as a "micro-kernel" approach to realtime
communications.

That is, just as one can use a micro-kernel to support multiple upper layer
sub-systems (e.g. Posix, Win32, etc.), using ORTC it is possible to support
multiple signaling approaches (e.g. SIP, H.323, JSON, etc.) on top of the
same core media library.

This is perhaps demonstrated most clearly in the ORTC Lib implementation
(see https://github.com/ortclib), which provides both access to ORTC as
well as the WebRTC 1.0 API, and could, I believe be used to provide support
for H.323, although so far noone has contributed an implementation of that.

However, while I have seen many different applications utilizing the RTCWEB
protocol stack with different interoperability requirements, 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.

If you are developing a basic realtime application that needs to provide
interoperable A/V with a different realtime application (either on the same
platform, or a different one), so far my experience has been that SIP/SDP
works well enough.  And where it doesn't work well enough (such as in
advanced video conferencing scenarios involving multi-stream, simulcast,
SVC, VR/AR, etc.) the odds are that interoperability between distinct
applications is not required, in which case a non-SIP/SDP signaling
approach can be utilized.

So with respect to the need to standardize a non-SDP signaling mechanism,
my view is "Don't bother, be happy."

Gotta go.  My 10 minutes are up.








On Tue, Jun 13, 2017 at 2:45 PM, Iñaki Baz Castillo <[e-mail]> wrote:

> 2017-06-13 22:33 GMT+02:00 Paul Kyzivat <[e-mail]>:
> > 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
> <[e-mail]>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>