Outgoing call receiving "not acceptable" response

[clweb]

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.

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:[email protected]: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:[email protected]: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:[email protected]:5060] for L:284.1[Extn]
24-Mar-2016 09:37:06.875	[CM503027]: Call(C:284): From: Extn:353 ("John" <sip:[email protected]:5060>)  to  T:Line:10001>>1xxxxxxxxxx@[Dev:sip:[email protected]: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:[email protected]:5060]
24-Mar-2016 09:37:06.875	Line limit check: Current # of calls for line Lc:10001(@PRI[<sip:[email protected]: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:[email protected]:5060>

 

[leejor]

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.

 

[clweb]

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.)

 

[leejor]

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.

 

[clweb]

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.

 

[leejor]

Not sure I'm clear...

You say

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

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.

 

[NickD_3CX]

What is on IP 192.168.111.21?

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]

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!

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:[email protected]: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 [email protected]: SIP/2.0 480 Temporarily Unavailable Via: SIP/2.0/UDP 192.168.111.167:5060;branch=z9hG4bK-32439dee To: <sip:[email protected]>;tag=ca1fb505 From: "John"<sip:[email protected]>;tag=18445d2aff55506o0 Call-ID: [email protected] 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:[email protected]: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:[email protected]: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:[email protected]: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 [email protected]: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.111.167:5060;branch=z9hG4bK-32439dee Contact: <sip:[email protected]:5060> To: <sip:[email protected]>;tag=ca1fb505 From: "John"<sip:[email protected]>;tag=18445d2aff55506o0 Call-ID: [email protected] 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:[email protected]:5060, Call(C:722)
05/16/2017 4:53:03 PM - [CM503025]: Call(C:722): Calling T:Line:10001>>1269767xxxx@[Dev:sip:[email protected]: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:[email protected]:5060]
05/16/2017 4:53:03 PM - [CM503027]: Call(C:722): From: Extn:353 ("John" <sip:[email protected]:5060>) to T:Line:10001>>1269767xxxx@[Dev:sip:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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 [email protected]: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.111.167:5060;branch=z9hG4bK-32439dee Max-Forwards: 70 Contact: "John" <sip:[email protected]:5060> To: <sip:[email protected]> From: "John"<sip:[email protected]>;tag=18445d2aff55506o0 Call-ID: [email protected] 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:[email protected]: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:[email protected]:5060>
05/16/2017 4:53:03 PM - Leg L:722.1[Extn:353] has external party ID {}

 

[YiannisH_3CX]

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]

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.

INVITE sip:[email protected]: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:[email protected]:5060>
To: <sip:[email protected]:5060>
From: "John"<sip:[email protected]: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:[email protected]:5060>;tag=490be25f
To: <sip:[email protected]:5060>;tag=552446499
Call-ID: MzF597P3aEBke-VCYTTdXQ..
CSeq: 1 INVITE
Contact: <sip:[email protected]: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:[email protected]:5060>;tag=490be25f
To: <sip:[email protected]: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:[email protected]: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:[email protected]:5060>;tag=552446499
From: "John"<sip:[email protected]:5060>;tag=490be25f
Call-ID: MzF597P3aEBke-VCYTTdXQ..
CSeq: 1 ACK
Content-Length: 0

 

[leejor]

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.

 

[StefanW]

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...

 

[clweb]

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!

 

[nb]

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.

 

[clweb]

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!

 

[leejor]

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.

 

[nb]

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)