Here's some of the fires I've been putting out this week

In my role as chief first-responder to technical "fires", I thought it might be interesting to share a couple of the typical glitches we hit here day-to-day. These concern our VIP-QC app, which was designed to be the world's simplest high-quality mobile streaming app. VIP-QC allows "one-button" connect to participating stations that use the STAC-VIP talkshow system.

First, all of a sudden I got word that the app was working fine on phones that are connected via Wi-fi but failed when on the Verizon Wireless network. Weird, right? The answer was in getting packet captures of what was leaving the phone and what was arriving at the STAC-VIP. Here's one of the lines in the "SDP" header, which defines a lot about the outgoing call you wish to make. This is what we sent:
o=MxSIP 85321307875255471 85321307875255472 IN IP4 74.94.151.146
and here's what got through to the other end:
 o=MxSIP43039135937389542286 3039135937389542287 IN IP4 70.192.23.167

So the working theory is that Verizon is processing SIP calls through their wireless networks through an "ALG" that alters a lot of the information sent between devices. This might not be all bad if it works, but if you look closely you'll see the network badly "munged" the line, losing a space and reducing six fields to five. Any device trying to interpret that will fail.

Beyond that, there's also a reported issue that the app now fails when the STAC-VIP you wish to call is registered with our preferred provider, OnSIP. OnSIP is great because they handle the problem of NAT translation very elegantly, and offer free accounts at getonsip.com.

This is a little deep in the weeds, but the problem appears to be with what should have been a benign change with OnSIP accounts. One of the things about our app is that it's extremely simple--no SIP registration is required on the app side to make it work. It just blindly dials any SIP URI programmed as associated with a particular station. This works fine with OnSIP, as they accept calls to SIP addresses without the user needing to be registered on their network (this is fairly gracious behavior and not all providers support this, but it makes the VIP-QC app work).

Like a piece of mail, a SIP call has a destination and return address. Because VIP-QC doesn't register, it creates a dummy "from" address by copying parts of the "to" address. So if it's calling gary@vipuser.onsip.com, the "from" field is set to <mac address of phone>@vipuser.onsip.com.

The change OnSIP appears to have made detects when a call is made from an OnSIP user, and challenges for a password. If the "from" field says it's from a non-OnSIP account, the call proceeds normally. Since VIP-QC made up the dummy OnSIP account, it aborts the call when challenged.

How do we fix these issues? We're working on hacking the app a bit to work around both. Hopefully, we'll have an update soon. In the meantime, try to avoid Verizon Wireless and OnSIP as provider for VIP-QC.