[RTW] Including or excluding an establishment protocol (Re: [dispatch] The charter formerly know as RTC-WEB take 3)

Fri Jan 28 19:29:31 CET 2011

Howdy,

A question in-line.

On Fri, Jan 28, 2011 at 7:38 AM, Harald Alvestrand <harald at alvestrand.no> wrote:
> Changing the subject as is my habit.... forgive the introductory
> philosophical distraction.
>
> I tend to look at success criteria, and if we need to achieve something to
> achieve success.
>
> If we fail unless we do this work, it MUST be done.
> If we can succeed without doing this work, it does not have to be done.
> If we can succeed only if someone else does this work, we need to make sure
> that other thing also gets done (the classical example here is Javascript
> APIs for the functions we make available).
>
> In this case, I define success (for myself - YMMV) as "browsers ship with
> well defined, usable functionality that allows audio and video communication
> between applications running as web pages in those browsers". More
> functionality (including legacy device interoperability with gateways only
> in the signalling path) is nice to have, but not essential for me to decide
> that we have succeeded.
>
> The charter is a description of what work is to be done in this WG of the
> IETF.
>
> If the IETF includes a signalling stack in the specification, it helps
> achieve the goal. But it's not essential, because those bits go across a
> wire that (likely) points in the direction of webservers that the pages load
> from, and those webservers can do signalling intermediation as needed.
>

I have described this in the past as a case in which the webserver is the
signal path, but your description of "signaling intermediation" sounds
more ambitious.  In particular, do you mean that it might use different
syntax with different clients, using this shared semantics?

> What IS essential is that the semantics (not the syntax) of the information
> needed to establish the connections between the browsers is known and
> documented - because otherwise, the goal can't be achieved.
>

Huh.  If we have an API at the client side and known semantics for establishing
the connections, isn't the easiest way to connect those two a standard protocol
syntax for taking the API-expressed desired and signaling it to the
intermediating
web server?

> I'd be happy if the charter defined somewhat weaselly words like "Describe
> the information that must be exchanged between the endpoints in order to
> establish connectivity, and optionally describe how this information can be
> represented using existing signalling protocols".
>

So, I may just be confused here.  Are you saying that we do define RTW syntax
as well as semantics used here, and optionally describe a mapping
to SIP/XMPP?  Or are you saying that we describe only the semantics
and optionally define the mapping to signaling protocols.  To my ears,
it sounds like you mean the second, but the first makes much more
sense, as it is difficult to see how we get full interoperability with
only a semantics description as a deliverable.

> But I wouldn't be happy with a charter that said "put SIP or XMPP in the
> browser". It's not necessary for success, so I don't want to be bound to
> doing it.

Each also does many other things, so I agree.  But if someone wants to implement
as:

[RTW API]
[Inbound mapping to signaling protocol]
[Sip/XMPP]
[Outbound mapping to RTW-syntax]

then the way they got to the RTW-syntax is no one's affair but their own, right?

best regards,

Ted Hardie

>
> On 01/27/11 10:08, Henry Sinnreich wrote:
>>>
>>> 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
>>
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>