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

["Even, Roni" <roni.even@polycom.co.il>]

Steve,
I would like to draw another scenario,
There is a mixer in an endpoint or a conferencing bridge that can support
more then one mixing session. the mixer receives many input streams, for
simplicity let's say that they are all G.711.

Two cases.

1. Do you see the mixer receiving all the streams that are to be mixed
together in one port.
2. Do you see the mixer using one port to receive all streams that may
belong to different mixing sessions. So that this mixer will have only one
receive port for audio.


Roni Even

> -----Original Message-----
> From: Stephen Casner [mailto:casner@packetdesign.com]
> Sent: Thursday, January 09, 2003 4:48 AM
> To: AVT WG
> Subject: Re: [AVT] RTP: SSRC multiplexing for same medium
> 
> 
> 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.
> 
> 
> On Wed, 8 Jan 2003, Even, Roni wrote:
> 
> > 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.
> 
> 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.
> 
> 
> On Wed, 8 Jan 2003, Magnus Westerlund wrote:
> 
> > 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:
> 
> [snip of Magnus's good explanation of three cases]
> 
> > 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.
> 
> 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
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt