Extract information out of P-asserted-identity

Is there a system “variable” in Asterisk 16 where I can get just the phone number part of the P-Assserted_Identity? Or do I just need to do a string manipulation on ${SIP_HEADER(P-Asserted-Identity)}?

So for example, ${SIP_HEADER(P-Asserted-Identity)} would give me "XYZ sip:+17145551212@99.99.99.99:5060;user=phone

But I just want asterisk to return +17145551212, is there a system variable where I can get that already?

CallerID(num/name) would not do as it return what is in the “from” header which sometime is “fake”. From the carrier, in the “from” header it would show “anonymous”, but they put the “true” callerid in the p-asswerted-identity.

Thank you!

You do need to tell it to trust RPID first, then you can use CALLERID.

can you explain a bit more? What you mean by “tell it” to trust RPID? You mean in some asterisk config file?

You mean this? But it seems this is for remote party id and not P-Asserted-Identity

Asterisk SIP trustrpid

trustrpid

This defines whether or not Remote-Party-ID is trusted. It’s defined in http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt

Usage

The following summarises information taken from Part 2 of this May 2010 blog post, based on testing v1.6:
http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-1/
http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-2/

P-Asserted-Identity
Asterisk does nothing when it receives a P-Asserted-Identity header. It ignores it totally no matter what settings you use for “trustrpid” or “sendrpid”. It does not copy it from an inbound call leg to an outbound call leg for a bridged SIP-to-SIP call.

Remote-Party-ID
If you have set “sendrpid=yes” in the settings for the destination peer in sip.conf then Asterisk will always add an RPI header. Here is a typical example:

can someone be so kind as to tell me (I’ve searched google but couldn’t find anyting) how to “search” character in Asterisk?

I need to extract “+17145551212” from the string “XYZ sip:+17145551212@99.99.99.99:5060;user=phone”

I need to find string" sip:" and “@” in the string so I can substring to get the phone number.

Thank you!

There are many examples using CUT and SIP_HEADER() function

Also see the : operator in https://wiki.asterisk.org/wiki/display/AST/Operators

However, why do you need to do this? Asterisk does this automatically for the request URI, setting ${EXTEN}, and that is the only place where you should be getting that full syntax.

2010 is ancient history. The chan_sip driver, referred to, is now deprecated and had p-asserted-identity support added many years ago.

thank you ambiorixg12! I guess I didn’t read carefully enough. The CUT function is like a “split” funciton in .net. It will split string using a “delimiter”. So, yes, using that function I was able to extract the information from the p-assert string.

And to David, I can’t use EXTEN as exten is the DNIS (the TO header number). I need the FROM number. The reason I have to use p-assert is that because the Carrier (Verizon in this case), they pass the call to me that way. It is a toll free (8xx) inbound service to us. Normally 8xx they will ALWAYS show the “true” callerid, no matter if the guy have callerid block (out going) or not. In this particular case, Verizon send us the caller-id (the blocked) in the regular FROM header. Which sometime shows as “anonymous”. But I need the “true” caller-id which Verizon then put in the p-assert section of the INVITE. Thus I have to use SIP_HEADER(p-assert) function to get it.

Unless, of course, you know an easier way of doing this?

Thank you both!

As already pointed out, since about Asterisk 1.8, Asterisk will do this for you, as long as you enable trustrpid.

Ya, that was another thing I just tried to start to do. In my database that field was set to “null”, so I changed to “yes” now. I will just have to wait until I see anther “anonymous” call to verify.

Thank you very much for your help!

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