Cannot receive incoming calls.

[MHRAdmin]

When a caller calls into our system all they hear is "Sorry, the number you called was busy", and nobody is on the phone.
I have been searching online for hours and not having much luck. I cleared my activity log and called in once.

Our system is hosted on google platform with a static IP. It worked yesterday. Outgoing, and extension to extension work. This only seems to bother the inbound calls.

The DID at the moment is set to connect to an extension for simplicity, it still fails.
I have followed all the guides but i must be missing something. Anyone have a suggestion?

Below are partial logs from the call.

03/25/2020 6:12:12 PM - Default best-route IP is determined as 10.128.0.2

03/25/2020 6:12:08 PM - Updating device Dev(1227963009):[sip:[email protected]:5063;rinstance=2418f8d488b61d24 / 90000] by message: DevUpd Recv Req REGISTER from 127.0.0.1:5063 tid=7a66ab18e338b236 Call-ID=eHpXZKKI3h9w4zQYHiy3fQ..: REGISTER sip:127.0.0.1:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5063;branch=z9hG4bK-524287-1---7a66ab18e338b236;rport=5063 Max-Forwards: 70 Contact: <sip:[email protected]:5063;rinstance=2418f8d488b61d24> To: <sip:[email protected]:5060> From: <sip:[email protected]:5060>;tag=bd2d9773 Call-ID: eHpXZKKI3h9w4zQYHiy3fQ.. CSeq: 426 REGISTER Expires: 60 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Proxy-Authorization: Digest username="90000",realm="3CXPhoneSystem",nonce="414d53595e7bd73791:ad69f41dc7eb67624eceb2b6186a87dd",uri="sip:127.0.0.1:5060",response="7215f74ab5110fe5f142472241e739f6",algorithm=MD5 Supported: replaces User-Agent: 3CX WebRTC proxy Content-Length: 0

03/25/2020 6:12:08 PM - Line 90000 got Device: Dev(1227963009):[sip:[email protected]:5063;rinstance=2418f8d488b61d24 / 90000]

03/25/2020 6:12:08 PM - Source is identified as trunk Lc:90000(@WebMeeting bridge[<sip:[email protected]:5063/UDP>])

03/25/2020 6:12:07 PM - Source is identified as trunk Lc:90000(@WebMeeting bridge[<sip:[email protected]:5063/UDP>])

03/25/2020 6:12:01 PM - Default best-route IP is determined as 10.128.0.2

03/25/2020 6:11:58 PM - Currently active calls [none]

03/25/2020 6:11:56 PM - Timezone offset: -240 min.

 

[MHRAdmin]

I should also note that i was working with queues this morning. However, nothing is pointed at the queues ATM for simplicities sake.

 

[JohnS_3CX]

The Log does not contain the call you mention. As a matter of fact the message you hear may be coming from the provider (I don't recall 3CX having the specific message you mentioned so who is sending it?)

Do you have a registration based provider, and if so, is the trunk registered?
Can you make outgoing calls?

 

[MHRAdmin]

I did think that first. And i DID reach out to the trunk provider first. They said the message is not coming from them. I also reviewed the messages that 3CX has in the system. I did not hear either of the messages i am getting. That being said .......

That log, is what I get when i call in. It IS hitting the system, but i don't know where it is going from there. I added another trunk and set it up. got the same thing. Today I noticed in the template that SIP TLS is not supported by my provider and i believe i turned that off, properly i mean

After changing that setting, the system rebooted and tried again.

I still hear "Sorry, the number you called was busy, please try again, message 14 switch 2314" from my cell phone and "All circuits are busy now. please try you call again later" from my company provided freepbx voip phone. i have no access to a POTS line to see what it would say.

Is there a way to send you the activity logs without compromising my system security?

 

[leejor]

The recording you are hearing is probably from the originating switch. With SS7 signalling, if the destination is busy (or another condition returned, that does not require an audio path), the call will not remain up and tie up a trunk. The originating switch is simply instructed to play the appropriate message ./ tone(s). If the call originates from some PBXs, then they may play the messges just as 3CX can.

 

[MHRAdmin]

That makes sense.
I just set up a trunk from SIP.us and called in. What it provides to the activity log is totally different from what it shows me with the Vitelity trunk.

So how do i fix it? Obviously it is getting some kind of code.

 

[leejor]

You didn't say what you got with the other trunk , only that it was "totally different" . What does that actually mean? When you set up the other trunk, did you do a "simple" install and terminate (as the default, no DID rules) all calls onto an extension?

 

[JohnS_3CX]

I think you should run a capture, and dial in.

The capture will tell you if the call is actually hitting your PBX, and what the PBX replies back to your provider.

If nothing comes in then, the provider needs to check their end using the numbers and timestamp you provide them.

If nothing hits the provider either, it may be a number portability issue, ie. the other providers (where you make the call From) may not know where to send that call, or they may be sending it to an invalid destination (ie. towards a provider that doesn't own your DID) and generating an error. In this case, your provider may need to "re-publish" the number to the other providers so they can correctly route the call. I suspect, that if you call your DID from a trunk belonging to your own provider, the call will work

PS: 90000 is the webmeeting bridge, it does not make calls anywhere, it just talks to the webmeeting servers to connect dial-in meeting participants. The message you see is simply the bridge Registering as an extension.

 

[MHRAdmin]

Last night I restored the system back to the way it was configured the day before. It will dial in now. I believe there was a handshake issue with Vitelity after I set the IP to Static. Before I restored it i took Vitelity out of "Account Based" and changed it to "IP Based". As soon as the PBX was restored i made the same change in 3CX.
Prior to that, every time I noticed in the log that the trunk seemed to intermittently go through a process of registering. but it would re-register many times in one minute.

After restoring it receives calls beautifully.

Thank you.

What i meant by totally different is , it populated the log like i see in other posts. With a lot more valuable information.

Please explain what you mean by "run a capture".

 

[SteveITS]

Please explain what you mean by "run a capture".

https://www.3cx.com/docs/capture-network-traffic/

 

[JohnS_3CX]

Management Console > Activity Log > Capture button

This does a packet capture which you can then analyze in WireShark (requires some knowledge on that)


It does show you however on a packet-per packet basis what came in and what reply went out from the ethernet card. IF nothing comes in then you can at least be sure the PBX is not at fault

This module gives you some basic instructions
https://www.3cx.com/3cxacademy/videos/advanced/basic-troubleshooting/