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

Jonathan Lennox <jonathan@vidyo.com> Sun, 02 March 2014 22:47 UTC

Return-Path: <jonathan@vidyo.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 403D81A0932 for <mmusic@ietfa.amsl.com>; Sun, 2 Mar 2014 14:47:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 K33nL1TMfkNe for <mmusic@ietfa.amsl.com>; Sun, 2 Mar 2014 14:46:57 -0800 (PST)
Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8058E1A0202 for <mmusic@ietf.org>; Sun, 2 Mar 2014 14:46:57 -0800 (PST)
X-Note-AR-ScanTimeLocal: 3/2/2014 5:46:54 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-80/SG:5 3/2/2014 5:46:17 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.841003 p=-0.988578 Source White
X-Signature-Violations: 0-0-0-14432-c
X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total
X-Note: SCH-CT/SI:0-1345/SG:1 3/2/2014 5:46:43 PM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail2.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 76593803; Sun, 02 Mar 2014 17:46:54 -0500
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Sun, 2 Mar 2014 16:46:53 -0600
From: Jonathan Lennox <jonathan@vidyo.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [MMUSIC] IETF#89: BUNDLE: Q12: Scope of non-RTP media de-mux procedures in BUNDLE?
Thread-Index: Ac82MKMUCOeiYc5PSXK9YNe83HDvFwAavSeA
Date: Sun, 02 Mar 2014 22:46:52 +0000
Message-ID: <822454EF-2BBF-4C9A-8ADE-734F3643120B@vidyo.com>
References: <7594FB04B1934943A5C02806D1A2204B1D1C4C88@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1C4C88@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.129.3.252]
Content-Type: multipart/alternative; boundary="_000_822454EF2BBF4C9A8ADE734F3643120Bvidyocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/KT_TIg6O_2av5EKkfuMRNlcWix8
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [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 22:47:00 -0000


On Mar 2, 2014, at 4:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

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.

In addition to this, I think BUNDLE should say explicitly that: You MUST NOT send an offer or answer with a bundle you don’t know how to de-multiplex (or multiplex).  If you receive an offer for a bundle you don’t know how to mux or de-mux, you MUST unbundle or reject m-lines so you know how to mux and demux the remaining bundle, or reject the offer.

I’m uncertain how explicitly this should define “know how to”, i.e. if the procedure has to be a normative spec.  I could imagine a scenario where there are multiple possibilities as to how to mix or de-mux two protocols (e.g., by restricting some field in one or the other protocol to a subset of its valid values, and there are multiple ways to pick the subsets), and if two endpoints have different approaches to muxing/de-muxing you would have interop failures.


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
_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic