CLID table

[coniglio]

I have CLID table 0 with my office's seven-digit number programmed as the HLCL. Every phone references this CLID table. Is there any where else in the PBX programming I need to look to make sure the correct seven-digit number is showing on the far end? I was out yesterday and my users are claiming that only their four-digit exts are showing on the far end. Can you please tell me where else I need to look? Thank you.

 

[johnpoole]

no that is the only place to enter that information that i know about, try to duplicate the trouble, check if the ext in question has a name programed. if you can't dup that one it was the central office. you can do a enl msgi dch (x) and see the data you are sending out. WARNING.. during peak hours this can be a problem: one page of text per call setup another during teardown.. i get an average on 10,000 calls per hour, may not want to turn that on around 11:30..

john poole
bellsouth business
columbia,sc

 

[coniglio]

the central office meaning the T1 provider? Because I'm convinced this has something to do with them. What happened was a user dialed an 800 # and, when it was called only from his phone, he got a message asking him to enter his security code. Everyone else in the office could dial this toll-free number fine. Then I find out the 4 digit ext (they're not DIDs) is what's showing on the far end, even though I have a CLID table. But even if there was no CLID or anything in the PBX, I would still think he could get through correctly...

 

[coniglio]

I just found out that the CLID table was NOT built after all. There was no CLID entry, which caused the far end to only see the last four digits of the caller's phone number. It seems this one guy's ext was being "read" by the far end as an ext. they probably also use for something and that's why he was prompted to enter a code, etc. I think this makes sense.

 

[johnpoole]

some (mci) 800 numbers can not be called with casual caller id entries. that bit me before also. the co (central office) is the company that installed the t1 demark, not always the same people that you pay for service, in their dax your information is reformated to send down steam. access to them will more then likely be through your t1 provider. only the enl msgi table in ld 96 will confirm if the trouble belongs to you, the t1 provider, or the called number service provider. after a t1 to pri upgrade i had a user that could call most 800 numbers but not all. come to find out that mci didn't accept my (non) clid entry on some types of 800 service, the smae way i can dial a code at home at not accept numbers with ani (auto-number id) blocked.

john poole
bellsouth business
columbia,sc

 

[coniglio]

very interesting, although a bit confusing. In either case, I wasn't here yesterday so my vendor did build a CLID table and the user was able to get through correctly on this 800 number. If it's not too much trouble, how would I tell via the d-channel messages whether it was the lack of a CLID table? if it's too lenghty to explain then that's okay but if it's something fairly simple please let me know as I would love to be able to understand. Thank you JohnPoole.

 

[coniglio]

back to this CLID issue...to be proactive I've decided to build CLIDs for all my sites before we put the PRI circuits in. Once I create the CLID in LD 22 as entry 0 (we will only be using one entry) and make each phone reference table 0, is that all I have to do? Or do I need to change anything in the CDB also? thanks very much for your response.

 

[johnpoole]

take the clid off and dial the number, prt the msgi/o for your d, put it back on, you'll should see the far end refuse to ack. and yes you have done both steps. most of my users want the main # and cetrain dept #'s to display instead of the ext. big shots don't want mortals calling them back on a direct line.

john poole
bellsouth business
columbia,sc

 

[coniglio]

i assume ACK means acknowledge? I am not yet proficient at reading D-channel messages but imagine I will be soon enough. Thanks for your help. I'll build all my CLIDs now.

 

[johnpoole]

correct

john poole
bellsouth business
columbia,sc

 

[coniglio]

okay, I thought I'd be proactive and build my CLID tables now so that when the new PRI circuits are installed at all my offices there's no chance of having this same problem in case the tech forgets to do it (we have regular T1s now). I see I do have to also make a change under NET_DATA in the CDB to set ISDN to YES. It's currently set to NO. Can I change it to YES now and build each CLID, even though the new PRIs are not all installed just yet?

 

[johnpoole]

yes it will not effect current t1s

john poole
bellsouth business
columbia,sc

 

[coniglio]

thank you.

 

[coniglio]

One more quick question regarding CLID...I saw something in my RDB called CLEN (CLID entry number). Can I assume the digit following this is the CLID entry built in LD 21 that shows on outbound caller ID?

 

[johnpoole]

yes if you want a company number broadcast with all outgoing calls from that route, the entr number would answer that prompt.

john poole
bellsouth business
columbia,sc

 

[coniglio]

That was what I was looking for. I understood that the CLIDs were created in LD 21 but thought there must be someplace to reference that CLID on the route. Perfect. Thanks again.

 

[johnpoole]

clids are printed in 21, they are created in 15.. cdb

john poole
bellsouth business
columbia,sc

 

[coniglio]

really? i asked my tech a hundred times about this and he said they're built in LD 21. Can you just point me in the right direction as far as where to build them in LD 15? if you give me the gate-opener I will be able to figure it out.

THANK YOU!

 

[johnpoole]

ld 15 under net_data, loads 20 21 and 22 are print only, the only 3 prompts you can use in to to answer req: are prt, ltm and end..

john poole
bellsouth business
columbia,sc

 

[coniglio]

thank you JohnPoole. I should've realized that myself. I already know those LDs are print only. You've given me all the steps I need. thanks again.