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

"Ejzak, Richard P (Richard)" <> Wed, 02 May 2012 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01D4021E80FD for <>; Wed, 2 May 2012 13:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.598
X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tr8WRkOz+YF6 for <>; Wed, 2 May 2012 13:27:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5600821E80E7 for <>; Wed, 2 May 2012 13:27:59 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id q42KRu2O026451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 15:27:56 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id q42KRtv4030791 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 May 2012 15:27:55 -0500
Received: from ([]) by ([]) with mapi; Wed, 2 May 2012 15:27:55 -0500
From: "Ejzak, Richard P (Richard)" <>
To: Christer Holmberg <>, Roman Shpount <>
Date: Wed, 02 May 2012 15:27:53 -0500
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0ogHSgvJMuob7cRgKJl8G8+8zPnAAACjMAAAf1TrA=
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-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
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:28:00 -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.  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.  To me this is not acceptable, hence my reluctant conclusion.

Maybe it could work if we simply delay ICE, DTLS, RTCP and media until we decide on a final ANSWER, and any nested offer/answer transactions (i.e., Partha's example) are handled at the JS layer only without interaction with the peer connection.  Does anyone think this is an acceptable approach?  Not I.


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