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

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

Return-Path: <prvs=2882cd9844=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 934E621F99D9 for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 04:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.976
X-Spam-Level:
X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 axgwKyBCmW9h for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 04:53:22 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D121F99D1 for <mmusic@ietf.org>; Wed, 19 Jun 2013 04:53:21 -0700 (PDT)
X-AuditID: c1b4fb38-b7fa16d0000027dd-b5-51c19bafb04c
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 7A.51.10205.FAB91C15; Wed, 19 Jun 2013 13:53:19 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 13:53:19 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE TEXT: De-mux procedures (June 19th)
Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CSw==
Date: Wed, 19 Jun 2013 11:53:18 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@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.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3AFDB7ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre762QcDDbreWVlMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3Bn7L+9jLljiV7Hu4nTWBsZ3zl2MnBwSAiYSTccbWCBsMYkL 99azdTFycQgJHGWUaH2/GMpZxCixu2cXkMPBwSZgIdH9TxukQURAXeLr3h5mEFtYwFhi2qtm Voi4hcTEFxvYIWw9ictr+8FqWARUJRYcfAoW5xXwlbi+ZgsjiM0ItPj7qTVMIDazgLjErSfz mSAOEpBYsuc8M4QtKvHy8T9WkBMkBBQllvfLQZTnS3x4+Z0FYqSgxMmZT1gmMArNQjJpFpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypGjuLU4qTcdCODTYzAwD+45bfFDsbL f20OMUpzsCiJ8346tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI4JJqYBRtUBEoKvPqvJWQ O8fd/NnRzpLT52z8Xs24JZypeX/rStmToVIzONOF/3ntcXARFG4ySzby6192MPbJ37Qthzg3 C96dtnV/QxA3193O3fbnI/WjL9+1fyrKXPO29t55k+fXI+6rv63zDb7yoIN79eVbNos1Y/+L HfIL/OnslH+yq7ZLed2ENiWW4oxEQy3mouJEACIIM+5PAgAA
Subject: [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 11:53:28 -0000

Hi,

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 :)

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 specification also specifies how RTP packats are separated from
   RTCP packets.

   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.