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

"Mo Zanaty (mzanaty)" <> Mon, 01 July 2013 03:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68A6221F9EF9 for <>; Sun, 30 Jun 2013 20:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pgpuXvH6FtPx for <>; Sun, 30 Jun 2013 20:33:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9497321F9EE3 for <>; Sun, 30 Jun 2013 20:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3359; q=dns/txt; s=iport; t=1372649580; x=1373859180; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uhwz3mJjn56VLlBhW+OiZpbkTvHErSfdyVp7ukU4yXo=; b=i5IA4fOETaE5/umSznXKBPVe9IfECemV40eIgXSfNUn8E9lRfq0bDQs5 9wAcAc5Ed0GAytTtCaSXnGnDSjq/Ng64l2cfHUCbMogJaWjJYKL4DzTpt oEKSdkewsRDBlTlSyUCEmMDwnxRFK7rz3u0Au4luzfN36DwUKWV6AVV8v g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,971,1363132800"; d="scan'208";a="226280574"
Received: from ([]) by with ESMTP; 01 Jul 2013 03:33:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r613Wx6G030484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 03:32:59 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Sun, 30 Jun 2013 22:32:59 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
Thread-Index: AQHOdON5iUTc8DI+/Em0svjaZWQNnJlPEy+A
Date: Mon, 01 Jul 2013 03:32:58 +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
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: Mon, 01 Jul 2013 03:33:05 -0000

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.


-----Original Message-----
From: [] On Behalf Of Paul Kyzivat
Sent: Saturday, June 29, 2013 12:12 PM
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.


mmusic mailing list