Subject: Re: [rtcweb] Text communication in RTCWEB sessions - benefits of specific standardization

From: <[email-masked]>
Date: Fri, 7 Dec 2012 11:08:08 +0000

Hi Gunnar, Cullen, 

It would indeed be very good to get a crisp understanding about the concrete benefits of the _additional_ RTT related standardization. Gunnar has a few points below which seem to be on the right level. Perhaps a very short draft that summarizes the benefits and the new requirements stemming from them would be a good way to progress this.

A couple of comments below based on my understanding. 

Gunnar Hellström wrote:
>
>[...]  for the gateway application it can likely be done without
>standardization, when the gateway implementation is also managing the web
>page used for the UI.

Yes, as long as everything happens within one "server" or "domain", a proprietary protocol over the data channel should work fine. And as long as the gateway to any external system (SIP, XMPP, ...) is fully under the control of that "domain", the gateway could do the mapping without further standardization. 

>
>The need for standardization comes in for the following cases:
>a. When you from the same UI want to have a SIP call at one moment, and a
>WebRTC call to another user of another browser and web server at another
>moment.
>

I guess this is still doable (withoug additional standards) as long as you fully control the gateway to SIP? I mean, just define your prorietary data channel RTT protocol and use it directly between browsers or from the browser to the SIP gateway.  

>b. When you want to separate the management and development of the
>gateway from the web pages and web servers.
>

This is definitely a valid point. If there was a "WebRTC RTT protocol", people could build generic gateways for it. 

>c. When you want to encourage development of the smartest web page for
>RTT communication that can fit into any server environment and have
>communication with other web pages used in that or other environments.
>
 
Not sure if that is what is meant here, but the main benefit of any standard "media" protocol/format in WebRTC - be it on top of RTP or data channel - is that in principle you can run it end-to-end (browser-to-browser) inter-domain. If two domains used differnet proprietary "RTT" protocols on top of the data channel, they would need to gateway between them. However, if they use the same protocol, they only gateway "signaling" but that data channel (or RTP) could run end-to-end.

Markus

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 07 Dec 2012 15:01:26 +0100

> A couple of comments below based on my understanding.
Markus,

Yes, it seems that a draft would be needed now to get everything collected.

Some simple pictures seem to be needed so that the use cases are clear.
e.g. I meant case a) to be inter-domain for the rtcweb call.
(a. When you from the same UI want to have a SIP call at one moment, and 
a WebRTC call to another user of another browser and web server at 
another moment.)

etc.

Gunnar

---

From: Adam Roach <[email-masked]>
Date: Fri, 07 Dec 2012 08:26:02 -0600

On 12/7/12 05:08, [email-masked] wrote:
> [T]he main benefit of any standard "media" protocol/format in WebRTC - be it on top of RTP or data channel - is that in principle you can run it end-to-end (browser-to-browser) inter-domain. If two domains used differnet proprietary "RTT" protocols on top of the data channel, they would need to gateway between them. However, if they use the same protocol, they only gateway "signaling" but that data channel (or RTP) could run end-to-end.

That's exactly what Randell has been proposing: defining how to send RTT 
over the data channel in a consistent fashion so that it can travel 
interdomain. This would also facilitate the "generic gateway" usecase 
you talk about.

/a