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

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 14 October 2011 22:41 UTC

Return-Path: <HKaplan@acmepacket.com>
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 D5BE621F8B3E for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 15:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 Ql6OLXjfCMw1 for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 15:41:27 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4C21F8B1D for <rtcweb@ietf.org>; Fri, 14 Oct 2011 15:41:26 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Oct 2011 18:41:25 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 18:41:25 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
Thread-Index: AQHMisJn8rgfXfSp5UKW00f9VXqrDA==
Date: Fri, 14 Oct 2011 22:41:24 +0000
Message-ID: <5748C5EE-48D1-4D30-B0D2-8703C45972EE@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> <CALiegfn6nv1D2HjeMo-jPDh9Acph7JdH1DT1xZXUtHqzqxya3Q@mail.gmail.com> <CA+9kkMB3p1u7hRX_vO1bQbQ2z-V+0rLiJmi+ZqkEA0mqc66keQ@mail.gmail.com> <CALiegf=26_6r_YjBCmO+6_GnrAzi=KcLoPFqUi-y1E8m_gWreQ@mail.gmail.com>
In-Reply-To: <CALiegf=26_6r_YjBCmO+6_GnrAzi=KcLoPFqUi-y1E8m_gWreQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <65F998441F1FAE4D828546CCB16DFB3B@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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 22:41:28 -0000

On Oct 14, 2011, at 5:41 PM, Iñaki Baz Castillo wrote:

> 2011/10/14 Ted Hardie <ted.ietf@gmail.com>;:
>> 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.

Actually I think you'd be surprised.  I don't know what Google Talk's latest numbers are, but I bet there is in fact more SIP done than XMPP even across the "Public Pure Pristine Internet".  It's not as much SIP as is done within the same network, but it's a still a lot. 
(of course the real king of "public Internet" VoIP would probably be Skype protocol :)


> 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 :)

Right I think we do agree - I was under the impression you were saying we don't need to work with SIP.

-hadriel