Headers of REGISTER message

Hello.
Softphones that we are using pass push notification tokens in REGISTER message.
Some of them pass those tokens as part of Contact header (according to RFC-i-forgot-its-number), and others pass in non-standard headers.

So to be able to send push notifications I have to be able to get headers of REGISTER message, parse them and extract notification tokens.

The question is: how to get those headers? Is it even possible with asterisk?

Is it RFC8599 related ? So may be accessible from PJSIP_CONTACT and then PJSIP_PARSE_URI functions ?

Is it RFC8599 related ?

Yes

So may be accessible from PJSIP_CONTACT

And how exactly?
According to the rfc, i need pn-prid, pn-provider and pn-param fields of contact header.

But there are no such options for PJSIP_CONTACT, at leaset so says the doc you linked

They are parts of the URI, so should be included in the contact value.

Maybe try something like this - substituting 1234 for your extension number Contact AOR:

exten = s,n,Set(uri=${PJSIP_CONTACT(1234,uri)})
exten = s,n,Set(uripart=${CUT(uri,;,2)})
exten = s,n,Set(uripartkey=${CUT(uripart,=,1)})
exten = s,n,Set(uripartvalue=${CUT(uripart,=,2)})
exten = s,n,Set(pnprovider=${IF($["${uripartkey}"="pn-provider"]?${uripartvalue})})

Following this thread out of interest. I am a bit confused now.

Can we really react on REGISTER requests in the dialplan? Never heard of it in all these years.

You can’t react on REGISTER requests in the dialplan. Calls can query some information about registrations.

That’s what I thought.
So I don’t see any chance here without modifying the code. No chance to do something with non standard headers of register messages and approaches in the dialplan to catch something of the contact URI will only look at the contact URI of the invite, not of the register.

The PJSIP_CONTACT dialplan function is for accessing contacts on an AOR from a registration.

Ah, now I see. Thank you so much.
But still I don’t see a chance for non standard headers.

According to the RFC, they are URI parameters, not headers, and are therefore part of the contact value.

I just mentioned headers because the threadstarter was talking about

Putting this together a little more, showing the parsing works, and moving closer to answering OP’s question - using a new patch submitted to sipp-scenarios, and this dialplan snippet (cleans up earlier exploratory dialplan post above - change 7004 to your extension number):

exten = 8599,1,NoOp(RFC 8599 parsing example - assumes max_contacts=1)
 same = n,Set(aor=${PJSIP_AOR(7004,contact)})
 same = n,Set(uri=${PJSIP_CONTACT(${aor},uri)})
 same = n,Set(uripart=${CUT(uri,\;,2)})
 same = n,Set(uripartkey=${CUT(uripart,=,1)})
 same = n,Set(uripartvalue=${CUT(uripart,=,2)})
 same = n,Set(pnprovider=${IF($["${uripartkey}"="pn-provider"]?${uripartvalue})})

SIPp command line invocation (adjust register_data.csv to your setup ie. change user/pass):

$ sipp -inf register_data.csv -sf sipp_uac_register_pns_push.xml 127.0.0.1

What the REGISTER sent by SIPp looks like:

[2024-07-16 12:50:56] VERBOSE[5595] res_pjsip_logger.c: <--- Received SIP request (371 bytes) from UDP:127.0.0.1:5061 --->
REGISTER sip:pbxi SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5061;branch=z9hG4bK-9861-1-0
Max-Forwards: 70
From: "sipp" <sip:7004@pbxi>;tag=1
To: "sipp" <sip:7004@pbxi>
Call-ID: reg///1-9861@127.0.0.1
CSeq: 7 REGISTER
Contact: <sip:sipp@127.0.0.1:5061;pn-provider=acme;pn-param=acme-param;pn-prid=acme-psn-user-7004>
Expires: 3600
Content-Length: 0
User-Agent: SIPp

Dialing 8599 from another phone then produces:

    -- Executing [8599@from-internal:1] NoOp("PJSIP/7003-0000000c", "RFC 8599 parsing example - assumes max_contacts=1") in new stack                                                          
    -- Executing [8599@from-internal:2] Set("PJSIP/7003-0000000c", "aor=7004;@7444807a64c52983b9ec8140711787ce") in new stack                                                                  
    -- Executing [8599@from-internal:3] Set("PJSIP/7003-0000000c", "uri=sip:sipp@127.0.0.1:5061;pn-provider=acme;pn-param=acme-param;pn-prid=acme-psn-user-7004") in new stack                 
    -- Executing [8599@from-internal:4] Set("PJSIP/7003-0000000c", "uripart=pn-provider=acme") in new stack                                                                                    
    -- Executing [8599@from-internal:5] Set("PJSIP/7003-0000000c", "uripartkey=pn-provider") in new stack
    -- Executing [8599@from-internal:6] Set("PJSIP/7003-0000000c", "uripartvalue=acme") in new stack                                                                                           
    -- Executing [8599@from-internal:7] Set("PJSIP/7003-0000000c", "pnprovider=acme") in new stack                                                                                             
    -- Executing [8599@from-internal:8] Hangup("PJSIP/7003-0000000c", "") in new stack         

HOWEVER, nothing special is being done by Asterisk, ie. no Push Notification Server functionality, but that is somewhat outside the scope of the RFC in question anyhow. You might be able to work something up with dialplan hints and a SIP SUBSCRIPTION from a minimalist UA (based on SIPp ?), or spool call file jobs from cron to an extension like 8599 above, or use AMI to watch for interesting things and react appropriately, etc.