Solved External calls going to attendant.

[chaznsc]

This weekend I got notification that our 3CX SSL Cert was renewed. This morning, all external calls are going to the after hours attendant. I have checked what I know to check, performed all updates with not luck. I am not blaming the SSL certificate, but Friday the system was working as normal.

Version 16.0.619


Help!

 

[chaznsc]

Here is a VM capture from a call I just made. I left everything intact.

08/04/2020 10:54:35 AM - Default best-route IP is determined as 10.0.19.16

08/04/2020 10:54:34 AM - Leg L:24.5[Ivr:851] is terminated: Cause: BYE from local

08/04/2020 10:54:34 AM - L:24.5[Ivr:851] got Terminated Send Req BYE from 0.0.0.0:0 tid=00045d437e697222 Call-ID=LEU38Dvi5LhVYi5QRc4uew..: BYE sip:[email protected]:5483;rinstance=ac1177ad144c6818 SIP/2.0 Via: SIP/2.0/ ;branch=z9hG4bK-524287-1---00045d437e697222;rport Max-Forwards: 70 Contact: <sip:[email protected]:5060> To: <sip:[email protected]>;tag=62728567 From: "WIRELESS CALLER :Main Number:Main Reception"<sip:[email protected]:5060;nf=e>;tag=8052e412 Call-ID: LEU38Dvi5LhVYi5QRc4uew.. CSeq: 2 BYE Content-Length: 0

08/04/2020 10:54:34 AM - Terminated from <sip:[email protected]>;tag=62728567 to "WIRELESS CALLER :Main Number:Main Reception"<sip:[email protected]:5060;nf=e>;tag=8052e412; reason: LocalBye

08/04/2020 10:54:34 AM - L:24.5[Ivr:851] Sending: OnSendReq Send Req BYE from 0.0.0.0:0 tid=9d65774ed13d987d Call-ID=LEU38Dvi5LhVYi5QRc4uew..: BYE sip:[email protected]:5483;rinstance=ac1177ad144c6818 SIP/2.0 Via: SIP/2.0/ ;branch=z9hG4bK-524287-1---9d65774ed13d987d;rport Max-Forwards: 70 Contact: <sip:[email protected]:5060> To: <sip:[email protected]>;tag=62728567 From: "WIRELESS CALLER :Main Number:Main Reception"<sip:[email protected]:5060;nf=e>;tag=8052e412 Call-ID: LEU38Dvi5LhVYi5QRc4uew.. CSeq: 2 BYE Content-Length: 0

 

[JohnS_3CX]

So back to point no.2 then:

If all incoming calls end up in the trunk settings destination, rather than follow your inbound rules, then perhaps its an indication that the number your provider sends you during an incoming call, does not match with whatever you set in your Inbound rules. So the number the provider sends, does not match in any way with *7067224114 for example.

This is what we would call a Call Source Identification issue and the logs should show a bit more detail as to what number arrives in the To: part

Would you be able to check and see what the provider sends?

 

[chaznsc]

So we would need to contact bandwidth.com?

 

[Alphabetic]

You would do a wireshark capture from the the Activity Log page then download it and view it with Wireshark to see what provider is sending. https://www.3cx.com/docs/capture-network-traffic/

Have you specified the office hours globally or in the SIP trunk? Have you confirmed date/time is correct on the machine?

 

[chaznsc]

Global office hours. It is sure behaving like there is a holiday but I dont see one.And I did verify the date and time.

 

[Alphabetic]

Can you screenshot your "Route calls to" on SIP trunk?

 

[chaznsc]

Here you go.

 

[Alphabetic]

Hmm.. i'd expect to see something in the activity log stating that the call had come in during out of office hours if that was the case..

Does EXT 201 have any forwarding going on?

 

[chaznsc]

 

[chaznsc]

As a follow up to this mystery, I have a DID number on my extension that we used as an experiment. That call goes thru like butter.

 

[chaznsc]

To wrap this up, here are some of the steps I took to resolve this:

System Service restarts (multiple, many, a lot)
Server Shut Down and restart
Server Win updates
Check all settings, 15 times
Check firmware on phones
Reboot phones
Pull hair out.
Post on 3cx forums and get multiple responses.
Check check and recheck all of the above.

I ended up calling the vendor, who restarted the services and rebooted the phone ONCE, and the system works. They dont have an explanation for me, just that its working.

Thanks to everyone for helping me chase this goose.

 

[JohnS_3CX]

Was the server time or NTP wrong by any chance?

 

[chaznsc]

It was not, I had also checked those a few times.

 

[JohnS_3CX]

Glad to hear it was resolved then