Subject: RE: [AVT] RTP: SSRC multiplexing for same medium

From: "Even, Roni" <[email-masked]>
Date: Wed, 8 Jan 2003 17:52:48 +0200

Hi,
Does it mean that you are saying that it is OK to multiplex RTP from
different sources. For example audio stream from two different sources
coming to the same RTP port. I thought that it is better to let the
transport layer handle the multiplexing in the network.
Thanks
Roni Even

> -----Original Message-----
> From: Stephen Casner [mailto:[email-masked]]
> Sent: Wednesday, January 08, 2003 1:18 AM
> To: AVT WG
> Subject: [AVT] RTP: SSRC multiplexing for same medium
> 
> 
> At Yokohama, we discussed multiplexing streams distinguished by
> different SSRC identifiers within one RTP session.  This discussion
> was in the context of the retransmission draft.  One or more people
> requested that a sentence be added to Section 5.2 in the RTP spec to
> say that SSRC multiplexing was OK for streams of the same medium
> (vs. different media which is the primary emphasis of that section).
> Here is the sentence I added.  Is it a good idea or bad idea to add
> this?  If you think adding such a statement is a good idea, does this
> sentence say the right thing?
> 
>                                                         -- Steve
> 
> OLD:
>    Using a different SSRC for each medium but sending them in the same
>    RTP session would avoid the first three problems but not the last
>    two.
> NEW ADDITION:
>    It may be appropriate to multiplex streams of the same medium
>    using different SSRC values in one RTP session in 
> scenarios where the
>    last two problems do not apply.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 08 Jan 2003 11:30:21 -0500

>coming to the same RTP port. I thought that it is better to let the

That has always been legal, and is the norm for multicast sessions.  The
addition is intended to make it clear that FEC data and/or retransmissions
from a single source can be multiplexed along with the original data.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 08 Jan 2003 17:49:43 +0100

Hi,

I think we need to get this definition very clear and clarify a couple 
of things. So lets make an example of how I have interpreted what's 
right and wrong in RTP multiplexing:

Case A: A receiver has an IP address (interface) and a port pair (RTP 
and RTCP). All RTP messages coming in on the RTP port is going to the 
same RTP session. Lets say that this RTP session is intended for Audio. 
So RTP messages coming from host A's microphone 1 (lecturer) is sent 
with SSRC A1. Host A also has a second microphone, nr 2 (for questions 
in the lecture hall). The RTP stream from microphone 2 at host A will 
use SSRC A2 when sending. There are also some listeners out there on the 
internet receiving this session. When the user at host B wants to ask a 
question he uses his mic and sends a audio stream with SSRC B1.

These are all media streams belonging to the same RTP session and using 
SSRC multiplexing in what I believe is the intended way. Because SSRC A1 
and A2 it is what distinguish the packets from host A from each other. 
They will otherwise have the same source and port and being received at 
the same RTP session. It is after all logical to have all these three 
sources in the same session as all participating in the lecture would 
like to hear all questions and the lecturer, they form a session.

Case B: It is not intended and strongly argued against sending also the 
video flow(s) to the same RTP session (destination/port) as the audio. 
The reason is that this is another media, which has other properties and 
may be controlled independent of the audio. See also chapter 5.2.

Case C: Know we comes to the interesting case that resulted in some 
debate, retransmission. As retransmission works in a proper way when 
sent in a way that makes it possible to distinguish from the original 
flow some multiplexing must happen. Due to the need for uninterrupted 
original RTP sequence numbers the multiplexing can't be the payload type 
which seems to be the most obvious one. Therefore some other 
multiplexing is needed. First, use another RTP session, works without 
problems, avoiding all the pitfalls in 5.2. However creating a 
completely new RTP session and using more ports are rather expensive in 
terms of resources. So looking at the retransmission flow one can state 
that this is in fact the same media as in the original flow + some extra 
wrapping. Therefore the reasons in section 5.2 of  RTP spec does not apply.

It is after all this case above that the extra sentence tries to 
address. However it seems evident that there is a lack of a clear 
explanation of the first case (A), which is actually the recommended 
one. However to explain this in much fewer words than above I don't 
think I am capable of.

>transport layer handle the multiplexing in the network.

Yes, it is allowed to multiplex RTP streams from different sources as 
long as the they are of the same media and based on the "same" session 
declaration, i.e. using the same media codecs and configurations.

Best Regards   

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Wed, 8 Jan 2003 18:47:48 -0800 (PST)

Answering several messages at once, inline...

On Tue, 7 Jan 2003, Jonathan Rosenberg wrote:

> I generally support the idea of multiplexing using SSRC. However, I
> found the text a bit inadequate for a couple of reasons:
>
> 1. multiplexing using different SSRC for the same media on the same RTP
> session is going to be the default case for multicast sessions, no? The
> text makes it sound like such a thing is an exception. Its true for
> unicast, but this section seems multicast-centric anyway.

This is a good point.  There should be a sentence or two about this.

> 2. Does this text imply that an RTP receiver MUST be prepared to receive
> multiple multiplexed streams on a single session? I expect most
> implementations today using unicast are not prepared for that (although
> I believe they should be)

No, it would be inappropriate to make that a MUST.  We do say, in
Section 6:

   RTP application designers SHOULD avoid mechanisms that can only
   work in unicast mode and will not scale to larger numbers.

> transport layer handle the multiplexing in the network.

Yes, when those sources are in unrelated sessions.  As Jonathan and
Colin mentioned, in a many-to-many IP multicast session the different
sources do all arrive on one port and are demultiplexed based on SSRC.
More below.

On Wed, 8 Jan 2003, Even, Roni wrote:

> One of the reasons mentioned for supporting it in Yokohama was to solve a
> problem of IP stack that do not handle the "select" on multiple ports very
> well. Is this a good reason for supporting unicast multiplexing in RTP. I am
> not an expert on QoS but will there be a problem with QoS protocols that
> will not be able to give different QoS for different users.

Indeed, QoS is one of the reasons given in Section 5.2.

In Yokohama we talked about SSRC multiplexing in two contexts.  One
resulted from the discussion of RTP retransmission, and the question
was whether we should allow SSRC original data packets and
retransmissions of those packets to be multiplexed in one RTP session
using different SSRC identifiers.  We decided that was OK because both
kinds of those packets should get the same treatment in the network
and should go to the same destination process.  So keeping them
together is logical.  Also, the FEC (RFC 2733) already suggests an
option to use SSRC multiplexing to carry original and FEC packets in
one RTP session.

The second SSRC multiplexing topic is the one to which Roni refers; it
was one I presented as a leftover topic that had been bounced from an
earlier meeting.  The original form of the request that triggered the
discussion was for an even bigger change, namely to make the SSRC id
be part of the tuple that distinguishes an RTP session.  We can't do
that because it precludes the multicast case.  But the motivation for
the request was, as Roni mentions, to work around inefficient
implementations of port demultiplexing in some operating systems.  If
you use a linear search to match ports to sockets, things really slow
down with a lot of ports!

Here's a little more explanation of the scenario.  In an application
with two (or maybe even N) VoIP gateways sending a bunch of streams
between/among themselves, each GW could receive all of the streams on
one socket if the SSRC identifiers could be coordinated and kept
distinct for each stream to allow demultiplexing based on SSRC.  Maybe
the socket would be unconnected to receive from multiple gateways, or
maybe there would be one connected socket per GW peer.  Managing the
SSRC id space might be tricky in the N-way case, but I'm sure you
could define a control protocol to manage it.

This scheme will work, and we can't keep anyone from implementing it,
but it does not fit right with the notion of how multiplexing should
be done in RTP, as Roni mentions.  We said it seemed like a better
idea to fix the operating systems in question.

> right and wrong in RTP multiplexing:

[snip of Magnus's good explanation of three cases]

> one. However to explain this in much fewer words than above I don't

Yes, I need to add something about the multicast case (A).  As I said
in my first message in this series, getting the wording exactly right
is tricky.  I should add that doing it concisely is even harder.  I'm
trying to do this without turning the RTP spec into a book.
(Side note to Colin: smiley).

                                                        -- Steve

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 11:48:01 -0500

inline.

>    work in unicast mode and will not scale to larger numbers.

I have a hard time seeing how this implies that receiving multiple 
streams on a single session is not a MUST. Indeed, receiving many 
streams on a single session is how multicast works, so one would imagine 
that the direct translation of this to unicast, receiving multiple 
streams on a single port for multi-unicast, would be the recommended 
approach.

If RTP does not mandate that a user be prepared to receive multiple 
streams on a single session for unicast (even though it does for 
multicast), I think it needs to say that its up to signaling mechanisms 
to indicate such a limitation. Of course, SDP has no such mechanism....

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com