Re: [rtcweb] Current state of signaling discussion

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Tue, 18 October 2011 23:13 UTC

Return-Path: <pravindran@sonusnet.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 1C37A1F0C36 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 16:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.924
X-Spam-Level:
X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599]
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 n+W-Ob7F8ItQ for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 16:13:07 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 652B921F8B91 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 16:13:07 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9INDYBi025504; Tue, 18 Oct 2011 19:13:34 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 19:12:59 -0400
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: Wed, 19 Oct 2011 04:42:20 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599FA@sonusinmail02.sonusnet.com>
In-Reply-To: <F89E752A-820B-4C41-BE14-15B358BFA267@acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Current state of signaling discussion
Thread-Index: AQHMjdmb9USwkyocF0KQH5G/+0/FIJWCuRLg
References: <4E9D773A.4010705@ericsson.com><E7E0C331-9943-444F-9D42-782DAD6A7FF3@acmepacket.com><CABcZeBP0v=q7sH4G4Ehvx7x5b_tyoukS1N0EOm1Ji8URNOeDUw@mail.gmail.com> <F89E752A-820B-4C41-BE14-15B358BFA267@acmepacket.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Hadriel Kaplan" <HKaplan@acmepacket.com>, "Eric Rescorla" <ekr@rtfm.com>
X-OriginalArrivalTime: 18 Oct 2011 23:12:59.0510 (UTC) FILETIME=[7A456160:01CC8DEB]
Cc: rtcweb@ietf.org, rtcweb-chairs@tools.ietf.org
Subject: Re: [rtcweb] Current state of signaling discussion
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: Tue, 18 Oct 2011 23:13:08 -0000

Hi Hadriel,

As you know in most of the IP real-time signaling protocol (SIP+SDP,
H.323(H.225, H.245), MGCP+SDP), there are two aspects

1) Signaling (SIP, H.225)
2) Media description (SDP offer/answer, H.245)

In case of Websocket or long poll HTTP, these protocol act as signaling
whereas media description is missing. ROAP will fill this signaling
protocol gap for websocket/HTTP.

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf
>Of Hadriel Kaplan
>Sent: Wednesday, October 19, 2011 2:35 AM
>To: Eric Rescorla
>Cc: rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
>Subject: Re: [rtcweb] Current state of signaling discussion
>
>
>In the abstract it states:
>"The protocol focuses solely on media negotiation and does not handle
>call control, call processing, or other functions."
>
>Ignoring esoteric stuff like session transfer, forwarding, etc. (ie,
>ignoring "phone" stuff) is fine.
>
>BUT, for an actual session protocol to work for even a gaming app, you
>need to do the following:
>1) determine a target for the ROAP message (ie, who's this OFFER going
>to in the end?)
>2) define how that target identity is conveyed (ie, how does the web
>server know which browser to give this ROAP OFFER to?)
>3) define a source identity model, possibly with authentication (ie,
who
>are you?)
>4) define how the source identity is conveyed (ie, how does the
>server/far-end-browser know who's calling?)
>5) define a end-of-session indication
>6) define a keep-alive mechanism, for when the far end goes away
>silently and (5) doesn't apply
>
>And I've probably missed some other things.
>
>-hadriel
>
>
>On Oct 18, 2011, at 4:50 PM, Eric Rescorla wrote:
>
>> Is this actually correct? The introduction of that draft suggests
>otherwise:
>>
>> "The protocol is designed to operate between two entities (browsers
>> for example), which exchange messages "directly" - meaning that a
>> message output by one entity is meant to be directly processed by the
>> other entity without further modification. In practice, this means
>> that a web server can treat ROAP messages as opaque and just shuffle
>> them between browser instances. This allows for simple
>> implementations."
>>
>> If we take the PeerConnection API as our point of reference, isn't
the
>> idea here that
>> you would instantiate callbacks that take messages coming out of the
>> PeerConnection
>> API and push them to the Web server and messages coming from the Web
>server
>> and push them to the PeerConnection instance. I don't know if this is
>20 lines
>> of code (though with JS minimization it might be one line of code
:)),
>> but it does
>> seem comparatively trivial...
>>
>> -Ekr
>>
>>
>>
>>
>> -Ekr
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb