Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[Matthew Kaufman <[e-mail]>]

On 9/16/11 4:24 AM, Hadriel Kaplan wrote:
> There is no need for a "default signaling protocol", because the "signaling" is between the browser's Javascript and its web server.  And as for the signaling protocol the web server has to support in order to speak to other servers or non-RTCweb endpoints, even if we specified to use SIP we'd just be summarily ignored by those who don't want to, because they actually don't *need* to.  It doesn't hurt interoperability of rtcweb if they don't implement SIP - it just means they can't talk to other SIP devices/servers.  But it's not like we need an RFC to say "if you don't implement X then you can't talk to people who do X".

Agree.

>
> Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call Manager, and the browser is the Skinny phone, but in this case instead of needing a 7960 phone, the Skinny protocol was written in javascript and uses a browser's user interface for its GUI and the built-in RTP library for media. (in fact one could probably write a javascript to do just that, if Call Manager handled SCCP over websocket)

Actually, it is even better than this. Think of the RTCWEB Javascript 
API as "Skinny/SCCP". The web developer is then free to have "call 
manager" be up in the server and simply pass down data that is reflected 
directly into the API... or the web developer can use the fact that 
there's a complete programming environment on the browser to implement 
some or all of "call manager" *at the browser*, and that choice is 
completely in the application developer's hands.

They can write Skinny in Javascript and use the browser UI for the GUI 
and RTP library for media, and interoperate with SIP by building a 
complete SIP-to-Skinny translation at the server.

But they can also write SIP in Javascript and use the browser UI for the 
GUI and RTP library for the media, and interoperate with SIP by building 
just a Websocket-to-SIP converter up at the server.

Completely up to them... *if* we build a Javascript API that actually 
lets the programmer make this decision, just like they can make the same 
decision when they are programming to the Windows or Mac APIs.

On other other hand, if we bake too much in (a SIP implementation, all 
the semantics of SDP offer-answer, etc.) then the application developer 
either has their hands tied, or is forced to resort to silly things like 
taking an SDP offer and parsing it in Javascript to get the capabilities 
of the browser they're running in and then writing it back out as a 
different SDP offer that matches what they really want.


>
> Clearly the IETF does not need to define for Cisco a standardized replacement for the SCCP protocol for this to work, because one isn't needed since the client javascript and server are built by the same developers and they know how their proprietary signaling works.

Indeed. The protocol needs exactly the same level of standardization 
that Google needed to build Gmail. You need HTTP, possibly Websockets, a 
common programming language (Javascript) and a common set of interfaces 
(the Javascript API). The rest, including exactly what is transported on 
the wire, should be up to the developer. The format, how much of the 
logic lives at each end, etc.

>   So how about for the signaling Call Manager would use to other VoIP devices, like gateways or VoIP service providers?  Does the IETF need to tell Cisco what peer-to-peer protocol(s) to implement on Call Manager?  No, and we never have.  Cisco's product managers decide that.  They decide if Call Manager needs to be able to communicate a standard protocol at all, such as SIP or H.323, and which one/any of those.  They decide based on their use-cases/need.

Agree. If they want to connect to SIP providers for PSTN access, they 
can implement that. If they want to talk XMPP and Jingle because that's 
their preferred federation protocol, that's ok too.

>
> Some rtcweb developers may not do any standard signaling protocol, ever.  For example many Instant Messaging providers still have closed environments to this day. (e.g., AIM, YIM, MSN, etc.)

My employer is arguably one of the largest VoIP providers in the world, 
and most definitely isn't using standard signaling protocols.

>   Some may choose to only use H.323, or XMPP, or IAX, or even BICC.  Some may choose to only support SIP with 3GPP extensions.  Obviously most of us think/hope people do SIP, but really the market makes those types of decisions, not the IETF.  Just like the IETF standardized MGCP but didn't specify what the MGCP Call Agent had to support to speak to other Call Agents.  SIP was given as an example in MGCP, but not mandated.
>
> The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways.

This, and supports enough security/safety that the library can be 
trusted to run in the browser environment. (This is where the ICE 
requirement comes from.)

>   And obviously since SIP is a very common protocol and defined by the IETF we need to make sure it's possible to use SIP on the rtcweb server, but we can't *mandate* that it be used or supported, and if we did it wouldn't change anything.

Obviously it is always possible to use SIP on the RTCWEB server. After 
all, it is fairly trivial to gateway from Flash Player and RTMP or RTMFP 
to SIP, and there's no commonality there at all. The odds are extremely 
high that we can make interoperation even easier, both by opening up the 
capability and control APIs and by using a standard media transport so 
that media gateways can be avoided in many cases.


Matthew Kaufman