Re: [MMUSIC] Draft new version: BUNDLE-21

Christer Holmberg <> Mon, 15 June 2015 18:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E58D1A1BA9 for <>; Mon, 15 Jun 2015 11:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dlNLevjqfZXc for <>; Mon, 15 Jun 2015 11:47:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 726CB1A1B9C for <>; Mon, 15 Jun 2015 11:47:42 -0700 (PDT)
X-AuditID: c1b4fb2d-f794d6d000004501-c4-557f1dcc64e0
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E9.72.17665.CCD1F755; Mon, 15 Jun 2015 20:47:40 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Mon, 15 Jun 2015 20:47:40 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] Draft new version: BUNDLE-21
Thread-Index: AdCnhmpPanaR7/uiT5OBNmuWS4ERdP//7wcA///L88CAAEyigP//3U9w
Date: Mon, 15 Jun 2015 18:47:39 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre4Z2fpQgz8NRhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxbVE3c8EkwYqWP/PZGhgP8nYxcnJICJhI XLo0jRHCFpO4cG89WxcjF4eQwFFGifUfW6CcxYwSe3eeYu1i5OBgE7CQ6P6nDdIgIuAr8ezx bTYQW1jASGL7679sEHFjiSub1rBA2G4SnatWgtksAqoSOxubWUFsXqDemUueg9ULCVxllPi5 DKyGU0BH4uKadcwgNiPQQd9PrWECsZkFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC2EoSaw9v Z4Go15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLc dCNjvdSizOTi4vw8vbzUkk2MwDg5uOW37g7G1a8dDzEKcDAq8fAm/KwNFWJNLCuuzD3EKM3B oiTOO2NzXqiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRgb7RXecz7R6qu4XVlVePdvlglbb n23BizxCLK/NCAqbMvN+2p1IiY7giDdW01w4v7XenSYiZcG7/LGW+hqBR3e3/JjIvdJE73yI S7Tns79ZqmEPpcLvxZbYylwtXCL459qV8MNLb0WyxzxZc0Ii3+PwJNEzs77auWe9OetweV6P x8aS7JksnEosxRmJhlrMRcWJADTgkqd0AgAA
Archived-At: <>
Subject: Re: [MMUSIC] Draft new version: BUNDLE-21
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jun 2015 18:47:45 -0000


>> But, I hear what you are saying, so perhaps we instead should say "received data"?
> That would fix it here. But the usage is elsewhere, with the same concern.

The only other place where I can find "packets" being used is in relation to RTP/RTCP, and as far as I know we always talk about "RTP packets" and "RTCP packets", don't we?



> -----Original Message-----
> From: mmusic [] On Behalf Of Paul Kyzivat
> Sent: 15 June 2015 20:14
> To:
> Subject: Re: [MMUSIC] Draft new version: BUNDLE-21
> One comment, on section 9.1:
>      This document describes a mechanism to identify the protocol of a
>      received packet among the STUN, DTLS and SRTP protocols (in any
>      combination), when UDP is used as transport-layer protocol, but does
>      not describe how to identify different protocols transported on DTLS.
>      While the mechanism is generally applicable to other protocols and
>      transport-layers protocols, any such use requires further
>      specification around how to multiplex multiple protocols on a given
>      transport-layer protocols, and how to associate received packets with
>      the correct protocols.
> ISTM that something is still missing from this section. It *assumes* that the transport protocol packages things into packets, and that each such packet can be associated with one of the application protocols sharing it.
> Consider TCP: while it uses packets on the network, it is a stream oriented transport. Upper layers built for TCP may not have any notion of packets. It is probably infeasible to multiplex m-lines for such protocols using BUNDLE.
> The protocols we have been thinking of either don't work over stream oriented protocols, or else define a way to packetize.
> This could get complex. The simple thing to do is to specify that stream-oriented transports are out of scope for this document.
> 	Thanks,
> 	Paul
> _______________________________________________
> mmusic mailing list