Re: [MMUSIC] Another bundling proposal - Christer's comments
Christer Holmberg <christer.holmberg@ericsson.com> Mon, 25 February 2013 13:09 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 DB53D21F9301 for <mmusic@ietfa.amsl.com>; Mon, 25 Feb 2013 05:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.256
X-Spam-Level:
X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fpf7qHNyZxw for <mmusic@ietfa.amsl.com>; Mon, 25 Feb 2013 05:09:26 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 31D3A21F92EE for <mmusic@ietf.org>; Mon, 25 Feb 2013 05:09:25 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-80-512b62844cfd
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.03.19728.4826B215; Mon, 25 Feb 2013 14:09:24 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 14:09:23 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Dale R. Worley" <worley@ariadne.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Another bundling proposal - Christer's comments
Thread-Index: Ac4TVbJsbUziS577R021PX4477xAdw==
Date: Mon, 25 Feb 2013 13:09:23 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvjW5Lknagwft/AhZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyjh56i97wTGZitbJ3ewNjNPEuxg5OSQETCS2 7FnODGGLSVy4t56ti5GLQ0jgEKPEzrkPGSGcxYwSL2+9ZO1i5OBgE7CQ6P6nDdIgIuAnsX7V B3YQW1jAVWLZlsdMEHE3ieU991ggbD2J3f+2gsVZBFQlZjzYwQ4yhlfAW+LC9jSQMCPQ3u+n 1oCVMAuIS9x6Mp8J4h4BiSV7zkPdJirx8vE/VghbUeLq9OVQ9ToSC3Z/YoOwtSWWLXwNVs8r IChxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS832sQIDOuDW36r7mC8c07kEKM0 B4uSOG+464UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxR01e/3vTq0Vb9k2o7NjvY/HjB vUxd/suyyuaTTndNgwQfhBcur9v3mc3vQUCQ8SKrrUwf7W/IvuThC8y3K4tKiflZqxWbGXW1 d+r1hjmTDmVZRqxT3JufmuCQeDL5NdvB+YIXIx74cSxtzK060nFT5d6mBSEXWE/ZZ2k2XDD4 slDFsNtu2W8lluKMREMt5qLiRACpQAK8OQIAAA==
Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments
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: Mon, 25 Feb 2013 13:09:27 -0000
Hi, I had previously provided comments to Dale off-line. Some has been addressed in the -03 version of the draft. But, I still have some questions. First, unless I've missed something, the mechanism is still for RTP ONLY. It is not possible to e.g. put the DataChannel in the bundle. I think we asap need to decide whether that is a requirement or not. Second, you use the non-bundle m- lines for codec negotiation etc. But, previously, when MMT was discussed, I believe that people indicated that they do not want to "refer" to other m- lines from the MMT m- line. Instead, the information should be explicitly provided in the MMT m- line (which is the reason why the SDP size gets pretty big with MMT, as most information is duplicated). Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 22. helmikuuta 2013 23:06 To: mmusic@ietf.org Subject: [MMUSIC] Another bundling proposal I've written an alternative bundling proposal which I think manages the problems of bundling better. A series of tutorial examples are here: http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4 so it's easy to see how the proposal works. Distinctive features of this proposal are: - A separate m= line describes the bundled media, allowing unambiguous attribution of attributes to either the bundle or a constituent, and independent rejection of each constituent. - Backward compatibility is achieved straightforwardly. - Multiplexed media flows are attributed to their original constituent media descriptions without requiring each to be declared individually in the SDP. - The multiplexed media flow is artificially given the media type "audio" to prevent rejection by SBCs. - An encapsulating RTP format is used so demultiplexing can be done without coordinating payload types between media descriptions, and to ensure the bundled media description is rejected by non-supporting endpoints. - Zero/non-zero ports and valid/null addresses are controlled to avoid duplicate port usage, and to ensure SBCs see exactly the media flows specified by the SDP. Filename: draft-worley-sdp-bundle Revision: 02 Title: Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP) Creation date: 2013-02-22 Group: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-02.txt Status: http://datatracker.ietf.org/doc/draft-worley-sdp-bundle Htmlized: http://tools.ietf.org/html/draft-worley-sdp-bundle-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-02 Abstract: This document defines a generic bundle mechanism for the Session Description Protocol (SDP) by which the media described by a number of media descriptions ("m= lines") are multiplexed and transmitted over a single transport association. The transport association is described by an additional media description, allowing SDP attributes to be applied to the aggregate, independently of attributes applied to the constituents. In offer/answer usage, the bundle mechanism is backward compatible with SDP processors that do not understand the mechanism. The mechanism is designed to be compatible with the limitations of the existing Internet infrastructure. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
- Re: [MMUSIC] Another bundling proposal - Christer… Christer Holmberg
- Re: [MMUSIC] Another bundling proposal - Christer… Dale R. Worley
- Re: [MMUSIC] Another bundling proposal - Christer… Christer Holmberg
- Re: [MMUSIC] Another bundling proposal - Christer… Dale R. Worley
- Re: [MMUSIC] Another bundling proposal - Christer… Christer Holmberg
- Re: [MMUSIC] Another bundling proposal - Christer… Dale R. Worley