Re: [MMUSIC] Another bundling proposal - Christer's comments

worley@ariadne.com (Dale R. Worley) Mon, 04 March 2013 20:23 UTC

Return-Path: <worley@shell01.TheWorld.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 ECC2521F8FB3 for <mmusic@ietfa.amsl.com>; Mon, 4 Mar 2013 12:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level:
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 u66CRntOnLii for <mmusic@ietfa.amsl.com>; Mon, 4 Mar 2013 12:23:09 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 533AA21F8FAC for <mmusic@ietf.org>; Mon, 4 Mar 2013 12:23:09 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r24KMDw0030337; Mon, 4 Mar 2013 15:22:16 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r24KMDlj3074902; Mon, 4 Mar 2013 15:22:13 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r24KMDkk3066535; Mon, 4 Mar 2013 15:22:13 -0500 (EST)
Date: Mon, 04 Mar 2013 15:22:13 -0500
Message-Id: <201303042022.r24KMDkk3066535@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-reply-to: <7594FB04B1934943A5C02806D1A2204B10AE32@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com)
References: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> <201302252244.r1PMiujk2613075@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B107B87@ESESSMB209.ericsson.se> <201302262018.r1QKIpUW2695618@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B10AE32@ESESSMB209.ericsson.se>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments
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: Mon, 04 Mar 2013 20:23:10 -0000

> From: Christer Holmberg <christer.holmberg@ericsson.com>
> 
> >>But, as far as I remember, there were never much discussion about it. 
> >>It was an open issue on one of my slides, and people simply indicated 
> >>support for adding explicit information, rather the referencing.

> As far as I remember, there were no real technical reasons - it was
> mostly "cosmetic".

If it's *purely* cosmetic, that is, only for human consumption, a
endpoint can add "a=comment:..." lines to document the PT
configuration of the bundle.

(What?  You've never heard of the "comment" attribute?  It isn't
defined -- and so all endpoints ignore it!)

> But, one issue is if there is an intermediary (e.g. transcoder) that
> modifies the payload type/codec information in the non-BUNDLE m-
> lines, but leaves the BUNDLE m- line untouched and passes the
> "kumquat" payload transparently. The offerer and answerer would not
> have different payload type/codec information.

Although if the PTs were listed in the bundle media description, there
would be no assurance that the intermediary would modify the PTs in
the bundle media description and the constituent media descriptions in
a coordinated way.  (Assuming the intermediary doesn't understand
bundling.)  That would cause demultiplexing to fail.  And that
analysis is true for all of the bundling proposals I've seen that
transmit the constituent media descriptions.

In any case, since we expect the RTP streams to be encrypted, no
transcoding is possible.

> >Adding payload types to the bundle media description makes it more
> >difficult to ensure that a non-supporting answerer rejects the
> >bundle media description.
> 
> It depends on how it's done. You could still only indicate "kumquat"
> on the m- line, but then provide the encapsulated payload type
> information using SDP attributes.

There's a design question "How do you ensure that non-supporting
answerers reject the bundle media description?"  There are three ways
that I know of:

1) an otherwise unused the media type.  Current proposals are
"anymedia" and "multipart".

2) an otherwise unused "proto" value.  No current proposals use this.

3) offering only an otherwise unused codec.

If what you mean is to provide a listing of the codecs used by the
constituent streams, but in some attribute other than a=rtpmap, or to
list them in a=rtpmap attributes but not put the PTs in the "fmt" list
of the m= line, it's not clear what benefit would be gained beyond
what a=comment would provide.  In any case, it's not clear how you
would describe the multiplexed SCTP streams in a way analogous to how
you would describe the RTP streams.

Dale