RE: [AVT] RFC3550 RTP Session defintion Qi

["Oren Peleg" <OrenP at audiocodes.com>]

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

So how can one identify session membership on a given graph topology?

" No, this is not valid.  Are you expecting that B will use the same
SSRC identifier in both RTP sessions"

No. Clearly B is looking at this as 2 different sessions, therefore
should assign different SSRC for each.

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

Isn't this the same with 3-way conference where each 2 participants have
a unicast session?

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

What I meant was that B & C have a unicast session with each other and
with A, while A has a Multicast session with B & C. All from the
reception point of view. Why cant A send B & C same SSRC, each one can
think that it's a Unicast session with A. Am I totally lost here?

I know that RTP multicast is the key feature of the RTP standard, I am
just trying to understand what is the RTP session definition ...

Thanks,

Oren P.

-----Original Message-----
From: casner at packetdesign.com [mailto:casner at packetdesign.com] On Behalf
Of Stephen Casner
Sent: Thursday, August 12, 2004 7:49 PM
To: Oren Peleg
Cc: Vivek Mudgil; avt at ietf.org
Subject: RE: [AVT] RFC3550 RTP Session defintion Qi

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

************************************************************************************************************
This email and any files transmitted with it are confidential material.
They are intended solely for the use of the designated individual or entity to whom they are addressed.
If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,use,
distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please notify postmaster at audiocodes.com and permanently delete the e-mail and files.


***********************************************************************************************************

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