Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

"Cullen Jennings (fluffy)" <> Mon, 08 October 2012 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F273111E809B for <>; Mon, 8 Oct 2012 15:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.458
X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OV0grsB7Sp6X for <>; Mon, 8 Oct 2012 15:51:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A1BA11E80FF for <>; Mon, 8 Oct 2012 15:51:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2136; q=dns/txt; s=iport; t=1349736707; x=1350946307; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T79wS4EY2O6hRYd1/3LjPXYnS+wxBt7w1v1kRc9f83w=; b=EpR6ZVbfawzAFR2qZKZveb+aJoV9gd4KjF+eEPo1k5MDH+si/JHZMTHR srDPFYFRHSP0hO+BYA/drtlKyd5eLdPk9yxpxLrlV88OJgfs+vld0oIAq Etg+rQoLYaphnMbAjlSUvE6idpgNltLAEffqqHUVhj5Ezd7DezFv9zPMj E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="126526569"
Received: from ([]) by with ESMTP; 08 Oct 2012 22:51:47 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q98MpkLa027072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:51:46 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:51:46 -0500
From: "Cullen Jennings (fluffy)" <>
To: Christer Holmberg <>
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: AQHNpad+aenXLuIV20+kkVz1nsB6Xg==
Date: Mon, 8 Oct 2012 22:51:46 +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--39.268400-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] JSEP: Relaxing SDP O/A rules?
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: Mon, 08 Oct 2012 22:51:48 -0000

On Oct 6, 2012, at 11:38 , Christer Holmberg <> wrote:

> Hi,
>>>>> Can I use the same local descriptor for every setLocal() call?
>>>> My experience suggests that you can.  However, that's not stipulated
>>>> in the API specification, so it's not an ironclad guarantee.
>>> If it doesn't, and a new local descripor is created, you would need to send that one to the remote 
>>> endpoint.
>> You don't create a new description, you just set one.
> Correct.
>> The only problem arises when you can't set the local description because
>> something broke since you last set it.  (Maybe setting the answer
>> caused the browser to release something that you need to set the

If you send an answer that has not relation to the offer, you are equally hosed. We are keeping the pairing of the offers and answers in the JS state so there are ways that the JS can mess things up if it is buggy but that not really a PRANSWER problem - it's just as much a issue with offers and answers. 

>> offer.)
> That is the main difference between PRANSWER and ANSWER: PRANSWER does not release local resources based on the answer.

Exactly - and the important implication of this is that the far end can keep using the resources that were in the  Offer. Sequential forking is a poster child for one of the cases where you need to do this but there are others.   

>> If that happens, you are hosed.  You could try to make a new PeerConnection, but you'll have to resend your INVITE because you will
>> get a new set of candidates, ufrag, pwd, etc...
> Or, you could set the new local descriptor BEFORE you apply the answer to the previous one. I think that is how the cloning is currently described in JSEP: the cloning happens first (eventhough it may never be used, if no additional remote peers are contacted).
> Regards,
> Christer
> _______________________________________________
> rtcweb mailing list