CallerId Presence Issue

Home » Asterisk Users » CallerId Presence Issue
Asterisk Users 3 Comments

Hi,

I’ve run into a minor snag trying to pass on CALLERID presence from one Asterisk to another via SIP (both running 13.16.0)

I have a PRI coming in PBX_A and PBX_A is connected to PBX_B via SIP. PBX_A gets PRI calls on a 4 port Digium card, and each call naturally has its own callerid values and presence. I pass on those calls to PBX_B via SI, and I’m trying to pass on this CALLERID info to PBX_B as well.

My relevant dialplan snippet on PBX_A is:

exten =>
1,1,Dial(SIP/pbx_b/5555555555,,f(${CALLERID(all)})u(${CALLERID(pres)})))

*the u() value being dynamically taken from the channel itself.

On pbx_b, I have a simply verbose line like this:

exten => 5555555555,1,Verbose(1,Presence information :
${CALLERID(num-pres)} – ${CALLERID(name-pres)} – ${CALLERPRES()})

Here is my experience with this: whenever “prohib_not_screened” (tested via a cell phone with hidden caller id info) is sent in the u() value of the Dial application, pbx_b always gets “allowed_not_screened” as presence state. Short version: the callerid presence seems lost on the SIP link. The callerid info isn’t, name and number are fine.

I’m clearly missing something to pass on the callerid presence state via the SIP link, but I can’t figure out what.

Any help or hint would be appreciated.

Michael

3 thoughts on - CallerId Presence Issue

  • Actually, a correction: the callerid isn’t passed on properly either: on SIP_B I get “Anonymous ” instead of ” <514-555-1234>” that my dial app is sending.

    The exact dial command that is used, once variables are evaluated, is this:

    Dial(SIP/pbx3/55555555555,,f(“” <5145551234>)u(prohib_not_screened))”

    While the log value found on the other end of the sip link are evaluated, I get this:

    Callerid name: Anonymous callerid number: number: anonymous Presence information : allowed_not_screened – allowed_not_screened –
    allowed_not_screened

    Somewhere in this Dial(SIP/) command callerid info is changed. An asterisk verbose check does not show me anything that would change callerid info.

    Mike

    From: asterisk-users-bounces@lists.digium.com
    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Mike Sent: June 14, 2017 10:18
    To: ‘Asterisk Users Mailing List – Non-Commercial Discussion’
    Subject: [asterisk-users] CallerId presence issue

    Hi,

    I’ve run into a minor snag trying to pass on CALLERID presence from one Asterisk to another via SIP (both running 13.16.0)

    I have a PRI coming in PBX_A and PBX_A is connected to PBX_B via SIP. PBX_A gets PRI calls on a 4 port Digium card, and each call naturally has its own callerid values and presence. I pass on those calls to PBX_B via SI, and I’m trying to pass on this CALLERID info to PBX_B as well.

    My relevant dialplan snippet on PBX_A is:

    exten =>
    1,1,Dial(SIP/pbx_b/5555555555,,f(${CALLERID(all)})u(${CALLERID(pres)})))

    *the u() value being dynamically taken from the channel itself.

    On pbx_b, I have a simply verbose line like this:

    exten => 5555555555,1,Verbose(1,Presence information :
    ${CALLERID(num-pres)} – ${CALLERID(name-pres)} – ${CALLERPRES()})

    Here is my experience with this: whenever “prohib_not_screened” (tested via a cell phone with hidden caller id info) is sent in the u() value of the Dial application, pbx_b always gets “allowed_not_screened” as presence state. Short version: the callerid presence seems lost on the SIP link. The callerid info isn’t, name and number are fine.

    I’m clearly missing something to pass on the callerid presence state via the SIP link, but I can’t figure out what.

    Any help or hint would be appreciated.

    Michael

  • Never heard of this method, are you sure this works for SIP, sound more like for ISDN (look at packet captures).

    But the/a standardized method is to use the P-Asserted-Identity and Privacy headers (rfc3325). This should work if you set in the peer configs in sip.conf on both sides:
    sendrpid=pai trustrpid=yes

    Or you can do header manipulation/getting/setting manualy if desired.

  • Thank you – At first glance it seems to have done the trick.

    Mike

    —–Original Message—

LEAVE A COMMENT