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

Iñaki Baz Castillo <ibc@aliax.net> Fri, 14 October 2011 21:18 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9634321F8B1A for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 14:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.27
X-Spam-Level:
X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQeHQiiTnFFF for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 14:18:53 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4EF721F8B18 for <rtcweb@ietf.org>; Fri, 14 Oct 2011 14:18:52 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1640736vcb.31 for <rtcweb@ietf.org>; Fri, 14 Oct 2011 14:18:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.9.3 with SMTP id j3mr792813vcj.6.1318627130329; Fri, 14 Oct 2011 14:18:50 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 14:18:50 -0700 (PDT)
In-Reply-To: <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com> <ABB0E87F-DEEF-4386-A718-D48E00F5961A@acmepacket.com> <CALiegfnHuYJnX3rnuDGbZPB4NvK=dCTJ=iLcu+zguP5wo_uPqQ@mail.gmail.com> <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com>
Date: Fri, 14 Oct 2011 23:18:50 +0200
Message-ID: <CALiegfn6nv1D2HjeMo-jPDh9Acph7JdH1DT1xZXUtHqzqxya3Q@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2011 21:18:53 -0000

2011/10/14 Hadriel Kaplan <HKaplan@acmepacket.com>;:
> *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

RTCweb is mostly focused on pure Internet world. Is SIP more extended
in pure Internet than XMPP? I don't think so (I mean pure Internet,
not telcos' private IP networks). So you like SIP (and me), but I
would like to hear the opinion of Google folks about it :)

More comments below.


> 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.

If you want your RTCweb deploment to interact with SIP... why don't
you use just SIP? :)

  http://sip-on-the-web.aliax.net/

Why are you assuming that there must be some kind of protocol gateway
RTCweb<->SIP ?  Personally I hate gateways! even more when they are
unnecessary.


Ok, so let's assume that you want some custom singaling protocol for
your RTCweb deployment (instead of using SIP over WebSocket) but want
also to interact with a SIP network out there. What is the problem
with current RTCweb specs?

You say "we do have to make sure that SIP can actually be used for
such an inter-domain protocol" but what do you mean with that? Of
course I want that a RTCweb client can establish a media session with
a pure SIP client (assuming ICE+RTP supported in the SIP device),
don't the current RTCweb specs allow that? I assume such specs and the
resulting JS API will be done with that in mind (but not just SIP but
also XMPP-Jingle and other VoIP protocols based on SDP
exchange/negotiation).


So honestly, I don't understand what you mean in your mail. Of course
we all want RTCweb to be interoperable with a SIP network but, how is
that related to "RTCweb federation"? The success of a interoperation
between RTCweb and a SIP network just depends on how good you are
designing your signaling mapping between your custom RTCweb signaling
and SIP, no more.


Regards.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>;