Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Fri, 16 September 2011 07:28 UTC

Return-Path: <mperumal@cisco.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 7D8C921F8BDC for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 00:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.479
X-Spam-Level:
X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 QQejNfvsMa0D for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 00:28:33 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E040A21F84D9 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 00:28:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=5246; q=dns/txt; s=iport; t=1316158247; x=1317367847; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=X12yf4nMhIe5C/TgQztpw78y+bq4B7XNSUydRyQNZ0Y=; b=Twbj3Y4eCBgAB/veU97qa1wa38xvUHMwYuyV0GRXr4Qs79PnJKZBGy4Y n8HBBa0il5QSm3/cm7VShqwwxbo+iEwKmywiXyDLpO1TSQjtMrmaApoXs 0BRUYzPCGX4d4xFO6+9XbH8OaJ5YYLvCTQLI53VpRbbmInAmBuwfUgoSg k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqgAAGj6ck5Io8UT/2dsb2JhbABBmFaPBHeBTAcBAQEBAwEBAQ8BHQo0CwwEAgEIDgMEAQELBhMEAQYBJh8JCAIEAQoICBMHh1mWPAGeEIYYYASHbZECjA4
X-IronPort-AV: E=Sophos;i="4.68,392,1312156800"; d="scan'208";a="115719957"
Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 16 Sep 2011 07:30:42 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8G7Uf2t019446; Fri, 16 Sep 2011 07:30:41 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 13:00:41 +0530
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 16 Sep 2011 13:00:42 +0530
Message-ID: <1D062974A4845E4D8A343C653804920206649221@XMB-BGL-414.cisco.com>
In-Reply-To: <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
Thread-Index: AQHMdBfEi7FefEQ3sUO4/j8bw5yK0pVPmxUA
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Hadriel Kaplan" <HKaplan@acmepacket.com>, "Ravindran Parthasarathi" <pravindran@sonusnet.com>
X-OriginalArrivalTime: 16 Sep 2011 07:30:41.0680 (UTC) FILETIME=[89E12900:01CC7442]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
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, 16 Sep 2011 07:28:34 -0000

|The only thing we need to do for rtcweb is make sure the 
|RTP library built into the browser supports media in such
|a way that it can communicate with other RTP peers at a 
|media plane, regardless of what signaling protocol those 
|peers might be using, preferably without going through 
|media gateways.  And obviously since SIP is a very common 
|protocol and defined by the IETF we need to make sure it's
|possible to use SIP on the rtcweb server, but we can't 
|*mandate* that it be used or supported, and if we did it 
|wouldn't change anything.

+1. 

We may also want to make sure that it is possible use SDP, but shouldn't
mandate that it be used.

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf Of Hadriel Kaplan
|Sent: Friday, September 16, 2011 7:55 AM
|To: Ravindran Parthasarathi
|Cc: <rtcweb@ietf.org>;
|Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
defining a signaling protocol
|for WebRTC (or not)]
|
|
|There is no need for a "default signaling protocol", because the
"signaling" is between the browser's
|Javascript and its web server.  And as for the signaling protocol the
web server has to support in
|order to speak to other servers or non-RTCweb endpoints, even if we
specified to use SIP we'd just be
|summarily ignored by those who don't want to, because they actually
don't *need* to.  It doesn't hurt
|interoperability of rtcweb if they don't implement SIP - it just means
they can't talk to other SIP
|devices/servers.  But it's not like we need an RFC to say "if you don't
implement X then you can't
|talk to people who do X".
|
|Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call
Manager, and the browser is the
|Skinny phone, but in this case instead of needing a 7960 phone, the
Skinny protocol was written in
|javascript and uses a browser's user interface for its GUI and the
built-in RTP library for media. (in
|fact one could probably write a javascript to do just that, if Call
Manager handled SCCP over
|websocket)
|
|Clearly the IETF does not need to define for Cisco a standardized
replacement for the SCCP protocol
|for this to work, because one isn't needed since the client javascript
and server are built by the
|same developers and they know how their proprietary signaling works.
So how about for the signaling
|Call Manager would use to other VoIP devices, like gateways or VoIP
service providers?  Does the IETF
|need to tell Cisco what peer-to-peer protocol(s) to implement on Call
Manager?  No, and we never have.
|Cisco's product managers decide that.  They decide if Call Manager
needs to be able to communicate a
|standard protocol at all, such as SIP or H.323, and which one/any of
those.  They decide based on
|their use-cases/need.
|
|Some rtcweb developers may not do any standard signaling protocol,
ever.  For example many Instant
|Messaging providers still have closed environments to this day. (e.g.,
AIM, YIM, MSN, etc.)  Some may
|choose to only use H.323, or XMPP, or IAX, or even BICC.  Some may
choose to only support SIP with
|3GPP extensions.  Obviously most of us think/hope people do SIP, but
really the market makes those
|types of decisions, not the IETF.  Just like the IETF standardized MGCP
but didn't specify what the
|MGCP Call Agent had to support to speak to other Call Agents.  SIP was
given as an example in MGCP,
|but not mandated.
|
|The only thing we need to do for rtcweb is make sure the RTP library
built into the browser supports
|media in such a way that it can communicate with other RTP peers at a
media plane, regardless of what
|signaling protocol those peers might be using, preferably without going
through media gateways.  And
|obviously since SIP is a very common protocol and defined by the IETF
we need to make sure it's
|possible to use SIP on the rtcweb server, but we can't *mandate* that
it be used or supported, and if
|we did it wouldn't change anything.
|
|-hadriel
|
|
|On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote:
|
|> I really didn't get your argument fully because in case there is no
default signaling protocol, it
|is unavoidable to have island of devices without gateways but you argue
other way around.
|>
|> I specifically asked for the scope of your opinion on RTCWeb work is
between browser-to-browser or
|browser-to-other end-point to know whether parallel universe has to be
build or not. In case there is
|no default signaling protocol, it is impossible to communicate between
browser-to-endpoint without
|gateways. Let us assume that the intention of RTCWeb is to create
island of browser devices even then
|the native signaling protocol for RTCWeb has advantage over Jquery
library and plugin is not the
|solution.
|>
|> Having said that, I agree that it is possible to implement RTP or
STUN or SIP stack or codec using
|Javascript or plugins but interop and better performance is not
guaranteed.
|>
|> Thanks
|> Partha
|
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb