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

Cullen Jennings <fluffy@cisco.com> Thu, 20 October 2011 00:40 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 7B7B911E80BB for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.595
X-Spam-Level:
X-Spam-Status: No, score=-105.595 tagged_above=-999 required=5 tests=[AWL=1.004, 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 ZD+7IuoWrTsk for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:40:22 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D2FEE11E80AF for <rtcweb@ietf.org>; Wed, 19 Oct 2011 17:40:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3004; q=dns/txt; s=iport; t=1319071222; x=1320280822; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Cgihryx7G0BZAUkLMpe0GRbmmP7PXmVqldyZY6mxhpQ=; b=cLi2zoK+eL64mMMzaX3wl/WbSU7kwI+kGkrdIBoUcrpS98PjNMQZTPeD 8hAVws6dphlYZgtOqkdYEATOe7vo3q6J4JpPBhROP3QYjfMzhOX2p4E8b nuTLh54iwR2FS40rIToL/n269wV2SCu2RfSmxNUVRxb8K6XYi4mi11W88 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAE9tn06rRDoJ/2dsb2JhbABEqQKBBYFuAQEBAQIBEgEnPxALRlcGNYdel3sBnk+HOmEEiAKLfIUqjEw
X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="9017815"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Oct 2011 00:40:22 +0000
Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0eM4N030747; Thu, 20 Oct 2011 00:40:22 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: <7F2072F1E0DE894DA4B517B93C6A058522341F4B3E@ESESSCMS0356.eemea.ericsson.se>
Date: Wed, 19 Oct 2011 18:40:24 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <F326A60F-DDA0-4FAF-B3BE-05F7719A276A@cisco.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <CAD5OKxvE77Fia1hVRhdmqnfsOExpdJq=J2VMwtsfB_7ztEYtLA@mail.gmail.com> <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4B3E@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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: Thu, 20 Oct 2011 00:40:23 -0000

inline but yes, your understanding is what I was thinking 

On Oct 19, 2011, at 7:04 , Christer Holmberg wrote:

> 
> Hi, 
> 
>>> 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. 
> 
> - Assume my browser is communicating with a SIP gatway, and I use some non-SIP signalling protocol to transport ROAP messages between the browser and the gateway.
> 
> - The gateway maps ROAP into SIP, and a proxy forks the INVITE to multiple SIP UAs.
> 
> - When the gateway receives reliable 18x provisional responses, on different early SIP dialogs, it forwards them as final ANSWERs towards the browser.
> 
> - When the gateway receives the 200 OK, all other early dialogs are terminated. Now, from a pure ROAP perspective, the only way to inform the browser about that would be for the gateway to send new OFFERs for every terminated early SIP dialog, and e.g. indicate port=0.
> 
> Correct?

yes - I think that port=0 is the wrong way to indicate these have ended as it is confusing with hold and ending a particular media stream vs ending an offer/answer session. So this makes the argument for a better way to clean up state on the ROAP side. 

> 
> Now, instead of mapping the 18x provisional responses to final ANSWERs, the gateway could of course map them to non-final ANSWERs, and then later send final ANSWERs with an error code. But, the problem then is that the browser is not able to (or, at least that's my assumption - see separate e-mail) send a new OFFER until it has received a final ANSWER.

Yes - we have the same understanding of how with would work.  I imagine this would be the path most things takes. I don't see uses case where needing to send a new OFFER before receiving the final ANSWER would be a problem. 


> 
> Regards,
> 
> Christer
> 
>