[asterisk-users] trust_id_inbound=yes but take CallerID(Num) from From: not from PAI

[Joshua C. Colp]

On Tue, Nov 19, 2019 at 10:52 AM Benoit Panizzon <benoit.panizzon at imp.ch>
wrote:

> Hi Gang
>
> Next Problem which occurs.
>
> In Switzerland this is the common using form SIP Signaling:
>
> P-Asserted-Identity: Contains the provider provided and screened phone
> number which is the 'legal' origin of the call. The origin which is to
> be billed for the call. If the caller has a DDI Range, this is mostly
> the main number of this range.
>
> From: can contain almost anything. It can be any phone number from a
> DDI range, or in a call forwarding scenario, the original calling
> number, or if the customer has a clip-no-screening agreement just any
> valid phone number he is entitled to send.
>
> Now for privacy to be correctly handled. I did this config:
>
> On the IC endpoint: trust_id_inbound=yes
>
> Without this, Callerid(num-pres) ist not set to 'prohib'
>
> On the Customer endpoint: trust_id_outbound=no
>
> This ensures, asterisk replacing the From header with 'anonymous'
> towards the customer if privacy is set.
>
> Unfortunately setting those variables also affect the way where the
> Callerid(num) variable is polulated from.
>
> If trust_id_inbound=yes, this is set from the PAI, which is not the
> phone I want to display to your customer.
>
> Is there a way to trust_id_inbound but still take Callerid(Num) from
> the From header?
>

No, there is a specific hardcoded preference order of PAI > RPID > From. It
doesn't take bits and pieces from different parts to construct the final
result. You'd have to see if you can do it in the dialplan using
PJSIP_HEADER, if not then likely code modifications would be required.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.sangoma.com & www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20191119/51be0950/attachment.html>