Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

Paul Kyzivat <> Tue, 25 June 2013 12:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC8FB21F9607 for <>; Tue, 25 Jun 2013 05:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.323
X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iIQNMHv7ErcA for <>; Tue, 25 Jun 2013 05:51:45 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:17]) by (Postfix) with ESMTP id C2CDA21F9302 for <>; Tue, 25 Jun 2013 05:51:44 -0700 (PDT)
Received: from ([]) by with comcast id sbul1l0061HzFnQ5AcrkWp; Tue, 25 Jun 2013 12:51:44 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id scrk1l0083ZTu2S3acrkNm; Tue, 25 Jun 2013 12:51:44 +0000
Message-ID: <>
Date: Tue, 25 Jun 2013 08:51:43 -0400
From: Paul Kyzivat <>
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
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1372164704; bh=4RyIppQaCa+gz6qKnNwry5iu35dsN6BmVJGd8Qps898=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oEFD+Vuuk+xyehBMxN376XCXeXIXHpKpLhbYnuD7OAcatmhN2NcYAZLpMOzcCbUHb osInaxEq9CUvF2/A4RpU0v9+zei0ehmw+i+j97sGkvRIFdu67J5yUO5MnuHzmJ/pn4 /SKVq5A64Tboigpz42YfEh2+Jb2TsyQeQdmO1ITE1cU4V9Lg6CNTOGuQNZJQQcoOMI gVbtINrhCKrsexOLIHLeqPdxYwmQBaCguroLxhdnfQXbxexnKksv4SIf7MEkZM/II8 +FLAl4EGSnoaMjYFDr5W5nqwxbmf4s7V+UTR2Hyx83ZymDNAT5lI+MbeJdyQ2IsR/+ B5dDLcfCaKp1g==
Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jun 2013 12:51:49 -0000

I started this issue, so I'll make my case again.

There must be a reason to have multiple m-lines in the bundle. (If there 
isn't, leave them out, and then maybe you won't need bundle at all.)

I assert that in all cases that reason can't be realized without being 
able to associate packets with the corresponding m-line.

The exception to this are those packets that deal only with those 
aspects of the bundle that are common. The most obvious example of this 
is ICE. But if *all* packets are common to all the m-lines then there is 
no reason for the bundle.


On 6/25/13 7:16 AM, Christer Holmberg wrote:
> Hi,
> There has been some discussions about whether BUNDLE should mandate that
> users are mandated to *always* (no matter what transport protocols are
> used in the BUNDLE group) have a mechanism to map received data to an m-
> line, or whether it from a generic BUNDLE perspective should be optional
> – IF there would be cases where it’s not needed.
> We haven’t had that much discussion about it yet, so I will not ask a
> DECISION question at this point, but I would really like to get some
> input from people who have opinions about this :)
> Note that this issue is NOT about HOW to map data to m- lines (there
> will be a separate question about how to map RTP to m- lines etc), or
> whether we should allow usage of the same PT value (for the same codec
> configuration) in multiple m- lines, but more about a general rule.
> Regards,
> Christer
> _______________________________________________
> mmusic mailing list