Re: [AVT] Re: What is an RTP Session?

["Mike Taylor" <mtaylor@dspos.com>]

Thanks so much.  This is just the kind of helpful info I was
hoping for.  

----- Original Message ----- 
From: "John Lazzaro" <lazzaro@CS.Berkeley.EDU>
To: <avt@ietf.org>
Sent: Monday, October 14, 2002 4:42 PM
Subject: [AVT] Re: What is an RTP Session?


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

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