Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

"Ravindran, Parthasarathi" <> Mon, 14 May 2012 08:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32B6821F859E for <>; Mon, 14 May 2012 01:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.492
X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KkbANJuUmbOD for <>; Mon, 14 May 2012 01:39:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B14721F84CE for <>; Mon, 14 May 2012 01:39:26 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Mon, 14 May 2012 01:39:26 PDT
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 14 May 2012 04:39:39 -0400
Received: from ([fe80::8d0f:e4f9:a74f:3daf]) by ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 14 May 2012 14:09:21 +0530
From: "Ravindran, Parthasarathi" <>
To: Cullen Jennings <>
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Date: Mon, 14 May 2012 08:39:20 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericss> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Randell Jesup <>, "" <>
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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: Mon, 14 May 2012 08:39:28 -0000


In case PRANSWER is designed for interop with SIP forking with ICE handling, 
then PRANSWER is not required because SIP (RFC 3261) never allows multiple
answer within the same dialog. In case of each forked response (18x/200 with 
new To-Tag), SIP UA creates new dialog and those dialog has to be handled 
separately. How grouping of those SIP dialogs works together is a implementation
issue in SIP. So, there is no need of new O/A state (PRANSWER) just to make 
SIP interop happen. Please let me know any other usecase which compels 

I agree with you that most of the deployed SIP end-point products does not 
Support parallel forking and its next hop B2BUA (PBX, SBC, GW) takes care
of the handling. Having said that, some of the well deployed SIP entity in 
service provider (SP) network is based on SIP forking which compels to 
support forking in actual End-point or B2BUA. I know that it is possible
to design JSEP without forking support and interop with SIP is possible which 
will be equivalent to H.323 to SIP gateway development wherein H.323 never
supports forking. Now the question is whether JSEP API supports forking 
or not. I'm lean towards forking because the same peerconnection cloning API 
may extend for browser media mixing later stage. If you explain about my 
mixing API idea is wrong, then I'll agree with you that cloning of peer 
connection is not required.


>-----Original Message-----
>From: Cullen Jennings []
>Sent: Friday, May 11, 2012 12:36 AM
>To: Ravindran, Parthasarathi
>Cc: Justin Uberti; Christer Holmberg; Randell Jesup;
>Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in
>I'm a very confused on what type of forking (with ICE) use case people
>want to satisfy.
>I agree with you that PRANSWER does make things more complicated but I
>presented at several of the meetings about how things just don't work
>without it or something like it so I don't see how to avoid it.
>On May 9, 2012, at 12:34 AM, Ravindran, Parthasarathi wrote:
>> Hi Justin,
>> Sorry for the delay in reply. There are two issues associated with
>this scenario:
>> Issue 1) SIP Forking : This is solved by peerconnection cloning
>> Issue 2)  UPDATE support within SIP early dialog in the non-forking
>scenario. Here, the cloning will not solve issue as the answerer
>originated the new offer during SDP_PRANSWER state . Issue 2 is the
>title of this mail thread.
>> IMO, SDP_PRANSWER will complicate the offer/answer state machine.
>> Thanks
>> Partha
>> From: [] On
>> Behalf Of Justin Uberti
>> Sent: Tuesday, May 08, 2012 8:40 PM
>> To: Christer Holmberg
>> Cc: Randell Jesup;
>> Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in
>> The conclusion on this thread seems to be that the right way to
>address this problem is via PeerConnection cloning, and that no changes
>are needed to the JSEP state machine. I'll work with Richard to figure
>out how we should extend JSEP to support cloning.
>> On Thu, May 3, 2012 at 5:16 PM, Christer Holmberg
><> wrote:
>> Hi,
>> >>>>You could also choose not to alert the remote user until the ICE
>procedures have finished - more or less using ICE with preconditions.
>> >>>>
>> >>>> Of course, that is going to trigger actions in STUN/TURN servers,
>> >>>> even if the called party won't accept the call, but at least from
>a user experience perspective that is still better than lifting the
>hook, and having to wait for whatever-time-it-takes-for-ICE-to-finish
>seconds before one can start to talk.
>> >>>
>> >>> This also has a downside of disclosing user's IP to the caller
>without the user confirmation. For a lot of applications this can be
>serious security flaw.
>> >>
>> >> The client can still log when ICE procedures occur.
>> >>
>> >> Because, even if I wait until your phone starts to ring, most
>likely I would still get your IP address without user confirmation
>(speaking in SIP terms, phones normally don't ask for user permission
>before they send 18x with SDP), eventhough you would easier be made
>aware of that it happens.
>> >
>> > Another alternative is of course to do ICE with an SBC, and/or
>> > having an SBC doing ICE on behalf of you :)
>> >
>> >
>> > This is true for SIP but was as far as I know was specifically
>> > designed around in WebRTC. WebRTC signaling server acts as B2BUA so
>any type of ringing notification goes through the web server and does
>not need to carry any type of client address information. The client
>address information is only provided when SDP answer is sent or ICE
>negotiation is started.
>> Assuming you are only going to make user confirmation (read: accept
>calls) in cases where you absolutely sure that the caller isn't someone
>trying to get your IP address.
>> But, never the less, having a solution where I first have to give user
>confirmation, and then wait until I can start to talk, is probably
>something most people want to avoid. Depending upon, of course, how long
>the waiting time is.
>> Regards,
>> Christer
>> _______________________________________________
>> rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list