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

Christer Holmberg <> Wed, 26 June 2013 06:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7263D11E810A for <>; Tue, 25 Jun 2013 23:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z-7C21hDoSwM for <>; Tue, 25 Jun 2013 23:58:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C527221E808E for <>; Tue, 25 Jun 2013 23:58:41 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f146d00000411d-f8-51ca9120912f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 90.F9.16669.0219AC15; Wed, 26 Jun 2013 08:58:40 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 08:58:40 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NP//+aaA///Dn0CAAGQQgP/+2P9g
Date: Wed, 26 Jun 2013 06:58:40 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra7CxFOBBss7TC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjUsMW5oKT6hXTz2xgamDcL9/FyMkhIWAi MXnOJlYIW0ziwr31bF2MXBxCAocZJeZ09bFCOIsYJVqONgFlODjYBCwkuv9pg5giAhoSk7aq gZjMAuoSVxcHgYwRFkiWmPLmLxuILSKQInF3/3l2CNtN4sqFp0wgNouAqsSW0x+ZQVp5BXwl Vi4NBAkLCVxllFj/EqyEU0BH4mvXR7AxjECXfT+1BizOLCAucevJfCaIiwUkluw5zwxhi0q8 fPwP6hNFifanDYwQ9ToSC3Z/YoOwtSWWLXwNVs8rIChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoW MLKsYmTPTczMSS833MQIjI6DW37r7mA8dU7kEKM0B4uSOO+HU7sChQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTDynT5QEB3DK54vcjN77++NCpusDRJn5qw4mNdl0Bm7ol+p8pnk1H1zjfUk ynV8nXb07E0vTDif4OO475as6u/LvbxNQf6Hnd6b18kvt/b8X7C8XmnOljKeoBNCqm5SX07d FEo1XtFpZrDOMWu3/5MlcwK9t6ieTdrloiJuXL3o17ayt8+4U5RYijMSDbWYi4oTAYbAH5Bc AgAA
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: Wed, 26 Jun 2013 06:58:47 -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 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?

I'm afraid not - I was just speculating :)

> 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.


What about the direction attributes? The network may use the information e.g. for bandwidth calculation purpose, but it does not need to distinguish the packets.

Anyway, I personally don't have any strong preference, so I'd like to hear from people who DO have an opinion :)

> 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.) 

I think we should use whatever "stack" is referenced in the 5-tuple definition.

> 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 DTLS/SCTP.)
> 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.

Sure, but it is not (I hope) the task of BUNDLE to define HOW data is mapped to m- lines for all kind of transport protocols. 

We are going to specify/reference something for RTP, but do you think BUNDLE should also e.g. define a mechanism for transporting SCTP ports in SDP? We COULD (I assume it would be a rather simply task), but should we?



> 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