Calls going dead after being put on hold for a few minutes - New behavior

[jpercival]

Hi there. We have just recently added queues to our 3CX system. We have one department that routinely needs to put callers on hold for a few minutes while issues are researched. Ever since we implemented call queues this team says that all (if not most) calls have issues once the caller has been placed on hold for an extended amount of time. The guess is that the being on hold starts being problematic after 3 minutes. We did switch over to another incoming SIP provider a couple weeks before this so that could also be a factor, but I'm not sure how.

When our employee goes to resume the call it indicates that it's still active but they cannot hear anything. Upon calling the caller back, they are told that things just went silent with no hold music and then disconnected shortly thereafter. The hold/resume process has not changed on our employee's end, as they're simply pressing the hold/resume button on the Fanvil phone that they've been using for months.

Any ideas? Thanks in advance!

• 3CX Version, Enterprise Annual 16.0.619
• Server OS, Server 2019
• Is the 3CX Server Hosted: Local VM
• IP Phone: Fanvil x4, latest supported 3cx firmware
• Provisioning Method: Local
• Trunk Provider: Unitel
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

 

[AWS2P]

Is your SIP provider a supported one ?

 

[jpercival]

Is your SIP provider a supported one ?

They are not on the supported list on the 3CX website from what I can tell. Our IT manager manages and chooses our SIP providers and agreements but I know that We used Plivo and Flowroute for quite some time but switched because of their lack of immediate support.

I'm hoping this doesn't get filed under the "They're not on the list, this issue will not be looked into" trash can.

 

[AWS2P]

No,we can try to help before saying there's no hope

So if it's not a supported provider you probably create trunk sip manually, is it possible you give some details on how you've done and perhaps a screen copy with sensitive info hidden.

if you call from internally extension to Q number and put the call on hold like you do with external callers does it behave same way or is it working fine?

 

[jpercival]

Before I was aware that the issue seemed to kick in around 3 minutes I tested it a few times yesterday from my 3CX extension from a Grandstream phone yesterday and it worked fine. It also worked from my cell phone (using Sprint cellular, not the 3CX app) and it worked fine as well.

Just started testing today with longer hold time with my personal cell phone calling in to the queue.

CALL 1: I spoke to the user in the queue for a few seconds and then she placed me on hold. After roughly 2 minutes the hold music stopped and the line went completely silent. From my admin console I saw my active call and transferred it to another admin sitting next to me and the call resumed just fine. We could hear each other.

CALL 2: I spoke to the user in the queue for a few seconds and then she placed me on hold. After a few SECONDS the hold music stopped and the line went silent on my end. The call was still active. I Skyped the user to pick the call up. She could hear me but I could not hear her. I transferred the call to the same admin and he could hear ME but I could not hear HIM.

The problem has definitely been verified, but it's intermittent and behaving differently when it does occur.

 

[leejor]

How are you putting the call on hold? A Hold button on the set?
Have you looked at the 3CX Activity Log to see if there is something, at the point the call dropped, or, there was an attempt to retrieve? Maybe a re-Invite issue?

 

[jpercival]

I made another test call that eventually ended up with the audio disappear on the cell side, but the employee could hear the caller.

Here is a general synopsis if the call followed by what I think is the pertinent part of the log.




1:45:13pm 3cx time
Call started
Hold started 46 seconds in to call
Music stopped EXACTLY 2 minutes into the call this time.
User picked up, we could hear eachother, placed on hold again (same call)
Next hold started 2:40 into the call.
Music stopped 3:50 into the call
User picked up. Could hear caller, caller could not hear user.
Hung up.




Incoming phone number 1xxxxxx5405




07/02/2020 1:50:34 PM - Leg L:3428.1[Line:10001<<1xxxxxx5405] is terminated: Cause: BYE from local
07/02/2020 1:47:51 PM - Leg L:3429.1[Line:10000<<+1xxxxxxx719] is terminated: Cause: BYE from 18.214.109.141:5060 (no idea what this is???) note by jpercival
07/02/2020 1:45:32 PM - L:3428.3[Queue:851] has joined to L:3428.1[Line:10001<<1xxxxxx5405]
07/02/2020 1:45:32 PM - [CM503025]: Call(C:3428): Calling T:Queue:851@[Dev:sip:[email protected]:5483;rinstance=2b1c6feb51d7dd5c] for L:3428.1[Line:10001<<1xxxxxx5405]
07/02/2020 1:45:32 PM - [CM503027]: Call(C:3428): From: Line:10001<<1xxxxxx5405 ("1xxxxxx5405" <sip:[email protected]:5060>) to T:Queue:851@[Dev:sip:[email protected]:5483;rinstance=2b1c6feb51d7dd5c]
07/02/2020 1:45:32 PM - [CM503004]: Call(C:3428): Route 1: from L:3428.1[Line:10001<<1xxxxxx5405] to T:Queue:851@[Dev:sip:[email protected]:5483;rinstance=2b1c6feb51d7dd5c]
07/02/2020 1:45:32 PM - [Flow] Call(C:3428): has built target endpoint: Queue:851 for call from L:3428.1[Line:10001<<1xxxxxx5405]
07/02/2020 1:45:32 PM - [CM503010]: Call(C:3428): Making route(s) from Line:10001<<1xxxxxx5405 to <sip:[email protected]:5060/UDP>
07/02/2020 1:45:32 PM - [Flow] Refer: RefTo=<sip:[email protected]:5060>; was call from=<sip:[email protected]:0> to="1xxxxxx5405" <sip:[email protected]:5060>
07/02/2020 1:45:13 PM - [CM503007]: Call(C:3428): Line:10001<<1xxxxxx5405 has joined, contact <sip:[email protected]:0/UDP>
07/02/2020 1:45:13 PM - L:3428.2[Ivr:299] has joined to L:3428.1[Line:10001<<1xxxxxx5405]
07/02/2020 1:45:13 PM - [CM503025]: Call(C:3428): Calling T:Ivr:299@[Dev:sip:[email protected]:5483;rinstance=a2201516ad63cff1] for L:3428.1[Line:10001<<1xxxxxx5405]
07/02/2020 1:45:13 PM - [CM503027]: Call(C:3428): From: Line:10001<<1xxxxxx5405 ("1xxxxxx5405" <sip:[email protected]:5060>) to T:Ivr:299@[Dev:sip:[email protected]:5483;rinstance=a2201516ad63cff1]
07/02/2020 1:45:13 PM - [CM503004]: Call(C:3428): Route 1: from L:3428.1[Line:10001<<1xxxxxx5405] to T:Ivr:299@[Dev:sip:[email protected]:5483;rinstance=a2201516ad63cff1]
07/02/2020 1:45:13 PM - [Flow] Call(C:3428): has built target endpoint: Ivr:299 for call from L:3428.1[Line:10001<<1xxxxxx5405]
07/02/2020 1:45:13 PM - [CM503010]: Call(C:3428): Making route(s) from Line:10001<<1xxxxxx5405 to <sip:[email protected]:5060/UDP>
07/02/2020 1:45:13 PM - [CM500002]: Call(C:3428): Info on incoming INVITE from Line:10001<<1xxxxxx5405:
Invite-IN Recv Req INVITE from 199.180.220.89:5060 tid=0c57773e17881d55 [email protected]:
INVITE sip:[email protected].219:5060;rinstance=fb03d87b2b5f1210;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 199.180.220.89:5060;branch=z9hG4bK-524287-1-NDE4MDM4ZTZiNGEyY2FhN2ExZDUwMGIzN2JkYWEwNjM.--0c57773e17881d55;rport=5060
Via: SIP/2.0/UDP 199.180.220.89:5061;branch=z9hG4bK-hwtwl3tlmqk5sw7r;rport=5061
Max-Forwards: 69
Record-Route: <sip:199.180.220.89:5060;lr;transport=UDP>
Contact: <sip:199.180.220.89:5061>
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=5ir6roxfl25hjv46.o
Call-ID: [email protected]
CSeq: 632 INVITE
Expires: 300
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling
h323-conf-id: 2285765574-2607974269-3178449465-3178449465
cisco-GUID: 2285765574-2607974269-3178449465-3178449465
Content-Length: 311

v=0
o=Sippy 1866156099348254171 1 IN IP4 199.180.220.89
s=Session Controller
t=0 0
m=audio 56238 RTP/AVP 0 8 18 101
c=IN IP4 45.33.70.196
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20
07/02/2020 1:45:13 PM - [CM503001]: Call(C:3428): Incoming call from Line:10001<<1xxxxxx5405 to <sip:[email protected]:5060>
07/02/2020 1:45:13 PM - [Flow] Looking for inbound target: called=1xxxxxxx500; caller="1xxxxxx5405" <sip:1xxxxxx5405@:0>

 

[jpercival]

Here is another one tested right after it. Same basic results. Called a different user in the same queue, same brand and firmware of Fanvil X4



Hold started 2:43 into call after a brief chat with the user.
Music stopped 4:08 into call
User picked up, could hear caller, caller could not hear user
Ended call






07/02/2020 2:25:22 PM - Leg L:3508.1[Line:10001<<1xxxxxx5405] is terminated: Cause: BYE from local
07/02/2020 2:20:51 PM - L:3508.3[Queue:851] has joined to L:3508.1[Line:10001<<1xxxxxx5405]
07/02/2020 2:20:51 PM - [CM503025]: Call(C:3508): Calling T:Queue:851@[Dev:sip:[email protected]:5483;rinstance=2b1c6feb51d7dd5c] for L:3508.1[Line:10001<<1xxxxxx5405]
07/02/2020 2:20:51 PM - [CM503027]: Call(C:3508): From: Line:10001<<1xxxxxx5405 ("1xxxxxx5405" <sip:[email protected]:5060>) to T:Queue:851@[Dev:sip:[email protected]:5483;rinstance=2b1c6feb51d7dd5c]
07/02/2020 2:20:51 PM - [CM503004]: Call(C:3508): Route 1: from L:3508.1[Line:10001<<1xxxxxx5405] to T:Queue:851@[Dev:sip:[email protected]:5483;rinstance=2b1c6feb51d7dd5c]
07/02/2020 2:20:51 PM - [Flow] Call(C:3508): has built target endpoint: Queue:851 for call from L:3508.1[Line:10001<<1xxxxxx5405]
07/02/2020 2:20:51 PM - [CM503010]: Call(C:3508): Making route(s) from Line:10001<<1xxxxxx5405 to <sip:[email protected]:5060/UDP>
07/02/2020 2:20:51 PM - [Flow] Refer: RefTo=<sip:[email protected]:5060>; was call from=<sip:[email protected]:0> to="1xxxxxx5405" <sip:[email protected]:5060>
07/02/2020 2:20:29 PM - [CM503007]: Call(C:3508): Line:10001<<1xxxxxx5405 has joined, contact <sip:[email protected]:0/UDP>
07/02/2020 2:20:29 PM - L:3508.2[Ivr:299] has joined to L:3508.1[Line:10001<<1xxxxxx5405]
07/02/2020 2:20:29 PM - [CM503025]: Call(C:3508): Calling T:Ivr:299@[Dev:sip:[email protected]:5483;rinstance=a2201516ad63cff1] for L:3508.1[Line:10001<<1xxxxxx5405]
07/02/2020 2:20:29 PM - [CM503027]: Call(C:3508): From: Line:10001<<1xxxxxx5405 ("1xxxxxx5405" <sip:[email protected]:5060>) to T:Ivr:299@[Dev:sip:[email protected]:5483;rinstance=a2201516ad63cff1]
07/02/2020 2:20:29 PM - [CM503004]: Call(C:3508): Route 1: from L:3508.1[Line:10001<<1xxxxxx5405] to T:Ivr:299@[Dev:sip:[email protected]:5483;rinstance=a2201516ad63cff1]
07/02/2020 2:20:29 PM - [Flow] Call(C:3508): has built target endpoint: Ivr:299 for call from L:3508.1[Line:10001<<1xxxxxx5405]
07/02/2020 2:20:29 PM - [CM503010]: Call(C:3508): Making route(s) from Line:10001<<1xxxxxx5405 to <sip:[email protected]:5060/UDP>
07/02/2020 2:20:29 PM - [CM500002]: Call(C:3508): Info on incoming INVITE from Line:10001<<1xxxxxx5405:
Invite-IN Recv Req INVITE from 199.180.220.89:5060 tid=ba17f825f4df5702 [email protected]:
INVITE sip:[email protected].219:5060;rinstance=fb03d87b2b5f1210;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 199.180.220.89:5060;branch=z9hG4bK-524287-1-ZTJkYWQzNzc2ZTRhNjQxMGI4NjE4ODU5NWIxYzkxZDc.--ba17f825f4df5702;rport=5060
Via: SIP/2.0/UDP 199.180.220.89:5061;branch=z9hG4bK-3md6mtym6lu4cbwh;rport=5061
Max-Forwards: 69
Record-Route: <sip:199.180.220.89:5060;lr;transport=UDP>
Contact: <sip:199.180.220.89:5061>
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=x6fs5sckjbhobzca.o
Call-ID: [email protected]
CSeq: 780 INVITE
Expires: 300
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling
h323-conf-id: 383078347-1946185489-2292020200-2292020200
cisco-GUID: 383078347-1946185489-2292020200-2292020200
Content-Length: 311

v=0
o=Sippy 2451771176060839141 1 IN IP4 199.180.220.89
s=Session Controller
t=0 0
m=audio 50020 RTP/AVP 0 8 18 101
c=IN IP4 45.33.70.196
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20
07/02/2020 2:20:29 PM - [CM503001]: Call(C:3508): Incoming call from Line:10001<<1xxxxxx5405 to <sip:[email protected]:5060>
07/02/2020 2:20:29 PM - [Flow] Looking for inbound target: called=14023310500; caller="1xxxxxx5405" <sip:1xxxxxx5405@:0>

 

[jpercival]

We have zero complaints of random call drops from other users on calls of any length. It only seems to be happening when a user is placed on hold. It also only seems to be happening on incoming calls only. We do use different SIPs for incoming and outgoing calls for pricing concerns. This is likely starting to look more and more related to our incoming SIP provider, but I can't tell.

Using the same SIP I have called my deskphone 3 times in a row from my personal cell and put myself on hold for 5+ minutes with no issue. I'm perplexed.

 

[AWS2P]

this is why i wanted you to do call test from internal extension and do the same MOH and see if you get same behavior or not, if NOT what I Guess, that mean problem is on SIP trunk side

 

[jpercival]

We cannot reproduce the issue from an internal call.

 

[JohnS_3CX]

In your trunk's settings, under Options, did you enable re-invites?
If so remove re-invites and try again.

 

[jpercival]

That setting was not enabled.

 

[JohnS_3CX]

Since you cannot reproduce it with internal calls, would you mind running the firewall checker one more time please?

 

[jpercival]

Just re-ran it and it and there were no errors.

 

[JohnS_3CX]

Since this is uni-tel, I would recommend that you take a backup first, and then delete your trunk and recreate it.


Let's make sure that the trunk is properly set up before we look into deeper details.

Alternatively, you may open a new chrome window with your management console, create a new unitel trunk with a fake number, and compare ALL the settings one by one on all the trunk tabs to ensure that it matches 1:1 with our own template.

 

[jpercival]

My apologies for the delay. We simply switched back to Flowroute. It's more expensive, but our testing indicated that the quality was higher and these issues did not occur. It's more expensive, but it works flawlessly. Thanks, everyone!

 

[JohnS_3CX]

No problem, glad to hear that you are at least happy with your current service.

 

[jpercival]

Aside from the price, one of the nice things about Unitel was that they actually had a viable ticketing system and email-based support. That being said, they looked at our service, firewall, and detailed 3CX settings for a few days and basically said, "There, we fixed it" two separate times and the issues never went away.

At some point in a production environment you can't keep guessing and have to go with what works.