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

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 19 October 2011 14:04 UTC

Return-Path: <christer.holmberg@ericsson.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 137D821F8C0A for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 07:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9T+Ycx-ePtjH for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 07:04:58 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE4421F8BDB for <rtcweb@ietf.org>; Wed, 19 Oct 2011 07:04:57 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-9e-4e9ed908750b
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.F0.20773.809DE9E4; Wed, 19 Oct 2011 16:04:57 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 19 Oct 2011 16:04:56 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Cullen Jennings <fluffy@cisco.com>, Roman Shpount <roman@telurix.com>
Date: Wed, 19 Oct 2011 16:04:55 +0200
Thread-Topic: [rtcweb] Forking - Re: SDP Offer/Answer draft-jennings-rtcweb-signaling
Thread-Index: AcyNxabFlE2H069MTM2qpnNjuIBAmwAnLUPQ
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F4B3E@ESESSCMS0356.eemea.ericsson.se>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <CAD5OKxvE77Fia1hVRhdmqnfsOExpdJq=J2VMwtsfB_7ztEYtLA@mail.gmail.com> <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com>
In-Reply-To: <5D0FFCB8-8059-4C54-843B-46F1EC720B10@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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: Wed, 19 Oct 2011 14:04:59 -0000

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?

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.

Regards,

Christer