IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 25 June 2013 14:48 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54021E8098 for <mmusic@ietfa.amsl.com>; Tue, 25 Jun 2013 07:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.874
X-Spam-Level:
X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 348KCowXY1yw for <mmusic@ietfa.amsl.com>; Tue, 25 Jun 2013 07:48:36 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05CC211E8110 for <mmusic@ietf.org>; Tue, 25 Jun 2013 07:48:35 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f536d000005ad4-5d-51c9adc291f6
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 18.CC.23252.2CDA9C15; Tue, 25 Jun 2013 16:48:34 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 16:48:34 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NP//+aaA///Dn0A=
Date: Tue, 25 Jun 2013 14:48:33 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <51C9925F.9000901@alum.mit.edu>
In-Reply-To: <51C9925F.9000901@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre6htScDDTb1yFlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG91m72QvWCFa8/r6cvYHxJW8XIyeHhICJ xNLTe9khbDGJC/fWs3UxcnEICRxmlDh66TY7hLOIUWL+jh9MXYwcHGwCFhLd/7RBGkQEfCWe Pb7NBmILCyRLTHnzlw0iniJxd/95dgjbSuLOlCmsIDaLgKrE10ltYDYvUG/7krlMILaQQL7E zEubwOo5BXQkFq07xgJiMwId9P3UGrAaZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2okT7 0wZGiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYmTPTczM SS833MQIjIWDW37r7mA8dU7kEKM0B4uSOO+HU7sChQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTCGB2eKRNuGfS3r1LAUqJoY/LlWYM9qlTlp/zPWfdrm4Me1ZMpzkV0FuVob89QfOO5VXjzx mGSdIsPWN/YuGlnfnzLdqmk9f+aFwr+dd97Y12v9Yzu8dIHSsshla9K3Ptrb6b39a+6SSr0b z23WvpmsPHnxm6MafGs3vr6QdvbslXR/nhL3jv+MSizFGYmGWsxFxYkAKEhV/FMCAAA=
Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 14:48:44 -0000

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.

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

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@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email