Transferred calls placed on "remote hold" after 30min - Session timer issue

Hi,

We’re having issues with calls from extensions to external numbers which are then transferred to another extension. In this case ext 101 dialed 3344988888, and shortly thereafter transferred the call to ext 20101. At the 30min marker the Zoiper softphone on ext 20101 shows the call as being placed on “Remote Hold” and everything goes quiet. We’ve also seen occasions where the call drops, but for the most part we are seeing the “Remote Hold”

The FreePBX is hosted in the cloud with a Public IP. Both exts 101 and 20101 are behind NAT (same LAN). Ext 101 is a Bria Softphone and Ext 20101 is a Zoiper Softphone.
Extensions and trunks are using res_pjsip.

I’m no expert, but looking at the logs it seems the trunk provider is sending an INVITE at the 30min (1800 session timer) mark. Not sure if it’s the PBX or the Softphone that needs to respond. But apparently neither does. Any clues as to how to remedy this?

Thank you!
Sal

[2020-07-08 09:35:20] VERBOSE[10522] res_pjsip_logger.c: <— Transmitting SIP request (1108 bytes) to TLS::3779 —>
INVITE sip:[email protected]:3779;transport=TLS SIP/2.0
Via: SIP/2.0/TLS :5061;rport;branch=z9hG4bKPjc81baf03-1697-4009-8279-5b4609c87c21;alias
From: “CID:” <sip:[email protected]>;tag=afd24c59-0bba-4308-a14f-6dbd7f67df05
To: <sip:[email protected];rinstance=724ccf469fd5a40b>;tag=f8151c7e
Contact: <sip:[email protected]:5061;transport=TLS>
Call-ID: df68b291-ac8d-49d9-bb5f-974c58a6dcc5
CSeq: 17269 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-15.0.16.61(16.9.0)
Content-Type: application/sdp
Content-Length: 337

v=0
o=- 588668918 588668918 IN IP4
[2020-07-08 09:35:20] VERBOSE[10522] res_pjsip_logger.c: <— Received SIP response (1040 bytes) from TLS::3779 —>
SIP/2.0 200 OK
Via: SIP/2.0/TLS :5061;rport=5061;branch=z9hG4bKPjc81baf03-1697-4009-8279-5b4609c87c21;alias
Require: timer
Contact: <sip:[email protected]:3779;transport=TLS>
To: <sip:[email protected];rinstance=724ccf469fd5a40b>;tag=f8151c7e
From: “CID:” <sip:[email protected]>;tag=afd24c59-0bba-4308-a14f-6dbd7f67df05
Call-ID: df68b291-ac8d-49d9-bb5f-974c58a6dcc5
CSeq: 17269 INVITE
Session-Expires: 1800;refresher=uac
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Z 5.4.5 rv2.10.9.0
Allow-Events: presence, kpml, talk
Content-Length: 370

v=0
o=Z 0 3 IN IP4
s=Z
c=IN IP4
t=0 0
m=audio 32050 RTP/AVP 0 106 9 8 18 3 101 98
a=rtpmap:106 opus/48000/2
a=fmtp:106 sprop-maxcapturerate=24000; minptime=20; useinbandfec=1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:98 telephone-event/48000
a=fmtp:98 0-16
a=inactive

Full SIP & PJSIP debug at the 30min marker:
https://pastebin.com/X3Y6H6Ys

Whenever I see “30 minutes” in a question, my mind always goes immediately to router/firewall configuration and session timer config.

If you look back through the forum and search for ‘30 minutes’, you will find a virton of questions and answers about the different causes and solutions for this. Here are three examples:

Thanks cynjut, I haven’t been able to find a solution in the forum.

Oddly this only happens on transferred calls, it won’t happen on inbound or outbound calls to either of these extensions.

It’s definitely a timer issue. PBX or extension (again I’m not an expert and don’t know who’s responsible for responding to the trunk’s INVITE at the 1800sec/30min marker) are not responding to the INVITE.

Which setting(s) would impact this?

Thanks again!
Sal

The provided pastebin appears to be incomplete. The SDP of the INVITE sent from Asterisk is cut off. That part needs to be seen.

The fact that it’s happening on the transfer seems like an important part of the issue. In the past, we’ve seen problems on transferred calls with things like audio. I seem to recall an issue like this on calls that went through the Misc Apps interface.

@jcolp pointed out that the SDP needs to be included in the dump you did. See if you can get that part of the log and let’s see what he can see,

I started the sip debug in the middle of the call and don’t have the SDP. Will make sure to fully log another call.

In a somewhat related post in the forum I found a user had resolved a similar issue by adding timers=no to the pjsip trunk settings. This appears to have resolved our issue. Feels like a work around as opposed to an actual solution. I’m unsure as to the actual impact this setting may have on other areas.

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