[asterisk-dev] STUN support in chan_sip revisited

[David Vossel]

Howdy,

My initial assumptions for how and why we would want to use STUN in sip were rather naive.  I have attempted to outline what I believe is the current expected behavior and am asking for some additional feedback.

--- Expected use of STUN in chan_sip.

In chan_sip, a STUN server can be queried to obtain the external address/port of connectionless SIP traffic to the local Asterisk box behind a NAT.  The only reason querying a STUN server would be used rather than setting the external address statically in sip.conf is if the address and port mappings used by the NAT device are dynamic or unknown, and the only way to accurately receive the correct address/port mappings used by the NAT device is to send the STUN request out the same transport and port as the SIP traffic is being sent out.   This is because the addressed/port received by the STUN response must directly map to the external address/port we expect to receive external SIP responses/requests in on.  Once the external address/port is received from the STUN response, that address/port is used in SIP and SDP messages which indicates where we exist so other endpoints can communicate back with us.

Another useful effect of using STUN support is as a keepalive mechanism for the state entry on the NAT device.  By setting the 'externrefresh=180 ;where 180 is the configured number of seconds' option in sip.conf we should expect the STUN request to be set every 180 seconds in order to refresh the state entry on the NAT device.

--- Current STUN implementation problems/limitations

1.  When STUN is used, the response's port mapping is internally used for both the external address for TCP and UDP.  Since STUN queries are connectionless and use the configured UDP port, the STUN response is not accurate as an external address for TCP connections.

2.  When a STUN request is sent out, we block on the SIP UDP socket, throwing away any non-STUN related traffic until the STUN response is received.  This means that any SIP signaling received during a STUN query is just thrown away.  It also makes for some confusing error messages.

3. Using STUN queries as a keepalive mechanism does not work exactly like it is documented in sip.conf.  According to the documentation by setting the 'externalrefresh=x ; where x is number of seconds' option we  should expect an event to fire every 'x' number of seconds.  This is not an accurate assumption as there is no scheduled event that causes a STUN request.  We are only guaranteed that a new STUN request will be sent sometime after 'x' number of seconds after the ast_sip_ouraddrfor() function is invoked as a result of processing a new incoming or outgoing SIP request of some sort.

4. Asterisk's STUN implementation has no way of determining the correct external port mappings for media.  This means that while the SIP signaling may work correctly, the media may.  Because of this, I question why anyone would even choose to use Asterisk's STUN support at all.

--- Conclusion.