Outgoing call receiving "not acceptable" response

Discussion in '3CX Phone System - General' started by clweb, Mar 24, 2016.

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

    Joined:
    Mar 24, 2016
    Messages:
    7
    Likes Received:
    0
    Hello,

    I am having an issue where I am unable to call out to a specific number. I was testing an outbound rule to block outgoing international calls, and created an outbound rule blocking my cell phone number to test the settings. The settings worked - when I called my cell phone number I received a "Not acceptable" response. However, when I deleted the rule - it seemed to keep the settings and now I am unable to call my cell phone number. Any ideas of how to fix this? All other outgoing calls work fine, so I know it's not a problem with my existing outbound rules. Thanks so much for your ideas.

    Code:
    24-Mar-2016 09:37:07.397	Leg L:284.1[Extn] is terminated: Cause: BYE from PBX
    24-Mar-2016 09:37:07.346	Leg L:284.2[Line:10001>>1xxxxxxxxxx] is terminated: Cause: 406 Not Acceptable/INVITE from 192.168.111.21:5060
    24-Mar-2016 09:37:07.345	[CM503020]: Call(C:284): Normal call termination. Call originator: Extn:353. Reason: Terminated
    24-Mar-2016 09:37:07.345	L:284.1[Extn] failed to reach Line:10001>>1xxxxxxxxxx, reason Not Acceptable HereReason Unknown
    24-Mar-2016 09:37:07.345	Call to T:Line:10001>>1xxxxxxxxxx@[Dev:sip:10001@192.168.111.21:5060] from L:284.1[Extn] failed, cause: Cause: 406 Not Acceptable/INVITE from 192.168.111.21:5060
    24-Mar-2016 09:37:07.344	[CM503003]: Call(C:284): Call to <sip:1xxxxxxxxxx@192.168.111.21:5060> has failed; Cause: 406 Not Acceptable/INVITE from 192.168.111.21:5060
    24-Mar-2016 09:37:06.923	[CM503025]: Call(C:284): Calling T:Line:10001>>1xxxxxxxxxx@[Dev:sip:10001@192.168.111.21:5060] for L:284.1[Extn]
    24-Mar-2016 09:37:06.875	[CM503027]: Call(C:284): From: Extn:353 ("John" <sip:353@192.168.111.20:5060>)  to  T:Line:10001>>1xxxxxxxxxx@[Dev:sip:10001@192.168.111.21:5060]
    24-Mar-2016 09:37:06.875	[CM503004]: Call(C:284): Route 1: from L:284.1[Extn] to T:Line:10001>>1xxxxxxxxxx@[Dev:sip:10001@192.168.111.21:5060]
    24-Mar-2016 09:37:06.875	Line limit check: Current # of calls for line Lc:10001(@PRI[<sip:10001@192.168.111.21:5060>]) is 0; limit is 23
    24-Mar-2016 09:37:06.875	Call(C:284): Call from Extn:353 to 91xxxxxxxxxx matches outbound rule 'Rule for PRI LD 11'
    24-Mar-2016 09:37:06.873	[CM503001]: Call(C:284): Incoming call from Extn:353 to <sip:91xxxxxxxxxx@192.168.111.20:5060>
     
  2. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,737
    Likes Received:
    278
    Compare the digits sent for a working call, with those sent for a non-working call. There has to be a difference to cause it to fail (length/prefix?). Why are they different, what, in your outbound rules changes that?

    Could it be the order of the rules? They are "matched" top to bottom. First match will be used.
     
  3. clweb

    Joined:
    Mar 24, 2016
    Messages:
    7
    Likes Received:
    0
    Nothing has changed with the outbound rules, other than me creating and then deleting a rule that blocked the number. It seems as if somehow the outbound rule that I deleted did not get removed completely and is lingering somewhere on the system. The only way I can get around it is to create a new outbound rule (using the settings in the attached picture) and move it to the top of the list. It's just a fix, and I'd like to figure out the root cause, but it may have to wait till we upgrade our system (we are still on version 11) to see if the upgrade fixes the problem.

    (I also found that the system is blocking all calls starting with 269-767, not just my cell number.)
     

    Attached Files:

  4. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,737
    Likes Received:
    278
    Are you required to send the leading "1", on those calls. The rule you posted removes both the 9 and the 1.
    Then, if your provider refuses it, it would be blocked as per the second route.
     
  5. clweb

    Joined:
    Mar 24, 2016
    Messages:
    7
    Likes Received:
    0
    The rule that I posted is the only one that lets me call out to my cell number using a 12 digit number. (9 1-269-767-xxxx)

    Yes, the leading 1 needs to be sent, and the other rules I have configured take care of that.

    Like I've said before - I have no problem calling out with any other number and the outbound rules I have in place have been working fine for years. I am wondering if there is somewhere else (besides the outbound rules configuration) where I might be able to find where this issue is stemming from.
     
  6. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,737
    Likes Received:
    278
    Not sure I'm clear...

    You say
    Yet the rule you posted will strip both the 9 and the 1 sending only 10 digits to the gateway.
    If your provider wants the leading 1, then there may be a rejection "condition" (from your provider) that the gateway is passing back to 3CX. The " Not Acceptable HereReason "

    So, the "other" rules work, but this one does not, could that be the reason?

    You haven't posted the other rules, so I can't compare.
     
  7. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,327
    Likes Received:
    73
    What is on IP 192.168.111.21?

    Code:
    24-Mar-2016 09:37:07.346   Leg L:284.2[Line:10001>>1xxxxxxxxxx] is terminated: Cause: 406 Not Acceptable/INVITE from 192.168.111.21:5060
    
    Whatever it is, that is what seems to be sending the "406 Not Acceptable" message. If it is some sort of Gateway, then that is what is rejecting the call attempt.
     
    clweb likes this.
  8. clweb

    Joined:
    Mar 24, 2016
    Messages:
    7
    Likes Received:
    0
    I hate to have to revive this thread, but I still have been unable to resolve this problem. I hoped that updating the system to V15 would resolve the issue, but unfortunately it did not.

    To recap - everything was working fine until I needed to create a rule to temporarily block outgoing calls with a certain prefix. (1269767) I created the rule and it worked (The rule was simply to block any outgoing calls starting with the prefix 1269767). However, after I deleted the rule, I still was unable to make outgoing calls to that prefix. I've included the results from the activity log detailing an attempt to call a number with that prefix.

    Any help would be greatly appreciated as I am stumped on how to resolve this issue.

    Thanks!

    Code:
    05/16/2017 4:53:04 PM - Stop call record for leg L:722.1[Extn:353]
    05/16/2017 4:53:04 PM - Removing leg L:722.1[Extn:353]
    05/16/2017 4:53:04 PM - L:722.1[Extn:353]: Terminating targets, reason:
    05/16/2017 4:53:04 PM - Leg L:722.1[Extn:353] is terminated: Cause: BYE from PBX
    05/16/2017 4:53:04 PM - Call(C:722), Extn:353 on exit: DlgInfo(722-3376/Terminated / I)
    05/16/2017 4:53:04 PM - Call(C:722), Extn:353 on entry: DlgInfo(722-3376/Terminated / I)
    05/16/2017 4:53:04 PM - Notify dialog-info: Extn:353: sip:353@192.168.111.167:5060, Call(C:722)
    05/16/2017 4:53:04 PM - L:722.1[Extn:353] Sending: OnSendResp Send 480/INVITE from 0.0.0.0:0 tid=-32439dee Call-ID=b31fbec2-932eb0d6@192.168.111.167: SIP/2.0 480 Temporarily Unavailable Via: SIP/2.0/UDP 192.168.111.167:5060;branch=z9hG4bK-32439dee To: <sip:1269767xxxx@192.168.111.20>;tag=ca1fb505 From: "John"<sip:353@192.168.111.20>;tag=18445d2aff55506o0 Call-ID: b31fbec2-932eb0d6@192.168.111.167 CSeq: 102 INVITE Warning: 499 3CXSERVER.clnf.local "Terminated" Content-Length: 0
    05/16/2017 4:53:04 PM - Call(C:722), Extn:353 on exit: DlgInfo(722-3376/Terminated / I)
    05/16/2017 4:53:04 PM - Call(C:722), Extn:353 on entry: DlgInfo(722-3376/Early / I)
    05/16/2017 4:53:04 PM - Notify dialog-info: Extn:353: sip:353@192.168.111.167:5060, Call(C:722)
    05/16/2017 4:53:04 PM - [CM503020]: Call(C:722): Normal call termination. Call originator: Extn:353. Reason: Terminated
    05/16/2017 4:53:04 PM - [CM503016]: Call(C:722): Attempt to reach <sip:1269767xxxx@192.168.111.20:5060> from Extn:353 has failed. Reason: Not Acceptable HereReason Unknown
    05/16/2017 4:53:04 PM - L:722.1[Extn:353] failed to reach Line:10001>>1269767xxxx, reason Not Acceptable HereReason Unknown
    05/16/2017 4:53:04 PM - Call to T:Line:10001>>1269767xxxx@[Dev:sip:10001@192.168.111.21:5060] from L:722.1[Extn:353] failed, cause: Cause: 406 Not Acceptable/INVITE from 192.168.111.21:5060
    05/16/2017 4:53:03 PM - L:722.1[Extn:353] Sending: OnSendResp Send 180/INVITE from 0.0.0.0:0 tid=-32439dee Call-ID=b31fbec2-932eb0d6@192.168.111.167: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.111.167:5060;branch=z9hG4bK-32439dee Contact: <sip:1269767xxxx@192.168.111.20:5060> To: <sip:1269767xxxx@192.168.111.20>;tag=ca1fb505 From: "John"<sip:353@192.168.111.20>;tag=18445d2aff55506o0 Call-ID: b31fbec2-932eb0d6@192.168.111.167 CSeq: 102 INVITE Content-Length: 0
    05/16/2017 4:53:03 PM - Call(C:722), Extn:353 on exit: DlgInfo(722-3376/Early / I)
    05/16/2017 4:53:03 PM - Call(C:722), Extn:353 on entry: DlgInfo(722-3376/Initial / I)
    05/16/2017 4:53:03 PM - Notify dialog-info: Extn:353: sip:353@192.168.111.167:5060, Call(C:722)
    05/16/2017 4:53:03 PM - [CM503025]: Call(C:722): Calling T:Line:10001>>1269767xxxx@[Dev:sip:10001@192.168.111.21:5060] for L:722.1[Extn:353]
    05/16/2017 4:53:03 PM - [Flow] Call(C:722): making call from L:722.1[Extn:353] to T:Line:10001>>1269767xxxx@[Dev:sip:10001@192.168.111.21:5060]
    05/16/2017 4:53:03 PM - [CM503027]: Call(C:722): From: Extn:353 ("John" <sip:353@192.168.111.20:5060>) to T:Line:10001>>1269767xxxx@[Dev:sip:10001@192.168.111.21:5060]
    05/16/2017 4:53:03 PM - [CM503004]: Call(C:722): Route 1: from L:722.1[Extn:353] to T:Line:10001>>1269767xxxx@[Dev:sip:10001@192.168.111.21:5060]
    05/16/2017 4:53:03 PM - Call(C:722): Call from Extn:353 to 1269767xxxx matches outbound rule 'PRI 11 Digits'
    05/16/2017 4:53:03 PM - [Flow] Call(C:722): has built target endpoint: Out#:>>Rule{PRI 11 Digits}>>1269767xxxx for call from L:722.1[Extn:353]
    05/16/2017 4:53:03 PM - [CM503010]: Call(C:722): Making route(s) from Extn:353 to <sip:1269767xxxx@192.168.111.20:5060>
    05/16/2017 4:53:03 PM - Remote SDP is set for leg L:722.1[Extn:353]
    05/16/2017 4:53:03 PM - [CM505001]: Endpoint Extn:353: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Cisco/SPA508G-7.4.9c] PBX contact: [sip:353@192.168.111.20:5060]
    05/16/2017 4:53:03 PM - [CM500002]: Call(C:722): Info on incoming INVITE from Extn:353: Invite-IN Recv Req INVITE from 192.168.111.167:5060 tid=-32439dee Call-ID=b31fbec2-932eb0d6@192.168.111.167: INVITE sip:1269767xxxx@192.168.111.20:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.111.167:5060;branch=z9hG4bK-32439dee Max-Forwards: 70 Contact: "John" <sip:353@192.168.111.167:5060> To: <sip:1269767xxxx@192.168.111.20> From: "John"<sip:353@192.168.111.20>;tag=18445d2aff55506o0 Call-ID: b31fbec2-932eb0d6@192.168.111.167 CSeq: 102 INVITE Expires: 240 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE Content-Type: application/sdp Proxy-Authorization: Digest username="353",realm="3CXPhoneSystem",nonce="414d535c0f2bf7af74:434cfc3491dd62f701ab0376e4072eff",uri="sip:1269767xxxx@192.168.111.20:5060",algorithm=MD5,response="d9e3051f3a6dd961cdf8f4e1dcea0d89" Supported: replaces User-Agent: Cisco/SPA508G-7.4.9c Content-Length: 407 v=0 o=- 225246769 225246769 IN IP4 192.168.111.167 s=- c=IN IP4 192.168.111.167 t=0 0 m=audio 16404 RTP/AVP 0 8 9 2 18 96 97 98 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
    05/16/2017 4:53:03 PM - [CM503001]: Call(C:722): Incoming call from Extn:353 to <sip:1269767xxxx@192.168.111.20:5060>
    05/16/2017 4:53:03 PM - Leg L:722.1[Extn:353] has external party ID {}
     
  9. YiannisH_3CX

    YiannisH_3CX Support Team
    Staff Member 3CX Support

    Joined:
    May 10, 2016
    Messages:
    6,016
    Likes Received:
    420
    From the attached logs i can see that the call matches the outbound rule "PRI 11 Digits". Is that the outbound it should match?
    What is on IP 192.168.111.21?
    If you run a wireshark capture on the server at the time of the call do you see the call leaving the PBX?
     
    clweb likes this.
  10. clweb

    Joined:
    Mar 24, 2016
    Messages:
    7
    Likes Received:
    0
    Yes, that is the correct outbound rule and the same rule works for all our other 11 digit phone numbers.

    The 192.168.111.21 is our PRI Gateway (Patton SN4960). I'm not very familiar with filtering through the results of a wireshark capture, but I've attached what seems to be the point where it leaves the PBX. It almost looks like the PRI Gateway is rejecting the call, but have no idea why that might be the case.


    Code:
    INVITE sip:1269767xxxx@192.168.111.21:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.111.20:5060;branch=z9hG4bK-524287-1---3864f869e5154557;rport
    Max-Forwards: 70
    Contact: <sip:10001@192.168.111.20:5060>
    To: <sip:1269767xxxx@192.168.111.21:5060>
    From: "John"<sip:269xxxxxxx@192.168.111.20:5060>;tag=490be25f
    Call-ID: MzF597P3aEBke-VCYTTdXQ..
    CSeq: 1 INVITE
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces
    User-Agent: 3CXPhoneSystem 15.0.62928.5 (62293)
    Content-Length: 431
    
    v=0
    o=3cxPS 162957099008 339906396161 IN IP4 192.168.111.20
    s=3cxPS Audio call
    c=IN IP4 192.168.111.167
    t=0 0
    m=audio 16424 RTP/AVP 0 8 9 2 18 96 97 98 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:9 G722/8000
    a=rtpmap:2 G726-32/8000
    a=rtpmap:18 G729a/8000
    a=rtpmap:96 G726-40/8000
    a=rtpmap:97 G726-24/8000
    a=rtpmap:98 G726-16/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=ptime:20
    a=sendrecv
    SIP/2.0 183 Session Progress
    Via: SIP/2.0/UDP 192.168.111.20:5060;branch=z9hG4bK-524287-1---3864f869e5154557;rport=5060;received=192.168.111.20
    From: "John"<sip:269xxxxxxx@192.168.111.20:5060>;tag=490be25f
    To: <sip:1269767xxxx@192.168.111.21:5060>;tag=552446499
    Call-ID: MzF597P3aEBke-VCYTTdXQ..
    CSeq: 1 INVITE
    Contact: <sip:1269767xxxx@192.168.111.21:5060;transport=udp>
    Server: Patton SN4960 1E30V 00A0BA061475 R6.8 2015-11-13 H323 RBS SIP M5T SIP Stack/4.2.8.10
    Content-Length: 0
    
    SIP/2.0 406 Not Acceptable
    Via: SIP/2.0/UDP 192.168.111.20:5060;branch=z9hG4bK-524287-1---3864f869e5154557;rport=5060;received=192.168.111.20
    From: "John"<sip:269xxxxxxx@192.168.111.20:5060>;tag=490be25f
    To: <sip:1269767xxxx@192.168.111.21:5060>;tag=552446499
    Call-ID: MzF597P3aEBke-VCYTTdXQ..
    CSeq: 1 INVITE
    Server: Patton SN4960 1E30V 00A0BA061475 R6.8 2015-11-13 H323 RBS SIP M5T SIP Stack/4.2.8.10
    Content-Length: 0
    
    ACK sip:1269767xxxx@192.168.111.21:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.111.20:5060;branch=z9hG4bK-524287-1---3864f869e5154557;rport
    Max-Forwards: 70
    To: <sip:1269767xxxx@192.168.111.21:5060>;tag=552446499
    From: "John"<sip:269xxxxxxx@192.168.111.20:5060>;tag=490be25f
    Call-ID: MzF597P3aEBke-VCYTTdXQ..
    CSeq: 1 ACK
    Content-Length: 0
    
    
     
  11. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,737
    Likes Received:
    278
    If all calls are using the same outbound rule, but some (a certain areacode , or number) , are being blocked, then you need to determine if your gateway is rejecting it, or it is your provider that is rejecting it.
    There may be a Syslog function in the gateway that would help determine what is going on once the call is passed onto it.
     
    #11 leejor, May 18, 2017
    Last edited: May 19, 2017
    clweb likes this.
  12. StefanW

    StefanW Head of Customer Support and Training
    Staff Member 3CX Support

    Joined:
    Jun 2, 2009
    Messages:
    1,215
    Likes Received:
    87
    you picked the right log part. As leejor said, now you would need to telnet to the device and see why. Best to contact patton support to give it a check as the logging after this point becomes very big...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    clweb likes this.
  13. clweb

    Joined:
    Mar 24, 2016
    Messages:
    7
    Likes Received:
    0
    Thanks for the help everyone! With after working with the Patton support team, we determined that the error is coming from our provider. I've opened a ticket with them and hopefully will have it resolved shortly!
     
  14. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,123
    Likes Received:
    150
    Perfect!! Thanks for the update.
    Keep us up to date on this one. I'm curious to know what the source was from the telco. See if you can extract that info.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  15. clweb

    Joined:
    Mar 24, 2016
    Messages:
    7
    Likes Received:
    0
    Just received a call back from the Telco - apparently the issue was that the number needed to be sent to them as a 10 digit number, which is strange because I've never had an issue with sending the 1 with that prefix before. Nonetheless, I've added the appropriate rules and it's all working now!

    Thanks again for everyone's help on this!
     
  16. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,737
    Likes Received:
    278
    It sounds as if your provider does not have consistency in the format (length) of the digits they accept, based on the area code/prefix. It may be that they are simply passing the call on "as-is" and the next destination (for the failing call) is rejecting it.
     
  17. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,123
    Likes Received:
    150
    You can send a report to us telling us country, provider and number format and we can add it to the next feature we are going to add - number normalization.. for providers. We will do it so you do not have to do it. (Call telco, wait etc etc)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.