Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources

Adam Roach <adam@nostrum.com> Mon, 22 July 2013 22:08 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D951D11E8182 for <mmusic@ietfa.amsl.com>; Mon, 22 Jul 2013 15:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level:
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 x0XB4SCowy+A for <mmusic@ietfa.amsl.com>; Mon, 22 Jul 2013 15:08:34 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 528A911E817C for <mmusic@ietf.org>; Mon, 22 Jul 2013 15:08:34 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6MM8T0Q077945 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 17:08:30 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51EDAD58.1050407@nostrum.com>
Date: Mon, 22 Jul 2013 17:08:24 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com> <00f401ce82a5$96dfff00$c49ffd00$@gmail.com>
In-Reply-To: <00f401ce82a5$96dfff00$c49ffd00$@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 22:08:35 -0000

On 7/16/13 23:24, Roni Even wrote:
> Hi,
>>> 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an
>>> integer) used for correlation;" I think that it must be a byte string
>>> or token not integer
>> Do you have some rationale for your assertion?
>>
>>
> [Roni Even] This is the syntax of the header extension and
> extensionattributes in RFC5285. It is a byte string and not an integer
>
>

Forgive the imprecision in the draft. What we mean to say is something 
along the lines of "a 16-bit identifier, expressed as an integer in the 
SDP, encoded in the RTP header as a two-byte byte string, in network 
byte order."

I apologize for the confusion. I thought this much would be obvious 
without needing to spell it out explicitly.

/a