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

Paul Kyzivat <> Fri, 28 June 2013 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F11D21F9BAA for <>; Fri, 28 Jun 2013 08:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.437
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Di0mXuJZNUL for <>; Fri, 28 Jun 2013 08:34:52 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:243]) by (Postfix) with ESMTP id CE06521F9BC1 for <>; Fri, 28 Jun 2013 08:34:51 -0700 (PDT)
Received: from ([]) by with comcast id tpcu1l00B17dt5G5DraqXL; Fri, 28 Jun 2013 15:34:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id traq1l00b3ZTu2S3Zraq7e; Fri, 28 Jun 2013 15:34:50 +0000
Message-ID: <>
Date: Fri, 28 Jun 2013 11:34:49 -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="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1372433690; bh=WVPhR3fPQprfU8xgO3n+UXHjzAtd/B+AH2SSDDSw87s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X2UrnmLhOdUK4ehe4A2A4Wuw8TlCWPvZUJYiNKx4LvmVd5Iq2vNOHzmXKcDsmX1k4 iPcBWKKmIZB+GurAnwhWXjz7v/qrsCGz6kQoamz9uxoH49Cp+WYAtDjAdXGkhWJtqt NVGXQpwYh/cMCP+Xf3cTBLRfxCnqvsostsO2r7CQRLEIxbZPdQth9BllMRynKQ+pRH 7S1JiqVBsf0hrE5gLsKrcOjjBGJy0ASMkF+qcRcrJv1AEvCoEB9PtS6J1BOt4if6+0 Qnlxb9yt73PqAoH1wRvj3dVDyumfCtt1ajv00zpQPqN//xX1eTHGuRGmIQLZr422/z Wv8tqgskn7h0g==
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: Fri, 28 Jun 2013 15:34:56 -0000


I think we are mostly in agreement here. I've put one question inline.

Have a good vacation. Don't work too hard while on vacation.
(But do at least check your email every 5 minutes! :-)
See you in Berlin.

On 6/28/13 7:06 AM, Christer Holmberg wrote:
> Hi,
>>>>>> 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.
>> No, Bundle can't define this for all possible m-lines.
>> But it can call out the requirement that this must be possible for a bundle to be valid, and that it is the responsibility of the answerer to ensure that.
>> Part of that is for the answerer to ensure that the *offerer* will be able to do it, and that both ends agree about *how* it will be done. (So that the sender and receiver of each packet agree on which m-line it is associated with.)
>> I am not sure if there is ever a need to *explicitly* signal what
>> mechanism(s) are to be used, or if it can always be inferred from the presence in the SDP of the data needed for the association.
> Assuming we do mandate mapping to m- lines, the Offer should only place m- lines in a BUNDLE group in a way that allows it to do the mapping.
> The same goes for the Answerer. If it's not able to do mapping (e.g. because it does not support an extension which would be required to do the mapping), it should either remove m- line(s) from the BUNDLE group, or reject m- line(s).
> Exactly HOW the mapping is done, and what SDP information it may require, is out of the scope of BUNDLE - perhaps with the exception of mapping between DTLS/SCTP and RTP (see below).
>> The place where this is an issue is if there is data in the answer that would allow the offerer to do the association, but the answerer is not certain if the offerer is prepared to use that data for that purpose.
> Well, as the Offerer has assigned the m- lines to the BUNDLE group, it needs to be able to do the mapping using *A* mechanism. SDP attributes etc can then be used to provide more information and data associated with such mechanisms.

I think this will usually be sufficient.
But I haven't convinced myself that there aren't some possible exceptions.

So I would like others to think about this - try to find exceptions, and 
report if you find one.

>>> 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?
>> We had this discussion already. IIUC there was consensus that the SDP for DTLS/SCTP would *not* include a way to convey the
>> SCTP port, so that only a single default port can be used. This implies that one can't bundle two m-lines for this together.
>> While I didn't agree with this decision, I can live with it until (if ever) a need arises.
> But, I guess BUNDLE doesn't need to explicitly forbid the usage of multiple DTLS/SCTP m- lines, as there in future might be a mechanism which allows to map DTLS/SCTP data to the correct DTLS/SCTP m- line. It would go under a general "if-you-can't-demux-it-don't-put-it-in-the-bundle-group" rule.
>> But I do think it needs to specify how to demux a bundle including a DTLS/SCTP and some RTP m-lines.
> I personally agree with that. There are basically two things:
> 1) How to demux between DTLS/SCTP and RTP.
> 2) With multiple RTP m- lines, how to map data to the correct one.
> Regards,
> Christer
> PS. I will leave for my summer vacation today, so I will not read my e-mail on a daily basis during that time.
> _______________________________________________
> mmusic mailing list