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

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Feb 2013 13:09:23 +0000

Hi,

I had previously provided comments to Dale off-line. Some has been addressed in the -03 version of the draft. But, I still have some questions.

First, unless I've missed something, the mechanism is still for RTP ONLY. It is not possible to e.g. put the DataChannel in the bundle. I think we asap need to decide whether that is a requirement or not.

Second, you use the non-bundle m- lines for codec negotiation etc. But, previously, when MMT was discussed, I believe that people indicated that they do not want to "refer" to other m- lines from the MMT m- line. Instead,  the information should be explicitly provided in the MMT m- line (which is the reason why the SDP size gets pretty big with MMT, as most information is duplicated).

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 22. helmikuuta 2013 23:06
To: [email-masked]
Subject: [MMUSIC] Another bundling proposal

I've written an alternative bundling proposal which I think manages the problems of bundling better.

A series of tutorial examples are here:
http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4
so it's easy to see how the proposal works.

Distinctive features of this proposal are:

- A separate m= line describes the bundled media, allowing unambiguous
  attribution of attributes to either the bundle or a constituent, and
  independent rejection of each constituent.

- Backward compatibility is achieved straightforwardly.

- Multiplexed media flows are attributed to their original constituent
  media descriptions without requiring each to be declared
  individually in the SDP.

- The multiplexed media flow is artificially given the media type
  "audio" to prevent rejection by SBCs.

- An encapsulating RTP format is used so demultiplexing can be done
  without coordinating payload types between media descriptions, and
  to ensure the bundled media description is rejected by
  non-supporting endpoints.

- Zero/non-zero ports and valid/null addresses are controlled to avoid
  duplicate port usage, and to ensure SBCs see exactly the media flows
  specified by the SDP.

Filename:	 draft-worley-sdp-bundle
Revision:	 02
Title:		 Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP)
Creation date:	 2013-02-22
Group:		 Individual Submission
Number of pages: 27
URL:             http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-02.txt
Status:          http://datatracker.ietf.org/doc/draft-worley-sdp-bundle
Htmlized:        http://tools.ietf.org/html/draft-worley-sdp-bundle-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-02

Abstract:
   This document defines a generic bundle mechanism for the Session
   Description Protocol (SDP) by which the media described by a number
   of media descriptions ("m= lines") are multiplexed and transmitted
   over a single transport association.  The transport association is
   described by an additional media description, allowing SDP attributes
   to be applied to the aggregate, independently of attributes applied
   to the constituents.  In offer/answer usage, the bundle mechanism is
   backward compatible with SDP processors that do not understand the
   mechanism.  The mechanism is designed to be compatible with the
   limitations of the existing Internet infrastructure.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Feb 2013 17:44:56 -0500 (EST)

> From: Christer Holmberg <[email-masked]>
> 
> I had previously provided comments to Dale off-line. Some has been
> addressed in the -03 version of the draft. But, I still have some
> questions.

I'm now in the position to deal with technical improvements.

> First, unless I've missed something, the mechanism is still for RTP
> ONLY. It is not possible to e.g. put the DataChannel in the
> bundle. I think we asap need to decide whether that is a requirement
> or not.

That's true.  Although none of the other 5 proposals I've seen discuss
SCTP/DataChannel multiplexing either.  Fortunately, adding support for
SCTP isn't difficult, either with encapsulation or without.

> Second, you use the non-bundle m- lines for codec negotiation
> etc. But, previously, when MMT was discussed, I believe that people
> indicated that they do not want to "refer" to other m- lines from
> the MMT m- line. Instead,  the information should be explicitly
> provided in the MMT m- line (which is the reason why the SDP size
> gets pretty big with MMT, as most information is duplicated).

I've heard that mentioned before, but I've never seen the argument in
favor of it.  Can someone tell me what it is, or provide a pointer?

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Feb 2013 08:03:58 +0000

Hi,

>> ONLY. It is not possible to e.g. put the DataChannel in the bundle. I 
>> think we asap need to decide whether that is a requirement or not.
>
> That's true.  Although none of the other 5 proposals I've seen discuss SCTP/DataChannel multiplexing either.  Fortunately, adding support for SCTP isn't difficult, either with encapsulation or without.

You would encapsulate SCTP inside the new payload type?

>> Second, you use the non-bundle m- lines for codec negotiation etc. 
>> But, previously, when MMT was discussed, I believe that people 
>> indicated that they do not want to "refer" to other m- lines from the 
>> MMT m- line. Instead,  the information should be explicitly provided 
>> in the MMT m- line (which is the reason why the SDP size gets pretty 
>> big with MMT, as most information is duplicated).
>
> I've heard that mentioned before, but I've never seen the argument in favor of it.  Can someone tell me what it is, or provide a pointer?

It was indicated in a meeting (at the moment I can't remember which meeting, though), but I never checked whether it was added to the minutes. I guess it will be on audio recording.

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.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 26 Feb 2013 15:18:51 -0500 (EST)

> > I've heard that mentioned before, but I've never seen the argument
> > in favor of it.  Can someone tell me what it is, or provide a
> > pointer?
> 
> It was indicated in a meeting (at the moment I can't remember which
> meeting, though), but I never checked whether it was added to the
> minutes. I guess it will be on audio recording.
> 
> 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.

If this desire exists, I'd like to hear technical reasons why it is
desired.  Adding payload types to the bundle media description makes
it more difficult to ensure that a non-supporting answerer rejects the
bundle media description.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Feb 2013 10:01:35 +0000

Hi,

>>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.
>>
>If this desire exists, I'd like to hear technical reasons why it is desired.  

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

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.

(Of course, if you assume that such intermediary would always remove the KUMQUAT grouping attribute value, the case won't occur.)

>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.

Regards,

Christer