Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

[Roman Shpount <[e-mail]>]

On Fri, Jun 21, 2013 at 6:19 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> Is there anyone not involved in SIP/PSTN business which feels
> comfortable with the SDP-based specs of WebRTC?
>

I am involved with SIP/PSTN and I am not comfortable with current WebRTC.

What is trivial to implement is a server based gateway that will terminate
and transcode media and signaling connection from WebRTC and connect WebRTC
to anything. For this you take the open source code which implements WebRTC
in Chrome, put it in your server and put a real SIP stack/media engine on
the other side. This way all the SDP negotiation and media decoding is done
using the same code as in the browser, and SIP/SDP negotiation on the
SIP/PSTN side is done using normal SIP stack. By normal SIP stack I mean
something that has been used with PSTN for significant period of time and
has all the interop issues resolved, and all the necessary configuration
parameters needed to work with SIP network implemented. Issues like hold do
not matter, since they are handled on the SIP side and not passed to WebRTC
side at all. Codec support, DTLS, ICE do not matter since they are handled
by the WebRTC engine in the server. If this is what you want you have
achieved your goal, but this is not a standard. There is no guarantee that
this will work in 5 years or even in 6 month, since SDP produced by WebRTC
can change. There is no guarantee that this will work with all the WebRTC
implementations, since the standard is loose enough that significant things
can be different while still being standard compliant. Finally, and most
importantly, this will not work if you want to pass SDP and media produced
by WebRTC to the outside world without transcoding it.

P.S. Not to offend anybody, but if you create a system any idiot can use,
only idiots will.
_____________
Roman Shpount