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

Wed Nov 9 10:37:51 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
> 
> 
> 
> 
> 
> 
> Thanks for this enlightment.
> 
> I can confirm CALLERID(RDNIS) is not explicitely changed within the
> Asterisk server.
> The choosen format like 3334436XXXX is noticeable (the system is
> installed in France where numbers are in this +33(0)123456789 shape).
> 
> It seems that sometimes, calls come in with this CALLERID(RDNIS) value
> set and sometimes not, though all of them where direct.
> 
> I agree that setting CALLERID(RDNIS) myself is definitively worth
> trying.
> 
> 1. Would you expect CALLERID(RDNIS) to be implicitely changed within
> the Asterisk server ?
> This page ( http://www.voip-info.org/wiki/view/RDNIS ) suggest this to
> be true ("The Dial application also sets the RGN to the current
> extension") and suggest CALLERID(RDNIS) to be overwritten by Dial.

Asterisk will not normally change the RDNIS value received.  That web
page does not state why the dial application sets RDNIS which can be
confusing.  The only time RDNIS is set is if the outgoing call is itself
redirected/forwarded by the peer.  For Asterisk v1.6.1 the only channel
drivers that support this are SIP and skinny.

> 2. As I feel specically new to this RDNIS concept, how should I set
> CALLERID(RDNIS), before or after Answer() statement ?

It does not matter in this case.  Asterisk v1.6.1 will keep both legs
of the call anyway.

If you ultimately want to get the call entirely off of your Asterisk
server, you will need Asterisk v1.6.2 or later.  You would also need
libpri 1.4.12 to do this with ETSI(EuroISDN).  You would then use
the DAHDISendCallreroutingFacility application *before* you answer
the call to forward/deflect the incoming call back to the network.

Richard