IETF Logo Mail Archive

[MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 19 June 2013 18:38 UTC

Return-Path: <prvs=788294ad5f=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 AD52C21F9D05 for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 11:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.843
X-Spam-Level:
X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=0.406, 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 SvYVOsVl0VGM for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 11:38:34 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BC01521F9B95 for <mmusic@ietf.org>; Wed, 19 Jun 2013 11:38:33 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-f3-51c1faa7c258
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 99.AA.15700.7AAF1C15; Wed, 19 Jun 2013 20:38:31 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 20:38:31 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic_ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE TEXT: De-mux procedures (June 19th) - Late night version
Thread-Index: Ac5tHDF8oQfPVxE5Tx+3QSEPln8FiA==
Date: Wed, 19 Jun 2013 18:38:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B154D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvre7yXwcDDV6+M7OYuvwxiwOjx5Il P5kCGKO4bZISS8qCM9Pz9O0SuDP+btvNUnBCoGLeJK8Gxt88XYycHBICJhLzzrUxQdhiEhfu rWfrYuTiEBI4zChx8zeMs4hR4v7cB4xdjBwcbAIWEt3/tEEaRARUJX5vmM0IYgsLeEjsWnuE GSLuK3H7+ik2CFtP4lLXDHYQmwWoflXrBjCbF6hm+vUlYDYj0OLvp9aAHcEsIC7x4eB1ZoiD BCSW7DkPZYtKvHz8jxXCVpJoXPKEFaJeR2LB7k9sELa2xLKFr5kh5gtKnJz5hGUCo/AsJGNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAsP44JbfujsYT50TOcQozcGiJM774dSuQCGB9MSS 1OzU1ILUovii0pzU4kOMTBycIIJLqoGRtzei18jFxkjIPOnyhOnfptgUhbasj/7+d5+LGCPj HT61gyHf8/I+PDwzs2Dlm2fBxy6uvXTSbQaf0v+KmftelC+8IBlrtEnnbffLeu9bTJt8il9I NBjrfd/4z6KdUXey/zS9GX+Kml+EH3maXXFj6U2tLLtlGsF/2/OMhXZYL0zeqs8rtG+yEktx RqKhFnNRcSIAr6bTsDYCAAA=
Subject: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version
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 18:38:40 -0000

Hi,

I modified the text, based on the comments.

- The text now refers to RFC 5764 for RTP, DTLS, STUN de-multiplexing.
- I added an open note regarding how much we need to specify regarding "m= line de-muxing" for the same transport protocol.
- I removed the MUST for having to be able to do "m= line de-muxing" for the same transport protocol, as there could be cases where it's not needed.

Regards,

Christer

--------------------------------------------------


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 might
   also have to be able to, in addition to associating received data to
   its transport protocol, associate the received data with a specific
   "m=" line representing that transport protocol.

   OPEN ISSUE: We need to discuss how much, if anything, we need to say
   about associating RTP packets with the correct "m=" line, in cases
   where there are multiple "m=" lines for RTP media.

   Section 5.1.2 of [RFC5764] specifies how to de-multiplex RTP, DTLS and
   STUN [RFC5389] data packets.

   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.

v2.23.0 | Report a Bug | By Email