[MMUSIC] IETF#89: BUNDLE: Q12: Scope of non-RTP media de-mux procedures in BUNDLE?

Christer Holmberg <christer.holmberg@ericsson.com> Sun, 02 March 2014 16:03 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD621A07A2 for <mmusic@ietfa.amsl.com>; Sun, 2 Mar 2014 08:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDk1P3w5GFY8 for <mmusic@ietfa.amsl.com>; Sun, 2 Mar 2014 08:03:48 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7150A1A07FA for <mmusic@ietf.org>; Sun, 2 Mar 2014 08:03:47 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-ce-5313565f68fe
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 15.BC.10875.F5653135; Sun, 2 Mar 2014 17:03:44 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Sun, 2 Mar 2014 17:03:43 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: IETF#89: BUNDLE: Q12: Scope of non-RTP media de-mux procedures in BUNDLE?
Thread-Index: Ac82MKMUCOeiYc5PSXK9YNe83HDvFw==
Date: Sun, 02 Mar 2014 16:03:43 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C4C88@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.148]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1C4C88ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvjW5CmHCwwcd9/BZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtMfJ9gL3ppXLH30namB8Z5BFyMnh4SAicSr9insELaYxIV7 69m6GLk4hAQOMUrM/nicBcJZzCixducU5i5GDg42AQuJ7n/aIA0iAuoSX/f2MIPYwgIhEp8/ fmSBiEdKXDu9ngnC1pNY/ncemM0ioCLxo3cvWA2vgK9E68M1bCA2I9Di76fWgNUwC4hL3Hoy nwniIAGJJXvOM0PYohIvH/9jhbCVJBqXPGGFqM+X2L9iAjvETEGJkzOfsExgFJqFZNQsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYzsuYmZOenlhpsYgWF/cMtv3R2Mp86J HGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj9++GFr6JyeqdP1ZufXOY LXbLrb9cd3OdDdP2/RWISve7Lfbz/ppJPRKGhsutTaYtY3CaNufS0aijzB9kf5q9u+H5xuSl iGwq89SpFxWD+TbnljLPfqgyv/7Od5f/Bn6vDMJL51w7GGP2ZvHWq/p9l6KeHNi23J6h3iJl 4/edH5vOZlktncEpocRSnJFoqMVcVJwIAJZ6MqxJAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/t-2-X-GqhzVHuJFOYkjUZqtxPBM
Subject: [MMUSIC] IETF#89: BUNDLE: Q12: Scope of non-RTP media de-mux procedures in BUNDLE?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 02 Mar 2014 16:03:50 -0000

Hi,

One of the open issues is what we, in the BUNDLE spec, are going to say about de-multiplexing about different media types, and for which (if any) media types we are going to specify how the de-multiplexing is done.

We have previously agreed that we are NOT going to describe all different possibilities in BUNDLE, and that separate specifications how to perform (and, indicate support of) de-multiplexing will have to be written. However, we haven't really agreed on the details.

I intend to suggest the following in London.

In the BUNDLE spec we:


1)      Reference to RFC 5764 for how to de-multiplex DTLS/SRTP/STUN; and

2)      Separate specifications are required to describe how to de-mulitplex other media types, and any type of information that needs to be exchanged between peers in order to perform the de-multiplexing.

I think that DTLS/SRTP/STUN is going to be the main use-case (not only for WebRTC) in the near future, so I think it's a good approach.

Regards,

Christer