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

Roman Shpount <> Thu, 03 May 2012 15:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FB1121F84F8 for <>; Thu, 3 May 2012 08:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.851
X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uLbYq3w8jjvz for <>; Thu, 3 May 2012 08:01:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2231A21F84D1 for <>; Thu, 3 May 2012 08:01:09 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1757674bkt.31 for <>; Thu, 03 May 2012 08:01:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lK/ZKfM4zxNteret3YOOxeDc1Ne8dSTDVMsoZ+Ga7i8=; b=fDm3GYdRy9qhJHDL+HylzqYs6xDwp0oTPZDxKUOBEY1ymNBYvg9I1H9I9l6c4Z1LXE t/ozwc++fxMPWN+m2PmS/+Oj9ElSgzMs4InOdsdabMXMg6oOXmLIpSxOFa5NNJqJVeDe CI4I98x9gRwXuBzxcAA0SUbENlAw7/BYKQyERsWkQSZ03TOf+hASuIkBdiOyzBM8JRdx dkEnXoglPyrefBLZsjXbpurkNqnCCV028/lUQSfRVmi++75WwlblUQ1h9q0jfmGZ3VeK DwYvXEGXjJBOxCxpF2G3MNzWqwgkvi6Uhimp9riSPabFGzohk5GKHZkaBxogSBC8j9qT t89A==
Received: by with SMTP id gm13mr843061bkc.79.1336057268981; Thu, 03 May 2012 08:01:08 -0700 (PDT)
Received: from ( []) by with ESMTPS id f11sm11273511bkw.6.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 08:01:06 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1757573bkt.31 for <>; Thu, 03 May 2012 08:01:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id k13mr885922bku.51.1336057264863; Thu, 03 May 2012 08:01:04 -0700 (PDT)
Received: by with HTTP; Thu, 3 May 2012 08:01:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 03 May 2012 11:01:04 -0400
Message-ID: <>
From: Roman Shpount <>
To: Christer Holmberg <>
Content-Type: multipart/alternative; boundary="0015175d67b4abfb7204bf2312d4"
X-Gm-Message-State: ALoCoQldQwgUSWRn8W/BuxogdUTV8xG4I7VEXrOEF+Ij4/W8JHGrBWZo9nPok0rnQ4xPs+Xnlm9g
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 15:01:17 -0000

On Thu, May 3, 2012 at 2:02 AM, Christer Holmberg <> wrote:

> 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,
> even though my own experience is different :)
You do end up with parallel forking when you allow registrations from
multiple devices. This is a policy option, but once you enable this,
parallel forking or B2BUA are the only options. Furthermore, even if you do
serial forking, you end up with multiple parallel media streams being
received by the client due to loose synchronization between RTP streams and
SIP signaling. The main discrepancy between current WebRTC signaling model
and SIP is that in SIP, when you do forking, you still have separate
dialogs that each maintain state. Even if only render media from one RTP
stream, black hole all the other media, and send media to one RTP
destination, you still have dialog specific SIP and ICE state that you can
update (for instance due to UPDATE transaction) and recover if the
currently selected dialog ended up not being the one that was selected in
200 OK. This is not an option with WebRTC.

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

> 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.
Roman Shpount