IETF Logo Mail Archive

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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 09 April 2016 20:19 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 8D49512D162 for <rtcweb@ietfa.amsl.com>; Sat, 9 Apr 2016 13:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.272
X-Spam-Level:
X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.972] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 bNfXMrSkQ3iB for <rtcweb@ietfa.amsl.com>; Sat, 9 Apr 2016 13:19:49 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B25412D157 for <rtcweb@ietf.org>; Sat, 9 Apr 2016 13:19:49 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id ozLdaSjwJnIc7ozMCaV3UB; Sat, 09 Apr 2016 20:19:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460233188; bh=ulJ/XS7tK8MhQzHzkqEvLtz29fa7GuM/9r7j3Quexp8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=lZM+IZVGeD2fKc9nLGRobogVObHB0mJ9yiDkoyrCNjbIrcXz5TvfreX859CRtQyix HJ36MLi1hregWlHJUqn+dsxkkqw9KuxwKc+eoUhu6UDxbEiPQQKQcVB/8gkqL9we7W cL6XmxVAqc7GrkEGPv3jDIUgEknwcPcPbfRUXGXXgLvwguvzfXlkRlEqD/19bi50nE ASfy5V8QmUbszqCmDYPOVxXX4YD6REmy+pkYV1PW0l8omTdo7OyOMobg/tDPA5nYTK 8B34iMJkVLmepqjBN1TPPl5orz5HqThSM+5+BLcQcFfS0XCfIQT69kJh9hPDPej1x6 ReATAuonzBRVw==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id gLKo1s0043KdFy101LKoXA; Sat, 09 Apr 2016 20:19:48 +0000
To: rtcweb@ietf.org
References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> <CAK35n0b=Qa5JxqrMUdSH92uw4U3=HyFuKSspZjgKN8vn_MuSqg@mail.gmail.com> <CAD5OKxuaxNEP6+vkzFTXi3Cacp3OEYuKMSNbPMHwpMjiNb+SiQ@mail.gmail.com> <CAK35n0bk2jXJTgzutzzktoo1cEWgk1Vfofg7_DkDcyV5j_zdtg@mail.gmail.com> <CAD5OKxvPKYV4XeRKUYDYZATD81kkQ9JL4RMjiNvMnEWC_HJXFw@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <570963E3.2090204@alum.mit.edu>
Date: Sat, 09 Apr 2016 16:19:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAD5OKxvPKYV4XeRKUYDYZATD81kkQ9JL4RMjiNvMnEWC_HJXFw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/UgWwmTfFsetQ6Vst1psyWJ-ia2k>
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: Sat, 09 Apr 2016 20:19:50 -0000

On 4/8/16 6:47 PM, Roman Shpount wrote:
> Taylor,
>
> After rereading RFC3264, I can see that you are correct: If the codec is
> not present in the answer, offerer MAY stop listening for this payload
> type (https://tools.ietf.org/html/rfc3264#section-7).
>
> Sorry for confusion,

Hmm.

Also, the end of section 6.1 says:

    The answerer MUST send using a media format in the offer
    that is also listed in the answer,

Together, those contradict what I said above.

So I guess Harald gets his wish to be able to discard resources for 
codecs that weren't mentioned in the answer.

Unfortunately this also means it isn't possible to have asymmetric 
behavior. For instance, it means you can't have telephone-events work in 
one direction and not the other.

	Sorry for missing the above,
	Paul

v2.23.0 | Report a Bug | By Email