Re: [rtcweb] PRANSWER is unusable for serial forking

Christer Holmberg <> Tue, 09 October 2012 06:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42FE221F873E for <>; Mon, 8 Oct 2012 23:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.127
X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 aIwc3+pJZJ3c for <>; Mon, 8 Oct 2012 23:41:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E626F21F8737 for <>; Mon, 8 Oct 2012 23:41:02 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-c0-5073c6fdcbd6
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7C.8C.11467.DF6C3705; Tue, 9 Oct 2012 08:41:01 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Tue, 9 Oct 2012 08:41:01 +0200
From: Christer Holmberg <>
To: Roman Shpount <>, Cullen Jennings <>
Date: Tue, 9 Oct 2012 08:40:59 +0200
Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking
Thread-Index: Ac2lyEt4PP2ZmsRWR5SrEKyXeCpPxwAH1vuQ
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre7fY8UBBrNW2lh8WP+D0WLGhanM Fmv/tbM7MHssWfKTyePy+Y+MHremFAQwR3HZpKTmZJalFunbJXBltEz/x1pwUabi0eFZjA2M i8S6GDk5JARMJJqO3WOBsMUkLtxbz9bFyMUhJHCKUeLphH9MEM4CRolrJxcCVXFwsAlYSHT/ 0wZpEBFwk3g74w0riM0soC5xZ/E5dhCbRUBF4tH/w4wgtrCArUTj2xlMEPV2EhM+7GOHsI0k Tnw6BRbnFQiXmPrnBVi9kECAxOWtX8FmcgoEStz6cBQszgh03PdTa5ggdolL3HoynwniaAGJ JXvOM0PYohIvH/9jhagXlbjTvp4Rol5P4sbUKWwQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzECo+nglt+6OxhPnRM5xCjNwaIk zsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PNwazTco1ZlpOOyXtzsiuUvr/saFzF NzeDTf3aGoG4npg55aFlsk0l2z5efuPTbyD91+6G00VPndj1Fp37dqU/DrioeuL/DZbDEdy7 c1de8Vu/Omftnom3V/37ddt+/teMlnKhG2vO5Mbf9jfo8tySpLlx68UTEY/FJA7off1VWVZk Mn+F0H8lluKMREMt5qLiRAB6H4A3dAIAAA==
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: Tue, 09 Oct 2012 06:41:04 -0000


I THINK Roman is talking about the following flow:


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

What is "????"?

Note that this is NOT about parallel forking, and which media is played to the user - the JS APP can make that decision based on whatever policy. The question is how the UPDATE is mapped to the JSEP API.



From: [] On Behalf Of Roman Shpount
Sent: 9. lokakuuta 2012 5:46
To: Cullen Jennings
Subject: [rtcweb] PRANSWER is unusable for serial forking

Changing subject

On Mon, Oct 8, 2012 at 10:30 PM, Cullen Jennings <> wrote:
>  The only issue is the there is currently no way to map an UPDATE received in the early dialog to WebRTC API calls. I am probably OK with it not being handled until the cloning is implemented, but this shows that PRANSWER is not very useful even for the serial forking.
How do you think this work in a SIP only system? Lets say A sends the invite with offer to proxy that forks to B. Then B does 180Rel followed by an update. Then the proxy forks to C on a new dialog. Do you think C can send send early media to A and A is actually going to play it? And what if B use still sending media - it that case A will be getting media from B and C at the same time. Do you have devices that do that?  Most people just seem to make voicemail work fine without needing to introduce this type of complexity. If you know what you want A to do in this case, I think we can figure out how to make that happen - there's been a lot of discussion about what a SIP device receiving early media from two places should do and there was never any really great answer other than don't do that.

The meta issue here is thought this is serial forking at the signalling level in SIP, it is actually parallel forking from a SDP / media  point of view.

The case that started this all was use UPDATE in awaited RFC says is not allowed. I'm not arguing there are not cases where clone would be useful, but I do think all the voicemail systems I am familiar with would work fine with the the simple PRANSWER.

This actually works fairly well in the current systems. The fact that UPDATE is used does not mean there are multiple media streams flowing at any given time. And, I am familiar with a couple of systems that do exactly what I have described. Typically some sort of announcement or color-ring-back system followed by a voice mail. I think the problem is that this group picked one interop scenario and added something to support it while arbitrarily deciding that other scenarios should not be supported. SIP does not have serial forking. Offer/Answer does not describe something like this. We either need to define it and make it something that describes some set of existing scenarios or add support for something that is defined.
Roman Shpount