<br><br><div class="gmail_quote">2011/11/9 Richard Mudgett <span dir="ltr"><<a href="mailto:rmudgett@digium.com">rmudgett@digium.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">> > > As promised, here is a follow up on my quest to get CallerID<br>
> > > correctly<br>
> > > presented when forwarding calls to cellphones.<br>
> > ><br>
> > > Here is a reminder of the issue at hand:<br>
> > ><br>
> > > Alice (GSM handset) calls Bob (ISDN-connected Asterisk extension)<br>
> > > which forwards to Cory (GSM handset)<br>
> > > What I would like to get is to see Alice's number (not Bob's<br>
> > > number)<br>
> > > presented to Cory.<br>
> > > Sometimes, I get Alice's number, sometimes, I get Bob's number<br>
> > > (new<br>
> > > findings from last sunday trials).<br>
> > > And of course, if Daniel or Eric would call Bob, the CallerID<br>
> > > number<br>
> > > presented to Cory would either be Daniel's number, Eric's number<br>
> > > or<br>
> > > Bob's number depending on a root cause I'm looking after for<br>
> > > several<br>
> > > days now.<br>
> > ><br>
> > ><br>
> > ><br>
> > > To check if CallerID is filtered or controlled by Telco, I<br>
> > > originated<br>
> > > calls from Asterisk using hand crafted caller ids: any CallerID<br>
> > > was<br>
> > > correctly presented.<br>
> > > So I originally thought the root cause I'm after is a telco<br>
> > > equipment<br>
> > > switching ANI and CID.<br>
> > > But a close look at some last trials output makes me asking for<br>
> > > opinions from this list readers.<br>
> > ><br>
> > > Here follows, the anonymized (and hand indented) output of command<br>
> > > PRI<br>
> > > debug command.<br>
> > > I focused on the end of call setup dialog.<br>
> > ><br>
> > > For the successfully presented call, the output is:<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [6c 0b 21 83 37 38<br>
> > > 36<br>
> > > XX XX XX XX XX XX]<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Calling Number<br>
> > > (len=13) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony<br>
> > > Numbering Plan (E.164/E.163) (1)<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Presentation:<br>
> > > Presentation allowed of network provided number (3) '78649XXXX' ]<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [70 0b 80 30 36 37<br>
> > > 31<br>
> > > XX XX XX XX XX XX]<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Called Number<br>
> > > (len=13)<br>
> > > [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)<br>
> > > '067100XXXX' ]<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [74 0e 21 01 8f 33<br>
> > > 33<br>
> > > 33 34 34 XX XX XX XX XX XX]<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Redirecting Number<br>
> > > (len=16) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony<br>
> > > Numbering Plan (E.164/E.163) (1)<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 0<br>
> > > Presentation:<br>
> > > Presentation permitted, user number passed network screening (1)<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 1 Reason:<br>
> > > Forwarded unconditionally (15)<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: '3334436XXXX' ]<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [a1]<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Sending Complete<br>
> > > (len=<br>
> > > 1)<br>
> > ><br>
> > ><br>
> > > For the unsuccessfully presented call, the output is:<br>
> > > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [6c 0b 21 83 36 37<br>
> > > 38<br>
> > > XX XX XX XX XX XX]<br>
> > > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Calling Number<br>
> > > (len=13) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony<br>
> > > Numbering Plan (E.164/E.163) (1)<br>
> > > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Presentation:<br>
> > > Presentation allowed of network provided number (3) '67854XXXX' ]<br>
> > > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [70 0b 80 30 36 37<br>
> > > 31<br>
> > > XX XX XX XX XX XX]<br>
> > > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Called Number<br>
> > > (len=13)<br>
> > > [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)<br>
> > > '067100XXXX' ]<br>
> > > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [a1]<br>
> > > [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Sending Complete<br>
> > > (len=<br>
> > > 1)<br>
> > ><br>
> > ><br>
> > > Am I correctly interpreting when saying that in the successful<br>
> > > call,<br>
> > > Asterisk is sending a [74 0e 21 01 8f 33 33 33 34 34 XX XX XX XX<br>
> > > XX<br>
> > > XX] message which is not otherwise sent ?<br>
> > > What can explains this difference ?<br>
> > > Is this something I can (should) control ?<br>
> > ><br>
> > > For reference:<br>
> > > dahdi show version<br>
> > > DAHDI Version: SVN-trunk-r8853M Echo Canceller: OSLEC<br>
> > > pri show version<br>
> > > libpri version: 1.4.10.2<br>
> ><br>
> > Improved support for manipulation of redirecting number is available<br>
> > with the REDIRECTING dialplan function in Asterisk v1.8.x and<br>
> > libpri v1.4.12. Prior to Asterisk v1.8.x you only have<br>
> > CALLERID(RDNIS).<br>
> ><br>
> > <a href="https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information</a><br>
> ><br>
> ><br>
> > Richard<br>
> ><br>
> ><br>
> > Hi Richard,<br>
> ><br>
> > 1. Could you elaborate a bit ?<br>
> > Do you imply that the lines bellow were present (or missing) because<br>
> > I<br>
> > did somewhere set CALLERID(RDNIS) and that I should use them ?<br>
> ><br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Redirecting Number<br>
> > > (len=16) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony<br>
> > > Numbering Plan (E.164/E.163) (1)<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 0<br>
> > > Presentation:<br>
> > > Presentation permitted, user number passed network screening (1)<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Ext: 1 Reason:<br>
> > > Forwarded unconditionally (15)<br>
> > > [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: '3334436XXXX' ]<br>
><br>
> No. I was trying to say that the value in the redirecting ie is<br>
> controllable by setting/clearing the CALLERID(RDNIS) value.<br>
><br>
><br>
> > 2. More generally, if I may ask, how do you understand both outputs<br>
> > (from my previous post) ?<br>
><br>
> Since you are not changing the value of RDNIS, then the RDNIS value<br>
> came in from the telco. The presence of the RDNIS value on the<br>
> incoming<br>
> call implies that the call has already been redirected at least once.<br>
><br>
> The first example (working):<br>
> I am interpreting the numbers as belonging to:<br>
> Party A is the calling number<br>
> Unknown party or Party B is the redirecting number<br>
> Party C is the called number<br>
><br>
> The second example (not working):<br>
> I am interpreting the numbers as belonging to:<br>
> Party A?? is the calling number<br>
> (guessing here. It is either the calling number of the incoming<br>
> call or your dialplan has set it with CALLERID(num).)<br>
> Party C is the called number<br>
><br>
> The information here suggests that you should try setting<br>
> CALLERID(RDNIS) to<br>
> party B and dialing. This would make the not working call look like<br>
> the<br>
> working call for your call forwarding case.<br>
><br>
> Richard<br>
><br>
><br>
><br>
><br>
><br>
><br>
> Thanks for this enlightment.<br>
><br>
> I can confirm CALLERID(RDNIS) is not explicitely changed within the<br>
> Asterisk server.<br>
> The choosen format like 3334436XXXX is noticeable (the system is<br>
> installed in France where numbers are in this <a href="tel:%2B33%280%29123456789" value="+33123456789">+33(0)123456789</a> shape).<br>
><br>
> It seems that sometimes, calls come in with this CALLERID(RDNIS) value<br>
> set and sometimes not, though all of them where direct.<br>
><br>
> I agree that setting CALLERID(RDNIS) myself is definitively worth<br>
> trying.<br>
><br>
> 1. Would you expect CALLERID(RDNIS) to be implicitely changed within<br>
> the Asterisk server ?<br>
</div></div>> This page ( <a href="http://www.voip-info.org/wiki/view/RDNIS" target="_blank">http://www.voip-info.org/wiki/view/RDNIS</a> ) suggest this to<br>
<div class="im">> be true ("The Dial application also sets the RGN to the current<br>
> extension") and suggest CALLERID(RDNIS) to be overwritten by Dial.<br>
<br>
</div>Asterisk will not normally change the RDNIS value received. That web<br>
page does not state why the dial application sets RDNIS which can be<br>
confusing. The only time RDNIS is set is if the outgoing call is itself<br>
redirected/forwarded by the peer. For Asterisk v1.6.1 the only channel<br>
drivers that support this are SIP and skinny.<br></blockquote><div><br>OK : then I will try to set this value (and update <a href="http://voip-info.org">voip-info.org</a>) <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> 2. As I feel specically new to this RDNIS concept, how should I set<br>
> CALLERID(RDNIS), before or after Answer() statement ?<br>
<br>
</div>It does not matter in this case. Asterisk v1.6.1 will keep both legs<br>
of the call anyway.<br>
<br>
If you ultimately want to get the call entirely off of your Asterisk<br>
server, you will need Asterisk v1.6.2 or later. You would also need<br>
libpri 1.4.12 to do this with ETSI(EuroISDN). You would then use<br>
the DAHDISendCallreroutingFacility application *before* you answer<br>
the call to forward/deflect the incoming call back to the network.<br>
<div><div></div><div class="h5"><br>
Richard<br></div></div></blockquote><div><br>That's definitively worth to try.<br>I can't think of any use case but does this DAHDISendCallreroutingFacility generates AMI events, for curiosity's sake ?<br><br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5">
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br>