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

[Henry Sinnreich]

>I believe 
> Jingle is more monolithic and easier to handle in this sense.)

This adds even more to the endless discussions of SIP vs. Jingle, actually
it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or
may not be happy about it.

Bottom line: 
Adding a 3rd option to the signaling will bog down the RTC-Web work even
more. The API should be a separate effort.
Oh, the discussions there...
Don't expect anyone there to give in easily :-), and why can/should they?

Let's leave the API out for scope.

Thanks, Henry



On 1/27/11 10:15 AM, "Markus.Isomaki at nokia.com" <Markus.Isomaki at nokia.com>
wrote:

> 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
> _______________________________________________
> dispatch mailing list
> dispatch at ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch