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

From: "Spiros Spirou" <[email-masked]>
Date: Mon, 13 Jan 2003 10:50:59 +0100

Hi,

Please see my comments below.

> 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. Moreover, if you assign a single
meaning to both occurrences then the part before the comma
directly contradicts the part after it due to the mutual
exclusion of the terms "multimedia" and "each medium". I would
suggest a substitution of the first occurrence of "session"
with "communication".

> 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? In this case the reader is left wondering about how a
specific subset of SSRC identifiers is reserved from the set of all
SSRC identifiers. Up to now I thought that the only constraint
for SSRC identifiers was that they should be unique within an RTP
session but the same SSRC identifier can transcend sessions.

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

Regards,

Spiros Spirou

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

---

From: Stephen Casner <[email-masked]>
Date: Mon, 13 Jan 2003 23:53:11 -0800 (PST)

> Please see my comments below.

Thanks for your comments.

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

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

> b) the set of SSRC identifiers and c) the scope of RTCP reports

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.

> distinguishes from other RTP sessions is only the destination RTP port

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.

> among participants of the session. I am now confused as to what constitutes

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

                                                        -- Steve

---

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

responses inline.

Stephen Casner wrote:

> destination transport addresses.

While I have no problem with this definition in principle, I don't see 
how it fits in with SDP, not just from a definitional perspective, but 
from a functional perspective. In particular, it was previously the case 
that the destination IP/port served as an identifier for the RTP 
session. Now, that is not the case. From the perspective of a single 
participant, an RTP session is a *collection* of (ip,port,port+1). This 
means that, from an SDP perspective, we are now in a scenario where a 
set of m-lines in SDP constitute the same RTP session. However, there is 
no identifier that indicates that. The session ID in the SDP, 
ironically, is not an RTP session ID, since it applies to the whole of 
SDP. In a multi-unicast conference composed of audio and video, a single 
SDP might have 3 video m-lines, constituting one RTP session, and 3 
audio m-lines, consituting one audio session. Thus, we have no way to 
signal which m-lines in an SDP are in the same RTP session.

Indeed, I am curious whether existing implementations of multi-unicast 
conferences actually do use the same SSRC on each unicast connection, 
and generate RR/SR based on the whole collection. Somehow, I doubt it. I 
suspect each unicast connection is treated as a separate RTP session.

-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