[kwlug-disc] WebRTC/STUN/TURN validation

[Paul Nijjar]

Here's hoping one of you has worked with (or understands) TURN and
STUN servers, because I have been struggling with this for days now. 

Say I have a server S and a client machine C. C wants to talk with S
for multimedia using RTP. Unlike the rest of the Internet where C
initiates all communication, in RTP S needs to send information to C
via UDP (so you cannot even just establish a channel). 

If C is behind a NATted firewall it is tough for S to communicate with
it. STUN supposedly solves this problem. STUN is provided by another
server X. It tells the client C what
its public IP is, and offers a server:port pairing for S and C to use.

That works until the server S is also behind a NAT (and that NAT has
bad properties like being symmetric, which I kind of get but not
really). Now the STUN connection X will only work for communications
between X and C, not between S and C. This is where another protocol
TURN comes in. In TURN, X establishes a connection between X and S,
establishes a connection between X and C, and then kindly offers to
relay traffic between the two. 

There is some other protocol called ICE that gathers information about
whether (a) you can make a direct connection ("host" records), (b)
a STUN server has found a pair to use ("srflx" records), or (c) a TURN
server has offered a relay ("relay" records). 

My understanding (which may be wrong) is that the client C has a list
of STUN and TURN servers configured in it. It then uses ICE to query
those servers. Then ICE provides a list of candidates back. 

I do not know how the server S gets a list of these candidates. My
guess is that S gets transmitted a list from C, and then chooses one
of the candidates to use. (How does this even work if S and C are
having problems communicating directly? There must be another way that
S and C communicate. In my case it is a web client which wants to
initiate voice and video connections via SIP/RTP.) 

The problem is that not all of these candidates will work. host
candidates often include NATted IP addresses and will fail. STUN srflx
records often work but not always. TURN relay records are supposed to
work but who knows? 

Here is my question: Whose job is it to confirm that the record in
question works? Is it the client's job? Is it the server's job? I do
not think it is the STUN/TURN server's job, and I do not think
(although I do not know) that it is the ICE client's job. 

In my case, the client (Firefox/Chrome) successfully sees a set of
records, including srflx records. Somehow the audio server
(FreeSWITCH) also sees this set of records. FreeSWITCH then chooses a
connection from the list -- but it chooses a STUN connection which
does not work, instead of a TURN connection that does. I need the list
of records that gets to FreeSWITCH to only include STUN srflx records
that will work, and I do not know how to accomplish this. Somebody
needs to check the list of records that are returned by ICE, and I do
not know how to make this happen or even when it is supposed to
happen.  Help?

- Paul



-- 
Events: https://feeds.off-topic.kwlug.org 
Blog: http://pnijjar.freeshell.org