Retransmission issues

sewilson · February 24, 2022, 5:02pm

I’m running FreePBX 15.0.21 on a VULTR server (public virtual server, static IP with no firewall besides the standard FreePBX firewall.) I have mostly old Panasonic IP phones. We have about 12 extensions, 10 of which are all at the same site behind a router that also has a static IP.

I have an issue with phones occasionally becoming UNREACHABLE, and then REACHABLE again.

As I understand the process, after an initial transmit and then six retransmits, an extension becomes UNREACHABLE. I’ve enabled SIP DEBUG in order to watch the packets as they get transmitted to each phone and then the replies received. In the period of 45 minutes, I’ve found that a single retranmission (retransmission #1) occurs for most extensions more than 100 times. The same happens for retransmission #2. Then, I’ve got about four retransmission #3 in the logs. Is that normal? That would mean an extension is being contacted four times before it’s responding.

Obviously, this EVENTUALLY causes a problem, since periodically a phone will reach the SIXTH retransmission, fail and go UNREACHABLE. I’m not sure why this is happening. I’ve tracked packets from the router the phones are behind; I can see the packets being sent, but they are not received by the phone server. When I run an MTR test, everything gets through to the other end 100%.

One of the results is that periodically, we’re getting phones that are ringing - and no one is there.

dicko · February 24, 2022, 5:05pm

Do they become ‘reachable’ on the same port or a different one?

sewilson · February 24, 2022, 5:07pm

Same ports - so it doesn’t SEEM like a NAT issue.

dicko · February 24, 2022, 5:09pm

More a ‘session timers’ issue I suspect

sewilson · February 24, 2022, 5:19pm

So I think our ITSP suggested we put SESSION-TIMERS=REFUSE in our SIP settings. (That was months ago - I don’t recall why.) I would guess removing that entry from our SIP settings might help resolve that issue.

Session timers in the extension configuration are already set to ACCEPT.

david55 · February 24, 2022, 6:06pm

Session timers doesn’t relate to going unreachable, but, to the extent that they call calls to drop, you probably want “refuse”.

Going unreachable is based on the qualify feature, using OPTIONS. An INVITE, OK, or ACK that exceeds the timeout limit will about the call, but not result in an unreachable. However, the underlying network problem that causes the INVITE transmissions is very likely to cause the OPTIONS to timeout. You need to fix the network problem, which might be due to excessive video streaming service use, as much as anything VoIP.

sewilson · February 24, 2022, 6:57pm

We aren’t using the network that much - and no video streaming. In fact, there are only four users in today - and they’re doing very little on the internet. Today is a slow day - we have been getting or making 2 calls an hour. We have a 500/50 connection.

Here are part of my logs from just in the last hour, which show one of our extensions going UNREACHABLE, then REACHABLE 10 seconds later. The port doesn’t change, so it doesn’t seem to be a NAT issue. And this time - it only did four retransmissions before going UNREACHABLE.

(We use a custom SIP port, so I’ve substituted xx60 for the custom SIP port in the logs.)

Reliably Transmitting (NAT) to STATIC-ISP-IP:4624:
OPTIONS sip:[email protected]:XX60 SIP/2.0
Via: SIP/2.0/UDP PHONE-SERVER-IP:XX60;branch=z9hG4bK4dd229a2;rport
Max-Forwards: 70
From: “Unknown” sip:Unknown@PHONE-SERVER-IP:XX60;tag=as4035a96e
To: sip:[email protected]:XX60
Contact: sip:Unknown@PHONE-SERVER-IP:XX60
Call-ID: 1824c77c2d8458203a4266c13900d478@PHONE-SERVER-IP:XX60
CSeq: 102 OPTIONS
User-Agent: FPBX-15.0.21(16.20.0)
Date: Thu, 24 Feb 2022 18:26:44 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Retransmitting #1 (NAT) to STATIC-ISP-IP:4624:
OPTIONS sip:[email protected]:XX60 SIP/2.0
Via: SIP/2.0/UDP PHONE-SERVER-IP:XX60;branch=z9hG4bK4dd229a2;rport
Max-Forwards: 70
From: “Unknown” sip:Unknown@PHONE-SERVER-IP:XX60;tag=as4035a96e
To: sip:[email protected]:XX60
Contact: sip:Unknown@PHONE-SERVER-IP:XX60
Call-ID: 1824c77c2d8458203a4266c13900d478@PHONE-SERVER-IP:XX60
CSeq: 102 OPTIONS
User-Agent: FPBX-15.0.21(16.20.0)
Date: Thu, 24 Feb 2022 18:26:44 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Retransmitting #2 (NAT) to STATIC-ISP-IP:4624:
OPTIONS sip:[email protected]:XX60 SIP/2.0
Via: SIP/2.0/UDP PHONE-SERVER-IP:XX60;branch=z9hG4bK4dd229a2;rport
Max-Forwards: 70
From: “Unknown” sip:Unknown@PHONE-SERVER-IP:XX60;tag=as4035a96e
To: sip:[email protected]:XX60
Contact: sip:Unknown@PHONE-SERVER-IP:XX60
Call-ID: 1824c77c2d8458203a4266c13900d478@PHONE-SERVER-IP:XX60
CSeq: 102 OPTIONS
User-Agent: FPBX-15.0.21(16.20.0)
Date: Thu, 24 Feb 2022 18:26:44 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Retransmitting #3 (NAT) to STATIC-ISP-IP:4624:
OPTIONS sip:[email protected]:XX60 SIP/2.0
Via: SIP/2.0/UDP PHONE-SERVER-IP:XX60;branch=z9hG4bK4dd229a2;rport
Max-Forwards: 70
From: “Unknown” sip:Unknown@PHONE-SERVER-IP:XX60;tag=as4035a96e
To: sip:[email protected]:XX60
Contact: sip:Unknown@PHONE-SERVER-IP:XX60
Call-ID: 1824c77c2d8458203a4266c13900d478@PHONE-SERVER-IP:XX60
CSeq: 102 OPTIONS
User-Agent: FPBX-15.0.21(16.20.0)
Date: Thu, 24 Feb 2022 18:26:44 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Retransmitting #4 (NAT) to STATIC-ISP-IP:4624:
OPTIONS sip:[email protected]:XX60 SIP/2.0
Via: SIP/2.0/UDP PHONE-SERVER-IP:XX60;branch=z9hG4bK4dd229a2;rport
Max-Forwards: 70
From: “Unknown” sip:Unknown@PHONE-SERVER-IP:XX60;tag=as4035a96e
To: sip:[email protected]:XX60
Contact: sip:Unknown@PHONE-SERVER-IP:XX60
Call-ID: 1824c77c2d8458203a4266c13900d478@PHONE-SERVER-IP:XX60
CSeq: 102 OPTIONS
User-Agent: FPBX-15.0.21(16.20.0)
Date: Thu, 24 Feb 2022 18:26:44 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

[2022-02-24 12:26:48] NOTICE[3550]: chan_sip.c:30535 sip_poke_noanswer: Peer ‘103’ is now UNREACHABLE! Last qualify: 383

With 10 seconds, I find this in my logs:

Reliably Transmitting (NAT) to STATIC-ISP-IP:4624:
OPTIONS sip:[email protected]:XX60 SIP/2.0
Via: SIP/2.0/UDP PHONE-SERVER-IP:XX60;branch=z9hG4bK4f537d36;rport
Max-Forwards: 70
From: “Unknown” sip:Unknown@PHONE-SERVER-IP:XX60;tag=as1802f4c4
To: sip:[email protected]:XX60
Contact: sip:Unknown@PHONE-SERVER-IP:XX60
Call-ID: 2de8e1aa0996720f24a578f8055137bc@PHONE-SERVER-IP:XX60
CSeq: 102 OPTIONS
User-Agent: FPBX-15.0.21(16.20.0)
Date: Thu, 24 Feb 2022 18:26:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

<— SIP read from UDP:STATIC-ISP-IP:4624 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP PHONE-SERVER-IP:XX60;branch=z9hG4bK4f537d36;rport=XX60;received=PHONE-SERVER-IP
Call-ID: 2de8e1aa0996720f24a578f8055137bc@PHONE-SERVER-IP:XX60
From: “Unknown” sip:Unknown@PHONE-SERVER-IP:XX60;tag=as1802f4c4
To: sip:[email protected]:XX60;tag=3336307575
CSeq: 102 OPTIONS
Allow: INVITE,ACK,CANCEL,BYE,INFO,UPDATE,OPTIONS,NOTIFY,REFER
Contact: sip:192.168.1.103:XX60
Server: Panasonic_KX-UT133/01.302 (0080f0c56e33)
Content-Length: 0

<------------->
— (10 headers 0 lines) —
[2022-02-24 12:26:58] NOTICE[3550]: chan_sip.c:24999 handle_response_peerpoke: Peer ‘103’ is now Reachable. (184ms / 2000ms)

ashcortech · February 24, 2022, 9:34pm

FWIW I know it’s not a fix to whatever underlying network issue are causing it but I had issues like that early on (FreePBX 13 I think) and could never get it resolved.

Same setup, FreePBX Distro on a Vultr VM. The solution I landed on was to create a site to PBX IPSec VPN between the Vultr VM and the local firewall. Then register the phones to the private IP on the other end of the VPN. Phones stayed connected from there on out… Only an occasional issue if the VPN dropped. I’ve got a bunch of sites still running like this with either ZyXel, Unifi or Sonicwall routers.

I used strongswan on the Vultr vm side.

system · March 27, 2022, 9:34pm

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