Passing information of P-Preferred-Identity Header from trunk inbound through asterisk to the extensions

I’ve set up a trunk connection between a LANCOM 1781VAW (branch office) and a FreePBX15 (headquater). The HQ authenticates inbound.
All Extensions can reach each other 1:1.
The problem is that the users in the headquater can only see the trunk name, when they are called by the branch office. That’s because of the FROM Header who has to contain the login username.
The LANCOM can pass the true caller by the P-Preferred-Identity Header. I thought a custom context would help, so I linked the trunk to from-trunk-internal:

[from-trunk-internal]
include => from-internal
exten => _X!,1,Set(CALLERID(num)=${SIP_HEADER(P-Preferred-Identity)})

The result is "blank"and the only thing which is displayed is the IP of the remote LANCOM. As I found out, this header seems not to be forwarded through asterisk!
I thought of preparing the SIP Packet on the trunk side and moving to another “free” header which is certainly passed thought to the extensions.
Has anybody got an idea how to transport the information in the P-Preferrred-Identity through asterisk and get the true CALLERID(num)?

Try for pjsip trunk:

[from-trunk-internal]
exten => _.,1,Set(CALLERID(num)=${CUT(CUT(PJSIP_HEADER(read,P-Preferred-Identity),@,1),:,2)}) 
exten => _.,n,Goto(from-internal,${EXTEN},1)

Or for chan_sip trunk:

[from-trunk-internal]
exten => _.,1,Set(CALLERID(num)=${CUT(CUT(SIP_HEADER(P-Preferred-Identity),@,1),:,2)}) 
exten => _.,n,Goto(from-internal,${EXTEN},1)

The above assumes that the header looks like
P-Preferred-Identity: <sip:[email protected]>
and you want to set CALLERID(num) to 1234.

If no luck, post an incoming INVITE showing theP-Preferred-Identity header.

Thanks a lot! That did the trick. I completely forgot to mention that it was PJSIP :blush:

Can you not get them to use Remote-Party-ID or P-Asserted-Identity, both of which have built in support in Asterisk, although disabled by default.

I tried that all. BUT the LANCOM Callmanager has - in my opinion - a strange behavior. It’s OK and easy to set up for branch offices but it’s not super flexible like asterisk.
You can select “IETF-Draft-Sip-Privacy-04” as transmission method in the LANCOM Config, it creates a Remote-Party-ID Header, but this header contains the SIP-ID of the trunk, not from the extension.
Only option RFC3325 creates a P-Preferrend identity header with the calling extension (and not the SIP-ID of the trunk). Maybe it’s a bug, I thought the extension would be transmitted with both options and it changes only the header format…
PAI is possible, but the LANCOM can only get the authenticating Trunk SIP ID into this field, not the calling extension.
So the PPI was the only option and as Steward1 showed it is available for processing… I didn’t know that there is a difference between PJSIP and CHAN, so I thought it wouldn’t be available.

Now I have found the combination of setting in the LANCOM configuration which creates the PAI header containing the source extension not the SIP-ID of the trunk.

You are right, that’s the far better way to get the real caller over the trunk.
Asterisk fills the FROM field with the PAI when a packet is comming inbound, so the trunk name in FROM is eliminated. That makes the connection 100% transparent.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.