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

[Richard Mudgett]

> Revisiting this old thread, following Richard's suggestion, I modified
> Asterisk config so that it would set RDNIS for every forwarded call.
> 
> I kept at hand, the results gathered in another test session :
> the output of a "successful" call (with appropriate CallerID) and the
> output of an unsuccessful one.
> 
> 
> 2011/11/8 Olivier < oza_4h07 at yahoo.fr >
> 
> 
> Hi,
> 
> 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
> 
> 
> 
> Regards
> 
> 
> From another unsuccessful try, I got the following (anonymized)
> output:
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Calling Number (len=13)
> [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan
> (E.164/E.163) (1)
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Presentation:
> Presentation allowed of network provided number (3) '95135XXXX' ]
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > [70 0b 80 30 36 37 31
> 30 XX XX XX XX XX]
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Called Number (len=13)
> [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
> '06710XXXXX' ]
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > [74 0e 21 01 8f 33 33
> 33 34 34 33 XX XX XX XX XX]
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Redirecting Number
> (len=16) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony
> Numbering Plan (E.164/E.163) (1)
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c:
> > Ext: 0 Presentation: Presentation permitted, user number passed
> > network screening (1)
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c:
> > Ext: 1 Reason: Forwarded unconditionally (15)
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: '333443XXXXX' ]
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > [a1]
> [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Sending Complete (len=
> 1)
> 
> 1. Am I correct not seeing any meaningful difference with the
> successful one above ?

I don't see any meaningful differences with what you have shown.

> 
> From this, I would conclude by:
> A. either, there is a bug in libpri/dahdi as though pri debug shows 2
> calls are treated the same (ie 2 different calls print the same
> output), in fact there is still a difference between them and this
> difference, in this specific case, change the way the CallerID is
> presented (for that I've got an pri intensive debug record at hand).
> B. either, the network behaves inconsistently : with the same input
> from Asterisk, it will either show or not show the CallerID though
> this data is passed to him.

I agree that the network appears to be handling the calls inconsitently.

> 2. As I'm not using latest libpri and dahdi versions, my plan is to
> update to 1.4.12 and 2.5.0.2 without changing my asterisk 1.6.1.18
> version and try again.
> Any comment on that particular mix ?

I don't see any problems with upgrading those components.

Libpri 1.4.12 is backward compatible with earlier versions.  The API
changes are for feature additions and not for changes in existing
behavior.

> 
> 
> 3. I don't believe much in alternative A.
> What do you think ?
> Suggestions are welcome.

You should consider upgrading to Asterisk v1.8 so you can take advantage
of the many ISDN supplementary services implemented since v1.6.1.

Richard