[asterisk-users] CallerID inconsistently presented through ISDN/cellular networks

Tue Nov 8 15:40:01 CST 2011

> > As promised, here is a follow up on my quest to get CallerID
> > correctly
> > presented when forwarding calls to cellphones.
> >
> > Here is a reminder of the issue at hand:
> >
> > Alice (GSM handset) calls Bob (ISDN-connected Asterisk extension)
> > which forwards to Cory (GSM handset)
> > What I would like to get is to see Alice's number (not Bob's number)
> > presented to Cory.
> > Sometimes, I get Alice's number, sometimes, I get Bob's number (new
> > findings from last sunday trials).
> > And of course, if Daniel or Eric would call Bob, the CallerID number
> > presented to Cory would either be Daniel's number, Eric's number or
> > Bob's number depending on a root cause I'm looking after for several
> > days now.
> >
> >
> >
> > To check if CallerID is filtered or controlled by Telco, I
> > originated
> > calls from Asterisk using hand crafted caller ids: any CallerID was
> > correctly presented.
> > So I originally thought the root cause I'm after is a telco
> > equipment
> > switching ANI and CID.
> > But a close look at some last trials output makes me asking for
> > opinions from this list readers.
> >
> > Here follows, the anonymized (and hand indented) output of command
> > PRI
> > debug command.
> > I focused on the end of call setup dialog.
> >
> > For the successfully presented call, the output is:
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [6c 0b 21 83 37 38
> > 36
> > XX XX XX XX XX XX]
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Calling Number
> > (len=13) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony
> > Numbering Plan (E.164/E.163) (1)
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Presentation:
> > Presentation allowed of network provided number (3) '78649XXXX' ]
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [70 0b 80 30 36 37
> > 31
> > XX XX XX XX XX XX]
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Called Number
> > (len=13)
> > [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
> > '067100XXXX' ]
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [74 0e 21 01 8f 33
> > 33
> > 33 34 34 XX XX XX XX XX XX]
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Redirecting Number
> > (len=16) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony
> > Numbering Plan (E.164/E.163) (1)
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 0 Presentation:
> > Presentation permitted, user number passed network screening (1)
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 1 Reason:
> > Forwarded unconditionally (15)
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: '3334436XXXX' ]
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [a1]
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Sending Complete
> > (len=
> > 1)
> >
> >
> > For the unsuccessfully presented call, the output is:
> > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [6c 0b 21 83 36 37
> > 38
> > XX XX XX XX XX XX]
> > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Calling Number
> > (len=13) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony
> > Numbering Plan (E.164/E.163) (1)
> > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Presentation:
> > Presentation allowed of network provided number (3) '67854XXXX' ]
> > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [70 0b 80 30 36 37
> > 31
> > XX XX XX XX XX XX]
> > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Called Number
> > (len=13)
> > [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
> > '067100XXXX' ]
> > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [a1]
> > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Sending Complete
> > (len=
> > 1)
> >
> >
> > Am I correctly interpreting when saying that in the successful call,
> > Asterisk is sending a [74 0e 21 01 8f 33 33 33 34 34 XX XX XX XX XX
> > XX] message which is not otherwise sent ?
> > What can explains this difference ?
> > Is this something I can (should) control ?
> >
> > For reference:
> > dahdi show version
> > DAHDI Version: SVN-trunk-r8853M Echo Canceller: OSLEC
> > pri show version
> > libpri version: 1.4.10.2
> 
> Improved support for manipulation of redirecting number is available
> with the REDIRECTING dialplan function in Asterisk v1.8.x and
> libpri v1.4.12. Prior to Asterisk v1.8.x you only have
> CALLERID(RDNIS).
> 
> https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
> 
> 
> Richard
> 
> 
> Hi Richard,
> 
> 1. Could you elaborate a bit ?
> Do you imply that the lines bellow were present (or missing) because I
> did somewhere set CALLERID(RDNIS) and that I should use them ?
> 
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Redirecting Number
> > (len=16) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony
> > Numbering Plan (E.164/E.163) (1)
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 0 Presentation:
> > Presentation permitted, user number passed network screening (1)
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 1 Reason:
> > Forwarded unconditionally (15)
> > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: '3334436XXXX' ]

No.  I was trying to say that the value in the redirecting ie is
controllable by setting/clearing the CALLERID(RDNIS) value.

> 2. More generally, if I may ask, how do you understand both outputs
> (from my previous post) ?

Since you are not changing the value of RDNIS, then the RDNIS value
came in from the telco.  The presence of the RDNIS value on the incoming
call implies that the call has already been redirected at least once.

The first example (working):
I am interpreting the numbers as belonging to:
Party A is the calling number
Unknown party or Party B is the redirecting number
Party C is the called number

The second example (not working):
I am interpreting the numbers as belonging to:
Party A?? is the calling number
     (guessing here.  It is either the calling number of the incoming
      call or your dialplan has set it with CALLERID(num).)
Party C is the called number

The information here suggests that you should try setting CALLERID(RDNIS) to
party B and dialing.  This would make the not working call look like the
working call for your call forwarding case.

Richard