[RTW] [dispatch] The charter formerly know as RTC-WEB take 3

[Markus.Isomaki at nokia.com]

Hi,

Adam Roach wrote:
>
>On 1/26/11 8:04 PM, Cullen Jennings wrote:
>> Perhaps the charter should explicitly say this but that is why it
>seems so mute on this topic, it is.
>
>I would imagine something along these lines would put the topic to rest:
>"The selection, design and/or extension of a protocol or protocols for
>establishing and controlling media sessions is in scope for the working
>group."
>
>I think it's a lot better than remaining silent on the topic, since it
>leaves several avenues open to the working group. We really don't want
>to get part of the way down this path with people under the
>misimpression that we *must* design a new protocol, or that we *must*
>select an existing protocol. I think we should do whichever of these
>makes the most sense after a careful analysis, and that such analysis is
>best performed by the working group (not in DISPATCH).
>

I think the question at this point is that what aspects of the media session establishment and control *need* to be standardized. Some people think that we have to either pick a concrete protocol like SIP/SDP or XMPP/Jingle or design something new but similar on top of HTTP or WebSocket. Other people seem to think that most of this should actually be outside the scope of the charter, and it is enough that we just standardize the media transport related "enablers" within the browser. Each application/service could then pick/design its own method of establishing the media sessions, on top of HTTP or WebSocket. 

The first option (choose/design a single common protocol) would have at least four main advantages:
1. There would be no need to re-invent it for each service
2. Inter-service/domain interoperability would be more straightforward
3. Interconnect to SIP/PSTN/Jingle services would be more straightforward
4. The service provider could buy/download and use an existing SIP or XMPP server

(The concrete problem with SIP would be, as we are aware of, that it would not suffice to just declare that we use SIP, but we would have to do a lot of profiling within SIP/SDP itself to ensure enough interoperability. I believe Jingle is more monolithic and easier to handle in this sense.)

The more liberal approach (let anyone do their own protocol) would probably be easier to get done in IETF, and would still allow service providers to get their services working across browsers. The need for reinventing a protocol for each service could perhaps be mitigated by reusing JavaScript libraries (a la Comet stuff today). Inter-domain/service interop would happen via SIP/XMPP gateways (but end-to-end media could be a challenge). What I worry a bit in this approach is that it might mean that only big/resourceful service providers who know a lot about the technical stuff could build services, while the ones with perhaps innovative services but little technical clue could be left behind (which the big providers present in this work would not necessarily mind). But I don't really know how the service provider scene would be with the browser RTC. From a device/browser vendor perspective my goal would be to make service creation and deployment as easy as possible.

I would see this as a bottom up approach that we should first focus on the media transport and NAT traversal issues that everyone agrees are needed, and as those start to shape up, look at the session establishment needs. It could be a phased approach that the browsers first only implement the media support and may add a common setup protocol later on based on the need. 
 
Markus