Solved Remote connections from same WAN IP as SBC

[deathonredbull]

I have what might be an usual issue with 3CX and I'm trying to figure out what might be causing it. I'm learning 3CX as I go along, so please forgive any glaring gaps in my knowledge.

Recently, everybody on the system has been sporadically receiving calls from telephone numbers that also appear to be answerable with the 'video' option in the Windows appllication. People logged in or out of queues are receiving them - it doesn't seem to matter. The call rings for a second then drops, and goes in the abandoned calls list. It doesn't always happen - these calls seem to happen in a batches for a short while, then stop - maybe over a few hours. They ring for such a short time, no seems to be able to pick them up. This seems to be relatively new behaviour, maybe over the last couple of weeks.

This may be a coincidence, but it could have started around the time I made some adjustments to our on-site Wi-Fi. One of the Wi-Fi networks that staff used to use in the past is now unable to see any local network resources (including the SBC), and this is by design. I've informed staff to not use this network, but of course, not everyone reads emails. I can't just change the Wi-Fi password, as a load of devices managed with our MDM use it, and if I did, they'd permanently lose connectivity.

What I'm wondering about is this: will the 3CX server in the cloud get confused if clients connect to it from the same WAN IP as the SBC, but not actually through the SBC? Effectively, devices on this network that have the 3CX app are making a remote connection, but from the same WAN IP as the SBC. Intuitively, it feels as though this would interfere somehow with call routing, in and out - but I'm not sure how it's working behind the scenes.

If certain users were present with their device(s) on this network for short periods, this might account for the behaviour we've been seeing, and many staff do come and go frequently.

Is anybody able to enlighten me? Any help appreciated.

Thanks.

 

[Alphabetic]

Recently, everybody on the system has been sporadically receiving calls from telephone numbers that also appear to be answerable with the 'video' option in the Windows appllication

Response for this:

@YiannisH_3CX " This happens because the call comes from a Digital receptionist. Then that happens the SIP flow is different. What happens in that case is that the incoming calls is answered by the Digital receptionist. When a transfer is made the Invite does not contain an SDP (no codecs). The codecs are negotiated when the call is established. Since the client is not aware if the incoming call is audio or video as there are no codecs it brings up both options. Once you press an option the client will send a 200 OK containing the codecs it uses and the PBX will reply with an ACK with the codecs from the incoming call. If no video codecs are present a normal audio call will be established. This is the default behaviour of the client and cannot be changed."

Have you opened up any ports on your network for 5060 which would result in you getting ghost calls?

Are all your remote phones/apps using the SBC and are they extensions provisioned this way under MGMT console?

I see no problem in routing if your EXTs are registering fine.

the 3CX mobile app doesnt use local SBC, instead it creates its own tunnel with 3CX.

 

[JohnS_3CX]

Hi,

They can coexist independently.

Check your PBX logs and see the origin of these calls: Do they appear in the call logs of the management console?

State your PBX version and your Windows app version please.

 

[deathonredbull]

Response for this:

@YiannisH_3CX " This happens because the call comes from a Digital receptionist. Then that happens the SIP flow is different. What happens in that case is that the incoming calls is answered by the Digital receptionist. When a transfer is made the Invite does not contain an SDP (no codecs). The codecs are negotiated when the call is established. Since the client is not aware if the incoming call is audio or video as there are no codecs it brings up both options. Once you press an option the client will send a 200 OK containing the codecs it uses and the PBX will reply with an ACK with the codecs from the incoming call. If no video codecs are present a normal audio call will be established. This is the default behaviour of the client and cannot be changed."

Have you opened up any ports on your network for 5060 which would result in you getting ghost calls?

Are all your remote phones/apps using the SBC and are they extensions provisioned this way under MGMT console?

I see no problem in routing if your EXTs are registering fine.

the 3CX mobile app doesnt use local SBC, instead it creates its own tunnel with 3CX.

Thanks for getting back to me.

To answer your questions:

- 5060 is not an inbound open port.
- All extensions are configured so physical phones are provisioned to use the SBC.
- The mobile app is correctly pointed at the cloud PBX.
- The Windows app only seems to provision with the cloud PBX address in the 'Out of Office' section in the account settings. I can manually place the internal IP of the SBC in the 'In Office' field, then reprovision (which works fine) but I'm not sure how to automatically populate this field.
- Extensions register fine.

To clarify about the 'phantom' calls, when they happen, even users whose status is set to 'Away' get them. You're right in that they do all seem to be coming via the IVR to the main queue, but the fact that users who are not even logged into the queue, and whose status shouldn't permit them to ring is strange. The calls show in the central logs as unanswered calls, and on local clients as 'Abandoned'.

 

[JohnS_3CX]

State your PBX version and your Windows app version please

 

[deathonredbull]

Hi,

They can coexist independently.

Check your PBX logs and see the origin of these calls: Do they appear in the call logs of the management console?

State your PBX version and your Windows app version please.

Thank you for getting back to me.

The calls do appear in the main 3CX logs - they come from various numbers and show as unanswered. They're hitting the IVR then being forwarded on to the main Q, as they should. They show in the local Windows client under 'Abandoned'.

As said above, even users set to 'Away' see them ring for a second or so, as do users not currently logged into the queue.

Versions:

PBX: 16.0.619
SBCs: 16.1.152
Windows clients: 16.3.0.144

Thanks for the help.

EDIT: additionally, I think this might have started happening a couple of Fridays ago, when there was the last update.

 

[JohnS_3CX]

Can you describe the entire call flow, step by step? (including any forwarding rules that may alter the direction of the call)

 

[deathonredbull]

We have two locations. There is only one inbound rule, and this is a DDI to redirect our south office's old number to a ring group that should ring everyone in the south office. To clarify, users in either office compain of this problem, though.

The call flow is this:
- Caller hits IVR.
- They are offered 5 choices.
- 4 of the 5 choices go to a corresponding ring group.
- One of the choices goes to the main queue. The call will also be passed to this queue if the IVR times out.

EDIT: the problem calls show as hitting the IVR then going to the queue - that's all the information I can see. The length of the calls seems to vary between 00:00:00 and 00:00:20.

Many of the staff who have been receiving the 'phantom' calls are not in any ring group - only the main queue. Of the staff who are members of the queue, only two or three are ever signed in at one time. Both staff who are signed into the queue and staff who are not signed into the queue will receive the phantom calls simultaneously, regardless of status.

 

[deathonredbull]

Update: just had another one now. I heard it ring but couldn't get to it in time.

A user who has two extensions reported that it rang on her Windows client, but the extension that is configured in the Windows client shouldn't have rung at all - it is set to divert to her second extension, which uses the app on her phone. She reports that her Windows 3CX never rings because of this - only when these problem calls happen.

The extension that rang IS a member of a queue, but she wasn't logged in. The extension that it is set to forward to didn't ring at all.

The event log shows ID 105: Lost call in queue.

 

[YiannisH_3CX]

What happens when you call your PBX from your mobile number? Is the behaviour the same or only the correct extensions ring? Also do the ghost calls reach the IVR timeout or is there an option selected?

As a first step i would recommend setting the PBX logging level to verbose. You can do this by navigating to Dashboard / Settings.

So the next time this happens you can go through the Activity log and follow the call. This should provide some details on how the call rings extensions that shouldn't ring.

Let us know if you need assistance going through the logs.

 

[deathonredbull]

Thanks for getting back to me, and apologies for the delay in replying.

I think, tentatively, I might have gotten to the bottom of this, although there might be some other issues I need to investigate.

There seemed to be several issues compounding one another:

- The maximum ring time on the main queue was only set to ten seconds. Some staff in the queue on mobile devices weren't even hearing it ring before it failed over to the ring groups. I've extended this to 30 seconds, which seemed to have helped.
- Some colleagues didn't realise that the queue ignores their status.
- Some collagues forwarding was erroneously set to accept calls from ring groups, even when set to 'away'.

My question about clients on the LAN that couldn't see the SBC but were using the same WAN IP proved, of course, to be red herring.

Since I made these changes, and colleagues are aware of a few facts, we haven't had any new reports.

It would be good if mobile devices responded a bit quicker to rings in some circumstances, but that will another round of investigation.

Thanks again for the help.

 

[YiannisH_3CX]

Glad to see you were able to get to the bottom of this and thank you for updating the thread with your findings. Setting this one as resolved but you can always create a new thread for anything else you find.