RE: [AVT] RFC3550 RTP Session defintion Qi

[Stephen Casner <casner at acm.org>]

On Thu, 12 Aug 2004, Oren Peleg wrote:

> If I understand you correctly, the session is identified by the
> receiver, and not as a generic graph topology.

No.  The RTP session is a set of participants that are sharing a space
(in the mathematical sense) of SSRC identifiers and managing
collisions of SSRC identifier choices within that space.

> Let me explain using example:
>
> Lets take the 3-way conference example. Lets call the 3-way
> conference participants A, B and C. Lets say that A is sending same
> RTCP report to both B & C. From A perspective, he is in one RTP
> session with B & C.  Lets say that B is sending different RTCP
> reports to A & C. From B perspective he is in 2 different sessions
> with A & C.  So, we have here A & B that are being participating in
> an RTP sessions with each other, while not the same one ... am I
> right?

No, this is not valid.  Are you expecting that B will use the same
SSRC identifier in both RTP sessions, or choose them independently?
If it is the same, then B must avoid a collision with both A and C,
which effectively means B really does have only one RTP session.  It
is just that B is withholding reception information by telling A only
about its reception from A, and telling C only about its reception
from C.

If B chooses the SSRC identifiers independently, then there is a
possibility that on its session with C it will choose the same SSRC
identifier that A is using.  Then C experiences a collision if it
considers this to be a single RTP session, and that collision will
never be resolved.  If C considers the sessions to be independent,
then there is no collision, but both B and C will be receiving
reception information from A about two sources when they think they
are in point-to-point sessions.

> It looks to me that if the RTP standard is fundamental, it should
> not include the RTP session as a definition and only explain the
> participants behavior, while letting the above application to define
> its own specific RTP sessions definitions (E.g. Megaco Context).

No, RTP defines an RTP session which consists of an SSRC identifier
space and specifies how to manage collisions in that space.  Megaco
can define its own sessions using RTP sessions with constraints that
fit Megaco's purposes.

> If the RTP standard wishes to give some session-like capabilities,
> perhaps a session ID should have been added to the RTP header,
> helping the application distinguishing between different sessions &
> also might suggest some RTP level session manipulations as well.

That is not necessary, and I believe not useful.  Some people complain
that the RTP header is already too large; we did not want to add more
than needed.

I suspect that most implementations of RTP will only handle
point-to-point sessions because that fits the circuit mindset.
However, I still believe that designing RTP to scale from P2P to
thousands using a lightweight session mechanism was an important
contribution to networking technology and was the right thing to do.
(I am not taking the credit for myself; there were several significant
contributors.)
                                                        -- Steve

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