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

Christer Holmberg <> Thu, 03 May 2012 06:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D490021F860B for <>; Wed, 2 May 2012 23:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.124
X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.125, 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 aLwRKyEoBxfL for <>; Wed, 2 May 2012 23:02:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9251121F854C for <>; Wed, 2 May 2012 23:02:47 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-1c-4fa21f857695
Authentication-Results: x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA)
Received: from (Unknown_Domain []) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by (Symantec Mail Security) with SMTP id E3.DE.03534.58F12AF4; Thu, 3 May 2012 08:02:46 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 3 May 2012 08:02:45 +0200
From: Christer Holmberg <>
To: Roman Shpount <>
Date: Thu, 03 May 2012 08:02:44 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0oqGjgQiWJ3cAZRvWmmuieyMazqQASTrzg
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: Thu, 03 May 2012 06:02:49 -0000


>> 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 sure why you would say that most forking is serial. It is quite often parallel. What is commonly done to avoid support for multiple 
> parallel media streams is playing media from the newest received RTP stream. In either case there is no guarantee that you picked the 
> winning stream, and you always need to make sure that you use the SDP received in the dialog that got 200 OK and that media playback 
> switches to RTP stream that remains. Making this work is often problematic in SIP since there is no way to associate received RTP with 
> received SDP information due to RTP being sent from a different IP/port from the one used in SDP. It should be easier with WebRTC 
> since ICE support is required and remote party IP/port can be determined for each flow.
> Finally, when you are dealing with forking you need to keep track of the remote IP/ports and ICE candidates for each dialog. You can 
> play media from only one of them, but this remote connection state is required to complete the call setup when 200 OK is received.

You are absolutely right. I still question whether we need to support parallel forking. If you say it occurs often, I can't argue against you, eventhough my own experience is different :)

(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.)

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