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

[Christer Holmberg <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Dale R. Worley
Sent: 22. helmikuuta 2013 23:06
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic