Anonymous when calling emergency numbers

[mls.nicolas]

Hello,

I have emergency numbers configured on 3CX server, but if a user add the *5 prefix before the emergency number, ie *5112, the call is sent to the SIP trunk but the Caller ID is set as Anonymous in SIP headers.
This is also the case if a Caller ID is hardcoded on the Emergency number configuration in the Outbound caller ID field.

When adding the SIP header P-Asserted-Identity on the trunk configuration via the XML, the caller ID is correctly presented on this field while it's set as anonymous on all others (From, Contact, Remote-Party-ID).

Is the behaviour of hiding the Caller ID (or any number, ie the one defined directly in the emergency number rule) really expected when calling an emergency number ? It seems to me that a user dialing *5 should not take precedence over a hardcoded caller ID set in the emergency rule.
Thanks

 

[NikosT_3CX]

As you may see from our online guide and also from the PBX side at the Dial Codes section,
the " *5 " is to hide the Outbound Caller ID.


https://www.3cx.com/docs/pbx-dial-codes/

Block Outbound Caller ID​

You can hide the outbound caller ID on a specific call. To do this just prepend the dialing number with *5. Example: if I want to call the number 004412345678 but I want to do this anonymously, dial *5004412345678. Your outbound caller id will be hidden.

 

[mls.nicolas]

Hello @NikosT_3CX
Yes, we're aware of this dial code. But our expectation is that when calling an emergency number, it should bypass the caller ID blocking. At least in Switzerland, the caller ID cannot be blocked when calling such numbers.

Maybe 3CX could add a parameter in the emergency rule or in the global settings to ignore caller ID blocking when calling an emergency number ? Or if there already is another method, I'm all ears

 

[Claas Felix Beyersdorf]

Why should one dial *5112 instead or 112? Maybe I don't get this but if you tell 3CX to hide the caller ID the ID is hidden.

And at least in germany our providers have to set the main trunk number for emergency calls, so you can hide your caller ID but the emergency dispatcher will see the main trunk number of the caller.

Maybe this is different in Switzerland?

 

[mls.nicolas]

@Claas Felix Beyersdorf It's totally an edge case I agree. I don't see a user dialing *5112 in case of emergency, but they can, and so we should handle it as correctly as possible.
The provider in this case needs the P-Asserted-Identity header with the phone number to handle it correctly. Which could be missing if the trunk is not configured as expected.
Yes usually the carrier can set a default number too here, but in this case it's a bit more complicated unfortunately.

Some PBX platforms have a special process for calls to emergency numbers, it ignore any sip trunk channel or licensing restrictions, it removes any caller id blocking, etc. So my question is about this feature specifically.

 

[VoIPTools]

I have not tried this, but my guess is that you could put in a outbound rule for your emergency number that strips the *5 and forwards just the 112. Have you tried that?

 

[Alphabetic]

I know at least here in the UK, the control room can see the number.

the ICO sets this out (https://ico.org.uk/for-organisation...etworks-and-services/line-identification-cli/)

"If you are a service provider, you must provide information about CLI and related privacy services. You must enable customers to withhold their number, and to reject anonymous calls.
There are exemptions for tracing malicious or nuisance calls, and for emergency 999 or 112 calls."

"Emergency 999 and 112 calls:
Regulation 16 sets out an exemption for emergency 999 or 112 calls. Callers cannot withhold their number on these calls. This is to enable the emergency services to make return calls if needed. Also the rules on location data do not apply, so that the emergency services can be informed of the caller’s location quickly and easily."

Not sure what its like in your neck of the woods.

Have you asked your provider?

 

[mls.nicolas]

I have not tried this, but my guess is that you could put in a outbound rule for your emergency number that strips the *5 and forwards just the 112. Have you tried that?

I don't think the *5 is still present in the outbound rules evaluation. I believe the dial code has been already processed and then the call is evaluated by the outbound rules.

 

[mls.nicolas]

I know at least here in the UK, the control room can see the number.

the ICO sets this out (https://ico.org.uk/for-organisation...etworks-and-services/line-identification-cli/)

"If you are a service provider, you must provide information about CLI and related privacy services. You must enable customers to withhold their number, and to reject anonymous calls.
There are exemptions for tracing malicious or nuisance calls, and for emergency 999 or 112 calls."

"Emergency 999 and 112 calls:
Regulation 16 sets out an exemption for emergency 999 or 112 calls. Callers cannot withhold their number on these calls. This is to enable the emergency services to make return calls if needed. Also the rules on location data do not apply, so that the emergency services can be informed of the caller’s location quickly and easily."

Not sure what its like in your neck of the woods.

Have you asked your provider?

I am the provider in this case. So indeed I must ensure that the Caller ID is sent to the PSAP/emergency service.
I have means to set some kind of default caller ID on the provider side too, But I'm looking for a solution on 3CX in case a user tries to hide their caller ID, to if possible still present they real number and not a generic one.

• Solution 1 : Add the PAI header on the trunk configuration, which asks for recreating the trunk and phone numbers
• Solution 2 : If recreating the trunk is too much trouble for the customer, I was looking for another way to ignore the *5 dial code when a call to an emergency number is started. This feature does not exist apprently.

 

[paulodagraca]

Hello mls.nicolas,

Correct, the *5 code (if not changed) will always work, and will be executed before the outbound rule.
Nothing you can do here, it's up to the provider to present the correct information regardless of your setting.

Please note that any alarm number like 112 is NOT just a normal phone number, the interconnect should always present a phonenumber at the callcenter.

Paulo

 

[paulodagraca]

I am the provider in this case. So indeed I must ensure that the Caller ID is sent to the PSAP/emergency service.
I have means to set some kind of default caller ID on the provider side too, But I'm looking for a solution on 3CX in case a user tries to hide their caller ID, to if possible still present they real number and not a generic one.

• Solution 1 : Add the PAI header on the trunk configuration, which asks for recreating the trunk and phone numbers
• Solution 2 : If recreating the trunk is too much trouble for the customer, I was looking for another way to ignore the *5 dial code when a call to an emergency number is started. This feature does not exist apprently.

I do not think this should ever be setup at the 3CX level.
This should be done at carrier side.

Also think about people that have their number always blocked,

Paulo

 

[mls.nicolas]

@paulodagraca it's already done at the carrier side when a user hides their caller ID, we present the main trunk number. But it would be better for 3CX to ignore the *5 and pass the real user caller ID to allow for a callback and possibly for a better location identification.

 

[leejor]

As has been mentioned, normally, when blocking your caller ID, you are not blocking the sending of a caller ID, you are telling your provider to withhold the number. On calls to a "normal" number, this will be honoured. In North America, at least, this causes the final provider to send a code that tells the caller ID device to display "Private", or something to that effect.

Because the majority of providers these days will not even allow calls to proceed without a caller ID, it is very difficult if not impossible to place a call that has no number attached to it. You instead send that code, saying that you don't want you number displayed, as is happening. On emergency calls, and calls to numbers such as Toll Free numbers, it should be ignored, and the number passed on, you don't get a choice.

Have you actually confirmed with emergency services that they are not receiving a number when using the *5 prefix?

 

[Kevin Attard Compagno]

You can also check exactly what is being sent to the provider from the activity log in verbose mode, though the provider should be able to share that with you also while troubleshooting this sort of thing.

 

[mls.nicolas]

As has been mentioned, normally, when blocking your caller ID, you are not blocking the sending of a caller ID, you are telling your provider to withhold the number. On calls to a "normal" number, this will be honoured. In North America, at least, this causes the final provider to send a code that tells the caller ID device to display "Private", or something to that effect.

Because the majority of providers these days will not even allow calls to proceed without a caller ID, it is very difficult if not impossible to place a call that has no number attached to it. You instead send that code, saying that you don't want you number displayed, as is happening. On emergency calls, and calls to numbers such as Toll Free numbers, it should be ignored, and the number passed on, you don't get a choice.

Have you actually confirmed with emergency services that they are not receiving a number when using the *5 prefix?

As far as I understand 3CX's implementation, they do not use the Privacy: Id SIP header in outbound SIP INVITEs.
And I can't see any relevant setting in the SIP provider XML template.
3CX sets the From, Contact, and Remote-Party-ID SIP fields to anonymous.
Apparently, only the field P-Asserted-ID field is left untouched. But this field is not sent by default. Therefore all existing trunk would need to be recreated.

 

[Kevin Attard Compagno]

The doc here does talk about anonymous calling. Please check out the information there and see if it helps.

 

[mls.nicolas]

Hi @Kevin Attard Compagno
Thank you for the link, it resumes indeed what I've discovered and posted in this thread any in my last comment.
I think it's quite clear now that SIP trunks need the P-Asserted-ID SIP header to correctly support 3CX's implementation of Anonymous calling.