SPA112 rings but can't set up incoming call

[Jaap de Jonge]

I'm trying to get my SPA112 to work... Outbound calls work just fine, but not so with inbound calls. My phone rings, but when I answer, I don't hear the person on the other side. Just a few beeps and then something like a dialtone. If I answer an inbound call on my mobile phone (Zoiper softphone) with wifi on the same network, it works just fine. What could I do to fix this issue? I've attached a log, maybe that's helpful. Thanks for any assistance!

[Dan Lukes]

The log you attached is log of SPA112 kernel. It has no value for us. The valuable log is log of voice application running on SPA112. See Debug and syslog Messages from SPA1x2 and SPA232D ATA for more.

But, may be, we need no such log now.

If the phone is ringing, then phone is successfully registered to VoIP provider (or no registration is required at all).

According the symptoms you described, the issue is related to incoming audio stream.

So we can assume one of following cause:

• NAT
• firewall
• codec misconfiguration.

Working Zoiper softphone excludes no option - it may use other port range for audio stream than you have configured in SPA112. Once provider detects the remote side is not reachable, it abort call immediately. The beeps as well as dial tone you are hearing is just new "ready for next call dialing" signal from SPA112.

While, syslog&debug of voice application may help us here a lot, the most helpful is full capture of SIP and RTP packet between SPA112 and VoIP provider.

Use Wireshark or so to capture them, attach saved *.pcap file here (it needs to be renamed to .pcap.txt or you will not be allowed to attach it).

Note that passwords will not be disclosed in such file, but user names as well as phone numbers will be contained inside. If you dislike it, I will disclose my email address of the day upon request, so you will be able to send such file just to me.

[Jaap de Jonge]

Dear Dan,

Thanks for your reply. My Wireshark proficiency is limited and rusty, but for now I managed to generate a syslog.pcap wich you'll find attached (per your suggestion it was renamed to .txt). Maybe this sheds some light already. Tomorrow I'll try to capture the packets.

By the way, if I assign the SPA112 to the DMZ it still doesn't work. Doesn't mean it still can't be a NAT / firewall issue, but I reckon it makes that less likely...

Cheers, Jaap

[Dan Lukes]

So sorry, but it's still just kernel syslog only. You must enable syslog&debug of voice application as suggested above first or you can't capture it.

No Voice log, no SIP&RTP packets - nothing to analyze so far.

if I assign the SPA112 to the DMZ it still doesn't work

I don't know your network skills. Unfortunately, term "DMZ" is used in various contexts by particular vendors and it's' rather fuzzy. It may, or may not mean "no NAT in DMZ". But I'm not claiming it's NAT for sure. It may be firewall or misconfigured codec as well.

[Jaap de Jonge]

Hi Dan,

Thanks for your patience. My mistake, I was too hasty and I hadn't properly configured the debugging and syslog settings in the SPA112.

My network skills are basic, but it's enough to realise that capturing packets between the SPA112 and provider presents a challenge, since the functionality of the network devices I have here is limited. The SPA112 is connected to a OEM docsis (cable) modem, with onboard firewall and switch. The laptop on which I run Wireshark connects to a wifi-ap that is on another port of the same device, but I can't see the external traffic to and from the SPA112. If I want to capture that traffic I'll probably need an 'old' ethernet hub or maybe I could configure my laptop (since it has 2 ethernet interfaces). Instead I downloaded and ran the syslog server to capture debug / syslog info and called my voip number from my cellphone for a test. You'll find that log in the attached file. It looks as if it could contain more meaningful information...

For your information: I changed the phonenumbers (origin and destination) and my sip accountname in this file for security reasons. It's my guess that this change shouldn't affect the analysis in this case. The originating phone number in this log that is trying to call the SPA112 is 0031621481234.

I hope this log is better than the previous one and contains useful information. Thanks again and I'll await your analysis patiently.

Best regards, Jaap

[Dan Lukes · Accepted solution]

OK. Most important part of log is the provider's BYE with the claimed reason:

Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION

So it seems to be codec configuration issue. Well, the short advice is - SPA112 configuration must follow PBX requirements.

Despite I know nothing about PBX configuration, I can guess something - the international codec is G711a (a.k.a PCMA or aLaw) with RTP Packet Size 0.020s

It seems your SPA112 have factory default configuration which is rather US-centric (G711u as most preferred codec)  or unusable at all (RTP Packet Size 0.030s).

So my recommendation is - configure G711a as only codec supported by SPA112, set RTP Packet Size to 0.020s and try again.

Capture new log if it will not work.

And one more advice unrelated to the matter itself - it seems you configured SPA112 to use CPC signal, but the analog phone you are using doesn't honor it. In such case it's better to turn CPC off at all. Set CPC Duration to 0

[Jaap de Jonge]

Hi Dan,

Bingo! I followed your recommendation and now it works! Thanks so much! I had previously noted that the SPA112's default settings were not to my providers' liking. When I first got it some weeks ago, I already changed the codec preferences, cause initially I could also not make any outbound calls. I got that to work; at that time my public phone number was not yet linked to my voip provider. That's why I couldn't test incoming calls.

My voip provider's (Xeloq) specification of supported codecs is " g729 / g723.1 / g711 ", but no mention of RTP packet size.

So sorry the SPA112's default settings are 'off' for the European market. This combined with the rather overwhelming number of system parameters, makes this ATA less suitable for the average consumer. But unless a device is provided and preconfigured by the provider, I suppose these devices aren't suitable for the average consumer in general. I was also disappointed somewhat that my provider's support did not provide any useful information when I reported my issue to them. And they didn't know much about the SPA112 at all, they only advised me on the NAT settings.

But all that isn't of much interest now, the important thing is that it now works. Thanks again and keep up the good work!

Cheers, Jaap

[Dan Lukes]

My voip provider's (Xeloq) specification of supported codecs is " g729 / g723.1 / g711 ", 

As long as you can take 80kbps required by uncompressed G.711a codec, never use compressed codecs, like G.729 and G.723.1.

but no mention of RTP packet size. 

It's because every codec have "well known reasonable default". G.711 kind of codecs use 20ms by default (10ms may be used if used for fax or data at the cost of slightly higher bandwidth required). Unfortunately, SPA112 default is 30ms which is incompatible with so many peers.

makes this ATA less suitable for the average consumer

Even SPA112 is "Small Business" kind of product, it doesn't mean it's suitable to be used by unskilled user. Based on particular environment, it may work good, it may not work good or it may not work at all.

It apply to any VoIP device, Cisco is not the exception.

I was also disappointed somewhat that my provider's support did not provide any useful information when I reported my issue to them ... they only advised me on the NAT settings.

According provider's support - no magic advice possible here. It's up to you to select whatever provider that fulfill your requirements. You should take more more criteria into consideration than just "cost" ...