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

Christer Holmberg <> Thu, 03 May 2012 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 539F421F866E for <>; Thu, 3 May 2012 11:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.133
X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 N9buGibPCbqa for <>; Thu, 3 May 2012 11:55:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 92E8E21F866B for <>; Thu, 3 May 2012 11:55:50 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-73-4fa2d4b4648b
Authentication-Results: x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA)
Received: from (Unknown_Domain []) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by (Symantec Mail Security) with SMTP id EA.92.26681.5B4D2AF4; Thu, 3 May 2012 20:55:49 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 3 May 2012 20:55:48 +0200
From: Christer Holmberg <>
To: Randell Jesup <>, "" <>
Date: Thu, 03 May 2012 20:51:23 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0pSy9uyFZgrYh+TFeIIxIfDOFlqwAEo043
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: AAAAAA==
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: Thu, 03 May 2012 18:55:51 -0000


>>     (Another option, if we want to support parallel forking, would of
>>     course be to create a completely new PeerConnection, with a *new*
>>     local IP address:port. But, you would of course then have to provide
>>     that information to the remote peer.)
>> This would probably do absolutely nothing to SIP interop. And if we do
>> not need SIP interop we can live without forking (at the cost of being
>> slightly less efficient in some call setup scenarios).
> Ignoring SIP interop, this might work as an equivalent to cloning, but
> requiring an extra O/A exchange (and adding considerable chance of
> clipping on a second fork being activated).

Assuming you have to perform the ICE procedures anyway, I don't think it would cause clipping. It probably would cause some additinoal call setup delay, though, as you need to perform that extra O/A exchange before the ICE procedures can start.

>>     I have no strong feeling on whether we want to do cloning, but do
>>     people agree that, for a given PeerConnection, we only need to
>>     support a single remote peer (which can be modified, though)?
>> I think if we do cloning we will only need to support a single remote
>> peer per PeerConnection. Strictly speaking even updates due to
>> provisional responses would not be necessary, since you can always clone
>> the connection and provide a new answer to it instead.
> I believe that's correct.

Sure. But, that would also mean that you would have to clone the PeerConnection mid-session, if the remote entity changes.