Re: [AVT] Final edits to RTP spec and A/V profile

[Stephen Casner <casner@acm.org>]

On Mon, 13 Jan 2003, Spiros Spirou wrote:

> Please see my comments below.

Thanks for your comments.

> > In a multimedia session, each medium is carried
> > in a separate RTP session with its own RTCP packets.
>
> In this sentence the word "session" is used twice but
> with different meanings.

Not exactly.  The two terms are "multimedia session" and "RTP
session".  That is, "session" is not a term by itself.  But your point
is well taken.  Chuck Harrison suggested that I include a definition
of "multimedia session" as another term, which I agree is a good
idea.

> > The distinguishing feature of an RTP session is that each
> > defines a distinct space of SSRC identifiers (defined next).
>
> Reading this I got the impression that SSRC identifiers used by
> one session cannot be used by another session. Is this the intended
> meaning?

No.  What the text was intended to mean is that each RTP session has
its own, separate, whole space of SSRC identifiers.  Different RTP
sessions may use the same SSRC identifiers independently.  I can try
revising the words.

> > A participant distinguishes multiple RTP sessions by reception
> > of different sessions using different pairs of destination
> > transport addresses, where a pair of transport addresses
> > comprises one network address plus a pair of ports for RTP and RTCP.
>
> > The distinguishing feature of an RTP session is that each
> > defines a distinct space of SSRC identifiers (defined next).
>
> > 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.  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.
>
> Each of the 3 aforementioned experts proposes a different distinguishing
> feature for an RTP session. These are a) the destination transport address,
> b) the set of SSRC identifiers and c) the scope of RTCP reports
> respectively.

These are all related aspects of an RTP session:

  - Since each RTP session defineds a separate space of SSRC
    identifiers, the same SSRC id may be used in two sessions, and
    therefore those sessions need to be received on different
    destination transport addresses in order to tell the packets
    apart.

  - If an application shares SSRC identifiers across multiple
    destination transport addresses, then there is just one SSRC
    identifier space (collisions must be resolved in that space), and
    one RTP session.

> I used to think that the common denominator in an RTP session and what
> distinguishes from other RTP sessions is only the destination RTP port
> number.

That is what RFC 1889 said for both multicast and unicast.  For quite
some time, draft-ietf-avt-rtp-new changed this for unicast so the port
numbers did not have to be common on both ends.  This was necessary
since there might be allocation conflicts with other protocols.  Now,
in this most recent expansion of the definition of an RTP session,
I've expanded the definition further to allow a single session to use
multiple destination transport addresses.  This was always necessary
(but not previously acknowledged) because an RTP translator or mixer
hooks together multiple parts of an RTP session using different
destination transport addresses.  And, we need to recognize that the
multi-unicast example that you quoted is also valid.

> In this way, the RTCP port number is implied by the RTP port, both unicast
> and multicast cases are covered and the SSRC identifiers are used to
> distinguish
> among participants of the session. I am now confused as to what constitutes
> an RTP session.

For typical, simple cases, that is all still true.

                                                        -- Steve

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