SeattleWireless
[Blog Home] [Homepage] [Projects] [SeattleWireless] [Email Me] [Resume DOC] [Resume HTML]
Location:

Fri, 30 Dec 2005

More fun with the SI-680H

After a lot of digging, I determined what "SIMPLE" messaging referred to. This is actually "SIP Message". Its supported by several handsets and pieces of software (like asterisk) to varying degrees. Currently, asterisk does not properly support reception of text messages, and can only transmit text messages to a handset during calls. This makes text messaging difficult to implement. My definition of "text messaging" is the ability to transparently send SMS-like messages of 160 characters or greater to other handsets, and ultimately, other providers. Which, BTW, can be done economically -- more on this later.

Thankfully, there are several promising hacks to offer such a system on VoIP phones like the Senao SI-680H that offer both MO (Mobile Origination) and MT (Mobile Termination) features via SIP Message.

As an added benefit, SIMPLE/SIP Message is supported during a call too on the handset. This is a very good thing.

Also, I have not been able to get the voicemail indicator to light (MWI) to show up on the SI-680H. I suspect that it does not support it. But then again, even one particular GSM carrier went without this for years, and simply used SMS notifications. Sounds pretty reasonable.

After I finish up a finalized asterisk configuration, which will include inbound/outbound dialing, voicemail, and activation system, it will be time for User Acceptance Testing (UAT). My hypothesis is that it will fail, but I plan on publishing some of the results...I suspect they will be interesting. People expect phone to work, cell phones are irrating, and i suspect that a VoIP phone with a UI designed by an engineer for an engineer will likely throw one heck of a wrench into the works. Maybe someone in Taiwan will read it and take a hint. Please give us good WiFi VoIP phones that end users like grandma can use!

[/voip] permanent link

SIP is Scary (Part 1)


There is nothing worse than an unregistered SIP phone. In this state, numerical dialing, as we know it, does not work. Dial 911 on an unregistered phone? HAH! sucker! Nothing happens. The entire concept of voice over IP is so abstract, there are many layers in the system (At Layer 7 or lower) that need to be put into place in order to permit voice traffic.

VoIP is not circuit-switched. The piece that makes the call is not sitting at the bottom of the OSI like other conventional cellular systems. You can't just dial a random number from an unauthorized phone, and get routed to 911, activation, or told that you are not permitted to make calls. Combinding VoIP with WiFi also introduces a number of new problems.

Lets go through the sequence of an average WiFi VoIP phone as it goes through all sorts of hoops to become a telephone. I will include basic flow and state machines in the same diagram. We will learn how complex the process is, what the breakdown points are, whats wrong with the state of WiFi VoIP today, and maybe some solutions to fix this problem.

Look at this giant state machine, and you can see why a simple concept as WiFi VoIP can be a very challenging ordeal. Being able to properly identify where a breakdown is taking place is absolutely critical in a WiFi VoIP network.

WiFi VoIP State Machine:

Here is more detail on all the processes involved:

Currently, on WiFi VoIP SIP phones today, dialing 911 (or any other emergency/activation/etc number) before State 7 results in no action. This probably goes for just about any other SIP phone out today. I propose the following framework or best practices for WiFi VoIP handling of emergency calls. Handset designers should probably consider incorporating some of these features. This will become more and more important as the FCC pushes E911 requirements on VoIP data networks.

Quick Draft - Best Practices for handling Emergency Calls

  • Specialized handling of "911" dialings

    If "911" is entered into a (WiFi) VoIP handset, and handset is not registered properly, the following attempts should be made:

    • Use pre-defined IP suffix existing in SIP phone config to place SIP call directly to proxy/gateway. IE: suffix is @10.1.1.2, so: 911@10.1.1.2

    • If handset is associated but is not assigned an IP address, handset should contain a pre-defined emergency static address, range, or make use of auto config address to establish the SIP session to the emergency number at the specified emergency gateway.

    • If handset does not have WiFi association, I am uncertain what the best effort attempt should be..

  • Transmission of useful data using SIP MESSAGE on established 911@x.x.x.x call

    Handset should originate useful information that would aid in the location of the particular handset in order to meet E911 standards. Location information would be items like:

    • Current SSID
    • Current BSSID
    • RSSI/Signal strength of current association
    • Quick scan for all BSSID's within an SSID (ie: all seen AP's for a given SSID), and RSSI/signal strength to aid in trangulation
    • Quick scan of everything near by, including SSIDs, BSSIDs, and associated RSSI/signal strength
    • Identity information like username, etc.
    • GPS location from internal GPS receiver

  • Special QoS or diffserv marking when 911 call made

    [/voip] permanent link

    For past blog entries, check out the archive on the side or click here.


  • Make some extra cash with your blog too: