2011/11/9 Richard Mudgett <rmudg...@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 >
-- _____________________________________________________________________ -- 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