Topic: Problem calling Glasgow 0141 numbers with Asterisk / ISDN BRI [Solved]

[markleman]

Here is an odd one. When ever I call a number starting 0141xxxxxxx I get a 'the number you have dialed has not been recognized' message in a very BT sounding voice.
The call is going out over ISDN BRI, we have 2 ISDN2e lines (=4channels). Our BT engineer temporarily took over one of our lines and can dial the number ok from the exchange, he also set up another number in the same target exchange to make test call to (0141 440 1994), I can't call this either.

Prefixing the number with 1280 to force the call over BT allows it to connect.
Prefixing the number with 1840 to force the call over Opal allows it to connect
Prefixing the number with 141 to prevent caller ID being sent allows it to connect.
Call are going via BT except international which are routed via opal using carrier pre-selection.

We only have one route set up:

Code: [Select]

MAINBRI : _0XXXXXXXXXX _0XXXXXXXXX _XXXXXX _1XX _1280. _1840. _1877. _00XXXXXXXX. 118118 118811 999 17094009 _1470. _141X.

Here is a log from asterisk when I attempt to make the call, I think we are sending the right number from the line 'called g2/01414401994'

Code: [Select]

pabx*CLI>
    -- Executing AGI("SIP/5021-b7e0cf70", "selintra|OutCluster|01414401994") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
    -- Executing AGI("SIP/5021-b7e0cf70", "selintra|OutRoute|MAINBRI") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script Executing Application: (Dial) Options: (Zap/g2/01414401994)
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called g2/01414401994
    -- Zap/5-1 is proceeding passing it to SIP/5021-b7e0cf70
    -- Zap/5-1 is making progress passing it to SIP/5021-b7e0cf70
    -- Hungup 'Zap/5-1'
  == Spawn extension (default, 01414401994, 1) exited non-zero on 'SIP/5021-b7e0cf70'
    -- Executing Hangup("SIP/5021-b7e0cf70", "") in new stack
  == Spawn extension (default, h, 1) exited non-zero on 'SIP/5021-b7e0cf70'
    -- Channel 0/1, span 2 received AOC-E charging 0 units
pabx*CLI>

BT think it our problem but don't have the kit at the exchange to actually monitor the line and see what  number I am passing them. I think it's their problem but can't prove it .

My only thought is that 0141 is very close to the 141 prefix to cause caller id to be withheld - how that could cause a problem I don't know but when I mentioned it the BT engineer mumbled something. I did try removing the '_141X.' bit in the routing rule 'just in case' but it made no difference.

Help appreciated,
Mark Leman

[markleman]

Forgot to add the version numbers:
Linux pabx 2.6.9-42.0.3.EL #1 Fri Oct 6 05:59:54 CDT 2006 i686 i686 i386 GNU/Linux

with:
selintra-sail-2.1.14-457
anabri-asterisk-zappri-florz-1.2.6-6
anabri-asterisk-florz-1.2.10-8


And someone else had a similar problem back in 2006, but there is no solution I can see from the archive of the mailing list http://www.mailfunnel.org/asterisk-users@lists.digium.com/2006-07/msg00115.html

very odd.

[SARK devs]

Hi Mark

Well - SARK is putting the call onto the Zap circuit ok...

called g2/01414401994

This is correct with no digits missing or mangled so it pretty much rules out a problem with SARK itself. 

You might want to try running pri debug (do help pri debug at the asterisk console).  This should show you a bit more about how and why the call is being rejected.     

You really could do with the Openreach engineer on-site with a Harrier to do a proper ISDN2 test.  They'll threaten you with a call-out charge if the problem isn't in the network but if you are nice to them while politely standing your ground, they are usually very helpful in the end.

Best

J   

[markleman]

Thanks, I'll try that tomorrow when I'm back at work.

There is another discussion on this subject (this time with a PRI rather than BRI line) I found in the asterisk IRC archive http://ibot.rikers.org/%23asterisk/20080708.html.gz with the section of interest starting at 12:44.24. The suggestion (at 13:06.43) being to change 'pridialplan=unknown', mine is currently 'pridialplan=dynamic'.

I found the following description of 'pridialplan=dynamic'

Code: [Select]

"dynamic"  : Parse the dialed number and try to find a matching prefix in
             the settings "internationalprefix", "nationalprefix",
             "localprefix", "privateprefix", "unknownprefix". If matched,
             set the TON/NPI to the matched setting and strip the prefix.
             Having set nationalprefix=0 allows you to call Dial with e.g.
             0461234567 and have it sent as TON=national, digits=461234567.

Which would imply to me that because I have 'nationalprefix=0' a match would occur on the leading zero of 0141 causing it to be removed? Which would cause 141xxxxxxx to be sent with 'TON=national'  (this is getting beyond my level of understanding of ISDN protocols ) and BT could be seeing the 141 as withhold caller ID rather than a dialing code.

Will pri debug show me what is actually being sent to BT?

Thanks again for you help.

[SARK devs]

Brilliant analysis Mark,

I think you could well be right.  I've just looked back through our install notes and we stopped specifying pridialplan=dynamic at some point.  Unfortunately, our change management wasn't good enough at the time to tell me why it was changed but I can't imagine us fixing something that wasn't broken....

Here are the settings we were using on bristuff installs just before we changed to mISDN last year.

Code: [Select]

context=mainmenu
resetinterval=never
immediate=no
switchtype=euroisdn
signalling=bri_cpe
pridialplan=unknown
prilocaldialplan=unknown
nationalprefix=0
internationalprefix=00
echocancel=yes
echocancelwhenbridged=no

Hope these help.

J

[markleman]

Ok folks - it's fixed and for the record here is the solution:

Changing 'pridialplan=' from 'dynamic' to 'unknown' in zapata.conf fixed it (*). 'pri debug span' helped because it shows what I was sending to BT eg:

With 'pridialplan=dynamic'

Code: [Select]

2 > Called Number (len=13) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '1414401994' ]
With 'pridialplan=unknown'

Code: [Select]

2 > Called Number (len=14) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0) '01414401994' ]
The problem calling Glasgow (0141) numbers was because Zapata matched and therefore striped the leading '0' from the std code and set the TON flag to 'national'. This has the unfortunate side effect of making an 0141 std code into 141 which (wrongly in my view) BT then interpret as withhold caller ID, rendering the rest of the number meaningless . Putting any thing valid (**) in front of the number stopped zapata matching/stripping the leading '0' and so the call worked.

I have also changed 'prilocaldialplan=unknown' to match Selintra's settings posted previously.

Thanks, as ever, to Selintra for the support.

Regards,
Mark Leman

* In Sail this was achieved by editing the values found in PCI cards -> edit -> 'ZAPATA Tuples' box, clicking save (repeat for each card) then 'commiting' the changes and restarting asterisk from the command line. We are running a quite old version of sark/sail (because it just works and if it aint broke don't fix it), Jeff informs me this is tidier in later versions.

** Like 1280 - a pre-selection code to force calls via BT, or even 141 to withhold Caller ID.