Incoming SIP calls on SPA3102 disconnecting

[lonvoice one]

I've configured a pair of SPA3102 ATAs as per this excellent howto: http://www.aoakley.com/articles/2008-01-08.php

The only thing that isn't working properly is inbound SIP calls. They ring on the handset fine, but when you pick the handset up, the call disconnects.

Can anyone recommend settings that I need to be looking at / what the issue might be?

[Dan Lukes]

Because of first sentence I assume both SPA3102 are connected to BT UK despite you didn't disclosed such detail. Also I assume both SPA3102 are connected to the same LAN, which is, in turn, connected to Internet via a NAT device. I also assume both SPA3102 behave the same way. You should confirm those guesses or disclose details about your's network topology.

With the assumption the guesses above are right ...

Most of "call disconnected on pickup" are caused by NAT configuration, a firewall may affect some configurations as well. There are so much types of NAT thus so much possible causes.

Turn on syslog&debug messages on SPA3102 (highest level possible) and catch them. It may, but may not help to analyze the issue. Either wait for results or catch packets related to affected call (SIP and RTP) as well at the same time. Unless you understand how it can be done on LAN ask your LAN administrator for help (unfortunately there's no generic advice how to do something like it on unknown LAN possible).

Of course, you may try to solve issue by random configuration changes of either SPA3102 and/or your NAT device, but it will take time and you may not hit correct combination. Make sure you have recorded current working configuration of all affected device so you will be able to roll back configurations to the current working one.

[lonvoice one]

Thanks for this, and sorry for the delay in responding.

It's a standard NAT firewall arrangement.

I have set the RTP ports on the SPA3102 to a narrow range, which I have forwarded on the firewall. This doesn't help, but I guess that depends whether the device or the network is setting the ports to use in the SIP conversation - I guess running a trace will tell me....

I'm unclear as to exactly what the "NAT Mapping Enable" setting does, but guessing it might be uPNP?

[Dan Lukes]

It's a standard NAT firewall arrangement.

It doesn't help so much to understand. I know at least three or four "standard NAT algorithms". Not counting the SIP-ALG extension. ;-)

Captured session may help to analyze cause.

[lonvoice one]

I've set syslog up, level to 3, and enabled 'full' in the Line1 debug setting. But I seem to be getting very limited info on the syslog. Seems just to be reg messages maybe? Every line just looks like this

2016-09-14T12:32:43.630198+01:00 10.10.131.110 [0]<<15.166.180.117: 5060(541)

2016-09-14T12:32:43.630198+01:00 10.10.131.110 

[Howard Wittenberg]

That is what you get if you put the pc's ip address under "Syslog Server" on the System Tab.  You need to put the pc's ip address under "Debug Server" on the System Tab instead.

When it is working correctly you will see an entry when you take the handset off hook on the phone attached to the SPA3102.

[lonvoice one]

Ah, oops, misread the instruction! Right, corrected that and now getting a lot more useful information, which I still can't quite work out - level 3 log of the full (failed) call process here: 

http://pastebin.com/FdxueEdD

[Dan Lukes · Accepted solution]

Don't use remote repository (like pastebin.com) in the future, please. Attach file to your comment here.

Well. We can see SIP session.There's incoming INVITE, then STUN has discovered your internal address 10.10.131.110:5060 is NATed to 5.5.5.5:1123, but RTP port pass unchanged (18750).

So far so good (assuming you are connected via E-Plus Mobilfunk which owns the 5.5.5.5 IP address).

Phone is ringing, you seized the line. SPA3102 is claiming following parameters:

Contact: home <sip:user92873@5.5.5.5:1123>
o=- 1298444 1298444 IN IP4 5.5.5.5
c=IN IP4 5.5.5.5
m=audio 18750 RTP/AVP 18 100 101
a=rtpmap:18 G729a/8000#015#012a=rtpmap

ACK from provider's server, call is considered connected.

Still so far so good. But then ...

BYE from SIP provider. Call is teared down. Claimed reason:

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

From Q.850:

2.2.7.5.8 Cause No. 88 – Incompatible destination
This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility, or other compatibility attributes (e.g. data rate) which cannot be accommodated.

It doesn't apply so much to our case. We can just guess why operator has terminated the call. Call operator support and ask.

In the mean time, as just a blind shot, try to disable all codecs but G.711a

[lonvoice one]

Ah yes I changed the public IP address for security reasons :)

The codec! That's what it was, it was set to g711*U* changed it to *A*law and it started working :) Thank you!

[Dan Lukes]

Glad to hear the blind shot has hit.

According codec - the incoming invite has claimed support for

a=rtpmap:18 G729/8000
a=rtpmap:102 SPEEX/8000
a=rtpmap:8 PCMA/8000
a=ptime:20

while your phone has claimed

a=rtpmap:18 G729a/8000
a=ptime:30

Your provider seems not to accept asymmetric ptime configuration (different values) or 30ms of ptime is unsupported at all, thus Q.850/88 error.

So if you prefer low bandwidth/low quality codec over G711a you may try G729a, but change SIP->RTP Parameters->RTP Packet Size to 0.020. There's chance it will work with your's provider.

Do it even in the case you will continue with G711a. RTP Packet Size greater than 0.020 are not recommended for G711 and may cause issues.

Note the G711a/20ms is best choice because it's native codec for 'classic' telephony - no format conversions (which case signal distortion) is necessary in such case. In USA and Japan the G711u needs to be used instead of G711a.

[lonvoice one]

That's great, thanks I will change those settings too.

It is quite odd as outbound was working fine, so I had assumed the codecs were happy!

[Howard Wittenberg]

lonvoice one,

The "howto" link you posted does not include a configuration for inbound SIP calls. The "howto" assumes a mix of outgoing calls from the handset attached to the SPA3102 either by sip or over the analog BT network. The changes for inbound SIP calls are not substantial, however they are additional settings.

One assumption is the other SPA3102 you mentioned is configured for the same purpose as the first SPA3102 and for incoming SIP calls is configured as a 2d extension or separate account from your first Voip SIP line.

As Dan Lukes said, problems of the type you mentioned are more than likely caused by your NAT configuration and he outlines good troubleshooting measures. For starters if you have not already done so you should have tried setting NAT Mapping Enable: Yes (the setting near the top of the Line 1 page, not the GW1 NAT Mapping Enable setting for the Gateway the "howto" suggests you use for outgoing calls. The next step would be to run a SIP Debug trace capturing the syslog data by a pc attached to your local network. Another more complex tool that provides additional benefits would be capturing the actual packet interchange.

For the SIP Debug trace you download and install a syslog program on a pc and put the pc's local network address under Debug Server on the SPA3102 System Tab. You set the Debug Level to 3 on the System Tab and you set the Sip Debug Option to FULL on the Line 1 Tab (and also on the PSTN Line Tab for other debugging interaction with your BT analog line). You can use any syslog program available, there is a simple Windows pc program available for download here.

For debugging your incoming SIP calls the Sip Debug Trace Syslog output will show the incoming SIP Invite and subsequent SIP control interaction with the calling server.