Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

[Hadriel Kaplan <[e-mail]>]

On Oct 14, 2011, at 2:48 PM, Iñaki Baz Castillo wrote:

> I'm not opposed to RTCweb federation, how could I say that? :)
> I just meant that trying to "standarize" that is unfeasible IMHO.
> First of all, because standarizing that means that we assume that
> every kind of communications made on top of RTCweb specs are the same,
> with same properties and capabilities. But I strongly assume that some
> web site could offer audio calls between users while other site just
> offers video calls. Some web site offers like-SIP full telephony
> capabilities (forking, earlymedia, transference) while another web
> site is just interested in very simple audio calls. How to make a
> standard for federating all those different scenarios? IMHO it's a
> no-go.

Oh yeah I don't mean to imply we should mandate what the inter-domain protocol must be.  Domains can use whatever they like: SIP, H.323, XMPP, BICC, IAX, some-apple-protocol, some-google-protocol, ...
Who are we to tell a web admin what protocol to use to another web admin?  And even if we did, why would they listen to us?

*BUT* we do have to make sure that SIP can actually be used for such an inter-domain protocol; both because it's an active IETF-defined protocol for real-time communications between peers and we'd look pretty silly if RTCWEB couldn't use it between RTCWEB domains, but also because SIP arguably is the most popular one out there and we should do everything in our power to make it usable to/from RTCWEB domains with as least cost/complexity as possible.

And I don't mean that only in the aspect of federation or PSTN-access.  I don't know if RTCWeb will be popular for those.  But I can guess one application where it will be popular: corporate websites, such as support/help pages or sales pages.  Lots of companies already use plugins/flash on their support/sales websites to enable audio and chat from customers to their internal support/sales people.  Obviously those sales/support employees could be using a browser to communicate with customers using the same website, but it's also as likely that they use their existing SIP infrastructure internally - if for no other reason than they already have it and it works with their IVR, ACD and recording systems, and they can reach employees on mobile phones or the PSTN back out their SIP trunks.

Another obvious application for RTCWEB-to-SIP is Webex, where a company could deploy their own web server for webex-style conferencing without paying Cisco/Webex.  Although most if not all the users on a webex have browser access, it's still the case you need SIP-PSTN access because you need to let conference-type phones access the meeting.  As for example happened this week at the IETF CLUE WG interim meeting: a webex session was available but the physical meeting room used a Polycom conference-phone for the moderator "participant".

-hadriel
p.s. I mean this all in the aspect of a trapezoid where SIP is the high-path between servers, not SIP between the browser and its server.