Leaving Voicemail Disconnects at Beep - Bridged 3CX Environment

Discussion in '3CX Phone System - General' started by aberry, Oct 6, 2017.

Thread Status:
Not open for further replies.
  1. aberry

    aberry New Member

    Joined:
    Jan 13, 2015
    Messages:
    118
    Likes Received:
    7
    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?
     
  2. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,567
    Likes Received:
    246
    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?
     
  3. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    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.
     
  4. aberry

    aberry New Member

    Joined:
    Jan 13, 2015
    Messages:
    118
    Likes Received:
    7
    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:299@192.168.200.110: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:299@192.168.205.15:5060> has failed; Cause: 486 Busy Here/INVITE from 192.168.200.110:36462
     
  5. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,567
    Likes Received:
    246
    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?
     
  6. aberry

    aberry New Member

    Joined:
    Jan 13, 2015
    Messages:
    118
    Likes Received:
    7
    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:3983@172.26.1.182: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:10002@127.0.0.1:5060;rinstance=d89aabbcca0e4d36] for L:4968.1[Extn:3983]
    10/06/2017 9:07:25 AM - [CM503027]: Call(C:4968): From: Extn:3983 (<sip:3983@3cx.s.us:5060>) to T:Line:10002>>299@[Dev:sip:10002@127.0.0.1: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:10002@127.0.0.1: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:*7299@3cx.s.us: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:3983@172.26.102.20:5060]
    10/06/2017 9:07:25 AM - [CM503001]: Call(C:4968): Incoming call from Extn:3983 to <sip:*7299@3cx.s.us: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:299@192.168.200.110: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:299@192.168.205.15:5060]
    10/06/2017 9:07:26 AM - [CM503002]: Call(C:32): Alerting Extn:299 by contact <sip:299@192.168.200.110:36462>
    10/06/2017 9:07:26 AM - [CM503025]: Call(C:32): Calling T:Extn:299@[Dev:sip:299@192.168.200.110: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:*73983@iei-3cx.s.us:5060>) to T:Extn:299@[Dev:sip:299@192.168.200.110: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:299@192.168.200.110: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
     
  7. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,567
    Likes Received:
    246
    #7 leejor, Oct 6, 2017
    Last edited: Oct 6, 2017
  8. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    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?
     
Thread Status:
Not open for further replies.