Re: [rtcweb] Do we still need PRANSWER?

[Roman Shpount <[e-mail]>]

This was all written out of frustration mainly by the direction taken by
this group on adding things that are not strictly necessary but break
interoperability. It is completely incomprehensible to me  why the group
decided to add PRANSWER if connection cloning is just as easy to implement
and would make, on one hand, interop easier, on another hand add
significant new functionality. When I am saying that connection cloning is
easy to implement I mean that I am willing to build a prototype based on
chromium code that implements it. Getting the new API through IETF/W3C is
above my skill level, since I am fairly bad at writing drafts.

On Thu, Jul 5, 2012 at 4:48 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> 2012/7/4 Roman Shpount <[e-mail]>:
> > It looks like WebRTC-SIP interop without an application layer gateway
> would
> > not be possible in the near future due to all the media transport
> > requirements that were introduced. Given that SIP interop is no longer
> > possible, why do we still need PRANSWER? Since an application layer
> gateway
> > must be deployed, the same gateway can handle both serial and parallel
> > forking.
>
> No please, don't decide/mandate/impose how the signaling must be
> implemented. And don't assure that pure SIP signaling cannot be used
> in the browser neither force the usage of annoying B2BUA's or
> signaling-protocol-exotic-and-buggy-gateways in order to interop with
> SIP networks (mostly because pure SIP interop is already possible
> without negative elements like B2BUA's or signaling gateways).
>
> I want a pure SIP proxy and handle parallel and serial SIP forking as
> RFC 3261 states, without magic servers breaking things. And this
> *already* works [1] so it IS possible.
>
>
I do not doubt that some SIP interop on the signaling level is possible.
It would break, however, on a first case of parallel forking. My main
concern, however, is the media level interop with any existing devices.

Correct me if I am wrong, but your already working solution is using an
older WebRTC implementation that supported plain RTP.

If most of the people assume that WebRTC-SIP interop requires some
> amateur and limited JSON based signaling protocol between the
> (stupid?) browser and a magic JSON-SIP-MEDIA gateway
> (super-intelligent?), that's their assumption, but that should not be
> mandatory by specs.
>

I do not want magic gateways either, but it looks like when this group is
adding features it assumes some sort of gateway would be present.


> About the media plance interop: ok, WebRTC has added lot of stuff, but
> AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible
> to interop in the media plane without negative intermediary elements.
> In the other side, once WebRTC is extended I'm pretty sure that SIP
> designers and vendors will try to satisfy WebRTC media requirements
> within SIP, so let's leave the door open rather than "requiring $$$$$
> B2BUA's black-death-boxes".
>
>
SDES-SRTP support is not something that this group decided upon. If the
group is honest about its security requirements (JavaScript application is
not trusted), then SDES-SRTP should not be allowed. This means you need
ICE+DTLS-SRTP+AVPF support in the SIP device to operate directly with
WebRTC on the media plane. I curious if you can name one device that
support all of those. I would actually buy one for interop alone. And from
experience, I doubt that large SIP vendors would do anything meaningful for
a while.

Please, don't limit or force the network topology.
>

I do not, but I think that what the group effectively does. I got a feeling
most of the major contributors only care about a limited sets of apps that
do not need to concern themselves with interop. I also got a feeling that
they are more concerned about marketing then security.


> > The WebRTC application will work with the gateway to create new
> > streams or to create new connections, as necessary when new SIP dialogs
> are
> > created and new answers are received.
>
> No, sorry, no. Or yes (in your specific case), but not in mine.
>
> It is, unfortunately, the only thing I can do in my case, since all the
SIP end points I am dealing with (SIP Trunks in PBXs and SIP from VoIP
vendors) do not support any encryption, have flaky support for SIP
re-Invites, and some do parallel forking. It is the real world, and here,
it is a magic box or bust.


> [1] http://sip-on-the-web.aliax.net/
>
> _____________
Roman Shpount