Re: [rtcweb] PRANSWER is unusable for serial forking

Christer Holmberg <> Sat, 13 October 2012 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 814CA21F8681 for <>; Sat, 13 Oct 2012 00:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.122
X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oQKvAUD1U+9o for <>; Sat, 13 Oct 2012 00:22:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 376ED21F8683 for <>; Sat, 13 Oct 2012 00:22:45 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-96-507916c3de64
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 2C.A0.11467.3C619705; Sat, 13 Oct 2012 09:22:43 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Sat, 13 Oct 2012 09:22:43 +0200
From: Christer Holmberg <>
To: "Cullen Jennings (fluffy)" <>
Date: Sat, 13 Oct 2012 09:21:30 +0200
Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking
Thread-Index: AQHNqOnc3QfmtiokskqSBC02DG7AB5e21Ob3
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre5hscoAg6mT5Sw6JrNZfFj/g9Fi xoWpzBZr/7WzO7B4TPm9kdVjyZKfTB6Xz39k9Lg1pSCAJYrLJiU1J7MstUjfLoEro+X2AcaC hSoVM2ZPYGpgvCLZxcjJISFgIvFm7wt2CFtM4sK99WxdjFwcQgKnGCW235nHDOEsZJT4tuQW UxcjBwebgIVE9z9tkAYRAUOJpj3zmEBsZoFciQe714INYhFQlTg47wcriC0sYCvR+HYGE0S9 ncSED/vYIWwjiRPfvjKD2LwC4RLvfu9kgth1n1Hi6r0OsGZOAV+J1+ungxUxAl33/dQaqGXi EreezGeCuFpAYsme88wQtqjEy8f/WCHqRSXutK9nhKjXkViw+xMbhK0tsWzha6jFghInZz5h mcAoNgvJ2FlIWmYhaZmFpGUBI8sqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzACDu45bfuDsZT 50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCgsvHSvk/CJBEWNSVyx k3VVzl6OCLLm15n7d8K1f5c3rmKM57h0wtXnR+P3gjlqKRetUv38mItjxF+stvvusTF+i9Sn NlW5edoyPkJ8J2MDX2twOp0pinG5OLm/1/PxU+/FxxQ/HN+wv//2CdbbIgtXBTce61X7uTGo +5L3R9/O4xekZrmwuimxFGckGmoxFxUnAgAmyUTmfgIAAA==
Cc: "" <>
Subject: Re: [rtcweb] PRANSWER is unusable for serial forking
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Oct 2012 07:22:46 -0000

Hi Cullen,

I'll read your reply more in detail later, but please note that I assume that the 180 is sent *reliably* (I left the PRACK out).



From: Cullen Jennings (fluffy) []
Sent: Saturday, October 13, 2012 5:24 AM
To: Christer Holmberg
Cc: Roman Shpount; Cullen Jennings;
Subject: Re: [rtcweb] PRANSWER is unusable for serial forking

On Oct 9, 2012, at 12:40 AM, Christer Holmberg <> 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.