Subject: [rtcweb] Do we still need PRANSWER?

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Jul 2012 15:46:50 -0400

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. 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.
_____________
Roman Shpount

---

From: Chenxin <[email-masked]>
Date: Thu, 5 Jul 2012 04:00:15 +0000

+1
 I think PRANSWER is still useful for Jingle interop especially  for ICE candidate trickling.

But I think we should not leave the WebRTC-SIP interop  problem to the application layer gateway.

I find some words in chart:

 9.  The group will consider options for interworking with legacy VoIP
        equipment.

it is necessary to solve SIP interop problem in RTCWEB other than leaving it to implementor.

BR,
    Xin
From: Roman Shpount [mailto:[email-masked]]
Sent: Thursday, July 05, 2012 3:47 AM
To: [email-masked]
Subject: [rtcweb] Do we still need PRANSWER?

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. 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.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Jul 2012 10:48:53 +0200

2012/7/4 Roman Shpount <[email-masked]>:
> 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.

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.

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".

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

> The WebRTC application will work with the gateway to create new

No, sorry, no. Or yes (in your specific case), but not in mine.

Regards.

[1] http://sip-on-the-web.aliax.net/

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 5 Jul 2012 11:12:55 +0200

4 jul 2012 kl. 21:46 skrev Roman Shpount:

> 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

I think that's a bad conclusion, Roman.

I talked about the installed base of SIP devices and their RTP stack. It doesn't mean that ALL SIP implementations won't be able to interop with WebRTC and that there never will be SIP connected to webrtc, either in a browser app or in a server implementation. I do expect that new SIP apps will arise and that the current ones will be upgrading. 

SIP interop is definitely possible in WebRTC regardless of the RTP layer.

I still think there's value in interop with a large installed base of RTP-capable devices. Having media relays in the media path is known not to improve media quality.

/O

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Jul 2012 07:30:14 -0400

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.

> *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.

> (super-intelligent?), that's their assumption, but that should not be

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.

> 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.

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.

> 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.

Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Jul 2012 07:55:08 -0400

On Thu, Jul 5, 2012 at 5:12 AM, Olle E. Johansson <[email-masked]> wrote:

> > 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
> possible
> I talked about the installed base of SIP devices and their RTP stack. It
> doesn't mean that ALL SIP implementations won't be able to interop with
> WebRTC and that there never will be SIP connected to webrtc, either in a
> browser app or in a server implementation. I do expect that new SIP apps
> will arise and that the current ones will be upgrading.
>
> I still think there's value in interop with a large installed base of
> RTP-capable devices. Having media relays in the media path is known not to
> improve media quality.
>
>
If we care about interop with existing devices something needs to be done
about DTLS-SRTP and ICE.

As far as I can see DTLS-SRTP is the major problem since it overly complex.
It is probably not a problem for desktop/softphone applications that can
use something like openssl or gnu-tls with DTLS-SRTP extension, but if you
need to write this from scratch for an embedded platform, this protocol has
too many features for no good reason. We would have been better of
designing a new key negotiation mechanism that has the same qualities as
DTLS-SRTP (ie uses public/private key exchange for session keys and
protects from replay), but does not introduce the initial call setup delay
or has so many features and options. This would, obviously, still mean that
existing devices need to implement a new protocol to interop with WebRTC,
but at least it would be a simpler protocol to implement and test.

I know that the group still discusses the use of SDES-SRTP, but I do not
think it satisfies the security requirements (ie it is not secure over
HTTP, allows replay, not secure if JavaScript is compromised), so if we
care about security, it should not be allowed.

ICE on the other hand is an understandable requirement, but it is still
something that is very badly supported by existing devices. On the positive
note, it is at least claimed to be supported by some vendors, and they are
typically quicker to fix bugs then to add features.

The group is also talking about AVPF, RTP retransmissions and other RTP
extensions, that typically break interop with existing devices. I think
these extensions are fairly acceptable if some sort of media relay device
is assumed, but would need to considered very carefully if legacy interop
is needed.

I think if the group operates under assumption that vast majority of the
WebRTC calls would be between WebRTC end points, and only a small portion
with communicate with legacy devices, such as SIP or Jingle, and would
require a media gateway for it, then it should be spelled out. If interop
is a priority, or even a hard requirement, then some of the design
decisions should be different. Keep in mind, that support legacy interop
will have significant negative impact on WebRTC, since it will has to be
more complex (support more parameter negotiations, more RTP profiles, more
key exchange mechanisms), and probably less secure.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Jul 2012 14:07:01 +0200

2012/7/5 Roman Shpount <[email-masked]>:
> interoperability.

Hi Roman, I did know that you mail was more a "passionate" mail (mine also) :)

> 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.

I don't know way. If my SIP client (in browser JS) receives varios
provisional responses with SDP I can act as so many SIP devices
choosing just one of them or whatever. IMHO that's up to the
implementor.

> My main concern,
> however, is the media level interop with any existing devices.

Sure.

> older WebRTC implementation that supported plain RTP.

Well, the fact is that we just test media in browser-to-browser, which
means SRTP.

> adding features it assumes some sort of gateway would be present.

And it's really BAD that a IETF WG assumes that magic servers
(media-gateways) are required for a new *Internet* protocol to
properly interoperate with existing standard networks. And what I mean
is that, in case a SIP network and devices support ICE + DTLS+SRTP it
should be possible to direct interop (in the media plane) between
WebRTC and that SIP/Jingle network.

> SDES-SRTP support is not something that this group decided upon.

My fault, I meant "DTLS-SRTP". Note that DTLS-SRTP is *already*
specified for SIP (in some XXXX RFC I cannot remember now). The fact
that lazy vendors don't implement it (because they are happy with
their "security" based on B2BUA's and walled gardens) does not mean
that real media interop is possible once SIP vendors implement what
they MUST implement (or die).

> If the
> 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.

At least I hope that SIP vendors will be interested in media interop
once WebRTC is widely adopted.

> they are more concerned about marketing then security.

Too much business for gateways vendors here IMHO... BAD. This is an
IETF WG, not GSMA/3GPP stuff.

> 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.

Sure, 90% of existing SIP stuff could be dropped. It's the mission of
SIP vendors to build nice SIP devices with proper and modern security
features (as *already* specified for SIP !!).

Regards.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 5 Jul 2012 15:12:43 +0200

5 jul 2012 kl. 13:30 skrev Roman Shpount:

> 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.

Oh. Sorry for my total misunderstanding, Roman!

/O

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Jul 2012 08:50:00 -0700

On 5 July 2012 04:30, Roman Shpount <[email-masked]> wrote:
> 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.

PRANSWER is purely an API construct.  How does that affect
interoperability other than making it harder to write the browser code
that achieves it?

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Jul 2012 13:35:34 -0400

On Thu, Jul 5, 2012 at 11:50 AM, Martin Thomson <[email-masked]>wrote:

> significant

PRANSWER is an API construct, but it assumes that only serial proxies are
supported. This is an interop issue.
_____________
Roman Shpount