[AVT] Re: What is an RTP Session?

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

> Mike Taylor" <mtaylor_eng@hotmail.com> writes:
>
> Furthermore, does anyone know of any commercial or public domain 
> voice conferencing apps that can create multipoint unicast 
> peer-to-peer conferences? 

While its not "voice" conferencing, the GPL'd sfront:

http://www.cs.berkeley.edu/~lazzaro/sa/index.html

does MIDI sessions using multipoint unicast. You can read about the
details here:

http://www.cs.berkeley.edu/~lazzaro/sa/sfman/user/network/

and download code to play with. 

Basically, it works like this:

 -- There's a "conference SIP server" (a B2BUA, in practice) 
    running at Berkeley, that keeps track of active sessions.

 -- When someone joins a session, it sends an SDP describing how
    to send data to itself to the Berkeley SIP server. This SDP
    includes a UDP IP/ports that the sender listens to using 
    recvfrom() in a connectionless way, so that it can receive
    DGRAMs from many sources.

 -- The Berkeley SIP server distributes the SDP of the new 
    session participant to the existing participants (if any),
    which all then start sending RTP and RTCP to the new member.

 -- The Berkeley SIP server sends the SDPs of the existing session
    participants to the new participant, which send starts sending
    packets to all of them. Each SDP codes the UDP IP/ports that the
    participant listens on for DGRAMs from any sender.

 -- The Berkeley server uses a variant of the NAT-breaking ideas
    for SIP currently working through midcom, to solve the
    problem that the "new session participant" might be behind
    a NAT box. We don't support firewalls -- in practice, about
    25% of the people who try to demo sfront seem to fail because
    of firewall issues, from my cursory look at our logs, so this
    is a significant shortcoming.

 -- Receiver multiplexing is a bit sticky, because by the rules
    of SDP, the hosts need not send UDP from the same IP/ports
    pair its receiving from. Sfront gets around this by assuming
    the sending and receiving IP/ports are the same, and falls
    back on demultiplexing via SSRC (which is explicitly 
    discouraged in the RTP RFC, for good reason ...) if this
    assumption is failing.

 -- I would recommend NOT to do multipoint in the way sfront
    does, unless you are also willing to run SRTP and authenticate
    every RTP and RTCP packet coming in.  By running UDP w/o a
    connect(), literally anyone could send you a UDP packet,
    which could be crafted to exploit bugs in your decoder and
    root your machine, etc. Sfront does this sort of authentication,
    but since it predates SRTP it uses its own method to sign the
    packets. 

Some of what I describe about is probably not legal SIP/SDP/RTP usage,
I tried as hard as I could to stay within the bounds of the RFCs when
implementing it, though ...

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