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

[John Lazzaro <lazzaro@CS.Berkeley.EDU>]

> Stephen Casner <casner@acm.org> writes:
>
> How do you avoid collisions in the choice of SSRC identifiers? 

If a session has N parties, each party is responsible for sending
an RTCP unicast stream to each of the other N-1 parties. In this
sense, sfront enforces an "all-to-all" session topology, just
as true multicast does. 

So, in steady-state, a party sees an RTCP stream from
each of the other parties, which is sufficient for doing SSRC
collision detection on its own SSRC.

However, compared to a true multicast scenareo, two pieces of
information are missing:

 [1] A party cannot detect the presence of a new session
     participant by examining the incoming unicast RTCP and
     RTP flows. Instead, active session management is needed
     (in the case of sfront, a B2BUA "SIP conference server"
     that exchanges session descriptions between the parties
     of a session).                  

 [2] Party A cannot sense how well Party B is receiving the
     RTP stream sent by Party C, because it doesn't see the
     RTCP traffic flowing between Parties B and C. 

So, session management is not needed to handle SSRC collisions,
but is needed for [1].                             

In addition, session management information is needed for
a party to associate the streams sent to a new party with
the streams received from a new party. This information 
takes the form of the username and address in the origin
line of the session description sent in [1], which matches
the CNAME of the RTCP packets sent back from the receiver of
the streams defined in the session description. Without this
information:

  o  A party wouldn't be able to know how to correctly 
     "narrowcast" RTCP RR reports.

  o  A party wouldn't know which RTP and RTCP streams to
     stop sending when another party exits. 

In practice, sfront NMP does currently "cheat", and embeds
the SSRC into the session ID on the origin line. The use
of a single-threaded B2BUA conference server at Berkeley
to set up sfront sessions makes it easy for the conference
server to see SSRC clashes -- it rejects INVITEs with 
clashes, with a non-standard SIP header line that tells
the new party to choose a new SSRC. But, I don't believe
this hack is required ... just as true multicast sessions
use the CNAME to associate streams, I'm pretty sure the
CNAME is sufficient for doing association in this case too.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt