VoIP Caller ID and returning calls using the SPA3102

[trumpton9]

Summary

Problem: Standard phones cannot display SIP Caller IDs, because they are alpha-numeric, and the phones are only numeric.
Solution: Modify SPA3102 ATA firmware to do some clever translations.

The Problem

I've got a dilemma!  I've got an SPA3102, which is connected to my PSTN line, and also to Voiptalk for SIP calling.

When I receive a call on the PSTN line, everything is fine, and I get the correct Caller ID.

When  I receive a call from another Voiptalk user, the Caller ID is   23456789@voiptalk.co.uk, but because the SPA3102 allows you to use a   standard phone, all that is displayed on the phone is 23456789, and, of   course, I can't tell if the call is from a Voiptalk, or Joe Bloggs down   the street.

When I receive a call from a different SIP customer (e.g. 23456789@voipbuster.com), my phone, again, displays 23456789.

Of  course, for outgoing calls, I can't type the @provider stuff, so I  use  SipGate, and put a *111 style prefix to select the Voip provider.   There  are two downsides here - firstly, SipGate may not be around for  ever,  and secondly, the recipient will still have the  23456789@voiptalk.co.uk  problem mentioned above.

Possible Solutions

With my  VoIP account, I get an 0843 number, as does the other voiptalk  user, so  I can just dial that - the problem here is that the call is  passed over  the PSTN network, and I pay for it!

I could also use INUM, where  users are given a +883 number but here,  the routing option is left to  the VoIP provider, and there is a chance /  probability that the call  will cost me.

Finally, there is ENUM, where I can put my 0843  number in a DNS type  database, and other adaptors will be able to do a  look-up, and find the  proper SIP address, and I would hope that I could  do a reverse lookup  and get their telephone number which I can display  with my Caller ID.   For me, the registration attempt kept returning a  504 error stating it  could not contact my VoIP provider.  More general  problems are that if  the DNS system is not working properly, there will be a delay in  establishing the call, which will eventually be routed across the PSTN.   What is needed in this instance is some  way of determining if the  number is VoIP or not.

Solution

What  is needed is a combination of the INUM and ENUM systems.  Numbers  have  to be allocated so that it is easy to determine the routing (i.e.  PSTN  or VoIP), and numbers can be easily translated to and from their   numerical equivalents.

The best place to do this is in the ATA -  that way, you can be  responsible for your own call routing, and the VoIP  providers cannot  take control.

So, the ATA needs to do these  translations, but we can't arbitrarily  pick +883 numbers, because those  are centrally allocated to the  (currently) 39 different VoIP providers.

How it Is Implemented

The  ATA software has an add-in, which translates numbers before they  are  called, and when they are received.  The following examples show  the  VoIP provider lookup and the ENUM systems working side-by-side:

Outgoing Call

Code:

Number dialled is +00 44 12345 111111111
Prefix of Phone Number is Checked against local database
     -> prefix matches +00 (+883 eventually)
    44 12345 is translated to voiptalk.co.uk
    number translated to 111111111@voiptalk.co.uk
Optional Check for ENUM (may take some time)
     -> match found in ENUM database
    number translated to enumaddress@voipprovider.com
Default Action
     call placed via standard dialling rules

Incomming Call

Code:

Received call from 222222222@voiptalk.co.uk
Optional check for ENUM (may take some time)
     -> match found
    number translated to numerical version
Suffix of number Checked against local database
  -> sufix matches 44 12345
           voiptalk.co.uk translated to 44 12345
    number translated to +00 44 12345 222222222
Default Action
     call established, and incomming number can be displayed

How are numbers and the database managed

Numbers  are allocated on a country-by-country basis, so that individual   country's telecom organisations can take ownership of the code   allocation.  The 44 in the above example is for the UK.

VoIP  providers would have a number allocated to them in the central  database,  along with some automated checks, for example, the provider  would be  required to give the URL of a webpage that they would  guarantee would be  present, and would return a specific keyword - that  way, if the VoIP  provider were to go bust, the database could be  updated appropriately.

This  database would be mirrored across multiple servers worldwide, and   telephone adaptors would regularly download the VoIP provider lookup   tables, which would be in the format prefix/suffix, for example:

4412345 voiptalk.co.uk

How Can This be Taken Forward

The  first step will be to modify the firmware in a telephone adaptor to   demonstrate that the mechanism is viable.  I have already requested  the  GPL code from Cisco for the SPA3102 in the hope that I will be able  to  effect this tailoring.

Help!

Any thoughts or comments would be greatly appreciated!

[Alberto Montilla]

Hi Steve;

Thanks for your ideas. Let me try first to comment on your idea of using ENUM and then on the SPA3102 applicability to it.

- On ENUM: As you may know already, what you propose is mentioned as ENUM DNS services, which is meant to address all users' destination via a single E.164 number. ENUM DNS is a service planned (in the process) to be controlled by governments as this is an ITU recommendation. Unfortunately, this is not available yet in majority of countries, so the realization is not possible (reason why this is not implemented in any residential product). It is definitively a powerful mechanism that if fully and broadly implemented, will change the way the people communicates (or at least contact others) as any e-mail, SIP, pstn or isdn could be initiated to another user just by knowing one identity, the E.164 number.

- Applicability to SPA3102: SPA3102 is somehow limited to achieve what you desire. Reasoning is that majority of ITSPs requires registrations to their Proxy (i.e. client-server SIP communications) and SPA3102 supports only one registration. SPA3102 can however support up to 8 VoIP gateways, so you should be able to achieve what you want via dial plans by associating the right prefix with the right GW destination. It will not work in your case because of the registration issue. We cannot provide code for SPA3102, it is not GPL (underlying SW is not Linux/Unix) but Cisco Intellectual Propriety.

My suggestion is that you select a device that is able to handle multiple registrations and have PBX/GW functions, examples are the SPA9000 or similar devices. SPA9000 is EOS from Cisco but you can still find it from distribution channel. You will be able to route between 4 routes.

Hope the explanation helps

Regards;

Alberto

[trumpton9]

Alberto,

Many thanks for your reply.

It's a shame the SPA3102 is not GPL (what lead me to believe that it was is that you can select it in the drop-down-list when requesting GPL source from Cisco.).

From your reply, I understand that I can set up 8 VoIP gateways, which will enable me to contact people who are subscribed to 8 different VoIP providers as I can add different gateway rules in for each.

My underlying problem is actually with the fact that the SPA3102 does not translate CallerIDs into something that my standard PSTN telephone can uniquely identify, so I can't return the call, not really with the fact that I want to call people on different VoIP providers (I can always achieve that with SipBroker).

The post that I wrote was trying to come up with a suggestion on how the callerid@ascii.domain.name to 0123456789 translation could be performed (for both outgoing and incomming calls), rather than how to route calls through different providers - I shouldn't have put the ENUM stuff in there, because it just confused my proposal.

Have you any other suggestions on how CallerIDs can be turned into and from a numerical form so that they can be recognised and used with a standard PSTN handset?

Again, Many thanks for taking the time.

Steve C

p.s. also noticed a cut&paste error in my original post.  For Incomming Calls, I should have written:

Prefix of number Checked against local database
  -> prefix matches @voiptalk.co.uk
         voiptalk.co.uk translated to 44 12345