20131130

STUNned... when a useful feature burns your ass

So I've been doing some experimentation with Asterisk.  I have deployed a couple of servers so far, one at work and one at home, both pure testing environments.  Yeah, don't worry, I have horribly miserable-to-type (i.e. strong) passwords on all my test accounts.  Anyway, I kept running into a small problem with my home box.

It all started with intermittent audio.  It was an issue I kept experiencing on my desktop clients, on my phone clients (such as CSipSimple and ZoIPer), but strangely not on my tablet.  Basically, sometimes the audio would work, and sometimes it wouldn't.  Now, I was simply calling a test extension, one which would play "Hello, world!" over and over again.  On occasion the audio would kick in part way through the sequence.  Usually it would either work or, more often, be absent altogether.

The SIP registration was fine.  The receive calls even worked, to the right client.  The legacy version of desktop ZoIPer, for instance, seemed to handle things well, but the newer version kept having issues.  I toyed with the sound card settings.  I tried removing bluetooth from the equation (which is probably just as well, as I keep having BT connectivity issues with my headset - probably an adapter problem).  I even tried connecting to my work server.

The work server worked fine.

While considering whether or not it could be an issue with my bleeding-edge release of Asterisk (which I had to compile to get Google Voice/Chat integration working correctly, at least in version 11), another observation finally struck me.  Earlier in the evening, as I watched the SIP debug packets fly by, I noticed that the client IP was not always a local address.  In fact, it had no reason not to be local, the server and the client were in the same subnet!  STUN support, as it appears, was part of the culprit.  Given that I don't know nearly enough about STUN, ICE, or SIP to really speak authoritatively about this stuff, I'll give it my best guess:  the client was using STUN and finding its external IP, which it was relaying to Asterisk during part of the call.  At other times it was using its well-known internal IP.  The server, consequently, tried talking to an unregistered IP and decided it wasn't such a good idea.

Intermittently.

Anyway, disabling STUN in the clients seemed to work well.  Especially with the newer desktop version of ZoIPer.  In my Asterisk config I had once issued an externaddr directive in sip.conf, but ended up commenting it out as my server currently lives on a dynamic IP.  I will eventually try to fix that, one way or another.  Disabling STUN is, naturally, not an ideal solution.  Things should work regardless and the client ought, in my opinion, to be smart enough to figure out when it does and doesn't need STUN.  Or maybe Asterisk is really missing that externaddr directive and isn't telling the client the right thing to do.

In either case, I'm just happy to finally have working clients.  Now to pick out a FXO/FXS card...