Overwriting P-Asserted-Identity on PJSIP trunk


(Gmjcv) #1

Hi,

My trunk-provider requires P-Asserted-Identity to be set on outgoing calls to one of the numbers that we have with them to bill the correct number regardless of outgoing caller-id.

I set this up with PJSIP and have “Send RPID/PAI” set to “Send P-Asserted-Identity header”. This works when a call has one of the called ids from this provider as it gets set to the same value as the outgoing caller id.
We have another number that we wish to set as the caller id, but since the number is not with this provider, we need to set the PAI to another value than the caller id and this I’m unsuccessful with.

This is the extensions_custom.conf that I tried using.

[set-pai-user1]
exten => s,1,Noop(entering user defined context custom-sip-header in extensions_custom.conf)
exten => s,n,Set(CALLERID(all)="Main Office" <XXXX>))
exten => s,n,GoSub(func-set-sipheader,s,1(P-Asserted-Identity,<sip:${FROMEXTEN}@YYYY.siptrunk.provider.net\;user=phone>))
exten => s,n,DumpChan()
exten => s,n,Return

The caller id gets set correct, however, it seems that the PAI header is overwritten by the Send PAI setting for the trunk and the PAI that is set is based on the caller id rathern than what I set in the custom extension. This results in the call being dropped by the provider.

DumpChan()
Info:
Name=               PJSIP/provider-00000050
Type=               PJSIP
UniqueID=           1615896806.80
LinkedID=           1615896806.80
CallerIDNum=        XXXX
CallerIDName=       Main Office
ConnectedLineIDNum= (N/A)
ConnectedLineIDName=(N/A)
DNIDDigits=         ZZZZ
RDNIS=              (N/A)
Parkinglot=         
Language=           en
State=              Ring (4)
Rings=              1
NativeFormat=       (alaw)
WriteFormat=        alaw
ReadFormat=         alaw
RawWriteFormat=     alaw
RawReadFormat=      alaw
WriteTranscode=     No 
ReadTranscode=      No 
1stFileDescriptor=  -1
Framesin=           0 
Framesout=          0 
TimetoHangup=       0
ElapsedTime=        0h0m0s
BridgeID=           (Not bridged)
Context=            set-pai-user1
Extension=          s
Priority=           6
CallGroup=          
PickupGroup=        
Application=        DumpChan
Data=               (Empty)
Blocking_in=        (Not Blocking)

Variables:
GOSUB_RETVAL=
~HASH~SIPHEADERS~P-Asserted-Identity~=<sip:BBBB@YYYY.siptrunk.provider.net;user=phone>
ARGC=0
CALLINGNUMPRES_SV=allowed_not_screened
CALLINGNAMEPRES_SV=allowed_not_screened
REVERSAL_REJECT=FALSE
MOHCLASS=oder18
CALLED_BLACKLIST=1
returnhere=1
FROMEXTEN=BBBB
REC_POLICY_MODE_SAVE=
MON_FMT=wav
TIMESTR=20210316-131326
YEAR=2021
MONTH=03
DAY=16
NOW=1615896806
REC_STATUS=INITIALIZED
FROM_DID=ZZZZ
DIRECTION=INBOUND
SIP-invite
INVITE sip:ZZZZZ@1.1.1.1;user=phone SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5060;rport;branch=z9hG4bKPj48859a4d-135b-47f1-943b-c7df2325dc54
From: "Main Office" <sip:XXXXXX@YYYY.siptrunk.provider.net;user=phone>;tag=518e0300-0e4e-4524-9b40-c96981dbcb53
To: <sip:ZZZZZ@1.1.1.1;user=phone>
Contact: <sip:asterisk@2.2.2.2:5060>
Call-ID: 6e5e392a-c8ec-4fd1-b226-94035049120c
CSeq: 9409 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: "Main Office" <sip:XXXXXX@YYYY.siptrunk.provider.net;user=phone>
Max-Forwards: 70
User-Agent: FPBX-15.0.17.24(16.15.1)
Content-Type: application/sdp
Content-Length:   313

I also tried adding a “[macro-dialout-trunk-predial-hook]” to the extensions_custom with the PAI rewrite, even though I had read that macros no longer exist, but as excpeted this didn’t work either.

Does anyone have a suggestion on how I could solve this?
Thanks!


#2

With Send RPID/PAI off in the trunk setting, try this, not tested:

[macro-dialout-trunk-predial-hook]
exten => s,1,Noop(Adding PAI)
exten => s,n,GoSub(func-set-sipheader,s,1(P-Asserted-Identity,<sip:XXXXXX@YYYY.siptrunk.provider.net\;user=phone>))
exten => s,n,MacroExit()

If no luck, report whether macro got executed and whether header got added to INVITE.


(Simon Telephonics) #3

Why not set the trunk caller ID to what you want in the PAI header and then force it in the trunk settings? What am I missing?

Is the provider delivering some other field to the far end as caller ID? Normally they would deliver PAI to the far end as caller ID.


#4

Some providers (including, I assume, the OP’s) have it backwards and want the caller ID to be sent in From and the pilot number in PAI. You could certainly have trunk settings that force the pilot number in PAI, but you would still need custom dial plan to set From. Six of one, half a dozen of the other.


(Simon Telephonics) #5

RFC 3325 and update RFC 5876 are not exactly leisure reading but they seem to make it clear that PAI is for caller identity purposes. Billing ID should come from the auth user in a 401 challenge or From header.


(Lorne Gaetz) #6

@Stewart1’s macro should work, but make sure to disable PAI for the trunk or it will be added 2x and prob not work as expected.


(Gmjcv) #7

Thanks, seems to be working! Now I just need to set up a route for some incoming calls to be treated as internal to get the macro to execute.


(Gmjcv) #8

In this case certain users/numbers are flat rate and they identify this through PAI. So if I set my PAI and make a call, regardless of caller id used, it’s included in the monthly fee. If I set it to another PAI (still a user with them), I’ll get billed per minute. Both the monthly flat rate users and per minute charges then get added up and invoiced together.


(Simon Telephonics) #9

What field contains the caller ID, then? From?


(Gmjcv) #10

Yes, here is the text from the implementation document from the provider.

"P-Asserted-Identity" Header Field
The SIP-PBX MUST include a “P-Asserted-Identity” header field in the INVITE request in
accordance with the rules of [RFC 3325] and [RFC 5876]. The URI MUST be an identity
assigned to the SIP trunk.

”From” Header Field
The SIP-PBX MUST populate the ”From” header field URI with a URI that the SIP PBX
wishes to be used for caller identification. This may be an Enterprise Public Identity, an
anonymous URI or a SIP that the SIP-PBX has received from an entity behind the SIP-
PBX.

Example:
From: sip:+46772252525@<companyX>.siptrunk.provider.net

In cases where the Enterprise Network needs to generate an anonymous URI on behalf
of a caller (as opposed to passing on a received anonymous URI), the SIP-PBX MUST
send a URI of the form
sip:anonymous@anonymous.invalid

”Privacy” Header Field
If the SIP-PBX requires privacy for a call by suppressing delivery of caller identity to
downstream entities, it MUST include a ”Privacy” header field with value ’id’ in the
INVITE request, in addition to providing an anonymous ”From” header field URI as
specified above.
When privacy is required screening will be based on the P-Asserted-Identity header,
i.e. that header MUST contain a valid trunk user.