Re: [rtcweb] Agenda requests for Atlanta meeting

Christer Holmberg <> Wed, 10 October 2012 08:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2745321F843A for <>; Wed, 10 Oct 2012 01:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.233
X-Spam-Status: No, score=-4.233 tagged_above=-999 required=5 tests=[AWL=-1.773, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, HELO_EQ_SE=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id okm1Omu-Kor9 for <>; Wed, 10 Oct 2012 01:03:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1CCCF21F8230 for <>; Wed, 10 Oct 2012 01:03:32 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-9c-50752bd3eb72
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 56.B6.17130.3DB25705; Wed, 10 Oct 2012 10:03:32 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Wed, 10 Oct 2012 10:03:31 +0200
From: Christer Holmberg <>
To: "Cullen Jennings (fluffy)" <>
Date: Wed, 10 Oct 2012 10:03:30 +0200
Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting
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: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre4V7dIAg43zWC06JrNZXDvzj9Fi 7b92dgdmjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZ9yc9Zi2YKFXxdp16A+NB kS5GTg4JAROJvR3b2CFsMYkL99azdTFycQgJnGKU+LO6kwnCWcgosePER9YuRg4ONgELie5/ 2iANIgKGEk175jGB2MwCIRIPz75jBilhEVCVeHJPAiQsLGApsWjzfjaIciuJNbeuM0PYYRJr l5wFs3kFwiVu7ZvLCrHqGYvE1U1zwBo4BXwlfs1ayAJiMwId9/3UGqhd4hK3nsxngjhaQGLJ nvPMELaoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WuoxYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkbh3MTMnPRyc73Uoszk4uL8PL3i1E2MwFg6uOW3wQ7GTffFDjFKc7AoifPq qe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cB4Wizok/XbG6E7/Je9fp0vk7MpROLUC1XV bXVHuj2q3NhfbL0n+XdSQ5Dk1PXcm19pHb2Vzacnfu2s6sqtE/L+tUxr/Tpf20VuPtfTDPfm X2uzHcoTv6vWBkey97DzWqr/zz7xZlPXdNXjKTvNXkdcEHZyl9tQfLg5ZZ/UnE8BS3Nj1NjW +lxTYinOSDTUYi4qTgQA10tNbXMCAAA=
Cc: "" <>
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: Wed, 10 Oct 2012 08:03:34 -0000


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

> So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs). 
> The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the 
> browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes 
> it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that 
> no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is 
> People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in 
> stone but the bottom line in the code is very simple to understand. When creating the offer you alloced some resources ( like a port to receive video on ). When you
> get an answer that does not use that resource, you need to tell the media stack if it should free the resources or not. O/A has situation where you need to keep the 
> resources available (like there are more dialogs coming) and situation where you need to free the resource.  Since we split the signalling out of the browser and left 
> the media in the browser, we need be able to allow the JS that is dealing with signaling to tell the browser when to free the resource. 

I don't know who "people" is, but at least I have only been talking about the O/A *signaling* :) Media is a separate issue.