IETF Logo Mail Archive

Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling

Cullen Jennings <fluffy@cisco.com> Tue, 18 October 2011 18:41 UTC

Return-Path: <fluffy@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 2FFD021F8B32 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Level:
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 qxTVOzVtDj61 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:41:54 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5D821F85A8 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 11:41:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2559; q=dns/txt; s=iport; t=1318963314; x=1320172914; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=s3NiElx7qhxisya0PZbyviapxm9IAZIzRVdNmxDlaYM=; b=aJwVyljPcC0fL5onK6S9pVYXYNPGfSf23zyVQ1gqG6kHA2tRFnDC8ue8 QYCXACeXHtcbtMtsezzB1o+IAu0HlT0IH0K55XsRdShdVcUO0CLMfm6t+ LL7jrXXUVbBFcCrU+2wrkD4j+sOmZydW2uPvn/PmkjmY3EkMg81k1XN36 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQAAL7HnU6rRDoH/2dsb2JhbABEmT6PMIEFgW4BAQECAQEBAQEPASc0BgUFBwQLDgMEAQEoBycfCQgGEyKHXgiXeQGeYIc6YQSIAot7kXY
X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8659868"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Oct 2011 18:41:54 +0000
Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IIemxc027916; Tue, 18 Oct 2011 18:41:54 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com>
Date: Tue, 18 Oct 2011 11:41:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <01441535-7FF6-4C88-AA28-53B5CB68374F@cisco.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, rtcweb@ietf.org, public-webrtc@w3.org
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling
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 18:41:55 -0000

So I might have messed up the draft a bit. I'm fine with things can be implemented as dialog statefull, what I want is that it is possible to make a signaling gateway that is only transaction statefull. I'm fine if some signaling gateways are built as dialog statefull.

 (As a side note, some B2BUA are effectively transaction statefull but that is pretty rare )


On Oct 17, 2011, at 15:28 , Ravindran Parthasarathi wrote:

> Cullen/Joanthan,
> 
> I like your proposed idea as it is going in the direction of having
> "standard" signaling protocol for RTCWeb. I'm seeing your proposal as
> SDP offer/answer over websocket and the proposal helps to easy gateway
> development between RTCWeb server and legacy signaling protocols.
> 
> I have fundamental question in the proposal as it proposes RTCWeb server
> as SIP proxy equivalent and in reality, unfortunately most of the SIP
> deployment work is based on B2BUA. The question is whether RTCWeb server
> shall be dialog-state or MUST be transaction-stateful only. 
> 
> Also, session-id in the draft is used to uniquely understand the offerer
> and answerer in the transaction or session. In case it is session, how
> to indicate the termination of the session.
> 

My personal opinion is that to be able to clean up all the state in a clean an easy way, we should add some message to indicate the SDP offer / answer state and related media streams can be discarded.  I'd like to add that to the next version. 


> Thanks
> Partha
> 
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf
>> Of Cullen Jennings
>> Sent: Saturday, October 15, 2011 8:39 AM
>> To: rtcweb@ietf.org; public-webrtc@w3.org
>> Cc: Jonathan Rosenberg
>> Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling
>> 
>> 
>> Jonathan and I submitted a new draft on setting up media based on the
>> SDP Offer/Answer model. The ASCII flows are a bit hard to read so until
>> I update them, I recommend reading the PDF version at
>> 
>> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf
>> 
>> Clearly the draft is an early stage but we plan to revise it before the
>> deadline for the IETF 82. Love to get input - particularly on if this
>> looks like generally the right direction to go.
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email