IETF Logo Mail Archive

Re: [rtcweb] Followup to discussion of O/A and codecs from Friday session

Taylor Brandstetter <deadbeef@google.com> Fri, 08 April 2016 22:36 UTC

Return-Path: <deadbeef@google.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 3787012D5DB for <rtcweb@ietfa.amsl.com>; Fri, 8 Apr 2016 15:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nJc2qNKZFns for <rtcweb@ietfa.amsl.com>; Fri, 8 Apr 2016 15:36:12 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA09012D14D for <rtcweb@ietf.org>; Fri, 8 Apr 2016 15:36:11 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id t10so151149467ywa.0 for <rtcweb@ietf.org>; Fri, 08 Apr 2016 15:36:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5ocKPoRMzMOMwrbjLvbFgn37BUumP6cMS+ZLHyVgalo=; b=oDxI9D9yW0c8IuPLEGLqvKZk9NnWOTh5mFvN9LAxz5gDc42kDFz4z6+eF62FGXCh2/ J2LPAUZNOM/OEGYevq0vkmi06bdPq9XM63fpZB7u3WUnUqWoXfZhAaDqq++9BlAtGT4n NEBoL2kyfReEYLimsbBpEL7RLcvc4Sa7PoAE8sERy/4aN3E70YgOSGY22nXFMSVz+NLy C45Yc97etKgcUavIRDF1kk9pHJ/MY1Fb4gBphxU+90uk6sXN/0FBakJ5nk/4rDvCPlOY CuSjIrPcyV6BURV69KDzZyNBYRfDqLK7dlnLwQb/GhGU7DNBGQk5zOCe6qe1y/6/p2d5 sFBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5ocKPoRMzMOMwrbjLvbFgn37BUumP6cMS+ZLHyVgalo=; b=lDfdy4Hlb72Bf2LcmX2+AAQuYyAn4DD8HQ2pYFM/9MXVAVK/V//uo9F/u7Setw67iC HG2EvEUwj9cAykg75SwObNqaPQvnGX+2xNnD5gNphAOufo+nHrsdvXPPpqhySwxCs678 mAXEzGcvrd3/em2fcmMo+JNRp7dvAYs64Y5CDOVYbN1pAba7k/KcniFxnH/D8rw2Hr8X /P263OPqkCy2h+SbXsBf1nKMjzc3XNoIiWMOnCCFeQK+sODJ3DQkJUDYmlW9e8LZo8mn NMdwHv71dLLwGEBYQJlRN+4dvnAR4ToATl2AYjrE3m8TEOIWoBaYl7FAyP5X1eAEYE/s AE8w==
X-Gm-Message-State: AD7BkJKMybfPI2aTaU5Sv71sJodasaozv4Khou7n8xtFalkJaEqnE7edCnNQ6Z9L3P66Ex1YTW0mge0XPhghhI7U
MIME-Version: 1.0
X-Received: by 10.37.66.21 with SMTP id p21mr6127165yba.77.1460154971034; Fri, 08 Apr 2016 15:36:11 -0700 (PDT)
Received: by 10.129.98.9 with HTTP; Fri, 8 Apr 2016 15:36:10 -0700 (PDT)
In-Reply-To: <CAD5OKxuaxNEP6+vkzFTXi3Cacp3OEYuKMSNbPMHwpMjiNb+SiQ@mail.gmail.com>
References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> <CAK35n0b=Qa5JxqrMUdSH92uw4U3=HyFuKSspZjgKN8vn_MuSqg@mail.gmail.com> <CAD5OKxuaxNEP6+vkzFTXi3Cacp3OEYuKMSNbPMHwpMjiNb+SiQ@mail.gmail.com>
Date: Fri, 08 Apr 2016 15:36:10 -0700
Message-ID: <CAK35n0bk2jXJTgzutzzktoo1cEWgk1Vfofg7_DkDcyV5j_zdtg@mail.gmail.com>
From: Taylor Brandstetter <deadbeef@google.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: multipart/alternative; boundary="001a11c00a305e0f9a053000d228"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/LXOa8KJi1RNXSq3H7hNChMlWQrc>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday session
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 08 Apr 2016 22:36:13 -0000

I understand if that was the intent, but that's not what RFC 3264 seems to
say. Both Section 6 and Section 8.3.2 state that the answer MUST send a
codec listed in both the offer and the answer.

So is RFC 3264 wrong? Or is my interpretation of the rule wrong?

On Fri, Apr 8, 2016 at 3:27 PM, Roman Shpount <roman@telurix.com> wrote:

>
> On Fri, Apr 8, 2016 at 6:18 PM, Taylor Brandstetter <deadbeef@google.com>
> wrote:
>
>> In Section 6 of RFC 3264:
>>
>>> The answerer MUST send using a media format in the offer that is also listed in the answer
>>>
>>> So, if X offers A and B, and Y answers B, how would Y be able to send A?
>> It's not in both the offer and the answer.
>>
>>
> A does not have to be in both offer and answer. Offer/Answer is
> declarative capability exchange with each side declaring what it is willing
> to receive. It is not intended to pick a single codec. Negotiation is
> considered successful if there is at least one common codec, but there are
> no other requirements. Each party can send any codec remote party is
> willing to receive and can switch between the codecs remote party supports
> at any time. So in this example, Y can not only send A but can switch
> between A and B at any time.
>
> Also, answer can include codecs which were not present in the offer, so
> the whole situation can be reversed.
> _____________
> Roman Shpount
>
>

v2.23.0 | Report a Bug | By Email