Identifying IDC tables using specific routes

[MikeyTen4]

Hi everyone! I hope you're all well.

I'm new to the site, but I've been lurking around for a loooong time - this place has already been a godsend over the last few years. I thought it was about time I signed up though. Hopefully I'll be able to get some direct help and possible help others over time. I've got a background in IT support starting about 7 years ago, and in the last 3 years I've been working solely on Nortel & Avaya VoIP, being the main (i.e. only) engineer looking after it in my organisation. What I know, I've learnt completely on the job from the ground up, so I go day to day with the attitude that there's always a lot more I don't know than do, but it's a continual learning experience!

Anyway, right now I'm hoping someone can help answer a quick question for me, and maybe provide some guidance.

My organisation uses various IDC tables with a long list of entries, all viewable by PRT'ing all DCNO's under LD 49. What I need to do is identify whether or not a table exists for a specific route. I know the route number (120, with 12 trunks under it). But I can't seem to find a way of identifying if any of the tables currently set up are using this route.

I may need to set some IDC entries up for calls coming in via DDIs on that route basically, and while I know I can build a new table and just set the table to use route 120 via LD 49 and 16, I want to avoid cluttering it up if such a table already exists.

Is there a way to tell?

Thanks
Mike

 

[KCFLHRC]

You wont be able to see in LD 49 if an IDC table is used ion a specific route. You will need to print the routes out to see what IDC table that route is using. Only 1 IDC table for day and 1 IDC table for night per route.

 

[hawks]

example of what kcf was talking about
Print the RDB in LD 21

Rout xx
IDC YES
DCNO 0 *
NDNO 1

 

[MikeyTen4]

Hi KCFLHRC, thanks for the reply.

I can print the rout details under LD 21, is this what you mean? If I do, then it includes...

IDC YES
DCNO 3
NDNO 3 *


I guess this is what I'm lookign for? Strangely DCNO 3 contains the following...

SDID NO
IDGT CDGT
40 640
4120 64101

The IDGT entry '4120' don't seem to match any DDI sitting on the trunks concerned. But i guess that could just be junk left over by whoever set it up before I did the job.

It's a bit clearer in my mind now anyway, thanks a lot

 

[Firebird Scrambler]

You need to go into LD 21 and print off all your RDB entries.
Against each one, look for IDC = YES and the IDC table number will appear below against the DCNO and NCNO prompts for day and night service.

e.g.

>LD 21
REQ: PRT
TYPE: RDB
CUST 0
ROUT
ACOD

TYPE RDB
CUST 00
DMOD
ROUT 1
DES EURO ISDN
TKTP DID
NPID_TBL_NUM 0
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC E403
CNTY ETSI
SBN NO
PNI 00000
NCNA NO
NCRD NO
ISAR NO
CPFXS YES
SDID NO
DAPC YES
TBL 0
INTC NO
DSEL VOD
PTYP DCO
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
RANX NO
SRCH LIN
TRMB NO
STEP
ACOD 8001
TCPP NO
TARG 09
CLEN 1
BILN NO
OABS
INST
IDC YES
DCNO 1
NDNO 1 *
DEXT NO
DNAM NO
MFC NO
ICIS YES

I hope this helps?.

All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[MikeyTen4]

Thanks Hawks! I hadn't seen your reply when i posted the above. but it confirms what i asked, cheers

Is the placement of the * important at all? i noticed on your example it's against DCNO, but on mine it's against NCNO.

 

[KCFLHRC]

Yes sir, you got it figured out. The 4120 could be like and old Main # DNIS pointed to that PRI. Alot of time the carrier will port the last 4 of the main # and point it to the new circuit, and yes you are correct, it won't match your DID range.

 

[MikeyTen4]

Haha, I'm always a reply behind!

But yes, Firebirdscrambler, everything here has helped

 

[KCFLHRC]

The * means that is the active table.

 

[Firebird Scrambler]

Against your last comment on

SDID NO
IDGT CDGT
40 640
4120 64101

This refers to e.g.
incoming DID digits 40 being translated to Meridian digits 640xx?
The same applies to 4120 being 64101.
I'm assuming that some of your DN ranges is 5 digits long?.
It's all to do with how many digits your incoming line provider is sending you.

All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[MikeyTen4]

Ahh, thanks KCFLHRC. That does ring true actually - it's a big organisation I work in, and we've got a lot of old numbers pointed at new circuits here and there. That could well be the reason, thanks.

 

[MikeyTen4]

Firebirdscrambler - yes we use a 5-digit DN range across the organisation, all starting 6. We 3 ISDN30 circuits hooked up to our CS1K with a large range of DDIs set to match those DNs - e.g. 01234 5[DN]. We have static 1120's on desks in all of our sites, and people then log in with their DN and get all of their calls through those circuits and across our network to wherever they happen to be.

But we've got sites which have their own circuits and have kept some numbers they hhistorically publicised prior to VoIP being rolled out. This is one of them. The site previously published theit number as 654040, so when VoIP was rolled out they were given DN 64040 on reception.

So... I guess the entry IDGT 40 > CDGT 640 is what has been doing the job of converting calls arriving via DID 654040 to ring on DN 64040? That makes sense, since it's exactly what happens. But... (this migth be a real novice question)... how does the CS1K know to send the call to 64040 rather than 64041, 64042, 64043, etc? Those are all valid DNs, and I'm sure some of them are deployed on the same site. As I under stood it, the IDGT entry can be the final X ammount of digits in a DID (which matches above), but this CDGT part is new to me. Any other table I've worked on seems to include a full DN.

 

[KCFLHRC]

That is strange, it should be 64040, not 640. However, since 64040 is the lowest valid DN in that range that must be why the CS1k is picking that #.

 

[Firebird Scrambler]

IDC tables can be a real pain when changes are made in the exchange as I've had many customers whereby the IDC entries are all over the place and in some cases, the entire table is full of useless data and bears no relation to what is actually being sent from the exchange.

Another point is that some programmers won't fill out the entire DID/DDI range and will save time typing it all in by only putting the lowest amount of codes that will work.

I personally prefer to fill out the whole DDI range where possible to match the Meridian's DN range. It's easier to trace on is going on.





All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[MikeyTen4]

KCFLHRC - Yeah, I guess that makes sense, it could be that '640' just means it will direct the call to the lowest DN in that range.

Firebirdscrambler - Yeah, I'm pretty new to all of this (3 years working with it and just learning through experience), but I think I'd prefer to enter the full DID/DN range myself so that everything is clear and tidy. A lot of the entries in our IDC tables were put in place by a previous engineer, and this is the problem I'm left with... tryign to figure out things like the above! But it's not the worst thing I guess, at least things are working.

I know a bit more now about how IDC tables function and why at least, so thanks a lot everyone. You've all really helped me out.