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

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Tue, 09 October 2012 14:11 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE921F0C8E for <rtcweb@ietfa.amsl.com>; Tue, 9 Oct 2012 07:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.528
X-Spam-Level:
X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyheYyx5heyQ for <rtcweb@ietfa.amsl.com>; Tue, 9 Oct 2012 07:11:32 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C51FF1F0C70 for <rtcweb@ietf.org>; Tue, 9 Oct 2012 07:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1724; q=dns/txt; s=iport; t=1349791893; x=1351001493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dqm0/nZlOEN11ZkNZeNnxupKYUBdi2aLhxV31zdiCq0=; b=JiVlSaPTT1vD1y4mOiu4l2e9q31cu733pfNdK9kjiVS3wiWhuPdrvuH0 ho22FCuOoSt+Yipc1I5TN3qq7NUIDj2154AfzYNDS0MH00fV74dkYXqGB fTrGpo/1ecT4v/oLUNeIOeWI37bX4SGBkicJS6KJGp0ITl+ojWFMvcXYU 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EANUvdFCtJXG8/2dsb2JhbABFvy6BCIIgAQEBAwESASc4BwULAgEIIhQQMiUCBA4FCBqHXQabRo9WkD2LOYUzYAOkL4Frgm2CFw
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129779927"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2012 14:11:29 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q99EBTbo029091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 14:11:29 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 09:11:28 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: AQHNpad+aenXLuIV20+kkVz1nsB6XpewgfNAgADWtgA=
Date: Tue, 9 Oct 2012 14:11:28 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB111881070@xmb-aln-x02.cisco.com>
References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <CABkgnnUFvw_J2+tvVBoHrzR9ZRkPT-6LhXvbaz_U1P7gqtJ4xw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <CABkgnnV6NcTeh=L_fpkpLv5UpkUSuacmQUtYwNKKwAfcb5+JQA@mail.gmail.com> <506D4F7A.5020109@alvestrand.no> <CABkgnnUgHRw4dtihk2fZppmzVWuV4hpvWtXt70N1HWQpJ+KsZw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <CABkgnnV+jHWF3t8s3t37pbQyXJEP9N_MyHWd3SsfoNrhMU=NXw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> <CABkgnnVFWDroiTWVOm6F3FRQ6dDkRjKdyV8apRK=0Y_ReYtmPA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se>, <CABkgnnUR6XL4QLmZAUVqnB5S+UFh7sfmzkDzfjK52+e9_FFkJg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5E@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB11187F8C2@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0861@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0861@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.121.138]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003
x-tm-as-result: No--36.264700-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: <074C0077C442194A9270307C626A207D@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2012 14:11:33 -0000

On Oct 8, 2012, at 23:26 , Christer Holmberg <christer.holmberg@ericsson.com>
 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. 
> 
> I am not sure what you mean by "an answer that has not relation to the offer". Answers are always related to the Offers.

Sorry - that was poorly written. Lets say you had two PeerConnection call them A and B and they both create an offer and far sides sends answers to both offers. Now if you take the answer from offer B and use it as the answer for A, all bets are off and bad things will happen. That is what I meant by if you use an answer that had no relation to offer it needed to be associated with. 

> 
> Regards,
> 
> Christer