[Home]

Summary:ASTERISK-07584: [patch][post 1.4] make optional to strip the (inter)national prefixes when in "dynamic" (local)dialplan mode
Reporter:Stefano Brandimarte (stevens)Labels:
Date Opened:2006-08-23 08:01:26Date Closed:2007-02-26 18:11:37.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap+dialplan_autodetect_SVN.diff
( 1) chan_zap+dialplan_autodetect-SVN.diff
( 2) chan_zap+dialplan-autodetect.diff
( 3) chan_zap+stb2.diff
( 4) chan_zap+stb4.diff
Description:Italian TELCO (BT Albacom) requires to set the nationalprefix in front of the
called number, even when the TON is set correctly to "National"; so the patch
add two zapata.conf flags:

stripinternationalprefix
stripnationalprefix

leaving the default to true, so the normal asterisk behaviour isn't altered, to
let the user to choose if those prefixes are to be stripped or not, when one or
both the "dialplan" are set to dynamic.

****** STEPS TO REPRODUCE ******

zapata.conf:

pridialplan = dynamic
prilocaldialplan = national

nationalprefix = 0
internationalprefix = 00

outbound nationals calls are sent with the correct TON but without the prefix.
Comments:By: Serge Vecher (serge-v) 2006-08-23 09:00:39

can't you do this with some combination of dialplan magic?
By: Stefano Brandimarte (stevens) 2006-08-23 11:22:05

i'm not aware of any application/setting/parameter to change the call plan. It
could be great to be set at runtime, e.g. as app_dial parameter. But it's not,
and it seems that the chan_zap code doesn't allow to play with it:

if (strncmp(c + p->stripmsd, p->pri->internationalprefix, strlen(p->pri->internationalprefix)) == 0) {
     dp_strip = strlen(p->pri->internationalprefix);
     pridialplan = PRI_INTERNATIONAL_ISDN;
} else if (strncmp(c + p->stripmsd, p->pri->nationalprefix, strlen(p->pri->nationalprefix)) == 0) {
     dp_strip = strlen(p->pri->nationalprefix);
     pridialplan = PRI_NATIONAL_ISDN;
} else {
     pridialplan = PRI_LOCAL_ISDN;
}

the problem arises only when the dialplan is set to "dynamic"; in fact if we
set the (local)dialplan to "national" the prefix is always sent as part of the
ISDN negotiation. So there a mismatch between the way asterisk send the number
if the (local)dialplan is set as "dynamic" or otherwise.

My first patch, however, is incomplete; i'm sending an update.
By: Serge Vecher (serge-v) 2006-08-23 12:40:17

ok, being a new feature, the patch needs to be against trunk...
By: Stefano Brandimarte (stevens) 2006-08-23 14:06:17

latest patch is against SVN-trunk-r40928M
By: Serge Vecher (serge-v) 2006-08-23 14:45:22

thanks, stevens
By: Stefano Brandimarte (stevens) 2006-08-23 14:46:35

Please, look also at this report:

http://bugs.digium.com/view.php?id=5331

i think i could implement this patch as well, if You accept, in a single diff.
By: Serge Vecher (serge-v) 2006-08-23 15:18:07

I've reopened 5331, so you can attach your patch for that specific right there. Feel free to tackle any open or suspended bug out there ;) Just let me know (I'm either on #asterisk-bugs as serge-v or email svecher@kbsuits.com) ... Thanks.
By: jmls (jmls) 2006-11-20 11:49:23.000-0600

so, can this be closed ?
By: Stefano Brandimarte (stevens) 2006-11-20 13:13:56.000-0600

the bug could be closed if the patch could be applied to stock asterisk.
Otherwise the bug (lacks of feature) remains.
By: Serge Vecher (serge-v) 2006-11-21 09:44:30.000-0600

stevens: we need a confirmation from you that you have a disclaimer on file or have filed a disclaimer before we can proceed with merging this to trunk.
By: Stefano Brandimarte (stevens) 2006-11-21 10:21:21.000-0600

serge-v: disclaimer on file since aug.
By: Tilghman Lesher (tilghman) 2006-11-21 10:22:12.000-0600

This is exactly the purpose of dialplan=unknown.  Why not just use dialplan=unknown and be done with it?  No patch needed.


By: Stefano Brandimarte (stevens) 2006-11-21 10:31:37.000-0600

corydon, not at all, because pri(local)dialplan set also the TON and the NPI.
The TON and the NPI should remain untouched, instead.
By: Tilghman Lesher (tilghman) 2006-11-21 10:46:34.000-0600

So does setting dialplan=unknown not work?  I know there are telco facilities on this side of the Atlantic that simply ignore those fields, which is why "unknown" works.  What that does is to force the telco to interpret the number based upon the prefix of the number, rather than rely upon the TON field.

It sounds suspiciously like your telco is simply ignoring the contents of the TON field and routing purely upon the contents of the called number.
By: Stefano Brandimarte (stevens) 2006-11-21 10:51:20.000-0600

corydon, not at all again, the telco expects to receive a _correct_ TON . We've
debugged the call flow with their specialists and they _require_ to us to send
the _correct_ TON for national and international calls; otherwise the calls will
not be routed at all. So, the assertion that TON is rarely used doesn't apply to
us; furthermore commercial grade hw/sw set that field, why not asterisk ?
By: Tilghman Lesher (tilghman) 2006-11-21 11:38:47.000-0600

I'd prefer that you use a different pridialplan setting instead.  The problem with these options is that it's not at all clear that these are only applicable when pridialplan=dynamic and you really only need them one way or the other (in other words, there would never be a time when stripinternationalprefix=no and stripnationalprefix=yes).

I'd go with pridialplan=redundant, since that's how you're setting your flags and it's clearly not compatible with other telcos.
By: Stefano Brandimarte (stevens) 2006-11-21 13:07:01.000-0600

corydon, a different pri(local)dialplan value for cases like this is a valid
alternative that could be implemented instead of two config switches. Please
note also that, when the dialplan is set to "dynamic" ONLY (inter)national #s
are checked and stripped, so imho this is an inconsistency, because of there're
not only (inter)national prefixes to be set but also private and unknown. So,
another choice would be let the user to choose if she wants to strip the prefix
or leave it untouched, even if set (in order to allow TON auto-recognition), and
this should be true for all kind of prefixes.
So think over it another time and let me know what do You prefer; i'm ready to
adapt the little patch to smart suggestions to allow a clearer configuration.
By: Stefano Brandimarte (stevens) 2006-11-22 20:25:34.000-0600

patch added for asterisk 1.2.13; it implements a new pri(local)dialplan
definition: autodetect
that's the same as "dynamic" without stripping/adding the various prefixes set;
so the Type Of Number could be computed dynamically, based on prefixes and the
numbers remain untouched.
By: jmls (jmls) 2007-02-11 03:36:38.000-0600

Corydon76, are you still not happy with this patch ?
stevens, is the patch up to date for trunk ? As it's a new feature it would only be accepted in trunk once / if the patch is allowed in.
By: Stefano Brandimarte (stevens) 2007-02-14 10:25:41.000-0600

jmls: i'll update the latest patch shortly. Thanks for Your interest.
By: Stefano Brandimarte (stevens) 2007-02-26 16:03:17.000-0600

jmls: updated diff for SVN, version 56921M .
By: Tilghman Lesher (tilghman) 2007-02-26 16:08:28.000-0600

"autodetect" is fully inaccurate, though.  What you want it to do is to make it redundant.  Most telcos do not work this way, and I do not want to see the word "autodetect" for something which is doing no autodetection whatsoever.

Please use the word "redundant", as that accurately describes what the telco wants to see:  redundancy between the indication fields and the number.
By: Stefano Brandimarte (stevens) 2007-02-26 16:20:35.000-0600

Corydon76: even if I could disagree with You, what's the problem ? Here it is a diff with "autodetect" replaced by "redundant". Et Voil?. (two words change :-).
By: Tilghman Lesher (tilghman) 2007-02-26 17:04:53.000-0600

Because I'm concerned with wording being confusing to future users.
By: Stefano Brandimarte (stevens) 2007-02-26 17:27:07.000-0600

Corydon76: well looking into chan_zap.c:12938 I can admit there's some kind of (local)diaplan autorecognition indeed. ;-)

if ((l != NULL) && (prilocaldialplan == -2)) { /* compute dynamically */

If You don't want to call this "autodetection" this doesn't mean that this code has been thrown away. :-)

This is the reason I don't agree with You. But, I've changed the patch because I think features are more important than opinions. So please, let this code in...


By: Tilghman Lesher (tilghman) 2007-02-26 18:11:37.000-0600

Committed revision 56952.