Outbound Caller ID issue in Outbound Rules

[Rowan]

Previously, in version 16, the Outbound Caller ID would be set by 15CHARACTERNAME<+17663686237>, but now, after upgrading to version 18, it will not allow the "<" or ">" characters. Rules that already have the "<" and ">" characters from version 16 still work, but if you open them to edit, it will not allow you to save, even if you make no changes.

If the caller ID is entered without the "<" and ">", it is ignored by 3CX

This is a bug, but I don't want to use a ticket just to report it.

 

[ChrisC_3CX]

Previously, in version 16, the Outbound Caller ID would be set by 15CHARACTERNAME<+17663686237>, but now, after upgrading to version 18, it will not allow the "<" or ">" characters. Rules that already have the "<" and ">" characters from version 16 still work, but if you open them to edit, it will not allow you to save, even if you make no changes.

This change was actually implemented on purpose hence the message you see underneath the field that states what characters are allowed. Your current values did not get removed but you won't be able to edit or add new ones as you have already noticed.

If the caller ID is entered without the "<" and ">", it is ignored by 3CX

Do you mean that if you do not use the chevrons, the Caller ID is not sent out by 3CX? I doubt that is the case to be honest and most probably has something to do with the SIP Provider but, just to confirm, go into "Dashboard >> Activity Log >> Settings >> Enable Verbose Mode", then, make an outbound call and end it. Go back to the activity log and check the SIP INVITE set outward to the SIP Provider by 3CX, is it indeed missing the Caller ID you set?

Also, which SIP Provider are you using, is it a 3CX Supported one?

 

[Rowan]

This change was actually implemented on purpose hence the message you see underneath the field that states what characters are allowed. Your current values did not get removed but you won't be able to edit or add new ones as you have already noticed.


Do you mean that if you do not use the chevrons, the Caller ID is not sent out by 3CX? I doubt that is the case to be honest and most probably has something to do with the SIP Provider but, just to confirm, go into "Dashboard >> Activity Log >> Settings >> Enable Verbose Mode", then, make an outbound call and end it. Go back to the activity log and check the SIP INVITE set outward to the SIP Provider by 3CX, is it indeed missing the Caller ID you set?

Also, which SIP Provider are you using, is it a 3CX Supported one?

It sends the number or the name, whichever one is in the field. If I want it to send both the name and the number, I have to enter it as 15CHARACTERSMAX#7663686237, which shows up on calls to other lines with the same provider, on the same or a different PBX. However, It's ignored by other VoIP providers, cellular and POTS lines.

My provider is US:Skyetel

 

[ChrisC_3CX]

In that case the PBX is indeed sending it as is meaning it's really out of 3CX's control so there might not be much we can do.

Is the name you want to present a static value? If yes, you could try setting it on the "From: Display Name" field in "SIP Trunks >> Edit >> Outbound Parameters". Just set the "From: Display Name" to use a custom field and then enter the value in the provided field(Just the name). The number you should set on the Outbound Rule level.

 

[Rowan]

We support 9 different Divisions, each with their own CNAM and number. There are specific Outbound Rules setup with these names and numbers for each Division. I can set the Outbound caller ID number on the user extension, but I don't want the individual callers' names showing up with the number. It should be "DIVISION'S NAME"<+17663686237>, just like how it worked in version 16 and before and with all other PBX systems I've ever used. The fact that it still works with the Outbound Rules that were migrated, shows that the capability is still there.

 

[leejor]

Unfortunately, sending a caller name, and having it received, can be hit or miss, as you've discovered. While you are fortunate enough to have a provider that passes it on within their network, it may, or may not be passed, on calls beyond that, or, may be passed, and, as you suspect, and is ignored.

In Canada, a name that originates with the caller is usually honored through to the destination, even over multiple carriers, overriding a name being added by the terminating provider, but in the US, it seems to be a different story.

 

[Rowan]

It currently works for 7 of our 9 Divisions, across POTS and cellular providers in NY state. It's just not working for the 2 providers added after the migration to 3CX v18.

 

[ChrisC_3CX]

It's just not working for the 2 providers added after the migration to 3CX v18.

To clarify, what changed on the 3CX end from v16 to 18 is the Caller ID validation. That said, 3CX will send whatever value the field holds so if that is not presented as expected then it means that it's probably one of the SIP Providers or the receiving end modifying the CID.

 

[Rowan]

The validation is the problem. It no longer allows the angle brackets which separate the name from the number. without it, most providers ignore the caller ID, because it's over 15 characters. The ones that accept it, ignore the beginning of the string and just send the number.

I think the part you're ignoring is that it currently works (and is properly formatted) with the angle brackets on the routes that were migrated from v16. The fact that it only throws up an error when those routes are edited or new ones with that specific format are added, shows that it's an issue with the code. If I could revert to v16, I would, just for this reason alone.

 

[ChrisC_3CX]

The fact that it only throws up an error when those routes are edited or new ones with that specific format are added, shows that it's an issue with the code.

I can confirm this is by no means an issue in the code, as mentioned earlier this change was implemented intentionally, the fact that it does not automatically invalidate your existing configuration is only due to the fact that the validation check occurs upon saving the configuration.

 

[Rowan]

But why? Why remove functionality? Why the regression?

 

[ChrisC_3CX]

Evidently certain values in the Caller Id will cause issues with a number of SIP Providers so some restrictions had to be imposed to avoid misconfiguration and maintain functionality. Plus, none of 3CX's Supported Providers actually require such configuration to work as intended.

 

[Rowan]

Plus, none of 3CX's Supported Providers actually require such configuration to work as intended.

From VoIP.ms: https://wiki.voip.ms/article/Caller_ID

 

[ChrisC_3CX]

I believe that by Caller ID name voip.ms is referring to the "From: Display Name" which is part of the Caller ID header in a SIP Invite:



Red is the "From Display name" (Caller ID Name) and Blue is the "From User Part" (Caller ID number). The way the 3CX Voip.ms template is set up will have both these fields populated with the Outbound Caller ID value you specify. That said, you would end up with something like this in the SIP From header:

From: "DIVISIONSNAME<123456789>"<sip: DIVISIONSNAME<123456789>@hostpart>

Needless to say, the above format is completely invalid and also violates some of voip.ms requirements mentioned in the same link you provided:


Taking the above into consideration, the only way this could perhaps work is if you had modified 3CX's SIP Trunk configuration for the specific provider hence deviating from the default settings and ultimately rendering the said SIP Trunk configuration an unsupported configuration.

In any case, even if this was valid, as per your post Voip.ms clearly states it is an additional option that CAN be used:

Therefore my statement that this is not a requirement still stands.

 

[Rowan]

It would be:

From: "DIVISIONS NAME"<sip:17663686237@hostpart>;tag=1234567890

not:

From: "DIVISIONSNAME<123456789>"<sip: DIVISIONSNAME<123456789>@hostpart>

 

[Rowan]

But I get it. If 3CX isn't working for me, I should look elsewhere.

 

[cobaltit]

Skyetel has a KB article on outbound caller id.

At the bottom it states this:

[HEADING=1]Outbound Caller ID Delivery[/HEADING] When Skyetel receives properly formatted calls, we pass along that information along intact to our interconnecting peers. Depending on the party you are trying to call, the time of day, network congestion, the anger of the VoIP gods, etc, this data may be stripped on the way to its destination. It is important to remember that many carriers (especially in the US) charge for this data, and will intentionally not deliver it unless the party you are calling has Caller ID enabled. Additionally, most US-based cell phone providers disregard this data entirely and won't even send it to your cell phone even if you have it enabled. If your end user is reporting that they are receiving reports of out-of-date Caller ID, and you have followed all of these steps, then the only solution is for the end user to have the party they called request support from their own phone provider. This is because that provider is either not honoring the Caller ID data, or is maintaining stale data. The reason we say this is because [B]we are not able to guarantee that the data you send us will arrive at its destination, and Outbound Caller ID Delivery is a "Best Effort" service. [/B]

Regardless if it used to work or even if you think it does still work, I've never set it up the way you have now. We put the 15 limit name in there, and the number is already provided when the call goes out. The assumption with any VoIP provider is that whatever you specify in the PBX (any PBX) may be passed on-net, but off-net we expect the receiving provider to do a CNAM dip for results based off the number.