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

[Olivier]

Hello,

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
>