RE: [AVT] RFC3550 RTP Session defintion Q

[Stephen Casner <casner at packetdesign.com>]

On Wed, 11 Aug 2004, Oren Peleg wrote:

> Sorry, still confused ... at the next paragraph it is written that a
> three-way conference where each participant sends to each other, both
> RTP & RTCP, is defined as three different RTP session, while according
> to the fact here below that a single RTP session participant may have
> distinct port pairs when communicating with other participants ... what
> am I missing???

That paragraph offers two alternative ways to use RTP.  The following
sentence applies to both of them:

      For example, consider a three-party conference implemented using
      unicast UDP with each participant receiving from the other two
      on separate port pairs.

The first way to use RTP in this setting is:

      If each participant sends RTCP feedback about data received from
      one other participant only back to that participant, then the
      conference is composed of three separate point-to-point RTP
      sessions.

The second way to use RTP in this setting is:

      If each participant provides RTCP feedback about its
      reception of one other participant to both of the other
      participants, then the conference is composed of one multi-party
      RTP session.  The latter case simulates the behavior that would
      occur with IP multicast communication among the three
      participants.

I think your problem is that you are expecting the RTP spec to
constrain its use to one, narrow mode of operation.  It would be
inappropriate to do this because RTP is a fundamental protocol, like
TCP, that may be used with a wide variety of applications.  The last
paragraph of the RTP session definition explains this:

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

So, the constraints you are seeking will come from another
specification that defines how RTP will be used in a particular
application.



On Thu, 12 Aug 2004, Vivek Mudgil wrote:

> Oren has made a right point. The line
>
> ", or may use a distinct pair of ports for each"
>
> contradicts the RTP session definition at other places. It requires a
> closer look. Especially, how an implementation of this would satisfy
> the distinguishing feature of RTP Session:
>
> "The distinguishing feature of an RTP session is that each maintain
> a full, separate space of SSRC identifiers (defined next). The set
> of participants included in one RTP session consists of those that
> can receive an SSRC identifier transmitted by any one of the
> participants either in RTP as the SSRC or a CSRC (also defined
> below) or in RTCP"

I see no contradiction here.  When distinct pairs of ports are used
for multiple participants in a single RTP session, then separate
copies of the same SSRC identifier must be transmitted to each
participant (in RTP as the SSRC or CSRC, or in RTCP).  This is as
described in the "second way to use RTP" above.

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt