CM6.3 not accepting inbound internal calls not using the access code

[hartlm]

Hi

My organisation uses 3 different phone systems (don't ask), and I look after the Avaya platform. The estate outside of Avaya is being modernised, and as part of that they are getting rid of the MD110 gateway that links Avaya to the other platforms. This also means that the '26' access code that allows calls off Avaya and onto the other platforms via the gateway (and vice versa), will no longer be used. All internal calls between Avaya and the gateway are carried on 2 specific ISDN 30s. Our DDI numbers are in a unique range (60001 to 60299) in the overall dial plan. I have successfully made the changes to the CM uniform dial plan and AAR analysis tables that will allow calls out over the internal trunks without using the '26' code, but I don't know what (if anything), I need to do in the CM to let it recognise inbound internal calls to our DDIs that aren't prefixed with '26'. The telecoms guys looking after the Cisco and Ericsson platforms and MD110 have made the config changes they say they need to make, but test calls to the Avaya DDIs fail. Does anybody have any suggestions?

Thanks.

 

[mattKnight]

change inc-call-handling-treat trunk-group x

First place I'd look




Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[hartlm]

I did think about that but I'm not sure how to configure it as I'm not changing the incoming number. They will be sending the correct 5-digit DDI number in the first place, so I didn't think I would be deleting or inserting any digits. And what would I put in the Per Call CPN/BN field?

 

[mattKnight]

Is the Trunk configured as a TIE?


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[hartlm]

Yes, it is

 

[mattKnight]

You have extensions 60001 to 602999

You used to receive 2660001 to 2660299 on the ISDN trunks that would then route to 60001 etc

Now you only receive 60001 to 60299, these should route directly to the extensions without using the incoming call treatment table. I'd check that it is empty

If all else, run a list trac tac for the trunk group and post the results


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[hartlm]

Yes, that's right regarding the extensions, etc. The treatment table is empty as well. I'll run some traces next week and post the results. Thanks for your help so far.

 

[dialtonebone]

Be sure to post your traces wrapped in

the code tag

 

[montyzummer]

Are you sure the treatment table is empty as somewhere you where manipulating 26 and stripping it , you must be if in the first place you received 2660001 and the call routed to 60001.

So another way this could be done is if the AAR access code is 26 , incoming calls would route to AAR and the AAR digit conversion would do the manipulation and change to extn , could also be done in ARS so check the AAR/ARS digit conversion tables.

But as Matt correctly stated if this is now a tie trunk when the system receives a known extension number it should (if nothing else is preventing it) route to stations , you could try adding an entry for 5 length starting with 6 in the incoming treatment table so .... length 5 ..digits 6.. cpn none leave all other fields blank.

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[hartlm]

The AAR analysis and digit conversion tables have no entries relating to numbers starting 26, but the digit conversion table does have ones for the DDI numbers:
display aar digit-conversion 6 Page 1 of 2
AAR DIGIT CONVERSION TABLE
Location: all Percent Full: 0

Matching Pattern Min Max Del Replacement String Net Conv ANI Req

600 5 5 0 ext n n
60099 5 5 0 aar n n
601 5 5 0 ext n n
602 5 5 0 ext n n

Could this be having an impact on inbound calls on the Tie lines? I also noticed that 60 is not in the uniform dial plan; does it need adding? I haven't had the opportunity to do a tac trace yet as the Tie lines are too busy, but will be able to do that in the morning.

I also tried making the suggested entries in the incoming call handling treatment tables for the two Tie lines, but test calls always get 'busy' at the testers end.

With regards to the 26 being stripped off somewhere to deliver the calls to the relevant extension I can't see anything in the ARS/AAR tables. There is an entry in the dial plan analysis table, but I thought that was just to do with outbound calls:
DIAL PLAN ANALYSIS TABLE
Location: all Percent Full: 3

Dialed Total Call Dialed Total Call Dialed Total Call
String Length Type String Length Type String Length Type
0 1 ext * 3 dac
1 4 ext # 3 dac
123 3 fac
18 7 ext
22 2 fac
26 2 dac
3 5 ext
38000 5 udp
4 5 ext
5 5 ext
6 5 ext
61 2 fac
7 5 ext
8 5 ext
9 1 fac

 

[montyzummer]

The 26 will get stripped if it is in the features table as an aar access code , check there , quickly looking at your cnfig the tie line should work , can you do a list trace on the tac and post , if 26 is in the feature table that will be reflected in the dial plan as a FAC which it is 5th entry down.

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[mattKnight]

Dialed Total Call Dialed Total Call Dialed Total Call
String Length Type String Length Type String Length Type
0 1 ext * 3 dac
1 4 ext 
123 3 fac
18 7 ext
22 2 fac
[b]26 2 dac[/b]
3 5 ext
38000 5 udp
4 5 ext
5 5 ext
6 5 ext
61 2 fac
7 5 ext
8 5 ext
9 1 fac 
* 3 dac
# 3 dac

I'm not a fan of doing this - defining the prefix as a Dial Access code. Style I guess. I'd consider changing the TAC on the trunk group into the *xx range and changing your AAR

List trace tac 26 will help



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[montyzummer]

ooops typo , Matt corrected my mistake but at least you know how calls are routing

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[hartlm]

After all that it turns out that the issue was on the MD110 gateway. BT INet were brought in by our telecoms team as traces revealed that the calls weren't even getting out of the gateway onto the Tie trunks. We have now got calls coming in to our DDIs over that route without being prefixed with 26. It's been an education, anyway! Thanks for all your help, guys.