Chan_pjsip config setting to fix calls disconnecting after 15 minutes 30 seconds

sgseidel · February 19, 2021, 8:05pm

FreePBX 15.0.17.24 / Asterisk 16.15.1 / all modules up to date

I know the fact that calls disconnect after 15 minutes and 30 seconds is a known issue. For example:

Call disconnects after 15 minutes and 30 seconds

Calls drop at 30 minutes - #24 by arjones5

and from what I’ve seen from the replies, proposed solutions can be controverted by some. I, too, see calls disconnecting after 15 min. 30 sec., but my question is a little different, and I’m hoping someone can point me in the right direction.

The issues cited above, as far as I can tell, refer to chan_sip. In my case, the Cisco SPA 504G and Cisco SPA 525G2 phones are configured with chan_pjsip, and the VoIP.ms trunks where the issue occurs have been configured as chan_pjsip trunks (altho’ I have additional trunks from other providers, like Flowroute, BulkVS, Call48, and Anveo, some of which are chan_sip and the others chan_pjsip).

I firstly went to VoIP.ms support, and here is a transcript of what they said on this issue:

09:47:54 AM [Edward] Hi, good morning
09:50:44 AM [Stewart] Good morning Edward. I’m seeing an issue with calls spontaneously disconnecting after 15 minutes and 30 seconds. I’m using FreePBX 15.0.17.24 with the latest patches. I am using vancouver[123].voip.ms chan_pjsip trunk.
This is apparently a known issue Call disconnects after 15 minutes and 30 seconds
Can you advise?
09:52:21 AM [Edward] It is. It happens when the device or system sends in the outbound calls a header to have a session timer in the call. The default is usually 15 minutes, so every 15 minutes the server will send a re-INVITE, which your system has to follow accordingly. If it fails to follow the re-INVITE process then the call gets disconnected a few seconds later
09:52:51 AM [Edward] so basically the issue is the inability of your system to follow the re-INVITE process, usually due to NAT/UDP session time outs
09:53:56 AM [Edward] Alternatively you can disable the session timer
09:54:19 AM [Stewart] So the problem is a configuration issue with my FreePBX, specifically with the trunk configuration.
09:55:06 AM [Edward] Correct. The session timer is usually intended to end stuck outbound calls that did not end correctly
09:55:14 AM [Edward] But you can disable it
09:55:31 AM [Edward] If it is asterisk based, you can add the following line to the peer details
session-timers=refuse
09:57:15 AM [Stewart] Yes, FreePBX is Asterisk based. I’m using chan_pjsip trunks so I’ll try to find where to add the “session-timers=refuse” in the trunk configuration, or I’ll change the trunk to chan_sip.
Thanks for your speedy help.
09:57:58 AM [Edward] You are very welcome!
09:58:17 AM [Stewart] That’s all for now. Have a good day my friend.

After the reply from VoIP.ms support, and after reading through the issues cited above, I added a field at the bottom of Settings==>Asterisk Sip Settings==>Other SIP Settings in the FreePBX GUI to say:

session-expires = 7200

A second fix might be:

session-timers=refuse

Presumably the config changes above will address the issue with calls disconnecting after 15 min. 30 sec. with chan_sip, but can someone point me to a similar setting in the pj_sip configuration to fix this issue?

Thanks

dirk2358 · February 19, 2021, 8:25pm

You have to analyze the SIP data right from the beginning of the call until the end. Maybe there is a problem with the SDP session ID sent by asterisk. Probably it isn’t increased though the SDP changed since the last SDP sent by asterisk to the ISP. If the SDP session ID isn’t changed though the SDP has changed, the call will be dropped by the ISP.

lgaetz · February 19, 2021, 8:28pm

Disabling the session timer is the band-aid, what you really want to do is to configure your router to allow the SIP signaling to proceed correctly at the 15 min mark. This may be a SIP ALG, or may require forwarding the SIP signaling port(s) and securing them at the PBX firewall, not the router firewall.

However, if you do need to disable the timer, you could do so with something like this in the file pjsip.endpoint_custom_post.conf:

[trunk_endpoint_name](+type=endpoint)
timers = no

where your trunk endpoint name is the value you see in pjsip show endpoints

sgseidel · February 19, 2021, 9:23pm

@lgaetz Thanks for your reply. I’m using pfSense 2.4.5p1 as my router/firewall, and pfSense forwards SIP ports coming from the public IPs of remote phones to FreePBX, so I presume SIP ALG does not apply. I’m reasonably familiar with pfSense, but I can’t think of any way of, as you say “forwarding the SIP signaling port(s) and securing them at the PBX firewall, not the router firewall.”

I have four chan_pjsip trunks, which pjsip show endpoints shows as:

Endpoint:  Anveo_1
Endpoint:  VoIPms_1
Endpoint:  VoIPms_2
Endpoint:  VoIPms_3

Thus presumably, if I decide to disable the timer I’ll need to enter, for each of the four trunks, in the pjsip.endpoint_custom_post.conf file:

[Anveo_1](+type=endpoint)
timers = no

Stewart1 · February 19, 2021, 10:01pm

Disabling the timer should be a last resort.

Confirm that you have disabled source port rewriting and the UDP timeouts are at least twice your qualify frequency. See https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html .

To be sure that the source port is passing correctly, at the Asterisk command prompt type
pjsip set logger on
and make a test call. The Asterisk log for the call will now include a SIP trace, in addition to the normal entries. Look at one of the responses to the outgoing INVITE. The Via header should contain an rport tag with a port number that matches the value of Port to Listen On in pjsip settings. If you haven’t changed it, it should be 5060. If the rport tag shows a different value, pfsense is not correctly configured.

Stewart1 · February 19, 2021, 10:34pm

Most problems affecting re-invite also affect BYE from the remote end. Two simple tests you can try:

From a PBX extension, call your mobile, answer it, wait a few seconds, then hang up the mobile. The calling phone should show a disconnect within one or two seconds. If it takes about 30 seconds (disconnect from lack of RTP), remote BYE isn’t working at all, almost certainly a source port rewrite issue.
If the above test passes, repeat it, but this time wait 14 minutes before hanging up the mobile. If now the BYE isn’t received, you’ve got a NAT association timeout issue.

sgseidel · February 20, 2021, 12:33am

@lgaetz

The pjsip Port to Listen On is 5061. The remote phone is a Cisco SPA 525G2. Here is the SIP trace of the outgoing INVITE (with some anonymized details):

Call-ID: 3733db4e-aea8-46a3-90c8-876fa49a6c8a
CSeq: 23450 OPTIONS
Server: voip.ms
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:162.213.157.117:5060>
Accept: application/sdp
Content-Length: 0

[2021-02-19 15:00:51] VERBOSE[713] res_pjsip_logger.c: <— Transmitting SIP request (422 bytes) to UDP:11.22.23.21:31133 —>
OPTIONS sip:[email protected]:31133 SIP/2.0
Via: SIP/2.0/UDP 11.22.15.72:5061;rport;branch=z9hG4bKPj3dc1e5a7-fd4e-4297-b6a0-31f156ae8370
From: <sip:[email protected]>;tag=3a1ea21a-7856-4b90-9def-c97235e8f6ef
To: <sip:[email protected]>
Contact: <sip:[email protected]:5061>
Call-ID: cdbc4712-a6a1-4e3d-9884-51b6155e5331
CSeq: 46168 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-15.0.17.24(16.15.1)
Content-Length: 0

[2021-02-19 15:00:51] VERBOSE[14082] res_pjsip_logger.c: <— Received SIP response (439 bytes) from UDP:11.22.23.21:31133 —>
SIP/2.0 200 OK
To: <sip:[email protected]>;tag=9b8228f3298a68eci0
From: <sip:[email protected]>;tag=3a1ea21a-7856-4b90-9def-c97235e8f6ef
Call-ID: cdbc4712-a6a1-4e3d-9884-51b6155e5331
CSeq: 46168 OPTIONS
Via: SIP/2.0/UDP 11.22.15.72:5061;branch=z9hG4bKPj3dc1e5a7-fd4e-4297-b6a0-31f156ae8370
Server: Cisco/SPA525G2-7.6.2f
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces

[2021-02-19 15:00:57] VERBOSE[14082] res_pjsip_logger.c: <— Received SIP request (833 bytes) from UDP:11.22.23.21:31133 —>
INVITE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-673362f9
From: “7525” <sip:[email protected]>;tag=4c3a02d4f448d9o0
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 101 INVITE
Max-Forwards: 70
Contact: “7525” <sip:[email protected]:5060>
Expires: 240
User-Agent: Cisco/SPA525G2-7.6.2f
Content-Length: 312
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces
Content-Type: application/sdp

v=0
o=- 53772451 53772451 IN IP4 192.168.1.50
s=-
c=IN IP4 192.168.1.50
t=0 0
m=audio 16406 RTP/AVP 0 2 8 9 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729a/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv

[2021-02-19 15:00:57] VERBOSE[713] res_pjsip_logger.c: <— Transmitting SIP response (495 bytes) to UDP:11.22.23.21:31133 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.50:5060;rport=31133;received=11.22.23.21;branch=z9hG4bK-673362f9
Call-ID: [email protected]
From: “7525” <sip:[email protected]>;tag=4c3a02d4f448d9o0
To: <sip:[email protected]>;tag=z9hG4bK-673362f9
CSeq: 101 INVITE
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1613775657/b0bbab09d433602bc1937d69d0d030b2”,opaque=“5d89a3fe298b2f0f”,algorithm=md5,qop=“auth”
Server: FPBX-15.0.17.24(16.15.1)
Content-Length: 0

[2021-02-19 15:00:57] VERBOSE[14082] res_pjsip_logger.c: <— Received SIP request (397 bytes) from UDP:11.22.23.21:31133 —>

ACK sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-673362f9
From: “7525” <sip:[email protected]>;tag=4c3a02d4f448d9o0
To: <sip:[email protected]>;tag=z9hG4bK-673362f9
Call-ID: [email protected]
CSeq: 101 ACK
Max-Forwards: 70
Contact: “7525” <sip:[email protected]:5060>
User-Agent: Cisco/SPA525G2-7.6.2f
Content-Length: 0

[2021-02-19 15:00:57] VERBOSE[14082] res_pjsip_logger.c: <— Received SIP request (1103 bytes) from UDP:11.22.23.21:31133 —>
INVITE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-398f60b1
From: “7525” <sip:[email protected]>;tag=4c3a02d4f448d9o0
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
Max-Forwards: 70

Authorization: Digest username=“7525”,realm=“asterisk”,nonce=“1613775657/b0bbab09d433602bc1937d69d0d030b2”,uri=“sip:[email protected]:5061”,algorithm=MD5,response=“e2bc2f2c0e0f8a592747f272fe97596d”,opaque=“5d89a3fe298b2f0f”,qop=auth,nc=00000001,cnonce=“e334847f”
Contact: “7525” <sip:[email protected]:5060>
Expires: 240
User-Agent: Cisco/SPA525G2-7.6.2f
Content-Length: 312
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces
Content-Type: application/sdp

v=0
o=- 53772451 53772451 IN IP4 192.168.1.50
s=-
c=IN IP4 192.168.1.50
t=0 0
m=audio 16406 RTP/AVP 0 2 8 9 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729a/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv

[2021-02-19 15:00:57] VERBOSE[713] pbx_variables.c: Setting global variable ‘SIPDOMAIN’ to ‘172.16.0.175’
[2021-02-19 15:00:57] VERBOSE[713] res_pjsip_logger.c: <— Transmitting SIP response (322 bytes) to UDP:11.22.23.21:31133 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.50:5060;rport=31133;received=11.22.23.21;branch=z9hG4bK-398f60b1
Call-ID: [email protected]
From: “7525” <sip:[email protected]>;tag=4c3a02d4f448d9o0
To: <sip:[email protected]>
CSeq: 102 INVITE
Server: FPBX-15.0.17.24(16.15.1)
Content-Length: 0

From how I read it, the VIA header does indeed contain the chan_pjsip Port to Listen On 5061at remote IP 11.22.23.21:

Via: SIP/2.0/UDP 11.22.15.72:5061

dicko · February 20, 2021, 12:38am

What is your server servicing on port UDP:5061 ? If TLS then check your keys are valid and the phone can handle them.

sgseidel · February 20, 2021, 1:20am

@dicko Sorry, but it’s not clear to me what TLS has to do with the issue of the phone disconnecting after 15 min. 30 sec,; if I’m missing something please explain.

The FreePBX pjsip Port to Listen On is 5061.

Stewart1 · February 20, 2021, 1:31am

I’m very confused about the log that your posted. It shows an INVITE received by the PBX from remote extension 7525 and the initial responses to it. The communication with the trunk (which came later) is not shown at all. I believe that is what we need to see to diagnose this issue.

While it is conceivable that the timer issue is on the extension side, in which case a call from a remote extension to an internal extension would also fail, earlier posts in this thread make it reasonably clear that the trouble is related to communication with the trunk.

dicko · February 20, 2021, 1:45am

By convention port 5061 both UDP and TCP are used for TLS, that you chose that for your un-encrypted signalling port is perfectly fine.

sgseidel · February 20, 2021, 6:40am

@Stewart1 I’m very sorry. I cut and pasted what I thought were the relevant bits but I guess I got it wrong. Here is the entire session:

Stewart1 · February 20, 2021, 7:00am

Where is ‘here’? Please paste the log at pastebin.freepbx.org and post the link here.

sgseidel · February 20, 2021, 8:23am

@Stewart1 Sorry, pastebin.freepbx.org seems to have timed out for me. Maybe it’s late and the site is down for maintenance? I’ll try again tomorrow.

sgseidel · February 20, 2021, 3:55pm

@Stewart1 https://pastebin.freepbx.org/view/4ef1f416

Stewart1 · February 20, 2021, 5:27pm

You are sending the call to 162.213.157.220:42872 .
42872 is an alternate port that VoIP.ms provides to help users avoid faulty SIP ALGs or ISP-imposed blocks on port 5060.

Unfortunately, it appears that VoIP.ms doesn’t implement that cleanly – their server responds with port 5060 in Contact headers (for example, see line 737) and further dialog has source port 5060; see line 1709 showing the BYE coming from their port 5060.

While I don’t believe that this violates any RFC, it’s very unusual and I suspect that either pfSense or Asterisk is not handling it correctly when the re-invite comes along.

Try changing Server Port for this trunk from 42872 to 5060 and test. If this causes a gross problem (calls don’t work, they disconnect after 30 seconds, etc.) there is likely a simple settings change in pfSense to fix that. Of course, if you already know what goes wrong in that case, don’t bother testing it but provide details.

If changing to port 5060 doesn’t break anything but also doesn’t help, my next suspicion would be something timing out in pfSense.

sgseidel · February 20, 2021, 7:38pm

@Stewart1 Thanks, you’re a gem.

I implemented port 42872 arbitrarily with VoIP.ms simply as an alternative to port 5060 (no other reason). Previously port 5060 was working with VoIP.ms without any problem, tho’ I don’t know whether or not the 15 minute disconnect was occurring. (“If it ain’t broke…”)

I will switch back to port 5060 and check to see if that fixes the issue with the 15 minute disconnect.

sgseidel · February 20, 2021, 7:46pm

@Stewart1

If changing to port 5060 doesn’t break anything but also doesn’t help, my next suspicion would be something timing out in pfSense.

As an FYI, just this morning I upgraded pfSense from 2.4.5p1 to 2.5.0.

sgseidel · February 22, 2021, 7:32am

@Stewart1 Here is the CDR from a 38 minute phone call from a mobile phone 778-999-3664 (anonymized) to a VoIP.ms DID 778-999-8749

Sun, 21 Feb 2021 19:56 1613966196.342 “JERRY GARCIA” <7789993664> 7789998749 Dial 5045 ANSWERED 38:43

Note that three VoIP.ms trunks are registered with port 5060:

VoIPms_Vancouver1/sip:vancouver1.voip.ms:5060 VoIPms_Vancouver1 Registered Sun 23:27:57 290 Sun 23:32:47 211
VoIPms_Vancouver2/sip:vancouver2.voip.ms:5060 VoIPms_Vancouver2 Registered Sun 23:28:05 290 Sun 23:32:55 219
VoIPms_Vancouver3/sip:vancouver3.voip.ms:5060 VoIPms_Vancouver3 Registered Sun 23:28:05 290 Sun 23:32:55 220

It appears that changing the VoIP.ms registration port from 42872 back to 5060 did indeed resolve this issue. Many thanks for your help. Much appreciated.

system · June 3, 2021, 11:05pm

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