Low Cost Calling Rules Engine

Within the low cost calling extension the rules engine carries out the work of translating from the outgoing number (the number selected by the user to dial) to the dialling number (the number actually dialled by the 'phone). It does this in two stages:

1. Select which of a number of potential dial chains to use


2. Iterate over a given dial chain to generate the dialling number

At the first stage the rules engine looks at the prefix of each dial chain in order and compares it to the outgoing number (it will use the first matching dial chain that it finds in the list, so ordering of the dial chains will be important). Once it has a suitable dial chain then it will process each entry in the dial chain to ensure that. Also, there is an implicit last dial chain at the end of each list that has no prefix and just returns the outgoing number. This ensures that all numbers will be dialed even if there is no rule to allow low-cost dialing.

A dial chain consists of a number of dial pieces, each of which contains a simple rule to generate a piece of the final number to be dialed (hence the name). A dial piece may provide one of the following:

• A user-entered number


• The outgoing number


• A pause


• The hash/pound key


• Hang up/li>
  

All of this is pretty straightforward, with a couple of exceptions. First is that the outgoing number may require some translation as it may use an incorrect prefix for international dialling (although this only matters when in a different country from your 'home' country). Second is that there appears to be no standard way of indicating that the line is to be hung up.

Between this and the process flow there should be a rough framework for building the extension. Next step: build it!

Low Cost Calling Process Flow

The design of the low cost calling extension is starting to come together. One of the items that is of interest is the ability to divert calls outside of the voice-based network entirely, for example sending the call over IP. Although this is not something that I am looking to provide at current I think that it is important that the architecture provides for this capability. As such I have introduced the idea of separate call routers, with the initial design only providing a single call router that carries out rewriting of the outgoing number without attempting to change protocol.

The basic flow of the extension is shown below.



Here there are five steps that take place when the a dialer application is ready to make a call:

1. The extension daemon sends details of a call to be made to the low cost calling extension


2. The request is picked up by the request handler, that passes on the details of the call to the call router


3. The call router uses information available to it such as current location, time of day, details from the address book etc. (but not the outgoing number) to select a set of rules to apply to the outgoing number


4. The rules engine applies the rules to the outgoing number and generates a number to dial


5. The number to dial is passed back to the extension daemon and hence to the dialer application

In the next post I will expand upon the rules engine, which is the item that does the actual work of generating the number to dial given the outgoig number.

Low Cost Calling for OpenMoko

So I have received my 'phone and spent some time doing the usual sshing in to it, making simple calls and the like, and overall am both happy and surprised at the feel of the 'phone, both physically (it is smaller and lighter than I expected, and its slightly strange shape does not make it harder to hold) and functionally (it's quite zippy, although I'm sure there are optimisations down the line that will make it even faster).

So, on to what to do with it. Well one of my personal bugbears is the inability to easily use lower-cost methods of calling. To do this without mangling your addressbook requires the ability to rewrite outgoing telephone numbers depending on its destination. So my first actual application will provide users with a way of deciding out to route their calls in various ways to reduce costs. I will need to gather some use cases for this so will be working through the various methods in the next week or so, but any comments on how you would like to see low cost calling implemented would be appreciated.

OpenMoko Phones Available

The OpenMoko 'phones are finally available. There are so many things that you could do with an open source 'phone that the biggest problem is working out where to start, but I think I'm going to spend some time looking at the messaging interface. Although people talk about 'smartphones' and 'convergence' a lot they're just mini PCs running lots of disparate applications, and it shows most in the interface.

Why do voicemails and emails show up in different areas of the 'phone? Why do sending an SMS and sending an IM use different interfaces? Why can't there be a way of knowing if people are on-line or off-line, and route messages appropraitely? It's an ugly mess at the moment, even in the best operating systems. Some sort of unification is required.

Anyway, a 'phone has been ordered so when it shows up I'll see what the thing is really like and if there is scope for this to start to become a real personal communicator rather than just another 'phone.