Re: [rtcweb] PRANSWER is unusable for serial forking

Christer Holmberg <> Sat, 13 October 2012 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F0DF21F8513 for <>; Sat, 13 Oct 2012 02:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.123
X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, 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 MJUbf-v5N1cK for <>; Sat, 13 Oct 2012 02:51:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3D44921F843E for <>; Sat, 13 Oct 2012 02:51:05 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-7b-50793985c71a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E5.7D.04547.58939705; Sat, 13 Oct 2012 11:51:01 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Sat, 13 Oct 2012 11:51:01 +0200
From: Christer Holmberg <>
To: "Cullen Jennings (fluffy)" <>
Date: Sat, 13 Oct 2012 11:51:00 +0200
Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking
Thread-Index: AQHNqOnc3QfmtiokskqSBC02DG7AB5e27xpu
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+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvrW6rZWWAwfp3shYdk9ksPqz/wWgx 48JUZou1/9rZHVg8pvzeyOqxZMlPJo/L5z8yetyaUhDAEsVlk5Kak1mWWqRvl8CV8WL2E7aC HpWKOZuusDYwTpPsYuTkkBAwkfjRf4cNwhaTuHBvPZDNxSEkcIpR4su9ScwQzkJGiW03HgA5 HBxsAhYS3f+0QRpEBAwlmvbMYwKxmQVyJR7sXssOYrMIqEp83nqUFcQWFrCVaHw7gwmi3k5i wod97CBjRASMJC5vygUJ8wqESzStnwK16j6jxNV7HWC9nAK+Eq/XT2cGsRmBjvt+ag3ULnGJ W0/mM0EcLSCxZM95ZghbVOLl43+sEPWiEnfa1zNC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+w TGAUm4Vk7CwkLbOQtMxC0rKAkWUVo3BuYmZOermRXmpRZnJxcX6eXnHqJkZgfB3c8lt1B+Od cyKHGKU5WJTEea237vEXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMgcxHlLPvZ59rv196bs +MwynTeY06ln1parnGZntzGV/A23PP25m3Mfe2jY+voA3n+PPu8S2qG8h79Nc92N/TcZ1Hq3 2u1es69v0kEGxuO7nOxY+5rbTssdXFLQmd78c1vwr8J31578yNnmwHAq4MSKsAIvHkabFVz/ 3xi1tugcmrz6+YvPVycqsRRnJBpqMRcVJwIAhfAD2n0CAAA=
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 09:51:07 -0000

Hi Cullen,

>> 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.

I agree. I appologize for making too many assumptions. The 180 IS sent reliably, there IS a PRACK, and there IS a response to the UPDATE.

> 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. 

We could even make it more simply by removing the forking part, ie there is a reliable 180, follwed by an UPDATE. But, for now, let's continue with the flow above...

(I have added some numbering to your text below)

>1. One fork to UA1, and one to UA2.


>2. The JS App needs to pick which one it is going to choose to have a media session with.


>3. Let's say it choose UA1, then it would map the Answer 1a to an Answer, the Offer2 to an offer.

Here comes the issue:

According to jsep-02, when Offer2 comes the JSEP O/A state machine is in the "pranswer" state, where a new offer is not accepted.

And, yes, we could fix that by accepting a new offer at that point. But, to which state would be then go?

>4. 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.


>5. 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.

I am assuming serial forking. Once the answer from UA2 has been provided to the browser, I don't care if the media session with UA1 goes away.

But, again, my main issue at this point is not about media - it's about how the offers and answers between the JS app and the UAs are mapped to JSEP offer/pranswer/answer.

> 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.

No disagreement from my side there :) 

> 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.

At the moment, JSEP-02 does talk about cloning. I don't know whether you suggest that to be removed, but if it stays it would work also for serial forking.