RE: [AVT] RFC3550 RTP Session defintion Qi

[Stephen Casner <casner at acm.org>]

On Sun, 15 Aug 2004, Oren Peleg wrote:

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

By the set of SSRC identifiers heard in both RTP and RTCP, and by
their mapping to longer identifiers in the required RTCP SDES CNAME.

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

Actually, they could be the same or different, but if they are chosen
randomly as prescribed, then they will probably be different.

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

It would be, if A were also communicating in independent unicast
sessions with B and C.  But your scenario was that A had a shared
session with B and C.

> "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'm not sure what you mean by "multicast" in conjunction with "from
the reception point of view" if you are talking about IP-layer
multicast.  IP multicast is more an aspect of transmission as it
relates to this discussion, even though the set of destinations is
determined by which receivers join the group in IP multicast.

One point to make clear is that it makes no difference to RTP whether
multicast or unicast is used at the IP layer, so it does not affect
this discussion of the RTP session definition.  Either one packet is
sent to a multicast address and received by all participants that have
joined that multicast group, or separate packets are sent to unicast
addresses of the other participants.  In the multicast case, the
destination port number obviously must the same for all receivers.  In
the unicast case, it could be the same or different.  It does not
matter to RTP.  That is what the RTP session definition says.

Yes, B and C can send RTP packets with different SSRC identifiers to
each other and to A, while A sends RTP packets with the same SSRC to
both B and C.  B and C would not know whether A was using the same
SSRC for both of them or different ones.  However, when A sends an
RTCP SR or RR packet to C containing a reception report block
describing its reception from B, that block will contain an SSRC
identifier that C does not know.  If C thinks it has a 2-party RTP
session with A, that could even be considered a violation of
protocol.

I hope you are not going to respond by asking why A would send a
reception report about B to C.  The scenario you specified was that A
has a shared RTP session with B and C, and RTCP reception reports are
supposed to be sent to all participants in the session.

Perhaps you are ignoring RTCP.  If you ignore RTCP, then the concept
of an RTP session becomes undefined, and there is no point in debating
what constitues an RTP session.

                                                        -- Steve

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