Forward original caller id to a external mobile

Hi mates.

I have an IVR with an option to send the call to a external mobile phone. The external mobile is a “Misc Destination” (but i don’t have problem to change it to another configuration)

The problem is that the external call is forwarded in the right way but the caller id is the number of my trunk, there is not the the external caller id.

How can i forward the right caller id?

Thanks you very much

This is going to become increasingly more difficult as STIR/SHAKEN is taken up globally. At best the number will end up marked as untrusted, with an implication of spam, and at worst, the mobile network will suppress the call, or only present the probably spam indication.

Eventually there will be mechanisms to forwards the digital signatures as well, but at the moment things are in a state of flux and you will have to consider how all the service providers involved handle STIR/SHAKEN.

I understand that i have to ask to the ISP about the trunk and if it is possible to send an external CID

But if it would be possible, what are the best way on FreePBX to make it possible?

Thanks you very much

Generally, with Asterisk, it is a question of stopping anything from changing the caller ID, as the default is to pass the caller ID through, although with trunks you may have to also specify an alternative to the From user as the caller ID mechanism, as From user tends to be used for your account name, and the new mechanism has to be supported by your provider. The available mechanisms are Remote-Party-ID, and P-Asserted-Identity.

You should look at the logs to see what caller ID FreePBX thinks it is using on the outbound leg, and use pjsip set logger on (etc.) to see what is being sent to the provider. You may find it is already being passed through.

FreePBX is not the problem. You can always write some custom code and set headers explicitly. First you need to find out what your service provider wants and, secondly, you need to consider in which country your are. Sometimes you can only switch a Caller ID within the set of numbers that have been assigned to you. Given the number of complaints in the US about telemarketers, I guess there are still no effective restrictions for service providers there.

SIP has no provisions for trunking (in den sense of bundling many channels), but there are the SIPconnect 2.0 recommendations. This gives you some idea what else you need to consider in addition to the Request URI and the To and From headers. There’s also a paragraph about handling forwarding new INVITEs (as opposed to forwarding without answering a call).

If you can manipulate the From header in a certain country and call a person in another country with stricter rules, you might get blocked in the future unless you are exactly following something like the SIPconnect rules. This is why you need to write some custom dialplans in some cases. I am not sure whether STIR/SHAKEN is really a good idea.

At least in the UK, the main demand for caller ID authentication relates to vishing fraud, rather than spam. Fraudsters are presenting legitimate bank and government phone numbers, and telling the victim to check them (although often they are incoming only numbers, but the victim doesn’t know that). The only case in which it relates to spam is when the spammer generates random, but plausible, phone numbers to get round caller ID blocking, but most of the post-STIR spam is, supposedly, presenting the true caller ID.

Are you saying that in the UK the service providers do not filter the From header for calls originating in their nets?

I think most of the bogus caller IDs originate from outside the UK and enter by non-IP means, although I’m not clear about the injection method. The UK seems to want to skip the SHAKEN part, and wait until the local loop has been replaced by IP, which was scheduled for 2025, but has been delayed because of concerns, amongst other things, of high risk customers with no alternative during a power failure.

If the bad calls originate from some other country, I don’t see how STIR is going to help. I guess there will always be small companies in poorer countries with extensive national rights that are willing to sell the lines + certificates in the future for a few extra bucks/quids/eurons.

If you set the Caller ID to something else in Germany, the telco will replace it with your default number. This has not changed since the days of ISDN, aka BRI P2P, BRI P2MP, PRI T1/E1. My assumption was so far that this is handled the same almost everywhere (including the US?), but that the regulations differ from country to country. AFAIK, replacing the caller ID in the United States is only punishable if it is done with fraudulent intent. This makes it relatively difficult for a callee in the United States and the problems seem to be more annoying there compared to European countries.

I see some fraudulent calls on the German lines that I have access to. The caller IDs do not change often and during the last 3 years they all came from a single provider, which sometimes can be detected by evaluating the complete From header. This could also indicate fraudulent employees, but I have nothing to prove such a thing. For some SIP products, the From header is not heavily manipulated and the original domain part is still present. I’d expect something like that in other countries.

In any case, up to now the rules were such that what came from other countries was largely taken over without being checked. I suspect that STIR supporters must hope for a placebo effect.

Hi mates,

I was talking to my ISP and they told me that have to make changes on the Trunk configuration.

Futhermore, they told me that I have to set my asterisk/freepbx to work with “Diversion”, my freepbx would send something like this:

Diversion: sip:[email protected];privacy=off;reason=no-answer;counter=1;screen=no

Can anyone explain how can i do that?

Thanks you very much

A small block of custom dialplan will do this, in it’s crudest form it will look like the below. Background reading: Hooking for fun and income

[macro-dialout-trunk-predial-hook]
exten => s,1,Noop(Entering user defined context macro-dialout-trunk-predial-hook)
exten => s,n,GoSub(func-set-sipheader,s,1(Diversion,sip:[email protected]\;privacy=off\;reason=no-answer\;counter=1\;screen=no))
exten => s,n,MacroExit()

You will prob need to substitute a channel variable in place of 911234567

Diversion is a header that Asterisk itself should manage, although I can’t guarantee that it will meet all the provider’s requirements. See:

https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information#ManipulatingPartyIDInformation-REDIRECTINGdialplanfunction

I’ve seen this particular back door to STIR/SHAKEN being mentioned on this forum several times, although I don’t really understand the trust model behind it. Someone with a a real world need for this really needs to look into whether the proper Asterisk way of setting Diversion can be made to work and try to get official FreePBX support.

It’s conceivable t me that some of the hard coded fields in the example may only be examples, e.g. is is possible that some providers will cope with multiple diversions and therefore counts other than on.

I have an option in my IVR that send a call to a external mobile. So i want that when an external call is calling to my freepbx and choose this option in the IVR the call is forwarded to the external mobile with the original calle ID (external call)

Do i have to add this code to cat /etc/asterisk/extensions_custom.conf ?

[macro-dialout-trunk-predial-hook]
exten => s,1,Noop(Entering user defined context macro-dialout-trunk-predial-hook)
exten => s,n,GoSub(func-set-sipheader,s,1(Diversion,sip:[email protected];privacy=off;reason=no-answer;counter=1;screen=no))
exten => s,n,MacroExit()

I have changed 911234567 by my trunk number.

Thanks you very much in advance

They told me that i have to modify in the FROM the SIP URI to put there the caller id.

How can i do that?

Thanks you very much in advance

That is the normal behaviour except when you are using the From header to authenticate yourself. What information in the INVITE is being used to authenticate you to the provider?

There are 3 numbers:

a) the external mobile number that calls to the freepbx: 6XXXXXXX7
b) the freepbx trunk mobile number that receive the call: 9XXXXXXX4
c) the external mobile that receive de call of A) trhough the freepbx b)

  1. a) calls to the Freepbx b).
  2. a) listen the IVR Message and press the option 8
  3. the call from a) is forwarded to c)

I attatch an image of the captured invite package

The a) number is variable

According to this, the From header does contain the number you are trying to forward, so you are meeting the provider’s constraint on that number. Providers seem to be improvising in how they handle STIR/SHAKEN and forwarded numbers, so there are no standards. That means that there is no specification for Asterisk to implement. However, you do seem to be doing what you have said your provider says you should do.

Although I don’t see how it relates to your issue, this is, almost certainly, wrong, and indicates your PABX is not correctly configured for use from behind NAT:

image

The address here should be your public IP address, which you should have configured in your SIP settings.

Actually, the fact that this is working at all may mean that your real issue lies with a router which is not handling the SIP transparently.

PS I still think you should use the Asterisk REDIRECTING function to create the Diversion header, although what is going out on the wire does meet the specification that you have quoted.

They told me that the problem is here, in the from

from

it would be in this case “sip:[email protected]:5051:>;tag=as13466f98b”

Whoops, I only checked the first instance on that line.

Please provide screen shots of your authentication options for the trunk and the pjsip.conf (or equivalent for any deprecated driver) customisation. Typically you will want IP authentication and must not have any from user setting.

As I’m not completely sure how the GUI maps to the actual configuration, it is best if you provide the configuration taken from the generated files, as well as the screen shots.

You should still fix the broken Contact header, or explain why you think it is not broken.

Hi @david55

Thanks you very much for trying to help me.

Here is the trunk configuration:

And the sip settings: