I was doing some work behind a broken AOL connection this weekend. The problem was that my phone on a NAT’d subnet was unable to connect out and register with my Asterisk server which sits on a public IP. I’d see it registering on the Asterisk server and the asterisk server dutifully trying to keep the NAT open with regular “Option” requests. No matter what I did, the connection didn’t stay open. Many tcpdumps later I discovered that the STUN support on the E61 is actually quite nice. On registering the phone will lookup the STUN server for the domain it’s registering to using DNS SRV records. This is cool. You can check they exist using the following command:
dig -t SRV _stun._udp.imaginator.com or,dig -t SRV _stun._tcp.imaginator.com
If they don’t you can add them like so:
$ORIGIN imaginator.com.
_stun._udp SRV 0 0 3478 stun.ekiga.net.
_stun._tcp SRV 0 0 3478 stun.ekiga.net.
Now when my phone registers and is potentially behind a horrible NAT it can query a STUN server. In this case I’m using the ekiga stun servers. I would run my own but a stun server requires 2 public IP addresses on the same server. Something I don’t have.
Here’s the registration process now.
47454.208033 10.15.11.8 -> 88.217.199.112 DNS Standard query NAPTR imaginator.com
47454.208519 88.217.199.112 -> 10.15.11.8 DNS Standard query response
47454.218645 10.15.11.8 -> 88.217.199.112 DNS Standard query SRV _sip._udp.imaginator.com
47454.219045 88.217.199.112 -> 10.15.11.8 DNS Standard query response SRV 0 0 5060 sip.imaginator.com
47454.235146 10.15.11.8 -> 88.217.199.112 DNS Standard query A sip.imaginator.com
47454.235440 88.217.199.112 -> 10.15.11.8 DNS Standard query response CNAME bunker.imaginator.com A 88.217.199.112
47454.241153 10.15.11.8 -> 88.217.199.112 DNS Standard query AAAA sip.imaginator.com
47454.241550 88.217.199.112 -> 10.15.11.8 DNS Standard query response CNAME bunker.imaginator.com
47454.283984 10.15.11.8 -> 88.217.199.112 DNS Standard query SRV _stun._tcp.imaginator.com
47454.284320 88.217.199.112 -> 10.15.11.8 DNS Standard query response SRV 0 0 3478 stun.ekiga.net
47454.298726 10.15.11.8 -> 88.217.199.112 DNS Standard query A stun.ekiga.net
47454.348053 88.217.199.112 -> 10.15.11.8 DNS Standard query response CNAME stun.buildserver.net A 194.39.182.241
47454.354068 10.15.11.8 -> 88.217.199.112 DNS Standard query AAAA stun.ekiga.net
47455.422987 88.217.199.112 -> 10.15.11.8 DNS Standard query response CNAME stun.buildserver.net
47455.468823 10.15.11.8 -> 88.217.199.112 DNS Standard query AAAA stun.ekiga.net
47455.469167 88.217.199.112 -> 10.15.11.8 DNS Standard query response CNAME stun.buildserver.net
47455.507036 10.15.11.8 -> 88.217.199.112 DNS Standard query SRV _stun._udp.imaginator.com
47455.508302 88.217.199.112 -> 10.15.11.8 DNS Standard query response SRV 0 0 3478 stun.ekiga.net
Look at that STUN goodness happening! Not sure that this will help my AOL problem but, the E-series SIP clients need all the help they can get.
For completeness here’s a packet dump of port 5060 and the registration process (sinkhole.imagilan being the E61 phone):
sudo tcpdump -i vlan4 port 5060
tcpump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan4, link-type EN10MB (Ethernet), capture size 96 bytes
10:15:15.756401 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 479
10:15:16.755989 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 479
10:15:16.971890 IP sinkhole.imagilan.sip > 194.39.182.241.3478: SIP, length: 20
10:15:17.003216 IP 194.39.182.241.3478 > sinkhole.imagilan.sip: SIP, length: 88
10:15:17.010745 IP sinkhole.imagilan.sip > bunker.imaginator.com.sip: SIP, length: 324
10:15:17.026108 IP sinkhole.imagilan.sip > bunker.imaginator.com.sip: SIP, length: 448
10:15:17.026289 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 422
10:15:17.026375 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 484
10:15:17.190018 IP sinkhole.imagilan.sip > bunker.imaginator.com.sip: SIP, length: 603
10:15:17.190263 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 422
10:15:17.269910 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 503
10:15:27.010448 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 497
10:15:27.148699 IP sinkhole.imagilan.sip > bunker.imaginator.com.sip: SIP, length: 328
10:15:28.149370 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 561
10:15:28.272179 IP sinkhole.imagilan.sip > bunker.imaginator.com.sip: SIP, length: 336
10:15:58.978251 IP sinkhole.imagilan.sip > bunker.imaginator.com.sip: SIP, length: 4
10:15:58.978997 IP sinkhole.imagilan.sip > 194.39.182.241.3478: SIP, length: 20
10:15:59.011163 IP 194.39.182.241.3478 > sinkhole.imagilan.sip: SIP, length: 88
10:16:27.148729 IP bunker.imaginator.com.sip > sinkhole.imagilan.sip: SIP, length: 497
That final packet coming back is the SIP option command that Asterisk sends out to keep the connection alive.
Here’s a diagram of the STUN process.
Should Anyone Ask 