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


#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.