Re: [rtcweb] Agenda requests for Atlanta meeting

"Cullen Jennings (fluffy)" <> Tue, 09 October 2012 20:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7560C1F0422 for <>; Tue, 9 Oct 2012 13:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -108.641
X-Spam-Status: No, score=-108.641 tagged_above=-999 required=5 tests=[AWL=-1.831, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OSQY1obdiMHp for <>; Tue, 9 Oct 2012 13:05:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8A20B1F040A for <>; Tue, 9 Oct 2012 13:05:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3061; q=dns/txt; s=iport; t=1349813145; x=1351022745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HcrxLONdBmJhiOqqoHyS64hUFh58oYFlpeWpIpFzCgw=; b=ZqQJSFcfMqnlTNr4hNsF69uPle6pVmiILlau0sTBTciKlBHtkKzKZCF6 yqeL3GhpdXGQHymqcj5PEjAGYiAlbMGLel9M+J5XlxTd8WakWi5eFLE/i sAh1ZtGQCDvm7Zk6NnngU8zsCRPJ/SOISDVD7HT3G9hNq/8UIKIELS1t0 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAE2DdFCtJXHA/2dsb2JhbABFvzCBCIIgAQEBAwESASc/BQsCAQgiFBAyJQIEDgUIGoddBpooj1iQRItDhTNgA5I6kXaBa4Jtghc
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129932230"
Received: from ([]) by with ESMTP; 09 Oct 2012 20:05:29 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q99K5TH7026397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 20:05:29 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 15:05:29 -0500
From: "Cullen Jennings (fluffy)" <>
To: Christer Holmberg <>
Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting
Date: Tue, 09 Oct 2012 20:05:29 +0000
Message-ID: <>
References: <> <> <> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--34.803200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 09 Oct 2012 20:05:48 -0000

On Oct 9, 2012, at 12:04 , Christer Holmberg <>

> 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. 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 the PRANSWER vs ANSWER. 

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.