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

Iñaki Baz Castillo <> Fri, 14 October 2011 21:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68CE821F8C6B for <>; Fri, 14 Oct 2011 14:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V7hx0mRS8w8Y for <>; Fri, 14 Oct 2011 14:41:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 703ED21F8BA7 for <>; Fri, 14 Oct 2011 14:41:43 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1654670vcb.31 for <>; Fri, 14 Oct 2011 14:41:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id by14mr10865906vdb.18.1318628502512; Fri, 14 Oct 2011 14:41:42 -0700 (PDT)
Received: by with HTTP; Fri, 14 Oct 2011 14:41:42 -0700 (PDT)
In-Reply-To: <>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <> <> <> <> <>
Date: Fri, 14 Oct 2011 23:41:42 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Ted Hardie <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:41:48 -0000

2011/10/14 Ted Hardie <>:
> Not speaking for Google, but I have no idea what you mean by "pure Internet
> world" here.

"Pure Internet" is just Internet, and that is not a private network or
a telco IP infrastructure. I just meant that.

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

Ok, let me try again:

IMHO RTCweb (specially the JS API for managing media sessions) must be
designed in a way that it's possible for a developer to implement a
SIP client in JavaScript or another custom signaling protocol having a
gateway that maps it to/from SIP. This means that SIP features as
parallel forking, early media, conference... should be possible using
the RTCweb JavaScript API. I think we agree here :)

So, assuming that there MUST NOT exist a *standard* signaling protocol
for federation in RTCweb, what is the purpose of speaking about
"federation"? Probably we all are speaking about the same concept, but
for me "federation" means a RTCweb server communicating with other
RTCweb server. If Hadriel and you meant "RTCweb server communicating
with a SIP network" then I repeat my first paragraph :)

So in order to accomplish with requirements of Hadriel we need to make
the RTCweb client stack and the RTCweb JavaScript API flexible enough
so all (or most of) the SIP features can be implemented in JavaScript
(I mean "audio/video features" since all the signaling can already be
coded in different ways).

Hope it's more clear now.

Best regards.

Iñaki Baz Castillo