[Home]

Summary:ASTERISK-05188: [patch] pridialplan and prilocaldialplan do not provide adequate control for all telco connections.
Reporter:Robert Christian (thetatag)Labels:
Date Opened:2005-09-29 12:12:55Date Closed:2007-11-06 20:12:46.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap.c.diff
( 1) chan_zap+dyn-dp.diff
( 2) chan_zap+ton_npi.diff
( 3) chan_zap+ton-npi_1.2.11.diff
( 4) chan_zap+ton-npi.diff
( 5) chan_zap-dyn-dp-1.2.11.diff
Description:Even with the adoption of pridialplan=dynamic, chan_zap still offers limited control of the outbound PRI dialing.  This has become debilitating for at least my connection with the telco (who is using a DMS100), and if the Asterisk user lists are any indication, other people are having some difficulty with this as well.

Let's look at an example.  I am in the United States, and for whatever reason, my telco's switch is configured to look for numbers in these formats:
Intl. TON -> [country code][number]
Natl. TON -> 1[area code][number]
Local TON -> [number] (no area code)
Unknown TON -> [number]

Either because they cannot or, more likely, because they will not, these cannot be changed, so it is my obligation to conform to their configuration if I want calls to be routed properly.  Some interesting points which occur on my particular connection:

International calls MUST have the "011" stripped off the beginning to work.
National calls MUST be presented with the initial "1".
Local calls MUST be presented in 7-digit format and will not work with any shorter feature number like 411.  (911 does, however, work.)
Unknown calls MAY NOT be international, national, or local, regardless of presentation.  (This appears to not be correct behavior on the part of the telco, but such a discussion is outside the scope of this report.)  Unknown calls can be "411", "911", "844" (a time & temperature service provided by this telco), and other non-standard numbers.

THE PROBLEM:

If I set a fixed pridialplan, I am blocked from being able to make certain types of calls.  It is imperative on this connection that the TON be set correctly.
If I use pridialplan=dynamic and provide internationalprefix=011, international calls should be properly identified and the prefix removed, which will allow the call.  However, if I provide nationalprefix=1, the prefix is stripped prior to sending the number, and the telco rejects the number.  (Yes, this can be fixed by adding another 1 to the dial string, but that would qualify as a hack in my opinion.)
The real problem is for local numbers and "feature numbers".  Local numbers can be from a number of exchanges, but some long distance numbers share the same area code.  Therefore, I must leave localprefix blank.  Unfortunately, that makes it impossible to use the unknown TON which is required for 411 and other calls which are non-standard numbers.

For whatever reason (and I don't question that it seemed like a good reason), someone decided that Intl. and Natl. TON prefixes should be stripped, while local, unknown, and private prefixes should not.

MY SOLUTION:

My solution is to add functionality to the chan_zap that would allow the dialplan to specify in the dial string a particular TON which would override any other behavior.  If not provided, existing behavior would apply.  The same functionality would apply for the CALLERID information, if a particular TON needed to be used for outbound CID.  This would allow more control from the dialplan, a place where performing some basic logic on the numbers is appropriate.  At the same time, the proposed patch does not remove or deprecate any existing functionality (so it won't break anything).


****** ADDITIONAL INFORMATION ******

With my proposed patch, the following dialplan commands will force a specified TON:

Local example:
exten => _NXXNXXX,1,Dial(Zap/g1/l${EXTEN})

National example:
exten => _1NXXNXXNXXX,1,Dial(Zap/g1/n${EXTEN})

International example: (logic for handling variable-length numbers omitted)
exten => _011[etc.],1,Dial(Zap/g1/i${EXTEN:3})

Unknown example: (411, 911, etc. in this example)
exten => _N11,1,Dial(Zap/g1/u${EXTEN})

Private example:
exten => _0990XXXX,1,Dial(Zap/g1/p${EXTEN:4})

In summary, the lowercase letters l,n,i,u, and p are added as valid prefixes to force the TON.

This patch also applies the same behavior to the outbound caller-ID.

For example: (sets calling number TON to national)
exten => _NXXNXXXX,1,Set(CALLERID(number)=n5555551212)

NOTE: While standard compatibility between channel types is not an issue typically, it should be noted that this is NOT compatible with non-PRI circuits.  Therefore it should ONLY be used as a prefix if it is dialing over a PRI.  Some may consider it a more elegant solution to introduce a channel variable that sets the TON on outbound calls (or, if the variable is empty, reverts to current behavior) and contains the TON on inbound calls.  I must admit, that may be the better long-term solution.
Comments:By: Robert Christian (thetatag) 2005-10-13 20:01:23

Giving more thought to this, I think "the thing to do" is what I described above with appropriate channel variables for this information.  I will look into implementing that shortly and offer that as a patch file in this report as well.
By: Kevin P. Fleming (kpfleming) 2005-10-31 18:44:24.000-0600

I'm going to close this one unti you have determined what you think is a better plan of attack... This is definitely post-1.2 material in any case.
By: Serge Vecher (serge-v) 2006-08-23 15:14:28

reopening this bug at the request of stevens in 7789 ...

stevens: please feel to attach your patch here for review and testing. And please don't forget to mention your disclaimer status. Thank you very much!
By: Stefano Brandimarte (stevens) 2006-08-23 17:43:28

uploaded patch against SVN-trunk-r40928M

Disclaimer faxed today to Digium (+1-256-864-0464).
By: Stefano Brandimarte (stevens) 2006-08-23 18:23:06

latest patch is against asterisk-1.2.11 and includes this one:

http://bugs.digium.com/view.php?id=7789
By: Serge Vecher (serge-v) 2006-08-24 08:31:28

let's keep patches separate per issue...
By: Stefano Brandimarte (stevens) 2006-08-24 10:43:02

uploaded patch for plain asterisk 1.2.11
By: Stefano Brandimarte (stevens) 2006-08-28 14:13:45

i tested the patch for a few days and it works well indeed.

Now, however, we need more control over the TON/NPI bits. The concept is that
dialing plan definitions are just convenients shortcuts for a composite value
and they don't cover every possible TON/NPI combinations.

For example (from libpri.h):

PRI_INTERNATIONAL_ISDN 0x11 == (PRI_TON_INTERNATIONAL << 4 | PRI_NPI_E163_E164)
PRI_NATIONAL_ISDN      0x21 == (PRI_TON_NATIONAL << 4 | PRI_NPI_E163_E164)
PRI_LOCAL_ISDN         0x41 == (PRI_TON_SUBSCRIBER << 4 | PRI_NPI_E163_E164)
PRI_PRIVATE            0x49 == (PRI_TON_SUBSCRIBER << 4 | PRI_NPI_PRIVATE)
PRI_UNKNOWN             0x0 == (PRI_TON_UNKNOWN << 4 | PRI_NPI_UNKNOWN)

Working together one of ours TELCO carriers (BT Albacom) we found that they need
another kind of setting:

(PRI_TON_UNKNOWN << 4 | PRI_NPI_E163_E164)

to set the Type Of Number to "Unknown" but the Numbering Plan to E163/E164. This
cannot be covered setting the dialplan (nor the localdialplan) because there're
no further definitions other those listed above.

So, my latest patch (uploaded for asterisk 1.2.11 also) implements the concept
of the previous ones but let's set the TON and the NPI, using two char: the 1st
one let's set the TON and the allowed character (and their meaning) are:

U (capital 'u') = TON set to UNKNOWN
I (capital 'i') = TON set to INTERNATIONAL
N (capital 'n') = TON set to NATIONAL
L (capital 'l') = TON set to NET SPECIFIC
S (capital 's') = TON set to SUBSCRIBER
A (capital 'a') = TON set to ABBREVIATED
R (capital 'r') = TON set to RESERVED

at this very moment the NPI bit is cleared (UNKNOWN) but if putting another
char after one of the above, we can set the NPI too (all lowercase):

u = NPI set to PRI_NPI_UNKNOWN
e = NPI set to PRI_NPI_E163_E164
x = NPI set to PRI_NPI_X121
f = NPI set to PRI_NPI_F69
n = NPI set to PRI_NPI_NATIONAL
p = NPI set to PRI_NPI_PRIVATE
r = NPI set to PRI_NPI_RESERVED

so our dialplan now contains something like:

exten => _00.,1,Dial(${TRUNK}/Ue${EXTEN})

and the TON is set to UNKNOWN and the NPI to PRI_NPI_E163_E164 .

To note that every PRI_* settings, a part of PRI_UNKNOWN, assume the NPI == 0x1
that is PRI_NPI_E163_E164 . So it should be consistent with the other settings
to let the (advanced) user to fine tune these ISDN messages.
By: Robert Christian (thetatag) 2006-10-31 12:31:55.000-0600

The reason I originally withdrew my patch was that it lacked elegance.  It's worked well for me for over a year now, but adding letters into the dial string is more than a little tacky and requires dialplan logic to handle inserting those letters into the dial string conditionally depending on whether the call is being routed over a PRI or some other link.  This is not altogether bad, and I reiterate that it has worked well for me in the past.

What I think is an elegant solution but never had time to complete, is to implement those controls into channel variables, as many SIP and other channel options are.  This is extremely clean and silently ignored if a different channel type is used:

A variable named "ZAP_PRI_TON" could contain the TON.  The dialplan would set it before calling the Dial application.  Likewise, an incoming call would set this to the received TON.  The same could be done for other PRI-specific information.

Another solution that I implemented and tested at one time was to expand the CALLERID function to include support for TON/NPI information -- both receiving and sending.  This is actually my favorite solution, although the developers may prefer the channel variables.  I will see about updating my patch of the CALLERID function for the current SVN of Asterisk.
By: Stefano Brandimarte (stevens) 2006-11-02 02:57:13.000-0600

thetatag: i agree that a variable or better a CALLERID() implementation could be
more elegant. If You'll do something about this, please remember to include not
only the TON setting but also the NPI, to allow making all sorts of combinations
between them. Best Regards.
By: petersv (petersv) 2007-02-23 00:41:37.000-0600

The dialplan selection really has to be in the dialstring. Consider the case of calling several recipients at once:

Dial(Zap/g1/15551234567&Zap/g1/1234567)

These may need a different TON, say international and local. The channel variables are very useful for settings related to the incoming call, but not so flexible for the outbound call.
By: Stefano Brandimarte (stevens) 2007-02-26 16:12:02.000-0600

petersv: you're right in this field. So the patch uploaded could be better tested now. I've to update it against SVN though. Indeed we're using it since august and it solved some incompatibility with our carrier's equipment.
By: Stefano Brandimarte (stevens) 2007-02-26 17:11:57.000-0600

diff added for SVN trunk 56921M .

Please note that it's required to set first the TON then the NPI, even if we want to modify just the latter. A warning is issued when using an unrecognized alpha char in the very first two positions of the called number.
By: Digium Subversion (svnbot) 2007-11-06 20:12:46.000-0600

Repository: asterisk
Revision: 89078

U   trunk/channels/chan_zap.c
U   trunk/configs/zapata.conf.sample

------------------------------------------------------------------------
r89078 | tilghman | 2007-11-06 20:12:45 -0600 (Tue, 06 Nov 2007) | 5 lines

Provide the ability to directly manipulate the TON/NPI bits in the dialstring.
Reported by: thetatag
Patch by: thetatag/stevens/tilghman
Closes issue ASTERISK-5188

------------------------------------------------------------------------