Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 28 June 2013 16:57 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 45DA321F9A08 for <mmusic@ietfa.amsl.com>; Fri, 28 Jun 2013 09:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 WwJTCUFVeyPM for <mmusic@ietfa.amsl.com>; Fri, 28 Jun 2013 09:57:21 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA4321F9950 for <mmusic@ietf.org>; Fri, 28 Jun 2013 09:57:20 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta12.westchester.pa.mail.comcast.net with comcast id tpgW1l0051uE5Es5CsxLzz; Fri, 28 Jun 2013 16:57:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id tsxL1l00R3ZTu2S3csxLnr; Fri, 28 Jun 2013 16:57:20 +0000
Message-ID: <51CDC06F.8070607@alum.mit.edu>
Date: Fri, 28 Jun 2013 12:57:19 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <CAPvvaa+6cZrHJk7yLq103c_jU_ZdLTaPb=KSJtUnX8anLjQZKA@mail.gmail.com>
In-Reply-To: <CAPvvaa+6cZrHJk7yLq103c_jU_ZdLTaPb=KSJtUnX8anLjQZKA@mail.gmail.com>
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=1372438640; bh=8bMypzF7z42hp9we2/dWYJ++fJ/ycjhVIO0KaNPGcm4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ixRoUjUnn8RTk1zce4z/DnYSpn0+VI6ZBcDuokm6IhvlKXlK6Ka27dsPsbWszY/Pv ztnYf/l0jGiSnKFMyPw2QbUPVpzyyis4Nd4pIFn31yZ8l6aEED4zGh67HEpjBQfySO dIsGrglSUK3eL69V1rEwUixRJQrqPDRowgqnUDLQXjW1M9tIUeRQlLEIkc2M6cHu8G wIBXGmvecXVbUoiyuvc3nJ4ekVVF+pWYeIGuLP86FYn6ajKu2mYIfApD8SNoQJ5Boy 313RaSCoxk/gpY2iEf1IsgIJMKcDPB9+YlMjmcLFxJHaG8KuDjyt+Mb2nyy9A2c+fT 0+wsUfKhyfbeg==
Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration
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: Fri, 28 Jun 2013 16:57:27 -0000

On 6/28/13 12:41 PM, Emil Ivov wrote:
> On Fri, Jun 28, 2013 at 1:25 PM, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
>
>> Q7: Within a BUNDLE group, do we allow the usage of the same PT value in
>> multiple RTP m- lines, for the SAME codec configuration?
>
> Generally yes.
>
>> Note: This of course prevents the mapping to m- line purely based on PT,
>
> You mean, only in case its actually used and not as a general BUNDLE
> rule, right?

I'm not sure I understand the distinction you are drawing.

The point is that when a packet with this PT is received, you won't be 
able to use the PT to determine which m-line in the bundle the packet 
should be associated with.

There must have been *some* reason that two m-lines were used, with the 
same PT, rather than just one. Each m-line heads a media section of the 
SDP that contains a bunch of declarations. Some of those are part of the 
payload description and so are the same. Something else must be 
different in those two media sections, or else a single media section 
would have been enough. Presumably whatever it is that is different is 
intended to affect how received packets are processed or interpreted. If 
you can't associate the packet with the m-line, then you don't know 
which of the multiple interpretations to apply to the packet.

	Thanks,
	Paul