VoIP Caller ID and returning calls using the SPA3102
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.
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 firstname.lastname@example.org, 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. email@example.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 firstname.lastname@example.org problem mentioned above.
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.
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:
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 email@example.com Optional Check for ENUM (may take some time) -> match found in ENUM database number translated to firstname.lastname@example.org Default Action call placed via standard dialling rules
Received call from email@example.com 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:
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.
Any thoughts or comments would be greatly appreciated!
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.
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 firstname.lastname@example.org 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.
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
Join David Bombal as he busts the myths around Cisco Designed while building out an SMB network right at his desk.
David, a CCIE, CCSI and an educator, has delivered training courses all around the globe across multiple Cisco topics. And he’s desig...
This Chat covers the intersection of technology and social impact from community to global levels. Learn how digital maturity accelerates SMB growth and profits that can fund social programs and enable sustainable business practices like remote work.
This Chat covers the intersection of technology and social impact from community to global levels. Learn how digital maturity accelerates SMB growth and profits that can fund social programs and enable sustainable business practices like remote work. We'l...
Join us live on Thursday, April 29 at 10 am PT as we discuss how the pandemic affected non profits and find out what their secret weapon was to weathering the past year. Our guests will share how giving back during this challenging time actually enabled t...