SIP PAI sent to ITSP - extra informations rejected by ITSP

Hi there.

I’m using the following to add PAI information requested by my upstream provider:

exten => s,1,Noop(Entering user defined context macro-dialout-trunk-predial-hook in extensions_custom.conf)
exten => s,n,ExecIF($["${OUT_${DIAL_TRUNK}_SUFFIX}"!=""]?Set(trunk_name=${OUT_${DIAL_TRUNK}_SUFFIX}):Set(trunk_name=${OUT_${DIAL_TRUNK}}))
exten => s,n,Noop(Trunk Name: ${trunk_name})
exten => s,n,GoSubIf($["${trunk_name}"="SIP/TO-ITSP-PROVIDER"]?func-set-sipheader,s,1(P-Asserted-Identity: <sip:[email protected]>))
; add addn'l gosubif for each trunk needed
exten => s,n,MacroExit

Working almost fine as call placed to that provider includes the PAI header, but thee is some extra information into the PAI header of outbound calls:

From: <sip:[email protected]>
To: <sip:[email protected]>
User-Agent: FPBX-15.0.24(13.38.3)
P-Asserted-Identity: <sip:[email protected]>:3333333333

FreePBX is adding an extra : followed by the dialled number.

With that extra information sent, my upstream provider is returning a 400 Bad Request with
Error-Info: sip:3333333333@provider;cause=“[line 013] SIP syntax error”

I wanna to know how to remove the extra :3333333333


I presume this is a bug, but because you are using an end of life version of Asterisk, and, at least an old version of FreePBX, I’d suggest upgrading before you try to debug.

Otherwise, I think we would want verbosity 3 or more full logs to understand why the wrong value is being used.

Incidentally, is there a reason that you are manually setting this header, rather than using the send PAI functionality, for caller ID. Normally Asterisk, itself, owns this header.

This is incorrect syntax. The call needs to be func-set-sipheader,s,1(P-Asserted-Identity, <sip:[email protected]>) there needs to be two arguments as ARG1 = header name and ARG2 = value of header. Your current syntax is just sending P-Asserted-Identity: <sip:[email protected]> as ARG1 which is going to make an incorrect header



We want to be able to send calls with different callerIDs name and number over this trunk. Normally our provider will allow outbound calls only for DIDs that are part of its network, unless calls are authorized with a PAI that contains a predefined DID. If calls are containing that predefined DID in the PAI field, the provider SBCs will accept outbound calls with any callerIDs.


I’ve heard of that requirement, but PAI is supposed to be used in the opposite way. The asserted ID is supposed to be the one you got from upstream.

From the RFC:

The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication .

Not sure why you think it’s just only for upstreams.


Well… I’m just following my provider’s support team, as they asked me to send a valid PAI with a local DID so outbound calls from our equipment can be accepted on their end with any other CallerIDs. My understanding of the PAI SIP extension is that it can be used to provide a sort of “trustines” within a private network, such as between an ITSP and their customers.

Bingo !

Thanks Tom, working flawslessly.

1 Like

In the typical case it is the upstream one, as in the typical case Asterisk is the intermediary. PAI contains the true originator of the call, whereas From contains the identity of the immediate source, which is Asterisk. Asterisk own identity is not something that Asterisk would ever need to verify, so it makes no sense for that to be something that was verified by authentication.

What providers are doing is to make From: be the true originator, and PAI be that of the intermediary.

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