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

Paul Kyzivat <> Sat, 29 June 2013 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69BEE11E817B for <>; Sat, 29 Jun 2013 09:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.038, 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 JkhjYxYXnhd2 for <>; Sat, 29 Jun 2013 09:12:26 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:212]) by (Postfix) with ESMTP id 7811111E8175 for <>; Sat, 29 Jun 2013 09:12:26 -0700 (PDT)
Received: from ([]) by with comcast id uG3l1l0040mv7h05EGCR5u; Sat, 29 Jun 2013 16:12:25 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id uGCR1l00e3ZTu2S3XGCRHw; Sat, 29 Jun 2013 16:12:25 +0000
Message-ID: <>
Date: Sat, 29 Jun 2013 12:12:24 -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=1372522345; bh=/vw9oe4mIrpw8jV1iqJBmG/nUIVRb8qsaDXSU+posV8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eNnp3QHkNf2iND3qBO6MVn/AbckNnqIjceaNcCYhPpyyrtBQCCKwzTfmgTBSxF8N2 FuyCHXHcPYspaGRsIPd/ye0djgx3V+tfaRJjsph27tneUkw4eUDWkGNmimp9ta9ysH 1Xks3UjMTleCXPIV+67BYpM30lB9rQll88wJWVO9iE8a1Kf56ln9QQba8RMCkkLwVT cem+7lG7ld7vLCB//jWhs4a7YVm02NGJ67TXIgMp2dR4njThwcezpSIDCBMJ5S4+Ne WX+swzqRtuaWnWt+EILG0Y1ogi+PNHQS4KaDYjCKuydS5QnAL9GdqnELuRzssLu7YQ kP4VpQms94x5g==
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: Sat, 29 Jun 2013 16:12:32 -0000

On 6/29/13 8:50 AM, Colin Perkins wrote:
> Christer,
> On 25 Jun 2013, at 12:16, Christer Holmberg wrote:
>> 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 :)
> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care.

I just replied elsewhere on this.
My opinion turns out to be the exact opposite of yours: we need to 
support multiple algorithms, and that all applications should care.

I won't repeat the stuff about multiple algorithms.

I will repeat what I have said about the need for being able to associate:

There must have been *some* reason that two m-lines were used, rather 
than just one. Each m-line heads a media section of the SDP that 
contains a bunch of declarations. Something 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 not, again 
there is no need for it to be there.) 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.

Maybe there is some exception to this, though I haven't come up with 
anything. If there is, then I hope someone will call it out. If so, then 
the constraint can be tightened.