Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 19 June 2013 12:37 UTC
Return-Path: <prvs=58822a6647=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 B12CB21F9C61 for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 05:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.777
X-Spam-Level:
X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=0.472, 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 uLOMss6LKMaA for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 05:37:22 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83E21F853A for <mmusic@ietf.org>; Wed, 19 Jun 2013 05:36:59 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-81-51c1a5ea4d6b
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0E.12.18006.AE5A1C15; Wed, 19 Jun 2013 14:36:59 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 14:36:58 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTA=
Date: Wed, 19 Jun 2013 12:36:58 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no>
In-Reply-To: <51C1A4A3.6070105@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvre7rpQcDDT5+5LM41tfFZjF1+WMW ByaPKxOusHosWfKTKYApitsmKbGkLDgzPU/fLoE74/qNmewFTXIV61d2MDUwbpboYuTkkBAw keha9ZEVwhaTuHBvPVsXIxeHkMBhRonpvU+ZIJxFjBL7G9vZuxg5ONgELCS6/2mDNIgIBEss /7SdCcQWFnCQuPd7FiNE3FGieclbFgjbSuLck/lsIDaLgKrE4y0N7CA2r4CvxJLjW8AWCwkU SHQf/QdWwymgKzF753OwOYxAB30/tQZsPrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP1aQ0yQE FCWW98tBlOtJ3Jg6hQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVI3tu YmZOernRJkZgLBzc8lt1B+OdcyKHGKU5WJTEeT+e2hUoJJCeWJKanZpakFoUX1Sak1p8iJGJ gxNEcEk1MDIuvOPUNWGRiabZEgu+ltir8+/N/iSpcVdYz9OHicGao6uGKydlqlll4OPNe6ep Goqqfl/w7dlNWcXPy94czbQT0dOcxVrzjsn4gLX18UStfYfNLWes+vY42lZkRZ6laE3Sjl2V l071v93ppt29f0vcM6b0ec9lZoTkP9Xexrdgh5Dpa6OtJ5VYijMSDbWYi4oTAdCL9HZYAgAA
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:37:34 -0000
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? 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