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

Christer Holmberg <> Wed, 02 May 2012 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43A8A21E8088 for <>; Wed, 2 May 2012 13:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.12
X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 RPmH05yufQ5t for <>; Wed, 2 May 2012 13:41:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5530111E8091 for <>; Wed, 2 May 2012 13:41:37 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-70-4fa19bf23f8a
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 AC.B8.26681.3FB91AF4; Wed, 2 May 2012 22:41:23 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Wed, 2 May 2012 22:41:22 +0200
From: Christer Holmberg <>
To: "Ejzak, Richard P (Richard)" <>, Roman Shpount <>
Date: Wed, 02 May 2012 22:41:22 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0ogHSgvJMuob7cRgKJl8G8+8zPnAAACjMAAAf1TrAAAKGjyg==
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==
Cc: "" <>
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: Wed, 02 May 2012 20:41:38 -0000


>Regarding whether we need to be able to simultaneously support multiple remote locations (forking), I have >reluctantly concluded "yes" after thinking about it for a bit.
>The UPDATE scenario from Partha is not the only reason we need the concept of peer connection cloning (or >something similar), although it is sufficient in itself.  As soon as you get multiple answers from different forked >targets, it is necessary to separately keep track of ICE and DTLS progress with each target, not to mention >RTCP.

...unless you, when you receive an answer from a new target, terminate the leg with the previous forked target.

>Otherwise ICE and DTLS results from one target will get overwritten by those from another and then need to be >redone again if an earlier target is selected as the winner. 

I think that is unlikely to happen, as forking is normally done in a serial manner (to avoid other issues associated with parallel forking).

I am not saying that there aren't use-cases that would break, but my question is still whether we can live with that restriction.



-----Original Message-----
From: [] On Behalf Of Christer Holmberg
Sent: Wednesday, May 02, 2012 11:29 AM
To: Roman Shpount
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP


>> Do people think that is not enough, and that we would need to support multiple remote locations
>> simultanously (no matter whether it's implemented using cloning or something else)?
> I never thought that was enough if we are to interop with anything that support forking. Latest example from > Partha shows that this is indeed the case.
> I actually think that adding support for forking is trivial (order of magnitude less complcated then DTLS-
> SRTP or identity) and would simplify interop as well as enable numerous additional calling scenarios.

It's not about forking as such - I also agree we need to support that.

The question is whether we need to *simultanously* need to support multiple remote locations, or whether we only have one "active" remote location, but we allow switching from one to another (based on where the previous answer can from, or whatever policy).


rtcweb mailing list