Re: [rtcweb] PRANSWER is unusable for serial forking

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Sat, 13 October 2012 02:24 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 D933021F86C1 for <rtcweb@ietfa.amsl.com>; Fri, 12 Oct 2012 19:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level:
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+WPBTiRpBch for <rtcweb@ietfa.amsl.com>; Fri, 12 Oct 2012 19:24:27 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF97B21F86AD for <rtcweb@ietf.org>; Fri, 12 Oct 2012 19:24:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3857; q=dns/txt; s=iport; t=1350095067; x=1351304667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NmnzR2zKlyeLxYccDZPyzDmy5OHBmngAknFAmghB9dc=; b=jEhljn/0o19lAIQ+W5GZtjoCQxr8AMQVZFjowUhmlrMwT9OeL9QKgqQr hW9xva/vcRfpVobXY6/t/Ey0mcKRv3QK3VkWTEc4OVug1UsfctQ1sSqgo 0X2BeNjqyUhTCGPWaDxbu73I06+ugo7KuoTBiB8HGQ/vDfvqjmHoK/O2D U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAHHQeFCtJV2Z/2dsb2JhbABFv2+BCIIgAQEBAwESARRSBQsCAQgiJDIlAgQOBQgah1wGm1ifaYtShV1gA4gjnA+Ba4Jtghc
X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="128166968"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 13 Oct 2012 02:24:26 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9D2OQmD020713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 02:24:26 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 21:24:25 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking
Thread-Index: AQHNqOnc3QfmtiokskqSBC02DG7ABw==
Date: Sat, 13 Oct 2012 02:24:25 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB111888AF6@xmb-aln-x02.cisco.com>
References: <CAD5OKxuOVgcKY_PBLXHeT_cyqJU9sExDWmP1M5u3-87cMQWtVA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000
x-tm-as-result: No--41.265700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <40517851574AF74F905E5655E709918A@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] PRANSWER is unusable for serial forking
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: Sat, 13 Oct 2012 02:24:28 -0000

On Oct 9, 2012, at 12:40 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
> I THINK Roman is talking about the following flow:
> 
> 
> BROWSER		JS APP			FORKING PROXY			SIP UA 1			SIP UA 2
> 
> ------- OFFER --------------->
>                                                  ----- INVITE (OFFER 1) --------->
> 							----- INVITE (OFFER 1) --------->
> 							----- INVITE (OFFER 1) ---------------------------------------------------->
> 							<----180 (ANSWER 1a) ----------
> 			<----180 (ANSWER 1a) ----------
> <----PRANSWER -----------
> 							<----UPDATE (OFFER 2) --------
> 			<----UPDATE (OFFER 2) ---------
> <----???? --------------------
> 							<----200 (ANSWER 1b) ------------------------------------------------------
> 			<----200 (ANSWER 1b) ----------
> <----ANSWER ---------------
> 
> 

That's not a call flow that is legal for use of update. From section 5.1 of of RFC 3311 has 

     o  If the UPDATE is being sent before completion of the initial
         INVITE transaction, and the initial INVITE contained an offer,
         the UPDATE can contain an offer if the callee generated an
         answer in a reliable provisional response, and the caller has
         received answers to any other offers it sent in either PRACK or
         UPDATE, and has generated answers for any offers it received in
         an UPDATE from the callee.

If the answer from UA1 is going to do updates before the invite transaction complete, it needs to do that with 100rel / PRACK. Note the diagram should also show an the 200 response to the update is going to cary an answer.

So if you made all these changes, lets talk about how you would solve this problem in the JS App. 

Fundamentally what is happening here is the call signaling is setting up two session - this is parallel media forking and parallel signaling forking. One fork to UA1, and one to UA2. The JS App needs to pick which one it is going to choose to have a media session with. Let's say it choose UA1, then it would map the Answer 1a to an Answer, the Offer2 to an offer. If it was going to choose UA2, it would not pass the answer down to the browser at all and would instead wait till it Answer 1b and pass that down. If you think it should simultaneously have a media session with both UA1 and UA2, then things are more complicated. I realize that at the time it gets ANSWER 1a, it does not know it will later get ANSWR 1b so that make it hard to choose UA2. 

Parallel forking with early media and secure media is a hard problem in SIP as we know from the HERFP discussion. I'm unaware of real world problem that are solved well with SIP and require parallel forking and thus my focus has been on making sure we solve serial forking. I'm perfectly happy if we *also* solve parallel forking but I don't care too much as long a early media serial forking scenarios work because theses do happen all the time. I'm pretty skeptical that are a lot of existing SIP phones that deal well with simultaneously receiving and sending media to two other UAs in a scenario like this (I'm trying to separate this from conferencing - I know lots of SIP UA do 3 way calling and conferencing just fine). 

If you want to do both, one way might be to create a new peer connection for the 2nd call, and map it to and IVNTE with replaces, or send a SIP refer to get the second session mapped to the new PeerConnection object. One could also try and work on some thing that allows one PeerConenction to clone to two places but that's going to be a bunch of work to figure out - and again, perfectly happy if someone goes and does that but it's a hard problem when you have resource allocations.