Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PRI 1
- Thread starter vztech
- Start date
- Thread starter
- #3
Not to sure yet
Customer stated they have a PRI in there system thats dropping calls.
They for some reason asume possibly they don't have the keycodes for a PRI so that could be the issue.
I work mostly on 11c-to 81c so I'm no Norstar guru but I have installed a straight T before in them.
They have about 20-30 users
Thanks
Customer stated they have a PRI in there system thats dropping calls.
They for some reason asume possibly they don't have the keycodes for a PRI so that could be the issue.
I work mostly on 11c-to 81c so I'm no Norstar guru but I have installed a straight T before in them.
They have about 20-30 users
Thanks
-
1
- #5
superiortel
IS-IT--Management
If the customer has a Pri in the system that is dropping calls, rest assured that you do have a Pri keycode, otherwise the Norstar would never allow the D channel to become active.
The way to look into it is F**config, <password>, back off 2 steps to "hardware" show card 1, and it will tell you if it's set up as a T1 or Pri. You cannot change the settings unless you disable the card in maintenance first.
I've seen a case of a database restore from a system that had a Pri which lost all the settings, and the restore will go thru, it will also ahow card 1 as Pri, but the D channel will not work until you enter the software key.
The most probable cause of dropped calls would be errors in the T1 (physical layer),like frames, etc. Go to the logs and scroll thru all of them, decoding the entries with the book (at the end of the installer's manual you have the codes)
The way to look into it is F**config, <password>, back off 2 steps to "hardware" show card 1, and it will tell you if it's set up as a T1 or Pri. You cannot change the settings unless you disable the card in maintenance first.
I've seen a case of a database restore from a system that had a Pri which lost all the settings, and the restore will go thru, it will also ahow card 1 as Pri, but the D channel will not work until you enter the software key.
The most probable cause of dropped calls would be errors in the T1 (physical layer),like frames, etc. Go to the logs and scroll thru all of them, decoding the entries with the book (at the end of the installer's manual you have the codes)
- Thread starter
- #6
Thanks Superiortel
Update: MICS xc 4..1
PRI works fine if a call is established and someone answers on the far end but if you call a company and hit their menu tree the call will drop in the middle of a menu recording 20-25 sec.Seems like its not getting its answer supervision.Also if you call a wrong number and you receive intercept treatment it drops between 20-25 sec.
replace combo card and pri card but same issue.
strange!!!
checked Dest.codes,Routes and Sig seem to be ok
anyone!
Thanks for any ideas in advance
-vz
Update: MICS xc 4..1
PRI works fine if a call is established and someone answers on the far end but if you call a company and hit their menu tree the call will drop in the middle of a menu recording 20-25 sec.Seems like its not getting its answer supervision.Also if you call a wrong number and you receive intercept treatment it drops between 20-25 sec.
replace combo card and pri card but same issue.
strange!!!
checked Dest.codes,Routes and Sig seem to be ok
anyone!
Thanks for any ideas in advance
-vz
superiortel
IS-IT--Management
If what you are getting is a disconnect when the call gets transfered out at the far end (i.e.: the recipient end, be it an auto attendant or a person hits transfer and sends the calls over a different circuit, usually a Pri), then, what you most probably have is a protocol mismatch. You might be on 5ess and the CO is on NI-2, or you are SL1 and they are 5ess.
Another viable explanation for the same case (disconnect on transfer) is that the CO is marking your calls as private (it is possible on ISDN), therefore, when a transfer out happens, the privacy marker forces the switch to drop the calls. This is true sometimes on calls from Federal entities, which lately looks like have implemented privacy. I already hit a case when calls from them could not be transfered out or conferenced, no matter what, but if I called from my cell phone, no problem whatsoever.
So far I'm just rambling on the possible scenarios. You need to gather a lot more information on the particular situations when the calls get dropped. I suggest you try to replicate the problem under controlled circumstances, where you make the call and you also receive the call and transfer it out, maybe another circuit at your own place, or even start by calling your own Pri and transfer out.
And, you can also request your LEC or CLEC to monitor one of those calls and figure out the reason for the disconnect.
Another viable explanation for the same case (disconnect on transfer) is that the CO is marking your calls as private (it is possible on ISDN), therefore, when a transfer out happens, the privacy marker forces the switch to drop the calls. This is true sometimes on calls from Federal entities, which lately looks like have implemented privacy. I already hit a case when calls from them could not be transfered out or conferenced, no matter what, but if I called from my cell phone, no problem whatsoever.
So far I'm just rambling on the possible scenarios. You need to gather a lot more information on the particular situations when the calls get dropped. I suggest you try to replicate the problem under controlled circumstances, where you make the call and you also receive the call and transfer it out, maybe another circuit at your own place, or even start by calling your own Pri and transfer out.
And, you can also request your LEC or CLEC to monitor one of those calls and figure out the reason for the disconnect.
- Thread starter
- #8
Thanks Superiotel
I can replicate the problem very easy I have a 1800# that drops everytime you make a call to it after 20-25sec.
Workes fine when called with a POTS or cell.
Only 1 pri is in this switch but it is a 5ess and I'm thinking of changing it to NI2 as you suggested.
LEC was on-site and tested at their D-marc with that number and it worked fine.
Thanks again
I can replicate the problem very easy I have a 1800# that drops everytime you make a call to it after 20-25sec.
Workes fine when called with a POTS or cell.
Only 1 pri is in this switch but it is a 5ess and I'm thinking of changing it to NI2 as you suggested.
LEC was on-site and tested at their D-marc with that number and it worked fine.
Thanks again
- Thread starter
- #10
- Status
Similar threads
- Locked
- Question
