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

Ted Hardie <> Fri, 14 October 2011 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE79121F8C6B for <>; Fri, 14 Oct 2011 14:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ev30r9eomotf for <>; Fri, 14 Oct 2011 14:27:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 81B8B21F8C46 for <>; Fri, 14 Oct 2011 14:27:04 -0700 (PDT)
Received: by yxn35 with SMTP id 35so1552190yxn.38 for <>; Fri, 14 Oct 2011 14:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FyUWfurdTjIEdNqJl21LE8F2/D5dno5MRDQA8NC8dRU=; b=UKcycrbw4WbZx4d4IR1+8f3WT7BSAOZzx6udi7MH/oiSTgpXUtPUg9U+vYekxtrVcM Uu8M7++ZwHdrAKM9QgZtVKSmSNGVVj9d0G+B3iKe7g49XqFWCiiDk+/hefHGwwaojxnk j1MByKrVl02ov1/FS/y8drB7QfQFmnYTpfLnU=
MIME-Version: 1.0
Received: by with SMTP id v2mr14689170yhd.57.1318627623970; Fri, 14 Oct 2011 14:27:03 -0700 (PDT)
Received: by with HTTP; Fri, 14 Oct 2011 14:27:03 -0700 (PDT)
In-Reply-To: <>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <> <> <> <>
Date: Fri, 14 Oct 2011 14:27:03 -0700
Message-ID: <>
From: Ted Hardie <>
To: Iñaki Baz Castillo <>
Content-Type: multipart/alternative; boundary="20cf300515181e256f04af48ebea"
Cc: "<>" <>
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Oct 2011 21:27:05 -0000

On Fri, Oct 14, 2011 at 2:18 PM, Iñaki Baz Castillo <> wrote:

> 2011/10/14 Hadriel Kaplan <>:
> > *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 :)
Not speaking for Google, but I have no idea what you mean by "pure Internet
world" here.  I'm also not really clear what your aim is.  Hadriel has said
that the overall system must be designed such that it is possible to use SIP
as a federation protocol, but that it should not be restricted so that only
SIP can be used as a federation protocol.  Perhaps if you responded to his
point on this issue, the rest of your comments might seem more clear.


Ted Hardie

> 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? :)
> 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
> <>
> _______________________________________________
> rtcweb mailing list