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

Paul Kyzivat <> Tue, 25 June 2013 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 093AF21F9E0D for <>; Tue, 25 Jun 2013 08:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.324
X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=0.113, 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 CCNQXNNqp5nW for <>; Tue, 25 Jun 2013 08:13:47 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:48]) by (Postfix) with ESMTP id 2D7FD21E809C for <>; Tue, 25 Jun 2013 08:13:46 -0700 (PDT)
Received: from ([]) by with comcast id sbLr1l0020Fqzac55fDmEe; Tue, 25 Jun 2013 15:13:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id sfDm1l00E3ZTu2S3UfDmRl; Tue, 25 Jun 2013 15:13:46 +0000
Message-ID: <>
Date: Tue, 25 Jun 2013 11:13:45 -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
To: Christer Holmberg <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1372173226; bh=wcneZD/uMNLdok/JQXB6i9s9X0ykOhdNeSOjsrgZzZ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aZFA/JWjsp6zzR+XlRF/0b2ExpyiGYzQv8YYrD4XVqUzL4jrWIU0x4aDKN/HrwvZ4 S3EpUospy8prcZZGZT84BhQwQW5hJ0D3Ve++sI2uvVY683B3+ym6OeDmt6anWYvyv2 FzYRDHOE/RGAjUAOr8ICHa3j0OdKHxZIjHc8Nc0i0fzFYreJqwRwnfuPKHRiMzoPGk YFoboYy9Pv7y7RdmJ46ljjjnM/z8eGCf2BfPaVkNtFnwg4BVh0rNAMaM6sOq10H78c E/zwkgyBWP0ZxIdd69qt9rmrMmgQnmRSpDtd9dX+M3vwagq34Jh65INOfyOcETu2lb uZnqVtE7MjX2Q==
Cc: "" <>
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 15:13:52 -0000

On 6/25/13 10:48 AM, Christer Holmberg wrote:
> Hi,
>> 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 reason for having m- lines could be because different characteristics (bandwidth, priority etc) is requested from the NETWORK, while the endpoint application that receive the data might not care which m- line it belongs to.

Can you be specific?

Note that if you are requesting different characteristics from the 
NETWORK, then the NETWORK must be able to distinguish the packets in 
order to apply those characteristics properly. So then *it* will need a 
way to distinguish. If so, then the endpoints can too.

If you are just requesting characteristics for the entire bundle, then 
it should be possible to do it with fewer m-lines, that you can then 
associate with.

>> 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.
> Correct. For ICE we explicitly say that the STUN messages apply to the whole BUNDLE group.

It can in principle apply to more than just ICE.

Somewhere I commented that the <proto> field describes more than just 
the low level transport protocol. It often describes a whole protocol 
stack with many layers. When we bundle multiple m-lines with different 
<proto> fields, they have different stacks. For the bundle to be valid, 
at least the bottom level of each stack must be the same. (E.g., UDP.) 
There may be more layers in common among some or all of the stacks. When 
some of the m-lines have multiple layers in common, then there may be 
some packets that pertain to housekeeping of the layer, and so need not 
be associated with one particular m-line.

For instance, *in principle* one could bundle multiple DTLS/SCTP m-lines 
together. Then there could be some SCTP housekeeping packets that can't 
be associated with a single m-line, but for this to work, SCTP payload 
packets would need to be distinguishable, probably by SCTP port. (Note, 
I'm not sure if there are any SCTP packets that don't have an SCTP port, 
so this might not be a good example. And of course for this example to 
work there would need to be a way to specify the SCTP port in SDP for 

AFAIK, for stuff *currently* under discussion only ICE falls into this 
category. But if we are going to define bundle so it can be applied to 
future cases then we need to phrase the constraint properly.


> Regards,
> Christer
> 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
> _______________________________________________
> mmusic mailing list