SMSC Address Caching in iPhones

I'm going to make one of my increasingly-rare technical posts today.

When we got back from Burning Man this year we received a few instances of a really interesting bug report. It goes like this: "My friend X and I texted each other on the playa with your system, but now that we are back home, we can't text each other anymore. Texts to and from other people still work. We both have iPhones." After some head-scratching, I recommended a brute-force fix: "Delete all of the messages you exchanged through our system at Burning Man." It worked.

So what happened? When you receive or send a text message via SMS, it has two E.164 addresses. One address, in layer 5, is the mobile phone number of the subscriber sending or receiving the message. The other address, in layer 4, is the SMSC that processes the text message. (SMSCs are to text messages what SMTP servers are to e-mail, and they have E.164 addresses just like telephones.) Normally, the SMSC address for your outgoing text messages is set by your carrier. In some phones, you can also override the carrier's SMSC address and provide one of your own. Here's my working theory: It appears that certain models of iPhone, under some set of conditions, remember the SMSC addresses from which you received a text message and then use that SMSC address for future outbound messages. When you send a text to a given person, these iPhones appear to send the outbound message through the same SMSC used for the most recent message received from that person, or, possibly, the SMSC address used for an error message associated with an attempt to send to that person. Since the OpenBTS system doesn't have a real SMSC address, we were just filling in the SMSC address field in the L4 header with a fake number. When people got home, these iPhones continued to use this fake SMSC address to send texts to anyone from whom they received text messages through our network. Those send attempts failed. When they deleted the messages with the fake SMSC address, everything worked normally again.

So what do we do to prevent this? One solution would be to stick a known SMSC address into the L4 header, instead of the fake one, but that might have unexpected effects of its own. A better solution is to preserve the L4 SMSC address end-to-end, even though we don't use it, which is what we will do in the future.

Live and learn. It is interesting to know, though, that you can use a BTS tool like OpenBTS or OpenBSC to control SMSC settings in a closed device like the iPhone. That probably deserves more investigation.

The Man Burns in 130 Days

We have cleared the legal hurdles to run a test network at Burning Man 2009. This network will probably operate in the PCS1900 band, making it compatible with nearly all AT&T and T-Mobile handsets currently used in the US, as well as with any tri-band or quad-band handsets sold anywhere else in the world.

The current plan is to deploy a system largely intended for local (BRC-only) text messaging. We will also support limited speech service, connecting on-playa calls through user-provided numbers and routing inbound calls through the +883 country code. As a practical matter, the Burning Man 2009 experimental network will be important for testing hardware and software designs for use in rural villages, remote facilities and disaster relief applications.

We will release more details as they come together.

Putting SMS in the SIP World

SIP/SIMPLE defines two models for messaging.  In the "pager model" (RFC-3428), the message is simply transferred with the MESSAGE method and the receiver responds with "ok" or "accepted".  In the "session model", the two SIP endpoints establish a session with the INVITE procedure, transfer messages within the session, and then close the session with BYE.

SMS naturally follows the paged model.  Radio channels are scarce resources and cannot be held idle for long periods in any practical system.  A typical SMS transaction occurs outside of an established call and the radio channel is held just long enough to move a single message.  Store-and-forward handling is an absolute requirement, too.  When a short message is submitted to the network by a handset, the payload part (the TPDU) must be held until a delivery channel can be established to the destination . Even if the destination handset has service, this can take several seconds. And if the handset does not have service this can take hours or days.

When we first contemplated SMS for a SIP-oriented core network, we thought we could use a messaging server like Jabber to replace the SMSC.  That doesn't work.  Most messaging servers follow the session model.  And why not?  IM applications are session oriented and maintaining an open session in the IP world is very cheap.  These messaging servers are built for chat sessions and presence, not for storing and forwarding one-off messages to intermittently connected handsets.

So the OpenBTS project is off to build its own store-and-forward page-mode messaging server, probably from MySQL and some simple scripts, using Kannel as a gateway to conventional GSM SMSCs.  We'll post more as it happens and welcome any suggestions.