Subject: [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

From: Xavier Marjou <[email-masked]>
Date: Wed, 9 Feb 2011 10:06:35 +0100

Hi,

We have posted a draft about interworking requirements between RTC-Web and
SIP-RTP.
http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt

Cheers,
Xavier and Jean-François

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 09 Feb 2011 11:36:45 -0600

GENERIC-REQ-1  The [RTC-Web] solution MUST be designed in a such way
                  it allows interworking with SIP-RTP applications both
                  at the signalling and media level.

Please help me understand how this and the other requirements do not cripple
the whole concept of the RTC-Web (innovation based on simplicity and
flexibility) by making it just another extension of legacy telecom design?

Or did the authors mean requirements for gateways only?

Thanks, Henry

On 2/9/11 3:06 AM, "Xavier Marjou" <[email-masked]> wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: David Singer <[email-masked]>
Date: Wed, 9 Feb 2011 10:00:46 -0800

well, reading it on its face, as long as we have an architecture which one *can* instantiate a component for the signalling that does SIP and a component for media-transfer that does RTP, and so on, this requirement is met.  And I would have thought that yes, we would agree the architecture should make that possible.

whether we choose those components as a baseline set to implement is much more a debate, I'd say.

On Feb 9, 2011, at 9:36 , Henry Sinnreich wrote:

> Please help me understand how this and the other requirements do not cripple the whole concept of the RTC-Web (innovation based on simplicity and flexibility) by making it just another extension of legacy telecom design?
> 
>> We have posted a draft about interworking requirements between RTC-Web and SIP-RTP.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 9 Feb 2011 20:26:28 +0100

Hi,

Hi Henry,

These requirements certainly do not want to cripple innovation (RTC-Web).
They rather want to catch attention so that RTC-Web is designed in a way it
can also work with existing SIP-RTP devices.

Cheers,
Xavier

On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich
<[email-masked]>wrote:

> Please help me understand how this and the other requirements do not
> cripple the whole concept of the RTC-Web (innovation based on simplicity and
> ------------------------------
> RTC-Web mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 19:52:29 +0000

Hi Xavier and Jean-Francois,

Thanks for putting this together.

Based on the recent list discussion, I would say that quite many people are leaning towards the architecture you depict in Section 5.2, Figure 2: The session setup protocol is an application specific Javascript implementation transported over HTTP or WebSocket, while media is running on standard RTP supported by the browser.

In that model we can't put many requirements on the session setup protocol or its interworking with SIP. If the service provider needs SIP interoperability (to connect to PSTN, to other service providers or SIP phones), it is indeed THEIR burden to make sure they use something that has a clean mapping to SIP - for instance, that they can do things like call hold. On the other hand if the service provider is not interested in SIP interoperability, they do not have to worry about that.  In the IETF there are probably two ways to address this interworking: a) do nothing and leave it completely to the implementers and service providers, or b) define some kind of a SIP/BOSH/HTTP or SIP/WebSocket mapping in the same way that the XMPP folks have done. The XMPP/BOSH spec does have implementations both on the client/Javascript side as well as on the server side, so I think that spec has had some value. (At least in a way that the Javascript library and the BOSH servers can be implemented somewhat independently.)

The RTP/media stack on the other hand is definitely in the scope of the IETF effort. I think we should standardize the RTP use in the browsers and that would be one step towards interop with SIP phones. The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC). DTMF transport capability may also be relevant interop requirement.

I think these are the key issues we should consider wrt. SIP phone interop.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Xavier Marjou
Sent: 09 February, 2011 11:07
To: DISPATCH list
Cc: [email-masked]; Jean-François Jestin
Subject: [RTW] [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

Hi,

Cheers,
Xavier and Jean-François

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Feb 2011 14:07:07 -0600

On 2/9/11 13:52, Feb 9, [email-masked] wrote:
> The RTP/media stack on the other hand is definitely in the scope of 
> the IETF effort. I think we should standardize the RTP use in the 
> browsers and that would be one step towards interop with SIP phones. 
> The critical thing seems to be the STUN connectivity check or media 
> authorization part. If we mandate browsers to get that exchange done 
> before they are allowed to generate any RTP packets on behalf of the 
> application, this will ruin the possibility of interop with 99% of 
> existing SIP clients (without some kind of an SBC). DTMF transport 
> capability may also be relevant interop requirement.

+1.

Also, it would be incorrect to characterize RTP as being solely for the 
benefit of SIP. Several other protocol -- both published and proprietary 
-- make use of RTP; Jingle comes to mind, as do the proprietary 
protocols used by various IP PBX vendors.

If we decide to go down an "RTP but with special sauce" or "not quite 
RTP" path, we lose a lot of potential functionality.

/a

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 9 Feb 2011 15:15:42 -0500

I also agree with the "make RTP just work" - signal where and how you want.. 

Sorry if I am being dense here - do we not need ICE connectivity checks to finish before RTP can be sent? Or is the point that this will take too long to get into browser code and that ICE in Javascript with STUN in the browser gets rolled out faster?

Peter Musgrave

On 2011-02-09, at 3:07 PM, Adam Roach wrote:

>> The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC)

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 21:05:58 +0000

Hi Peter,

I hope I'm answering the right question:

I think something like the STUN connectivity check or authorization is required to be implemented in the browser to prevent the Javascript application from sending RTP or some other UDP data to any arbitrary IP addresses and port. If the browser only allows the sending after a successful connectivity check it can ensure (to some extent) that the other peer also actually wants to receive this traffic. That code needs to reside in the browser so that the browser can act as the gatekeeper.

Markus

From: ext Peter Musgrave [mailto:[email-masked]]
Sent: 09 February, 2011 22:16
To: Adam Roach
Cc: Isomaki Markus (Nokia-CIC/Espoo); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

Peter Musgrave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Feb 2011 17:09:19 -0500

I don't think the picture in 5.2 is quite right either:

Architecture with HTTP in the browser:

     -----------------                            -----------------
    |     RTC-Web     |                          |     SIP-RTP     |
    |   application   |                          |   application   |
    |-----------------|                          |                 |
    |rtcweb    rtcweb |                          |                 |
    | sig      media  |                          |                 |
    | APIs     APIs   |                          |                 |
    |   | XXX     |   |                          |                 |
    |---|---------|---|   XXX                    |                 |
    | --|--       |   |   over  --------         | -----           |
    ||HTTP |      |   |<-HTTP->|HTTP|SIP|<-SIP-->|| SIP |          |
    ||stack|      |   |        |   GW   |        ||stack|          |
    | -----       |   |         --------         | -----           |
    |           --|-- |                          |           ----- |
    |          | RTP ||<----------RTP----------->|          | RTP ||
    |          |stack||                          |          |stack||
    |           ----- |                          |           ----- |
     -----------------                            -----------------

                                  Figure 2

It explicitly calls out "rtcweb sig APIs" as something that exists in 
the browser as an API distinct from traditional AJAX techniques for 
communicating with the server (e.g., XMLHttpRequest). I dont think there 
is anything called an "rtcweb sig API" in the browser; the API is at the 
discretion of the application and does not need anything new.

Thanks,
Jonathan R.

On 2/9/2011 2:52 PM, [email-masked] wrote:
> Based on the recent list discussion, I would say that quite many people
> are leaning towards the architecture you depict in Section 5.2, Figure
> 2: The session setup protocol is an application specific Javascript
> implementation transported over HTTP or WebSocket, while media is
> running on standard RTP supported by the browser.
>
> In that model we can’t put many requirements on the session setup
> protocol or its interworking with SIP. If the service provider needs SIP
> interoperability (to connect to PSTN, to other service providers or SIP
> phones), it is indeed THEIR burden to make sure they use something that
> has a clean mapping to SIP – for instance, that they can do things like
> call hold. On the other hand if the service provider is not interested
> in SIP interoperability, they do not have to worry about that.  In the
> IETF there are probably two ways to address this interworking: a) do
> nothing and leave it completely to the implementers and service
> providers, or b) define some kind of a SIP/BOSH/HTTP or SIP/WebSocket
> mapping in the same way that the XMPP folks have done. The XMPP/BOSH
> spec does have implementations both on the client/Javascript side as
> well as on the server side, so I think that spec has had some value. (At
> least in a way that the Javascript library and the BOSH servers can be
> implemented somewhat independently.)
>
> The RTP/media stack on the other hand is definitely in the scope of the
> IETF effort. I think we should standardize the RTP use in the browsers
> and that would be one step towards interop with SIP phones. The critical
> thing seems to be the STUN connectivity check or media authorization
> part. If we mandate browsers to get that exchange done before they are
> allowed to generate any RTP packets on behalf of the application, this
> will ruin the possibility of interop with 99% of existing SIP clients
> (without some kind of an SBC). DTMF transport capability may also be
> relevant interop requirement.
>
> *From:[email-masked]
> [mailto:[email-masked]] *On Behalf Of *ext Xavier Marjou
> *Sent:* 09 February, 2011 11:07
> *To:* DISPATCH list
> *Cc:* [email-masked]; Jean-François Jestin
> *Subject:* [RTW] [dispatch] RTC-Web I-D about interworking between
> RTC-Web and SIP-RTP
>
> Hi,
>

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 9 Feb 2011 22:42:01 +0000

Hi Xavier, folks,
 Forgive the dense question, but ... why?
If one wants to gateway, fine.
However, this seems to imply that *all* implementations will interwork with SIP, RTP, ...
Was that intended?

all the best,
  Lawrence
[who has been here before :]

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Feb 2011 17:13:36 -0600

I think the intention here is that we don't make decisions that 
*preclude* reasonable interoperation with legacy SIP systems. No 
specific implementation will need to interoperate with anything it 
doesn't need to, of course.

Unfortunately, it's almost a non-requirement, because everything can be 
forced to interoperate with everything else at some level (in a worst 
case, by laying a microphone for one system next to a speaker for the 
other, pointing a camera at the screen, etc.). I believe we're trying to 
convey a principle of "least impedance mismatch" between the parts we 
standardize in the IETF and the already-established mechanisms for SIP.

For example: Specifying the use of stock RTP over UDP would be a perfect 
match. Using RTP with a hard requirement for STUN would be less of a 
match, since it would preclude direct media streams with most deployed 
terminals. Sending media over HTTP would be a complete mismatch, since 
it would be unable to send media directly to any existing deployed 
terminals. So this principle would point towards using stock RTP.

I think the problem we're running into here is that it's tricky to 
convey principles in requirements language. Perhaps we need to add a 
"guiding principles" section to the document that sums up these kind of 
difficult-to-quantify qualitative goals.

/a

---

From: Göran Eriksson AP <[email-masked]>
Date: Thu, 10 Feb 2011 00:33:35 +0100

+1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: den 10 februari 2011 00:14
To: Lawrence Conroy
Cc: DISPATCH list
Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

I think the intention here is that we don't make decisions that
*preclude* reasonable interoperation with legacy SIP systems. No specific implementation will need to interoperate with anything it doesn't need to, of course.

Unfortunately, it's almost a non-requirement, because everything can be forced to interoperate with everything else at some level (in a worst case, by laying a microphone for one system next to a speaker for the other, pointing a camera at the screen, etc.). I believe we're trying to convey a principle of "least impedance mismatch" between the parts we standardize in the IETF and the already-established mechanisms for SIP.

For example: Specifying the use of stock RTP over UDP would be a perfect match. Using RTP with a hard requirement for STUN would be less of a match, since it would preclude direct media streams with most deployed terminals. Sending media over HTTP would be a complete mismatch, since it would be unable to send media directly to any existing deployed terminals. So this principle would point towards using stock RTP.

I think the problem we're running into here is that it's tricky to convey principles in requirements language. Perhaps we need to add a "guiding principles" section to the document that sums up these kind of difficult-to-quantify qualitative goals.

/a

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 09 Feb 2011 19:48:28 -0600

Hi Adam,

> Sending media over HTTP would be a complete mismatch, since

Your comment adds clarity to the fundamental difference of opinions here:

http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00
says:

   The last few years have also seen a new platform rise for deployment
   of services: The browser-embedded application, or "Web application".
   It turns out that as long as the browser platform has the necessary
   interfaces, it is possible to deliver almost any kind of service on
   it.

So the objective is either
A. To enable the browser as the key communication platform, or
B. Existing deployed terminals, I suppose you mean SIP phones and SIP UAs

The protocol design decisions are naturally very different or even quite
opposite. 

Since it is hard to imagine a SIP phone or SIP UA having a similar infinite
rich application potential as the browser has, the choice seems obvious.

We will probably not agree on (A) making the browser the protocol design
focus and not the (B) existing SIP UA, but is this the core of the
disagreement?

Thanks, Henry

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Feb 2011 09:27:42 +0100

I agree with what Adam says here. We need a way of enabling browser-based RTC applications while at the same time making it reasonable for those browser-based applications that so choose to interoperate with conventional SIP/RTP entities. By reasonable, I mean without undue complexity, cost or performance hit. SIP does not seem to be an issue, because that can be left as a choice for those applications wanting to work with the outside world. I get the feeling RTP is not such an issue, because a lot of people seem happy that the browser support conventional RTP. The big issues seem to be STUN and codec support.

STUN is not implemented on the vast majority of SIP endpoints, so we need to look at solutions to this: using an SBC to mediate between the STUN and SBC worlds, or using the return RTP stream as evidence when working with conventional endpoints, have already been suggested.

Concerning codecs, although transcoding can be used, this is highly undesirable for reasons others have already stated. For audio codecs, it is probably not a big issue to put G.711 in the browser. Video codecs are more of a challenge.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 09 February 2011 23:14
> To: Lawrence Conroy
> Cc: DISPATCH list

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 10 Feb 2011 08:12:00 -0600

If you include both a media gateway as well as a signaling gateway, then
there should be no barrier.

The question here devolves to whether you want any universality at one
level or another, 
or just bunches of proprietary islands connected by full gateways.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henry Sinnreich
Sent: Wednesday, February 09, 2011 8:48 PM
To: Adam Roach; Lawrence Conroy
Cc: DISPATCH list
Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between
RTC-Web and SIP-RTP

Hi Adam,

> terminals. So this principle would point towards using stock RTP.

Your comment adds clarity to the fundamental difference of opinions
here:

So the objective is either
A. To enable the browser as the key communication platform, or
B. Existing deployed terminals, I suppose you mean SIP phones and SIP
UAs

Since it is hard to imagine a SIP phone or SIP UA having a similar
infinite
rich application potential as the browser has, the choice seems obvious.

Thanks, Henry

On 2/9/11 5:13 PM, "Adam Roach" <[email-masked]> wrote:

>> However, this seems to imply that *all* implementations will
interwork with
>> SIP, RTP, ...
>>>> cripple the whole concept of the RTC-Web (innovation based on
simplicity
>>>> and

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Feb 2011 09:40:05 -0600

>     interfaces, it is possible to deliver almost any kind of service on

If you think what I said and what Harald says in that passage are at 
odds, then you're misunderstanding one of us.

I agree with the general principle that this effort is best served by 
designing an infrastructure to support browser-embedded applications.

That doesn't mean that we need to throw away all the work that's been 
done in the AVT working group over the past couple of decades.

Are you really advocating that we say real-time-multimedia over HTTP/TCP 
with a same-origin policy is good enough, and that we don't need to 
specify anything better tailored for realtime media?

/a

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 10 Feb 2011 15:06:38 -0600

Hi Adam, folks,

>odds, then you're misunderstanding one of us.

Thanks for clarifying and I am happy it is only my mistake.

>designing an infrastructure to support browser-embedded applications.

Do you mean a Web application infrastructure and not another VoIP-like
network infrastructure? If so, this is another good agreed point to check
off.

>done in the AVT working group over the past couple of decades.

Correct. The AVT work has generated world wide accepted standards that are a
reason of legitimate pride.
However, other technologies have emerged since that matter just as much:

* Skype for p2p and especially relevant here for using UDP without any RTP
or SDP. Fully effective NAT traversal. Superior codecs, security, etc.
Yes, Skype is proprietary (though reasonably well understood), but we can
learn from what Skype DID NOT DO.

* Streaming HTTP instead of RTP, such as in
http://tools.ietf.org/html/draft-pantos-http-live-streaming-01
While RTC require lower delay, say 150ms, the technique can be adjusted to
work for nearby media servers, say inside ISP domains, as CDN do.
For remote media servers, existing CDN/HTTP technologies are relevant.
Both the above require TCP as you mention and for this, the 3rd ingredient
may be an even better solution:

* HIP for NAT traversal, secure UDP inside VPN-like tunnels, IPv6
transition, mobility and multihoming.
http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09

* Allow/encourage the deployment of proprietary endpoints as Jonathan
Rosenberg mentions (did I understand right?), such as Flash and Silverlight;
virtual machines (VM) that justifiably benefit from the e2e principle and
from the RIA/Web architecture. Such proprietary VM and other apps will
naturally always be ahead of standards and may not be standardized ever,
though many parts are often offered as OS SW.

>specify anything better tailored for realtime media?

HTTP/TCP is certainly not good enough, but a combination of the above will
definitely meet all possible requirements we know about at present.
Even more important, such a solution fully meets the criteria of freedom to
innovate and to have flexibility.

Last but not least, hastily word processed standards have been shown to come
to a just a as speedy end. Consensus and process is no substitute for
engineering and experimenting.
Putting this together in a meaningful way requires experimenting first and
writing standards second. That's where the IRG comes in, jointly with vendor
labs interested to advance this work.
My two cents.

Thanks for the excellent focus,

Henry