Can I disable P-Asserted-Identity in dialplan dynamically to affect only current call?

Asterisk Asterisk SIP
1

I recently upgraded from Asterisk 14 to Asterisk 16 and now certain calls seem to experience undesired P-Asserted-Identity updates where I don’t think they were previously.

SUMMARY OF MY QUESTION: Why is Asterisk updating the Caller’s Caller ID with 0000000141 that resulted from a simple Goto() ? I understand the rationale of ${EXTEN} having a correlation to Caller ID but it doesn’t seem to make sense for Asterisk to arbitrarily update Caller ID when a Goto() sends a call somewhere in the dialplan.

My PJSIP endpoints are configured with P-Asserted-Identity (PAI) so that when callers dial local telephone numbers not leaving the system, Asterisk connects to the other user by way of a MySQL table that maps the number to the other user’s device ID. Asterisk dials the other user’s device (endpoint) and when the other user answers, Asterisk will nicely send a SIP message with PAI back to the caller so that the caller can see the answering user’s Caller ID name & number (the ones associated with their callee’s endpoint). I believe the PJSIP endpoint option I’m referring to is send_pai=true.

But my Asterisk is configured with certain other types of menu-driven calls where the caller dials a special telephone number and my dialplan uses Goto() to process the call on a different/special calling context. The special context associated with the menu will generally Dial the user to various outside telephone numbers depending on what menu option they chose. What I am observing is that the moment Asterisk dialplan flow hits the new context, the caller’s display is updated with Caller ID information wiping out the dialed number and replacing it with the internal routing number from the dialplan that I don’t want the caller to see.

Is there a way to suppress Caller-ID updates in my special context such that it disables PAI for the current call only? I don’t want to lose the PAI updates for the calling endpoint on future calling activity, only the current all being processed by my special context. I am familiar with the CHANNEL(pjsip) function and the PJSIP_ENDPOINT(name,field) function but these only seem to be read only, and even if these functions allowed write for send_pai=false I would be afraid such a function call would alter the setting of the endpoint itself and not the dynamic channel-related setting for PAI.

For illustration on my issue, here is a snippet of CLI output of a call where Asterisk updated the Caller ID to 0000000141, wiping out from the display the actual telephone number dialed into my IVR menu. So basically the caller dials 18009876543 (not the real number, by the way) and that number remains in his phone’s display during his navigation of IVR, but after pressing option “1” Asterisk updates his display to 0000000141 which is the place Goto() sent the call for further dialplan processing. I don’t want Asterisk to wipe out the 18009876543 number that the caller dialed in this instance.

– Executing [18009876543@pspp-program:164] ExecIf(“PJSIP/javauser-00012e0b”, “1?Set(ACD_args=ACD,solucion,1,000000014)”) in new stack
– Executing [18009876543@pspp-program:165] ExecIf(“PJSIP/javauser-00012e0b”, “1?Goto(ACD_inbound,s,1)”) in new stack
– Goto (ACD_inbound,s,1)
– Executing [s@ACD_inbound:1] Playback(“PJSIP/javauser-00012e0b”, “ACD_soluciongreeting”) in new stack
– <PJSIP/javauser-00012e0b> Playing ‘ACD_soluciongreeting.slin’ (language ‘en’)
– Executing [s@ACD_inbound:2] Read(“PJSIP/javauser-00012e0b”, “DigitReceived,ACD_solucionmenu,1,0.3”) in new stack
– Accepting a maximum of 1 digits.
– <PJSIP/javauser-00012e0b> Playing ‘ACD_solucionmenu.slin’ (language ‘en’)
– User entered ‘1’
– Executing [s@ACD_inbound:3] GotoIf(“PJSIP/javauser-00012e0b”, “1?pspp-program,0000000141,1”) in new stack
– Goto (pspp-program,0000000141,1)
– Executing [0000000141@pspp-program:1] Set(“PJSIP/javauser-00012e0b”, “vzrouteused=0”) in new stack
.
. (much other dialplan logic)
.
Dial(PJSIP/outsidenum@outsideroute)

Why is Asterisk updating the Caller’s Caller ID with 0000000141 that resulted from a simple Goto() ?

2

Please provide evidence that this is happening, as I don’t think it should happen, and can’t see how the channel driver would even know that that number was relevant.

3

Hi

I am experiencing the exact same issue, also with PJSIP if that’s important. I am upgrading an Asterisk 11 box to 16 using the latest packages from Debian Buster - so that’s 16.2.1 at the moment.

PAI is configured on my phones to correctly see who answered a call.

When I place an outgoing call, I catch the dialed number and jump to a different context that handles some pre-processing (in my case it sets the Caller ID of the outgoing call, which passes through my trunk provider to the PSTN):

exten => _90[1-9].,1,Gosub(dial_trunk,s,1(${EXTEN:1},${EXT_CID}))

As you can see, now instead of dialing the original number, I’ve passed that as an arg to the actual dialing context and am hitting that at extension s.

[dial_trunk]
exten => s,1,Set(CALLERID(all)="${ARG2}" <${ARG2}>)
exten => s,2,Verbose("Dialling ${ARG1} (from ${ARG2})")
exten => s,3,Dial(PJSIP/${ARG1}@my_external_trunk)

In the SIP 180 Ringing response to the Dial command, I see Asterisk is sending the phone a PAI update with “s” as the other party - this seems only to be coming from the dialplan extension I GoSub’d to:

ast%20pai%20wrong%201
ast pai wrong 1.png938×285 20.9 KB

So in this case, just like the original poster above, I also either want to inhibit the sending of PAI back to the phone for this call, or fix this behaviour so Asterisk doesn’t send a PAI of “s”.

I suppose, in my case, I could adjust the dialplan to pattern match the external dialed number, but this behaviour did not happen under Asterisk 11 and chan_sip.

Thanks for any thoughts.
Giles.

4

Hi

I figured it out:

Firstly, as a workaround, I changed my diaplan so my trunk dialing context used an ‘any’ pattern match. This made Dial() send the PAI of the dialed number instead of “s”, which was better:

[dial_trunk]
exten => _X.,1,Verbose("Dialling ${EXTEN} via trunk (Dial function ${ARG1})")
exten => _X.,2,Dial(${ARG1})
exten => _X.,3,Goto(103)
;
; if a number is BUSY, indicate this rather than the generic CONGESTION error tone
exten => _X.,103,Verbose("Dialled number ${EXTEN} appears to be BUSY or call was rejected by the trunk")
exten => _X.,104,Busy()

But I still didn’t really like giving in to what Dial() wanted to do with the PAI, plus I was intrigued by the name element of the PAI, since my SIP phones display this. Could I send something useful back?

The answer turned out to be easy - and is mention in Manipulating Party ID Information. The CONNECTEDLINE function can be used to set up the channel variables so you can send anything you like as the PAI when Dial() sees it necessary to update the calling phone. Note Dial() needs the I flag to prevent it overriding your overrides.

My trunk dialing context now looks like:

[dial_trunk]
;
; Context to place a call to one of the provider trunks.
; Psuedo usage: Gosub(dial_trunk,DialledNumber,1(DialString))
;  DialString:          The command to pass to Dial()
;
exten => _X.,1,Verbose("Dialling ${EXTEN} via trunk (Dial function ${ARG1})")
; use CONNECTEDLINE to over-ride the PAI returned to the calling phone once Dial() executes
exten => _X.,2,Set(CONNECTEDLINE(name,i)=External)
exten => _X.,3,Set(CONNECTEDLINE(num)=${EXTEN})
; use I to inhibit Dial() changing the CONNECTEDLINE vars itself;
; yeah, by default it'd simply set the (num) to ${EXTEN} which is what I'm doing anyway, but nicer to have full control
exten => _X.,4,Dial(${ARG1},,I)
exten => _X.,5,Goto(104)
;
; if a number is BUSY, indicate this rather than the generic CONGESTION error tone
exten => _X.,104,Verbose("Dialled number ${EXTEN} appears to be BUSY or call was rejected by the trunk")
exten => _X.,105,Busy()

Now when I place an external call, my SIP phones neatly display “External” and the dialed number. Hope you find this useful.

Giles.

2 Likes