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

From: Stephen Casner <[email-masked]>
Date: Sat, 1 Mar 2003 22:11:05 -0800 (PST)

Delayed response as I finally get to finishing the editing:

On Thu, 16 Jan 2003, Jonathan Rosenberg wrote:
> Stephen Casner wrote:
> >>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.
>
> I have a hard time seeing how this implies that receiving multiple
> streams on a single session is not a MUST.

Certainly it is a good idea, but as you can see, the word in the
sentence I quoted from Section 6 is SHOULD, not 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.

Yes, I agree.

> 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....

I've added the following sentence in the definition of "RTP session"
to address that:

   The RTP framework allows the variations defined here, but a
   particular control protocol or application design will usually
   impose constraints on these variations.

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt