Re: [rtcweb] Agenda requests for Atlanta meeting

Paul Kyzivat <> Sun, 14 October 2012 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED6DA21F845D for <>; Sun, 14 Oct 2012 12:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.057
X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ZgIAi25YiUW for <>; Sun, 14 Oct 2012 12:43:33 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:40]) by (Postfix) with ESMTP id 20CAD21F8421 for <>; Sun, 14 Oct 2012 12:43:32 -0700 (PDT)
Received: from ([]) by with comcast id B7Me1k0030Fqzac547jdD6; Sun, 14 Oct 2012 19:43:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id B7eN1k00J3ZTu2S3U7eNAr; Sun, 14 Oct 2012 19:38:22 +0000
Message-ID: <>
Date: Sun, 14 Oct 2012 15:38:31 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
References: <> <> <> <> <> <>, <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting
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: Sun, 14 Oct 2012 19:43:34 -0000

On 10/10/12 4:03 AM, Christer Holmberg wrote:
> Hi,
>>>>> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264.
>>>> RFC 3264 doesn't describe PRANSWER.  The concept is entirely absent.
>>>>   The offerer MAY immediately cease listening for media formats that
>>>> were listed in the initial offer, but not present in the answer.
>>>> "the" answer.
>>> I agree with Martin. 3264 O/A is always per dialog, and forking is supported by generating multiple dialogs. JSEP, OTOH, in order to support forking with a
>>> single "dialog" (peerConnection local descriptor), now defines O/A as offer+any number of pranswers + answer.
>>> So, we would e.g. have to define what happens if a new offer is received from the remote side while the browser is in pranswer-received state (see my call flow in another reply).
>> 3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane.
>> I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be.
> The *initial* O is shared across multiple legs. Once a dialog has been created, O/A transactions on that leg will not affect other legs.


I'll also observe that you can have early dialogs without reliable 
provisionals. E.g.:

- A sends INIVTE offering codecs C1 and C2
- proxy P forks first to B.
- B sends unreliable 180, tag BBB, with answer selecting codec C1,
   and starts sending media.
- P cancels the invite to B and forwards the invite to C
- C sends unreliable 180, tag CCC, with answer selecting codec C2,
   and starts sending media
- C sends 200 with same answer as before.

Note that A must not invalidate the use of C2 when it receives the 180 
from B, unless it first clones the invite. It must leave it eligible for 
use on other dialogs. And of course while it can manage separate O/A 
state machines per dialog, down at the RTP stack it may not be able to 
correlate the incoming media with a particular one of those O/A state 

(Consider the example above, but the 180 from B is lost - never received 
by A. Since it isn't reliable, nobody knows this. But the media still 

Of course things are a bit different when you layer ICE on top of this. 
I won't try to discuss that.