Inbound calls failing from specific carrier

[TSSEngineers]

Hello Team,

Was hoping to get some assistance/guidance on a strange issue we appear to be having with certain Dubai Numbers being reachable.

When a certain carrier calls into the 3cx, it is coming up with the response that the 3cx isn't available. I can reach these specific extensions/numbers from a UK Number, and other numbers are also able to reach these numbers.The carrier so far has said it is an issue with the PBX, as they are seeing a not available coming back from the 3cx.But i can't see why it would be saying not available to a specific carrier/number range

I have attached an example image. The call from the UK Number goes through fine but the call from the number below it always fails.

Kind Regards,
Joe

 

[Alphabetic]

Have you checked to make sure you have this DID set up in your SIP trunk?

What does the event log say.

 

[TSSEngineers]

Hello,

The DID is set up in the SIP Trunk. I can reach it fine from a UK Number, and i can see other numbers have been able to reach it as well it just seems to be this range, there is nothing within the event logs that indicates any issue from today.

Kind Regards,
Joe

 

[KyriacosS_3CX]

Hi, have you asked your Trunk provider to check from their end?

 

[TSSEngineers]

Hi Kyriacos,

We have, they just responded with this:
We received below feedback from technical team :

The below release is coming from the customer PABX. customer needs to check from his PABX side.

Warning: 499 sigma.3cx.uk "Not available"

But from further discussions, the SIP Trunk and the number that has been trying to call in are both using the same underlying carrier so it could be some form of internal routing on their side?

I'm not sure what else i can check on the 3cx Side, as the number works fine its just these specific numbers that have issues dialling in.

Kind Regards,
Joe

 

[Alphabetic]

You should run a trace and see whats happening

 

[leejor]

You should run a trace and see whats happening

Exactly, if you have access to the 3CX Activity Log, (Verbose setting), it will give you a lot more information about how 3CX is "reacting" to the specific calling numbers that are failing. And hopefully, how that differs from the calls that get through.

 

[TSSEngineers]

Hi All,

Thank you for your assistance so far. We have turned on the Verbose logging, and it has come back with the below:

05/27/2026 12:00:33.158 PM	[CDR] Call(C:241): CDR: Incoming params: cdr_id = '00000000-01dc-edc8-09f7-88640000023e' call_history_id = '00000000-01dc-edc8-09f7-6838000000f1' source_participant_id = '00000000-01dc-edc8-09f7-887f0000032e' source_entity_type = 'external_line' source_dn_type = 'provider' source_dn_number = '10001' source_dn_name = 'Dubai Audiocodes' source_participant_name = '058xxxxxxx' source_participant_phone_number = '+97xxxxxxxxxxx' source_participant_trunk_did = '+97xxxxxxxx' source_participant_is_incoming = 1 (i32) source_participant_is_already_connected = 0 (i32) source_participant_group_name = '' source_participant_billing_suffix = '' destination_participant_id = '00000000-01dc-edc8-09f7-88860000032f' destination_entity_type = 'inbound_routing' destination_dn_number = '+97xxxxxxxx' destination_dn_type = 'unknown' destination_dn_name = '' destination_participant_name = '' destination_participant_phone_number = '+97xxxxxxxxx' destination_participant_trunk_did = '' destination_participant_is_incoming = 0 (i32) destination_participant_is_already_connected = 0 (i32) destination_participant_group_name = '' destination_participant_billing_suffix = '' creation_method = 'call_init' creation_forward_reason = 'none' source_presentation = '05xxxxxxxxxxx' termination_reason = 'dst_participant_terminated' termination_reason_details = 'forward_all' terminated_by_participant_id = '00000000-01dc-edc8-09f7-88860000032f' cdr_started_at = '2026-05-27 11:00:33.073166' cdr_ended_at = '2026-05-27 11:00:33.158522'
05/27/2026 12:00:33.158 PM	Lsip{462724/241.1/UAS[Rejected&OfferReceived]} sends: SendResp Send 480/INVITE from 0.0.0.0:0 tid=ac33196655 Call-ID=[email protected]: SIP/2.0 480 Temporarily Unavailable Via: SIP/2.0/UDP 10.31.12.28:5060;branch=z9hG4bKac33196655 To: <sip:[email protected]>;tag=57f31918 From: <sip:[email protected];user=phone>;tag=1c1234781532 Call-ID: [email protected] CSeq: 1 INVITE Warning: 499 sigma.3cx.uk "Not available" Content-Length: 0
05/27/2026 12:00:33.158 PM	L:241.1[Line:10001<<++97xxxxxxxx{00000000-01dc-edc8-09f7-887f0000032e}] onReadyToSend: Send Send 480/INVITE from 0.0.0.0:0 tid=ac33196655 Call-ID=[email protected]: SIP/2.0 480 Temporarily Unavailable Via: SIP/2.0/UDP 10.31.12.28:5060;branch=z9hG4bKac33196655 To: <sip:[email protected]>;tag=57f31918 From: <sip:[email protected];user=phone>;tag=1c1234781532 Call-ID: [email protected] CSeq: 1 INVITE Warning: 499 sigma.3cx.uk "Not available" Content-Length: 0
05/27/2026 12:00:33.081 PM	Lsip{462724/241.1/UAS[SentProvisional&OfferReceived]} sends: SendResp Send 180/INVITE from 0.0.0.0:0 tid=ac33196655 Call-ID=[email protected]: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.31.12.28:5060;branch=z9hG4bKac33196655 Contact: <sip:[email protected]:5060> To: <sip:[email protected]>;tag=57f31918 From: <sip:[email protected];user=phone>;tag=1c1234781532 Call-ID: [email protected] CSeq: 1 INVITE Content-Length: 0
05/27/2026 12:00:33.081 PM	L:241.1[Line:10001<<++97xxxxxxx{00000000-01dc-edc8-09f7-887f0000032e}] onReadyToSend: Send Send 180/INVITE from 0.0.0.0:0 tid=ac33196655 Call-ID=[email protected]: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.31.12.28:5060;branch=z9hG4bKac33196655 Contact: <sip:[email protected]:5060> To: <sip:[email protected]>;tag=57f31918 From: <sip:[email protected];user=phone>;tag=1c1234781532 Call-ID: [email protected] CSeq: 1 INVITE Content-Length: 0 But a successful call comes through as: 05/27/2026 12:26:09.640 PM [CDR] Call(C:244): CDR: Incoming params: cdr_id = '00000000-01dc-edcb-9cec-9f5000000244' call_history_id = '00000000-01dc-edcb-9cec-8563000000f4' source_participant_id = '00000000-01dc-edcb-9cec-9f6400000337' source_entity_type = 'external_line' source_dn_type = 'provider' source_dn_number = '10001' source_dn_name = 'Dubai Audiocodes' source_participant_name = '0044xxxxxxxxx' source_participant_phone_number = '+44xxxxxxx' source_participant_trunk_did = '04xxxxxxx' source_participant_is_incoming = 1 (i32) source_participant_is_already_connected = 0 (i32) source_participant_group_name = '' source_participant_billing_suffix = '' destination_participant_id = '00000000-01dc-edcb-9cec-9f6c00000338' destination_entity_type = 'inbound_routing' destination_dn_number = '04xxxxxx' destination_dn_type = 'unknown' destination_dn_name = '' destination_participant_name = '' destination_participant_phone_number = '04xxxxxxxx' destination_participant_trunk_did = '' destination_participant_is_incoming = 0 (i32) destination_participant_is_already_connected = 0 (i32) destination_participant_group_name = '' destination_participant_billing_suffix = '' creation_method = 'call_init' creation_forward_reason = 'none' source_presentation = '0044xxxxxxxx' termination_reason = 'redirected' termination_reason_details = 'by_did' continued_in_cdr_id = '00000000-01dc-edcb-9cf9-a71a00000245' cdr_started_at = '2026-05-27 11:26:08.116926' cdr_ended_at = '2026-05-27 11:26:08.202324' It appears as though its the destination phone number that is causing the issue, at least from a brief look.

 

[NikosT_3CX]

@TSSEngineers as I can see the VoIP Provider you are using is " du.ae " .
Now I see on the TO section number " +971xxx9311 " and Contact number " 0xxx9311 " .
Where does this DID point to ?
Also what are the inbound parameters of this Trunk ? Export the trunk and check it and ensure they check the TO User Part.

 

[TSSEngineers]

Hi Nikos,

So we were told by the provider the numbers should be formatted as 0xxx, which is what all the DDIS are set as. It just seems to be these specific numbers there are sending their To as +971xxx instead. Is it worth adding the +971 numbers to the trunk as well and assigning them to the same users?

 

[NikosT_3CX]

@TSSEngineers you may give it a go but in order to have stability, speak with your VoIP Provider and tell them
to provide you a standard format of the TO they send to the PBX.
If they say to put the DID as 0xxxx and then they send the call with +971xxxxx, you can understand that you will
have issues.

 

[leejor]

If you use a wildcard (*) in the DID trunk settings, you will cover all your bases. It won't matter what prefix they send you.

Thread 'DID and wildcard'

Dec 16, 2024

Wildcard asterix not working at the end of the did number. For example +3912635* cannot be recognized. Faeature was avalailable in V18 and must be included also in the latest V20.oduce wildcard

• infosetsrl
• Replies: 2
• Forum: Server