Subject: [clue] RTP Muxing Guidance

From: Peter Musgrave <[email-masked]>
Date: Mon, 21 Feb 2011 14:47:24 -0500

Hi Magnus, 

I saw your post wrt muxing RTP in the context of rtc-web. [http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html]

Previously there was a thread on RTP muxing in CLUE. [see http://www.ietf.org/mail-archive/web/clue/current/msg00061.html for the start]

You made reference to http://tools.ietf.org/html/rfc3550#section-5.2 which governs RTP muxing. 

If I am reading this correctly ISTM that muxing only works when all the streams in the RTP session have the same payload type. In the case of CLUE I am not sure if this is the case. If I understand 3550 correctly this would then suggest that RTP muxing is not a good design choice?

Regards, 

Peter Musgrave

---

From: "Roni Even" <[email-masked]>
Date: Mon, 21 Feb 2011 23:25:31 +0200

Peter,

You can RTP mux multiple video streams, just consider the issues mentioned
in RFC 3550.

I am not sure what is your concern

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Musgrave
Sent: Monday, February 21, 2011 9:47 PM
To: Magnus Westerlund
Cc: CLUE CLUE
Subject: [clue] RTP Muxing Guidance

Hi Magnus, 

I saw your post wrt muxing RTP in the context of rtc-web.
[http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html]

Previously there was a thread on RTP muxing in CLUE. [see
http://www.ietf.org/mail-archive/web/clue/current/msg00061.html for the
start]

You made reference to http://tools.ietf.org/html/rfc3550#section-5.2 which
governs RTP muxing. 

If I am reading this correctly ISTM that muxing only works when all the
streams in the RTP session have the same payload type. In the case of CLUE I
am not sure if this is the case. If I understand 3550 correctly this would
then suggest that RTP muxing is not a good design choice?

Regards, 

Peter Musgrave

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 21 Feb 2011 16:55:41 -0500

HI Roni, 

IIUC the motivation of this section in 3550 was to dissuade re-using the same SSRC for a stream with both audio and video content (i.e. not relevant to CLUE). 

However some of the text about shared sessions with the same SSRC  looked relevant to me. Perhaps I am mistaken. 

My concern was that in the unlikely event of an SSRC collision among the multiple video streams there would be issues similar to those as described in 3550 5.2. I do realize this is a SHOULD NOT. 

However, it does also say 
"On the other hand, multiplexing multiple related sources of the same
   medium in one RTP session using different SSRC values is the norm for
   multicast sessions"

And this does seem to fit with what CLUE may choose to do. Presumably CLUE would need to guarantee SSRC uniqueness in the related sources even when the streams have a different payload type. 

Peter

On 2011-02-21, at 4:25 PM, Roni Even wrote:

> Peter,
> You can RTP mux multiple video streams, just consider the issues mentioned in RFC 3550.
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Musgrave

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 21 Feb 2011 14:29:55 -0800

Hi Peter,

I think notion of RTP muxing of media streams with the mechanism for
doing it are being intertwined, and it is being assume that the
mechanism needs to be with SSRC. Probably we would find another way to
demultiplex than SSRCs. That would be a large part of what the work in
AVT would be- figuring out an appropriate mechanism.

Thanks,

Allyn

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Musgrave
Sent: Monday, February 21, 2011 1:56 PM
To: Roni Even
Cc: 'CLUE CLUE'
Subject: Re: [clue] RTP Muxing Guidance

HI Roni, 

IIUC the motivation of this section in 3550 was to dissuade re-using the
same SSRC for a stream with both audio and video content (i.e. not
relevant to CLUE). 

However some of the text about shared sessions with the same SSRC
looked relevant to me. Perhaps I am mistaken. 

My concern was that in the unlikely event of an SSRC collision among the
multiple video streams there would be issues similar to those as
described in 3550 5.2. I do realize this is a SHOULD NOT. 

And this does seem to fit with what CLUE may choose to do. Presumably
CLUE would need to guarantee SSRC uniqueness in the related sources even
when the streams have a different payload type. 

Peter

Peter,

You can RTP mux multiple video streams, just consider the issues
mentioned in RFC 3550.

Roni Even

Hi Magnus, 

You made reference to http://tools.ietf.org/html/rfc3550#section-5.2
which governs RTP muxing. 

If I am reading this correctly ISTM that muxing only works when all the
streams in the RTP session have the same payload type. In the case of
CLUE I am not sure if this is the case. If I understand 3550 correctly
this would then suggest that RTP muxing is not a good design choice?

Regards, 

Peter Musgrave

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Feb 2011 17:48:48 +0100

> AVT would be- figuring out an appropriate mechanism.

RTP sessions are intended to separate media streams for different
purposes and kind. Here is something I have written that will show up
next week in an Internet draft. Warning for still being a non polished text.

   RTP has three fundamental points of multiplexing.  The first one is
   the RTP session, which is used to separate media of different kind or
   purpose.  Such as Audio and Video, or the document camera and the
   speaker camera in video conference.  This is multiplexing point that
   doesn't have an identifier within the RTP protocol, instead it is
   relied on the lower layer to separate the different RTP session.
   Thus the most common RTP session separation is different RTP port
   number, but also address or other identifiers maybe used to achieve
   this separation.  The second multiplexing point is the SSRC that
   separates different sources of media within a single RTP session.
   The third is the RTP Payload type, which identifies how the media
   from a particular source are encoded.

   These multiplexing points area fundamental part of the design of RTP
   and is discussed in Section 5.2 of [RFC3550].  From that list the
   ones that are directly related to the importance of the RTP session
   as concept are 4 and 5 (from RFC 3550):

   "4.  An RTP mixer would not be able to combine interleaved streams of
      incompatible media into one stream."

   "5.  Carrying multiple media in one RTP session precludes: the use of
      different network paths or network resource allocations if
      appropriate; reception of a subset of the media if desired, for
      example just audio if video would exceed the available bandwidth;
      and receiver implementations that use separate processes for the
      different media, whereas using separate RTP sessions permits
      either single- or multiple-process implementations."

   Point 4, has to do with media of different kind or purpose.  The
   processing that can happen in an RTP mixer, translator or in an end-
   point is dependent on the purpose and media type of the stream.  Thus
   there is an importance of separating such streams from each other.
   This could of course be achieved by other methods, like tagging SSRC
   values with their purpose, however there are reasons why this was not
   chosen.  First of all it is not the simple solution, as this require
   additional signalling, and possibly synchronization between session
   peers.  In addition there is the issue point 5 raises.

   Point 5 has to do with enabling quality of service or traffic
   engineering between the media flows in different RTP sessions.  By
   using different transport layer ports, QoS mechanism that are capable
   of operating on the 5-tuple (Source address, port, destination
   address, port, and protocol) can be used without modification on RTP.

   Due to these design principle implementors of various services or
   applications using RTP has not violated this model.  If one would
   chose to violate it today one would not achieve simple
   interoperability with existing services, applications and
   implementations.  Lets assume one overloads multiple RTP sessions
   into one by tagging the SSRC to belong to different purposes.  If one
   would gateway that design into a legacy system, then there would be a
   significant issue with SSRC collision.  This as the legacy system
   would not know about the need to avoid using the same SSRC in the
   different RTP sessions.

   There are also various RTP mechanism that has the potential for
   issues if one don't have a clear separation of RTP sessions:

   Scalabilty:  RTP was built with media scalability in consideration.
      The simplest way of achieving separation between different
      scalability layers are placing them in different RTP sessions, and
      using the same SSRC and CNAME in each session to bind them
      together.  This is most commonly done in multicast, but
      gatewaying of such a session would then require more alterations
      and likely stateful translation.

   RTP Retransmission in Session Multiplexing mode:  RTP Retransmission
      [RFC4588] does have a mode for session multiplexing.

   FEC:  The "An RTP Payload Format for Generic Forward Error
      Correction" [RFC2733] and its update [RFC5109] can only be used on
      media formats that produce RTP packets that are larger than half
      the MTU if the FEC flow and media flow being protected are in
      different RTP sessions.  This is because the SSRC value of the
      original flow is recovered from the FEC packets SSRC field.

   RTCP behavior also becomes a factor in why overloading RTP sessions
   is problematic.  The extension mechanisms used in RTCP depends on the
   media streams.  For example the Extended RTCP report block for VoIP
   is of suitable for conversational audio, but clearly not useful for
   Video.  This has three impacts, either one get unusable reports if
   they are generated for streams where there are little purpose.  This
   is maybe less likely for the VoIP report, but for example the more
   detailed media agnostic reports it may occur.  It otherwise makes
   the implementation of RTCP more complex as the SSRC purpose tagging
   needs not only to be one the media side, but also on the RTCP
   reporting.  Also the RTCP reporting interval and transmission
   scheduling will be affected.

   As a conclusion not ensuring that RTP sessions are used for its
   intended purpose as a multiplexing point does violate the RTP design
   philosophy. It prevents the usage of certain RTP extensions.  It will
   require additional extensions to function and will significantly
   increase the complexity of the implementation.  At the same time it
   will significantly reduce the interoperability with current
   implementations.

So read and consider and lets continue the discussion on what is
appropriate and what is not when it comes to what one put in a single
RTP session compared to using multiple ones.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 28 Feb 2011 15:19:36 -0800

Hi Magnus,
I wanted to let you know that I saw your email which brings up good points. I'm tied up for a couple of days, so I'll be able to respond later in the week.

Best regards,
Allyn

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, February 28, 2011 8:49 AM
> To: Allyn Romanow (allyn)
> Cc: Peter Musgrave; Roni Even; CLUE CLUE