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

Wed Nov 9 11:42:15 CST 2011

2011/11/9 Richard Mudgett <rmudgett at digium.com>

> > > > 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.
>

OK : then I will try to set this value (and update voip-info.org)

>
> > 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
>

That's definitively worth to try.
I can't think of any use case but does this DAHDISendCallreroutingFacility
generates AMI events, for curiosity's sake ?

> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20111109/511d81d5/attachment.htm>