Retransmission Timeout Reached on Internal Calls


#1

Hi All,

I am having an issue where all internal calls are ringing 2 times and going to voicemail. The recipient phone does not ring at all. BLFs do update showing that the phone is ringing, even though it is not. External calls are working perfectly. All phones and PBX are on the same switch and network. The cause appears to be the “retransmission timeout reached on internal calls” which looks like it is typically a networking issue.

Here is a tcp dump of the interface that connects to the LAN on the PBX. It is also limited to a single ip. I placed one internal call and these are the results.

https://pastebin.com/LR45aXpt

Here is the asterisk log from a similar call.

https://pastebin.com/vH4t87YV

I did isolate 2 phones and the pbx on a brand new switch. The results were the same. I also moved the main network interface to another available interface and the results were the same.

Any help would be greatly appreciated.


#2

Have you configured the freepbx network settings correctly? Have you defined trusted zones on the freepbx firewall?


#3

What do you mean by “configured the freepbx network settings correctly”? This is a new issue on an existing system, it just recently started happening. The firewall is disabled and I have confirmed that the subnet is listed in the asterisk sip settings page.


#4

That’s exactly what I meant. Network settings related to trusted networks and sip. Sorry if I didn’t get that this is an existing setup.


#5

Sorry if my post sounded snappy. I didn’t mean for it to but looking back I can see how it looks that way.

So I think the problem lies in the second packet but I could be wrong. The first packet shows the invite from the phone (104@172.25.59.229) to the pbx (172.25.59.164) the second packet shows the pbxs reply of 401 unauthorized. I am not sure why it is being denied or if it is even related to the issue I am experiencing.

It does seem like they are able to communicate just fine. In fact the call does go through to the pbx for the voicemail so it is definitely able to establish a call between the phone and the pbx. I am also still able to park calls. The only thing that is not working is establishing a call between 2 endpoints. I have to think that the 401 is related.

I’ll have to try a endpoint to endpoint call on a working system and compare the dumps. Will report back tomorrow.


#6

That 401 is expected, FreePBX is just asking the phone to authenticate itself. Are you using that network on purpose? 172.25.x.x is not a private network, 172.16.x.x is.


#7

172.25.x.x is a fine private network; see


#8

Ya it is within the range, I have however, seen a network using public addresses in a private lan. It was odd.

So if the 401 is supposed to be there then I guess I’ll still have to compare to find what is missing.


#9

Sorry, not sure what was I looking at regarding the network, but the initial 401 is expected as the PBX is asking the phone to authenticate.


#10

The phones are using ‘random’ local SIP ports and if something caused them to ‘regenerate’ the port number, an incoming INVITE would receive no response.

See


page 49, try setting Use Random Port to No (on the destination phone) and retest. Also, try setting Register Expiration for the account to 2 (minutes).

However, your statement about external calls being OK may conflict with the above theory. How are extensions reached from outside (dedicated DIDs, IVR, queue, etc.)?

Do you have qualify set for these extensions? If so, do they go ‘unreachable’?

Just after an incoming internal call fails, can you ping the destination phone from the PBX?


#11

Extensions are reached like this ivr>ring group. Not sure about qualify. I have seen phones on other systems say unreachable in the endpoint manager, is that what you mean? If so then no they are not doing that.

I’ll try the grandstream settings and the ping later today.


#12

Ok so I have some better logs. Still unsure what is causing this issue to occur. I believe it has something to do with the SIP re transmission error. The error states “no reply to our critical packet”. Does anyone with more experience than I know what I should be looking for in the packet capture to determine the cause of this retransmission error?

SIP debug (call from 109 to 104)
https://pastebin.com/Cqv43LSB

full debug (call from 109 to 104)
https://pastebin.com/Lhmi74cx

tcpdump (call from 109 @ 172.25.59.198 to 104 @ 172.25.59.229)
https://pastebin.com/Ar8eGuMh


(Dave Burgess) #13

I did a quick Google search, and remembered that the error message actually has a link in the error message. There are lots of pointers to solutions, which include SIP-ALG interactions and UDP NAT redirection settings.


#14

Yes I read that article. Here it is.

https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

In my tcpdump I am seeing that the calls are establishing, but there are so many interactions in a single call it is difficult to track. It is possible that there are a few missing packets, but I dont know how to tell where they should be.

Here are the reasons listed in the article as potential causes.

For some reason signalling doesn’t work as expected between your Asterisk server and the other device. There could be many reasons why this happens.

  • A NAT device in the signalling path. A misconfigured NAT device is in the signalling path and stops SIP messages. (The devices involved here are 2 sip phones, the PBX, and a dumb switch so I dont think NAT is the issue)
  • A firewall that blocks messages or reroutes them wrongly in an attempt to assist in a too clever way. (same as above)
  • A SIP middlebox (SBC) that rewrites contact: headers so that we can’t reach the other side with our reply or the ACK. (I am far from an expert but from what I understand there is no SBC in this case, unless Freepbx could be considered the SBC)
  • A badly configured SIP proxy that forgets to add record-route headers to make sure that signalling works. (no proxies involved here unless there is something built in to the default freepbx config)
  • Packet loss. IP and UDP are unreliable transports. If you loose too many packets the retransmits doesn’t help and communication is impossible. If this happens with signaling, media would be unusable anyway. (I do not think this is the case either as the issue happens every time without exception. Even when using new cables, switch, and network interface. I am open to suggestions if there is something I missed here.)

I still have yet to try changing any grandstream settings on the endpoints themselves. Hoping to give that a try soon. Thanks for all the help and suggestions guys. I really appreciate it.


#15

Executing [s@func-set-sipheader:1] NoOp("SIP/109-00000cd0", "Sip Add Header function called. Adding Alert-Info = ;info=internal") in new stack

I suspect that the Grandstream thinks this is corrupted and choking on it, so not responding to the INVITE.

In FreePBX Advanced Settings, try setting Internal Alert Info to unset.

If no luck, post another full debug.


#16

That was it Stewart. I completely missed that. This was a legacy setting I had for the grandstreams to allow for alternate ring tones. I’m guessing that grandstream has changed their syntax causing this to break. Thank you everyone for all the help!


(system) closed #17

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.