Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 01 November 2013 21:45 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 C2B2821E808A for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 14:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.251
X-Spam-Level:
X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRkOQyZ13kQh for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 14:45:38 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A99A511E817E for <rtcweb@ietf.org>; Fri, 1 Nov 2013 14:45:34 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id kD7V1m0021wpRvQ55MlYqk; Fri, 01 Nov 2013 21:45:32 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id kMlY1m00k3ZTu2S3eMlYFd; Fri, 01 Nov 2013 21:45:32 +0000
Message-ID: <527420FC.3070805@alum.mit.edu>
Date: Fri, 01 Nov 2013 14:45:32 -0700
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383342332; bh=S+x5Ik2328c+QJ8p2fP6RhfOLhiBesT4LErXKk1HfOA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X+bI0zupTOA8JK//F6mGXGBZr9+uwK/OeuOcF9vCDn/Kr2Txw9v/pm0zFyKiucdJO n4b95Z4o3zttWTWgB7WUFa6l9MD/tkMhr5con5lCwBEwpQ3PNzfNLLICDigiebiMji 8nvF+ElewMTrkQOdKDoehUTpdKKHCJsyAJUSzwvkTcot1YpBvf6KCR8Du/fCXz/dL/ bzuZHctm7y4QdZTWjyWHMp4gwcGXnaLL4EyHUG/HHPTsDuAVUwd5mRX9qmsUGYVQU7 SlazZ6N4fJ+pwfJCgt9J0Qdw6a9PxuUUSbTFpws056I438Igtffco5WdlGKzYAgQOZ gHBQ816KzQL/g==
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
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: Fri, 01 Nov 2013 21:45:43 -0000

Section 5.2.2 (Subsequent Offers) says:

    o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
       only include codecs present in the remote description.

    o  The RTP header extensions MUST only include those that are present
       in the remote description.

    o  The RTCP feedback extensions MUST only include those that are
       present in the remote description.

    o  The "a=rtcp-mux" line MUST only be added if present in the remote
       description.

    o  The "a=rtcp-rsize" line MUST only be added if present in the
       remote description.

Including only codecs that were present in the prior answer is a bad 
idea. It doesn't play well with SIP. There is no harm in continuing to 
include all the codecs you support. And it keeps options open for 
changing codecs later.

The same is true for most other things that are being restricted based 
on what was in the last answer. (But I won't say that with certainty 
without checking the semantics of each one.)

For further info, see RFC 6337, especially section 5.1.

	Thanks,
	Paul