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

Markus.Isomaki at nokia.com Markus.Isomaki at nokia.com
Mon Jan 31 07:38:08 CET 2011


Hi,

Ted Hardie wrote:
>
>On Fri, Jan 28, 2011 at 7:38 AM, Harald Alvestrand
><harald at alvestrand.no> wrote:
>>
>> 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?
>

I would find it weird if the web server would *want* to do this between browser clients that it is serving. It would seem easiest to use the same protocol for every browser client, and just act as a "signaling proxy". Assuming something like STUN/ICE were used, the web server would not need to deal with NAT traversal issues either.

But where the web server may need to do "signaling intermediation" is towards other providers/domains or e.g. native SIP or XMPP clients served in the same domain. If we believe in a world of lot of interconnected providers/domains, that "server-server" interface needs a common standard. For VoIP/video, SIP is a natural choice, while for IM/presence XMPP is the de facto. However, I believe that side is out of scope of the RTC-Web work.

If we again assume the use of STUN/ICE and want e2e media across providers/domains, we have to assume that it is possible to map the necessary information on the signaling path: Browser A <-> provider1-protocol <-> SIP/Jingle <-> provider2-protocol <-> Browser B, so that Browser A and B can get the media path up. Is that doable and if we leave the session setup protocol completely open, is there *something* that we can do to make that easier? Some people have talked about defining session setup protocol semantics but not syntax for this purpose.

Markus


More information about the RTC-Web mailing list