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

Paul Kyzivat <> Tue, 02 July 2013 14:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 278B721F9D4D for <>; Tue, 2 Jul 2013 07:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.062
X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Vexp+Iy2PQF for <>; Tue, 2 Jul 2013 07:05:32 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:212]) by (Postfix) with ESMTP id 5A5D121F9DD0 for <>; Tue, 2 Jul 2013 07:05:31 -0700 (PDT)
Received: from ([]) by with comcast id vRQP1l0030SCNGk5ES5XeN; Tue, 02 Jul 2013 14:05:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id vS5X1l0043ZTu2S3VS5X2B; Tue, 02 Jul 2013 14:05:31 +0000
Message-ID: <>
Date: Tue, 02 Jul 2013 10:05:30 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" <>
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=1372773931; bh=miLwS88QpW4ENXaA2xQDAyDC2EG9dWiXvLhcL13jr9E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bMq6N7UjpT8R71QtZG00cuvVkTXblgOPVp6bEQxOqlaMfdYkww/EXY4ndA3Rr8b8e CuHq3T7r9WiB0bOWdPq2lxRQdOmcDHekWXNU+D9KwEVwoV9em4bvOatgwVWVgo97iL AwC7QoXGT+233/p7T7QVdMFYulhDxoid0dpt30ZxdB9hDo1NAZgmP1bTQgxNMEWYnk VzgoaDre2Z/5Fi0UWmWL/9VMJwQ4BIGnyBBua0UNTYTdf1A/aWXqN8SmZAI61gKf0v kdRJSdckk4xm4k9DvZLBoMCoH8U+optotkAWhg7n5R5HlSn+r8bTahYE326HbQ7Iib haPkL842PUURQ==
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, 02 Jul 2013 14:05:37 -0000

On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote:
> Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology?
> The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan.

I'm going to keep asking this question until I get an answer that makes 

Please explain to me a meaningful situation when there are multiple 
m-lines in a bundle and there is insufficient information to associate 
each packet with an m-line.

The *point* of plan A is that there be an m-line per "flow", and that 
the offerer is enumerating the flows. So clearly it knows the mapping. 
If the answerer isn't capable of doing the same mapping, then the use of 
plan A has failed.

The part that I want to be normative is that an O/A is not valid unless 
the mapping is possible with the information in the O/A, and that the 
offerer and the answerer would agree about the mapping of each packet. I 
don't care if they actually do the mapping, though if they are doing any 
sensible processing then they will be doing something *equivalent* to 
the mapping.


> Mo
> -----Original Message-----
> From: [] On Behalf Of Paul Kyzivat
> Sent: Saturday, June 29, 2013 12:12 PM
> To:
> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
> 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.
> 	Thanks,
> 	Paul
> _______________________________________________
> mmusic mailing list