View Single Post
Unread 06-12-2010, 02:44 PM   #1
Junior Member
Join Date: Aug 2009
Posts: 3
Thanks: 1
Thanked 0 Times in 0 Posts
scaev is on a distinguished road
Default Numeric-to-alphanumeric translation for arbitrary SIP URI

Hello, currently I'm trying to play with the SIPBroker service, and I have one suggestion.

The SIPBroker is essentially a redirection service which takes a number in form *(network-code)(sip-number) and redirects it to (sip-number)@(network-address), e.g. *4190000 translates into

The need for such a redirection service arises, as I see it, mainly when using ATAs (analog telephone adapters) instead of IP-phones or softphones, as ATAs are ordinarily unable to make calls to arbitrary SIP URIs in a full form.

However, while being quite economical in the sense of the dialled number length, SIPBroker service has two main drawbacks.

First, it confines the service to a predefined list of SIP operators. Any operator/end user who wants to be accessed via SIPBroker has to register with it.

Second, it only deals with the "right side" problem of the SIP URI, leaving the "left side" problem unsolved. For example, if I want to call to John Doe at I must dial *4191234 and it is easily done with my ATA. But if I know Jonh's SIP URI only in alternative form I would be unable to call John using SIPBroker service.

The only solution to these problems, as far as I think, is to add an extra service that would do a translation of the numeric sequence (formed by known rules) into a full SIP URI. For example, let us set the following numeric-to-alphanumeric mapping table 00 = 0, 01 = 1, ..., 09 = 9, 10 = @, 11 = ., 12 = _, ..., 21 = a, 22 = b, 23 = c, 25 = A, 26 = B, 27 = C, ..., 94 = z, ..., 99 = Z and arrange that redirects to full SIP URLs resolved according to the list above. Then -> m and a call to m turns out to be a call to

The main disadvantage of the offered scheme is a huge length of a numeric-translated number. This can be eased by several means, e.g. partial translation (translate only left part of SIP URI while replacing the right part when using ordinary *-rules, e.g. * ->

The advantage of the offered scheme is quite clear: it allows to make a call to ANY SIP URI just using ATA, without any extra settings, setting short number dialling and so on.

Of course, there is a great room for discussion, including the actual need for such service. But is think that the offered scheme might be quite simple to implement anyway.

P.S. domain address have been used here solely for illustrative purposes; any other domain could be on its place.
scaev is offline   Reply With Quote