Leaving Voicemail Disconnects at Beep - Bridged 3CX Environment

[aberry]

Does anyone have any reason why this might happen? I have two 3CX servers bridged in a master / slave configuration.

If I call an extension across the bridge, and the extension doesn't answer it will play the voicemail greeting. But as soon as the tone plays that would indicate I can start recording a message the call disconnects. No errors, no events. Do I have a setting missing somewhere?

 

[leejor]

I've heard of "tone issues" involving gateways, but not causing a SIP trunk to drop. Could it be a coincidence that the call drops at the same time the tone is heard? There must be something in the 3CX activity log as to which end, ended the call, which may provide a clue as to what is happening. I assume that all other calls, not to voicemail, remain up?

 

[NickD_3CX]

Check in the Bridge settings of both sides that Re-INVITE and Replaces is off. Also I would recommend making sure PBX Delivers Audio is on. These settings are in the "Advanced" tab.

 

[aberry]

That is correct, calls between devices at each site work just fine.

Re-invite and replaces were already off. I have turned on PBX Delivers audio, but that dodn't make any difference. I do have the bridge setup to use the tunnel connection on port 5090. I can't see any other settings, but I will keep messing with settings and see what I can figure out.

Also here is info from SIP log:

10/06/2017 8:34:39 AM - Call to T:Extn:299@[Dev:sip:[email protected]:36462;line=leinmx36] from L:23.1[Line:10002<<+*73983] failed, cause: Cause: 486 Busy Here/INVITE from 192.168.200.110:36462
10/06/2017 8:34:39 AM - [CM503003]: Call(C:23): Call to "Anthony Berry" <sip:[email protected]:5060> has failed; Cause: 486 Busy Here/INVITE from 192.168.200.110:36462

 

[leejor]

As you are using two 3CX servers, you have access to logs at both ends. There should be logs showing the extension as busy, but the call being passed to the voicemail. After that, which end drops the call?

 

[aberry]

From what I can see in the logs, the receiving end forwards to voicemail. It makes sense that at that point I would begin hearing the VM greeting. About 7 seconds later on the calling end I get a BYE from local - so it seems that the call is being terminated on the sending end right after the message completes and tone plays.

I have also tried changing from a tunnel connection to standard and no change.


Log from server where call originated:

10/06/2017 9:07:43 AM - Leg L:4968.1[Extn:3983] is terminated: Cause: BYE from local
10/06/2017 9:07:43 AM - [CM503008]: Call(C:4968): Call is terminated
10/06/2017 9:07:43 AM - Leg L:4968.2[Line:10002>>299] is terminated: Cause: BYE from 127.0.0.1:5080


10/06/2017 9:07:43 AM - Leg L:4968.1[Extn:3983] is terminated: Cause: BYE from local
10/06/2017 9:07:35 AM - [CM503007]: Call(C:4968): Extn:3983 has joined, contact <sip:[email protected]:5060>
10/06/2017 9:07:35 AM - L:4968.2[Line:10002>>299] has joined to L:4968.1[Extn:3983]
10/06/2017 9:07:25 AM - [CM503025]: Call(C:4968): Calling T:Line:10002>>299@[Dev:sip:[email protected]:5060;rinstance=d89aabbcca0e4d36] for L:4968.1[Extn:3983]
10/06/2017 9:07:25 AM - [CM503027]: Call(C:4968): From: Extn:3983 (<sip:[email protected]:5060>) to T:Line:10002>>299@[Dev:sip:[email protected]:5060;rinstance=d89aabbcca0e4d36]
10/06/2017 9:07:25 AM - [CM503004]: Call(C:4968): Route 1: from L:4968.1[Extn:3983] to T:Line:10002>>299@[Dev:sip:[email protected]:5060;rinstance=d89aabbcca0e4d36]
10/06/2017 9:07:25 AM - Call(C:4968): Call from Extn:3983 to *7299 matches outbound rule '3CX Bridge'
10/06/2017 9:07:25 AM - [Flow] Call(C:4968): has built target endpoint: Out#:>>Rule{3CX Bridge}>>*7299 for call from L:4968.1[Extn:3983]
10/06/2017 9:07:25 AM - [CM503010]: Call(C:4968): Making route(s) from Extn:3983 to <sip:*[email protected]:5060>
10/06/2017 9:07:25 AM - [CM505001]: Endpoint Extn:3983: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [UniFi VoIP Phone 5.0.14.660] PBX contact: [sip:[email protected]:5060]
10/06/2017 9:07:25 AM - [CM503001]: Call(C:4968): Incoming call from Extn:3983 to <sip:*[email protected]:5060>


Log from server receiving call:

10/06/2017 9:07:35 AM - Leg L:32.2[Extn:299] is terminated: Cause: 486 Busy Here/INVITE from 192.168.200.110:36462
10/06/2017 9:07:35 AM - L:32.1[Line:10002<<+*73983] forwards call from Extn:299 to VMail:999 based on rule Fwd[Available/Busy]
10/06/2017 9:07:35 AM - L:32.1[Line:10002<<+*73983] failed to reach Extn:299, reason Busy
10/06/2017 9:07:35 AM - Call to T:Extn:299@[Dev:sip:[email protected]:36462;line=leinmx36] from L:32.1[Line:10002<<+*73983] failed, cause: Cause: 486 Busy Here/INVITE from 192.168.200.110:36462
10/06/2017 9:07:26 AM - [CM505001]: Endpoint Extn:299: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom715/8.9.3.66] PBX contact: [sip:[email protected]:5060]
10/06/2017 9:07:26 AM - [CM503002]: Call(C:32): Alerting Extn:299 by contact <sip:[email protected]:36462>
10/06/2017 9:07:26 AM - [CM503025]: Call(C:32): Calling T:Extn:299@[Dev:sip:[email protected]:36462;line=leinmx36] for L:32.1[Line:10002<<+*73983]
10/06/2017 9:07:26 AM - [CM503027]: Call(C:32): From: Line:10002<<+*73983 ("TJ Berry" <sip:*[email protected]:5060>) to T:Extn:299@[Dev:sip:[email protected]:36462;line=leinmx36]
10/06/2017 9:07:26 AM - [CM503004]: Call(C:32): Route 1: from L:32.1[Line:10002<<+*73983] to T:Extn:299@[Dev:sip:[email protected]:36462;line=leinmx36]
10/06/2017 9:07:26 AM - [Flow] Call(C:32): has built target endpoint: Extn:299 for call from L:32.1[Line:10002<<+*73983]
10/06/2017 9:07:26 AM - [Flow] Target endpoint for 299 is Extn:299

 

[leejor]

What type of originating sets are you using, are they all the same? Is the behaviour different if you were to use an Android device, or 3CX softphone on Windows? Does the disconnect happen on calls in the other direction?

Never heard back on a similar issue....
https://www.3cx.com/community/threads/voicemail-hangs-up-after-greeting.48505/

 

[NickD_3CX]

The logs aren't enough to determine the hang up reason. On the originating side you see 127.0.0.1:5080, not 5090, so this is the decoding of the Tunnel traffic that happens locally, so this actually probably implies that the BYE came from the receiving side.

Now on the receiving side,, the logs only show up until the point where the call goes to VMail, they do not include the point in time where the call to VMail ends.

One more question, on the receiving side I see the number "+*73983". Where it the *7 coming from? Are you dialing it like that on originating side?