[Home]

Summary:ASTERISK-26698: PJSIP: PAI showing dial plan filters to customers
Reporter:Luke Escude (lukeescude)Labels:
Date Opened:2017-01-05 21:54:28.000-0600Date Closed:2017-01-16 15:39:56.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:
Versions:13.13.1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) CID_bug.pcap
Description:Occasionally (not all the time) when dialing out or picking up a parked call, the caller ID will no longer display the 10-digit phone number and name (if valid)... It will show the actual dial plan filters, like _1XXXXX.

I will attached a PCAP of the PAI header including the filter, as well as a console readout showing the dialplan execution in case my code is at fault.
Comments:By: Asterisk Team (asteriskteam) 2017-01-05 21:54:28.839-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Luke Escude (lukeescude) 2017-01-05 21:55:22.142-0600

PCAP with the PAI header showing the XXXX. filters

By: Luke Escude (lukeescude) 2017-01-05 21:55:58.679-0600

Console readout:
{noformat}
Executing [9794182768@from-internal:1] Goto("PJSIP/143-000001d0", "dial-out-143,9794182768,1") in new stack
  -- Goto (dial-out-143,9794182768,1)
  -- Executing [9794182768@dial-out-143:1] Set("PJSIP/143-000001d0", "temp=19794182768") in new stack
  -- Executing [9794182768@dial-out-143:2] Goto("PJSIP/143-000001d0", "_1XXXXXX.,modified") in new stack
  -- Goto (dial-out-143,_1XXXXXX.,2)
  -- Executing [_1XXXXXX.@dial-out-143:2] GotoIf("PJSIP/143-000001d0", "0?keepDir") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:3] Set("PJSIP/143-000001d0", "EXTEN=19794182768") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:4] Set("PJSIP/143-000001d0", "CDR(cdr_direction)=2") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:5] Set("PJSIP/143-000001d0", "CDR(cdr_outbound_dialed_phonenumber)=19794182768") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:6] Set("PJSIP/143-000001d0", "CDR(cdr_outbound_from_extension)=143") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:7] Set("PJSIP/143-000001d0", "CDR(cdr_application)=Outbound Dial") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:8] Set("PJSIP/143-000001d0", "CALLERID(all)="TB3 143" <9726001155>") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:9] Set("PJSIP/143-000001d0", "CDR(cdr_outbound_did)=9726001155") in new stack
  -- Executing [_1XXXXXX.@dial-out-143:10] Dial("PJSIP/143-000001d0", "PJSIP/flowroute/sip:123456*19794182768@sip.flowroute.com") in new stack
  -- Called PJSIP/flowroute/sip:123456*19794182768@sip.flowroute.com
  -- PJSIP/flowroute-000001d1 is ringing
     > 0x7fab00aee5e0 -- Probation passed - setting RTP source address to 74.120.95.196:19624
{noformat}


By: Rusty Newton (rnewton) 2017-01-12 19:04:54.462-0600

Pretty certain this is a dialplan issue and it has to do with how you have a Goto jumping straight to a pattern literally instead of an extension matched by a pattern.

However I wasn't able to reproduce it!

Please remove unnecessary bits from the dialplan and attach a sample dialplan that reproduces the issue simply.

In addition attach a debug log that includes a SIP trace. I'll add another comment with instructions.

By: Rusty Newton (rnewton) 2017-01-12 19:05:04.747-0600

We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information



By: Richard Mudgett (rmudgett) 2017-01-15 22:37:30.794-0600

This is not a bug.
{{Dial}} tries to *guess* what the outgoing Caller-ID should be if the channel driver does not supply it.  One of the sources of Caller-ID *is* the calling exten.  You should look at the documented {{Dial}} options.  The 'o' and 'u' options apply to outgoing Caller-ID and 'I' affects the reported connected line ID back to the caller.

Also you cannot {{Set}} the value of EXTEN.  EXTEN has a special built-in meaning that overrides any variable you try to set of the same name.  The CONTEXT, EXTEN, and PRIORITY values together specify the currently executing dialplan location.  To change the EXTEN value you need to {{Goto}} a new location.

For example:
{noformat}
exten = X!,1,NoOp(EXTEN is '${EXTEN}')
; Prepend 1800 to EXTEN by going to the next dialplan location.
same = n,Goto(1800${EXTEN},$[${PRIORITY}+1])
same = n,NoOp(Now EXTEN is '${EXTEN}')
{noformat}


By: Luke Escude (lukeescude) 2017-01-16 15:39:36.060-0600

You are correct, we were going directly to a pattern instead of simply depending on the pattern matching.

This has solved our problem. Thanks!