Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
Harald Alvestrand <harald@alvestrand.no> Wed, 19 June 2013 12:48 UTC
Return-Path: <harald@alvestrand.no>
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 921C221F9A59 for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 05:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.539
X-Spam-Level:
X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 d2NvGgRyrri6 for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 05:48:29 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10221F9A36 for <mmusic@ietf.org>; Wed, 19 Jun 2013 05:48:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7DBE839E1C8; Wed, 19 Jun 2013 14:48:28 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tri+RwgpzC1D; Wed, 19 Jun 2013 14:48:27 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0AD5D39E1C4; Wed, 19 Jun 2013 14:48:26 +0200 (CEST)
Message-ID: <51C1A89A.9020603@alvestrand.no>
Date: Wed, 19 Jun 2013 14:48:26 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
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: Wed, 19 Jun 2013 12:48:34 -0000
On 06/19/2013 02:36 PM, Christer Holmberg wrote: > Hi Harald, > >>> I put together some text regarding the de-muxing for BUNDLE. >>> >>> Note that there is yet no text on HOW the de-muxing is performed. The text only cover the SCOPE of what will be specified in the BUNDLE spec. I want us to agree on that first :) >> I think you should be careful about this. You risk duplicating material from other specs. > That's why I am eager to hear your input on what shall be covered in the BUNDLE spec regarding de-muxing :) > > For example, are you saying BUNDLE shouldn't specify HOW the de-muxing is done? Absolutely, I'm saying that BUNDLE should not specify a procedure for de-muxing. Instead, it should point to the specs that already specify how the de-muxing is done. See my comments below as to what I think it should say. > > Regards, > > Christer > > > > > --------------------------------------------------- > > > > 9. Transport Protocol De-Multiplexing > > 9.1. General > > Endpoints can assign "m=" lines representing different transport > protocols [RFC4566], identified using the "m=" line proto value > [RFC4566]. > > As each "m=" line in a BUNDLE group share the BUNDLE address, an > endpoint MUST be able to de-multiplex data received on the BUNDLE > address, meaning it MUST be able to associate the received with one > of the transport protocols assigned to the BUNDLE group. Endpoints > MUST NOT assign a transport protocols to a BUNDLE group, unless it is > able to separate received data from data associated with other > transport protocols assigned to the BUNDLE group. > > In addition, if an endpoint assigns multiple "m=" lines representing > the same transport protocol to a BUNDLE group, the endpoint MUST be > able to, in addition to associating received data to its transport > protocol, also associate the received data with a specific "m=" line > representing that transport protocol. > > This specification defines how to de-multiplex received media > associated with the following transport protocols: > > o "RTP/AVP" [RFC4566]; > > o "RTP/AVPF" [RFC4585]; > > o "RTP/SAVP" [RFC3711]; > > o "RTP/SAVPF" [RFC5124];and > > o "SCTP/DTLS" [ref-to-be added]. > > This is somewhat incomprehensible to me; the most logical description I can make is that it means that you can separate packets into one heap containing all the RTP variants and another heap containing SCTP/DTLS - but that is not obvious. Suggest instead: > > > This specification defines how to de-multiplex protocols carried over RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from protocols carried over DTLS (which include SCTP/DTLS []). > > And that makes the specification of the demultiplexing very simple: > > "See RFC 5764 section 5.1.2" > > > > This specification also specifies how RTP packats are separated from > RTCP packets. > > Again, the specification of how to do this separation is very simple: > > "See RFC 5761 section 4" > > > If an endpoint assigns multiple "m=" lines representing RTP/RTCP > media to a BUNDLE group, it is outside the scope of this > specification how the endpoint associates received RTP/RTCP packets > with a specific RTP/RTCP "m=" line (endpoints might use payload type > values, or SSRC values, for the association). > > If endpoints want to assign "m=" lines representing other transport > protocols to a BUNDLE group, it MUST be documented how the de- > multiplexing is performed. There might also be a need for signalling > extensions in order for endpoints to exchange data needed for the de- > multiplexing. > > I agree with the sense of these paragraphs. > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19t… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Stach, Thomas
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Harald Alvestrand
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Harald Alvestrand
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Harald Alvestrand
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Bernard Aboba
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Bernard Aboba
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Harald Alvestrand
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Emil Ivov
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Harald Alvestrand
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Emil Ivov
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Emil Ivov
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Harald Alvestrand
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Bernard Aboba
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Colin Perkins
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Emil Ivov
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Emil Ivov
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Colin Perkins
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June… Bernard Aboba