Re: [rtcweb] draft on media multiplexing submitted to AVTCORE

[Christer Holmberg <[e-mail]>]

Hi,

> I just want to be clear what you mean by "BUNDLE".  I assume here that you refer to the use of the grouping mechanism and NOT necessarily the use of disjoint payload type values?

Correct.

> Correct me if I am wrong:
> So you propose that the SDP grouping mechanism would be used regardless of the RTP multiplexing scheme employed to indicate that some form of multiplexing is to be used and to identify which lines are grouped together.

Correct.

> If no other mechanism is agreed, then multiplexing based on payload type is assumed.

Yes. The details of that, however, is something that the community will have to discuss and agree upon. My point was that it would be easier to define a fallback if we use a single mechanism for bundling m- lines together.

> If ssrc-prefix values are successfully negotiated then RTP subsessions are used.  If SHIM is successfully negotiated then SHIM is used.  (This all depends on which schemes are ultimately supported.)

Correct.

> I have no objection to this approach in principle but am not convinced that we need to support all of these multiplexing schemes.

That is a separate discussion :)

Regards,

Christer




-----Original Message-----
From: Christer Holmberg [mailto:[e-mail]]
Sent: Monday, June 04, 2012 11:10 AM
To: Ejzak, Richard P (Richard); [e-mail]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi Richard,

> I agree with you that we should separate the discussion of how multiplexing is done at the RTP level from
> how it is signaled in SDP.  My draft addresses both aspects by describing how to partition the SSRC space
> between m lines at the RTP level and how to signal that use in SDP using a new "ssrc-prefix" attribute.

Sure. But as far as the IP address:port re-use is concerned, I think you should use BUNDLE.

> With the use of the ssrc-prefix attribute to identify RTP subsessions it is not absolutely necessary to use the
> grouping framework to indicate bundling, since the ssrc-prefix attribute implicitly indicates the bundling.
> These two mechanisms are compatible but redundant.

I see no reason for having two mechanisms to do the same thing, and in general I also think we should try to avoid implicit indications. If often causes troubles later on.

Using BUNDLE would also make it easier to define fallback behavior. For example, you could say that if the SDP answerer does not support the ssrc-prefix, but it does support BUNDLE, the fallback would be default BUNDLE behavior.

Regards,

Christer




-----Original Message-----
From: Christer Holmberg [mailto:[e-mail]]
Sent: Monday, June 04, 2012 8:54 AM
To: Ejzak, Richard P (Richard); [e-mail]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi,

> I agree that BUNDLE in its current form would be consistent with the RTP subsessions proposal, but it would also be technically redundant.  I'm not sure exactly which comments in the paper you object to.  I agree with you about the purpose of BUNDLE
> and that it works (with limitations) for its intended purpose.  My understanding is that BUNDLE is primarily intended for the case where a single RTP session is shared across m lines.

That is not true. That is only the "default" that we chose, and the limitations in the draft are related to the case when you use a single RTP session - they are not related to the BUNDLE mechanism as such.

> There is no need for BUNDLE (and specifically the constrained PT assignment) when you use another mechanism such as SHIM or RTP subsessions to segregate the
> flows associated with each m line.  Whether the grouping framework is applicable is open for discussion.

You still need something in order to use identical IP address:port values for multiple m- lines.

> So perhaps we should separately discuss the grouping framework and constrained PT assignment procedures associated with BUNDLE to be sure we understand one another.
> The source of our disagreement may be more what is meant by "BUNDLE" than anything else.  I have no problem redefining it if there is agreement to do so!

We should separate the discussions on how the multiplexing is done on the RTP level (which I think your draft mostly focuses on) and how it is signaled in SDP.

Regards,

Christer



________________________________________
From: Christer Holmberg [mailto:[e-mail]]
Sent: Monday, June 04, 2012 2:23 AM
To: Ejzak, Richard P (Richard); [e-mail]
Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE

Hi Richard,

I will not comment on the RTP aspects of your proposal, but I don't understand your comments regarding BUNDLE.

The core purpose of BUNDLE is to allow the usage of identical IP address:port information for multiple m- lines.

It is true that BUNDLE defines that, by default, all media belong to the same RTP session. But, nothing prevents you from using BUNDLE also with multiple RTP sessions, RTP "subsession" etc. You simply need an extension mechanism  to indicate/negotiate such usage (in your case the ssrc-prefix could perhaps be used for that).

Regards,

Christer

From: [e-mail] [mailto:[e-mail]] On Behalf Of Ejzak, Richard P (Richard)
Sent: 4. kesäkuuta 2012 2:10
To: [e-mail]
Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE

Please see the mail attached below that I just sent to avtcore announcing a personal ID I just submitted on the topic of media multiplexing.  I am sending this notice to rtcweb since this is the group that triggered recent work on RTP multiplexing.

I also request the rtcweb chairs consider giving me some time to present this work at next week's interim meeting if there is time on the agenda.  It might be useful to discuss the ideas in the ID before avtcore meets in Vancouver.

Richard

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: '[e-mail]'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt

In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration.  There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use of SSRC as the basis for multi session multiplexing that I think is superior and worthy of consideration as a potential replacement for BUNDLE and/or SHIM.  Please comment.

Richard

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, June 03, 2012 5:16 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository.

Filename:   draft-ejzak-avtcore-rtp-subsessions
Revision:   00
Title:            Media multiplexing with Real-time Transport Protocol (RTP) subsessions
Creation date:    2012-06-04
WG ID:            Individual Submission
Number of pages: 9

Abstract:
   This document describes a means of multiplexing RTP streams having
   different media types within a single transport connection and how to
   represent this multiplexing option in SDP.  This mechanism is an
   alternative to the BUNDLE and SHIM proposals currently under active
   consideration in AVTCORE.  Instead of adding an extra multiplexing
   header as in SHIM to allow multiple RTP sessions within a single
   transport connection, or using the payload type field to separate
   different media streams within a single RTP session, this document
   describes how to partition the existing SSRC space to create RTP
   subsessions from a single RTP session.  A filter can be used to
   identify each RTP subsession for different QoS handling as necessary.
   RTP subsessions can be treated like RTP sessions with a few
   restrictions.  In particular, SSRC mapping may be needed when
   forwarding RTP streams into an RTP subsession to avoid SSRC
   conflicts, but there are few use cases in which this limitation is a
   concern and RTP subsessions can be disabled if necessary.




The IETF Secretariat