IETF Logo Mail Archive

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

Cullen Jennings <fluffy@cisco.com> Tue, 18 October 2011 18:42 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 478E621F8C9C for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.549
X-Spam-Level:
X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 jLr0-xXt9pkx for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:42:09 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D313B21F8AF5 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 11:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1946; q=dns/txt; s=iport; t=1318963329; x=1320172929; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0jT+PS6w8G/glJ74yqdhDGqB1erAcX8zIFShTndbbgM=; b=AZJH6MPzHShlLog5O6ubCOzejXXG2777PMT1ZpdFKKcOOx1xw+aV3m9V 1EhlTeDcn54355lKCG61Qr20RKxb3imgC5dzAFwqCLfSrmnPn3ijNSX+z PDR4wvtUc5FMT3cRL03UT0UWO44cvlRbxG7EAZVcdra9VVMIoTbQPNmmR 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAHHHnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAgEBAQEBDwFbBgUFCyMuJzAGEyKHXgiXeQGeYIc6YQSIAot7kXY
X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8641705"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 18:42:04 +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 p9IIemxd027916; Tue, 18 Oct 2011 18:42:04 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="iso-8859-1"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <CAD5OKxvE77Fia1hVRhdmqnfsOExpdJq=J2VMwtsfB_7ztEYtLA@mail.gmail.com>
Date: Tue, 18 Oct 2011 11:42:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <CAD5OKxvE77Fia1hVRhdmqnfsOExpdJq=J2VMwtsfB_7ztEYtLA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, rtcweb@ietf.org, public-webrtc@w3.org
Subject: [rtcweb] Forking -Re: 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:42:10 -0000

On Oct 17, 2011, at 17:58 , Roman Shpount wrote:

> Cullen,
> 
> Did we decide to explicitly not support forking which generates multiple final answers? If this is not the case, how is this supposed to be implemented using your model?

I think that it is critical that we support what is needed to make a call that goes to 1-800-go-fedex work. So 
consider the following use case: A browser calls through a signaling GW to a sip that forks the call to an SIP to PSTN gateway and also to a voicemail server. The PSTN gateway generates an 180 with ringback tone but the SIP call is eventually answered by the voicemail server that sends a 200. 
 
So 3264 supports forking by an single offer may result in say two answers. In the case above, an single offer resulted in two different answers. Roap would support this type of transaction by allowing two answers to be received. There are two ways this can happen - one is with different answererSessionId in the the answers. Another is the use of the More-coming flag. We think with these, one can support the range of what 3264 allows for offer/ answer. 


> _____________
> Roman Shpount
> 
> 
> On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings <fluffy@cisco.com> wrote:
> 
> 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.30.2 | Report a Bug | By Email | System Status