I have a Merlin Legend 6.1 with a 100D card that was connected to an Acculink 3160 CSU/DSU that went bad. I had to replace the card with a new 100-DCD becuause the 100D is no longer in production. I was informed by my distributor as well as Avaya technical support that the 100-DCD card was compatible with 6.1 and that the Legend would just disregard the internal CSU/DSU and I should not have any problems. Everyone seemed to be correct except for one thing - all my analog fax/modem extensions hanging off my 016 cards can not negotiate with other external fax/modems. You can dial the extensions over the T-1 and hear the negotiation process perfectly, as well - you can dial out from the fax/modem extensions and hear the negotiation process perfectly but for some reason they can never complete the handshake. (As a matter of fact, on one of the more expensive fax machines - it complains of poor line quality). These fax machines (4 of them) can call each other as extensions and communicate perfectly so I know that the 016 cards are not an issue and it boils down to the new DCD card. I know there is no magical diagnostic tool to determine what is going on and I'm a little concerned with the answers that I'm getting from Avaya & Distributor. Has anyone heard of this before and what can I do - upgrade?
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 IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
100-DCD Card Causes Fax/Modem Troubles Over T-1
- Thread starter BURLYMAN
- Start date
gregarican
IS-IT--Management
Here's some specifics from the Merlin Magix 2.0 Online Feature Reference Manual. Note that the internal CSU on the 100DCD board isn't even supported until Magix r1.5! Below is the excerpt...
Channel Service Unit
The channel service unit (CSU) is the interface between the 100D, 100R INA, and 100 DCD modules and the DS1 facility provided by the telephone company. The DS1 facility contains 24 channels on one 4-pair wire.
The 100R INA and 100 DCD modules contain an internal CSU, so no external CSU is needed. However, the CSU in the 100 DCD module is supported only in systems of Release 1.5 or later.
The CSU is a hardware component needed when two endpoints are located in different buildings or when the distance between the two endpoints makes office or line repeaters necessary. The CSU is located on the customer's premises and is used to connect the system to DS1 network facilities. The CSU has the following functions:
It terminates an outside DS1 facility on the 100D, 100R INA, or 100 DCD module.
It ensures that the signals entering the public network comply with the requirements of the DS1 facility as specified by the FCC.
It includes maintenance, diagnostic, and testing capabilities.
Verify that any CSU on the DS1 circuit between the MERLIN MAGIX Integrated System and the PSTN is programmed for the same framing as the DS1 slot on the MERLIN MAGIX Integrated System.
There are several external channel service units: ACCULINK 3150 and 3160/3164 ESF T1 CSUs, ESF T1 CSU (no longer available but still supported), and 551 T1 L1 CSU (no longer available but still supported). The ACCULINK 3150 or 3160/3164 CSUs are recommended for this system because they allow maintenance without interrupting service and provide diagnostic and testing capabilities as well as B8ZS line coding. They can be programmed remotely or onsite, using menus. The lower-cost 551 T1 L1 CSU does not provide the B8ZS line coding required for 64-kbps data (clear channel signaling support) and for maintenance features, nor does it provide diagnostic and testing capabilities for the DS1 facility.
Channel Service Unit
The channel service unit (CSU) is the interface between the 100D, 100R INA, and 100 DCD modules and the DS1 facility provided by the telephone company. The DS1 facility contains 24 channels on one 4-pair wire.
The 100R INA and 100 DCD modules contain an internal CSU, so no external CSU is needed. However, the CSU in the 100 DCD module is supported only in systems of Release 1.5 or later.
The CSU is a hardware component needed when two endpoints are located in different buildings or when the distance between the two endpoints makes office or line repeaters necessary. The CSU is located on the customer's premises and is used to connect the system to DS1 network facilities. The CSU has the following functions:
It terminates an outside DS1 facility on the 100D, 100R INA, or 100 DCD module.
It ensures that the signals entering the public network comply with the requirements of the DS1 facility as specified by the FCC.
It includes maintenance, diagnostic, and testing capabilities.
Verify that any CSU on the DS1 circuit between the MERLIN MAGIX Integrated System and the PSTN is programmed for the same framing as the DS1 slot on the MERLIN MAGIX Integrated System.
There are several external channel service units: ACCULINK 3150 and 3160/3164 ESF T1 CSUs, ESF T1 CSU (no longer available but still supported), and 551 T1 L1 CSU (no longer available but still supported). The ACCULINK 3150 or 3160/3164 CSUs are recommended for this system because they allow maintenance without interrupting service and provide diagnostic and testing capabilities as well as B8ZS line coding. They can be programmed remotely or onsite, using menus. The lower-cost 551 T1 L1 CSU does not provide the B8ZS line coding required for 64-kbps data (clear channel signaling support) and for maintenance features, nor does it provide diagnostic and testing capabilities for the DS1 facility.
- Thread starter
- #22
Is is possible that what made the first T-1 card "go bad" is still at work? I see three possible scenario's 1) You have a bad "new" 100 DCD card (wil it pass the internal and external loopback tests in the maintenance for that slot?)2) Telco has been the problem all along, and you first card was good 3) Something common to both T-1 cards (Processor, backplane, building wiring or Paradyne) has gone belly-up. You can eliminate the Paradyne by simply bypassing it, and taking the T-1 connection straight to the T-1 card and bypassing the Paradyne, if problem goes away, you have it, if not you've eliminated it. Can Verizon take a T-bird or other T-1 analyzer to your end and prove it good? You don't have a happy situation.
- Thread starter
- #25
Verizon confirmed that they were receiving bit errors at CPE. They moved further up the chain and found that the end legs were converted from B8ZS to AMI and the translation was causing a problem. I will not know until the complete circuit is now re-worked (possibly Tuesday next week) to determine if it was the sole problem. I've ruled out the card & Paradyne pretty much and confirmed with Tier 2 engineering with Avaya. I'm hopeful it has been the problem the whole time but according to Verizon - this circuit has been configured like this for a very long time so I'm baffled as to how (with the original 100D card) that all fax/modem's worked without a hitch. Slow as I go and I hope it gets resolved. I will be converting the new DCD board and paradyne to ESF/B8ZS once Verizon has completed the new circuit - go figure!
gregarican
IS-IT--Management
A line code mismatch such switching between AMI and B8ZS line coding along the circuit would result in a considerable number of Bipolar Violations.
These errors would reflect in the Current Hr and Previous Hr entries under Maintenance-->Slot-->8-->Error Events under the BPV heading on the Merlin.
Do you see any notable amounts of BPV's? Other common causes of BPV's out on telco's end are incorrectly placed bridge taps (more prevalent with today's HSDL2's), loose ground wires, and electrical interference. On your end a common cause of BPV's would be bad cabling somewhere close between the smartjack and your CPE.
Please keep us updated, as the more this goes on the more I'm curious as to what the culprit is! I know my more recent circuit installs I've coordinated with telco were melodrama much like this.
These errors would reflect in the Current Hr and Previous Hr entries under Maintenance-->Slot-->8-->Error Events under the BPV heading on the Merlin.
Do you see any notable amounts of BPV's? Other common causes of BPV's out on telco's end are incorrectly placed bridge taps (more prevalent with today's HSDL2's), loose ground wires, and electrical interference. On your end a common cause of BPV's would be bad cabling somewhere close between the smartjack and your CPE.
Please keep us updated, as the more this goes on the more I'm curious as to what the culprit is! I know my more recent circuit installs I've coordinated with telco were melodrama much like this.
gregarican
IS-IT--Management
What ever came out of this? Did things work out after Verizon suddenly rebuilt the circuit? Just checking in...
- Thread starter
- #28
I'm meeting with Verizon on Friday a.m. as they have put through all the necessary paperwork/etc... to get this circuit rebuilt. Apparently, this circuit was always coming (on one of it's last legs to DMARC) as B8ZCS and as luck would have it the same day I replaced the DS1 card because it blew-up, a Verizon technician had made a change in the CO from B8ZCS to AMI because the circuit was originally provisioned for AMI (according to the circuit information in Verizon database). This Verizon tech was scheduled (as a result of my call to them on the day the DS-1 card blew-up) to line-test the circuit. I wanted the circuit tested to prove no troubles before I re-placed the DS-1 card. No one has an answer as to how this mismatch ever worked or how it wouldn't work as configured with AMI. This mix-match was configured 6 years ago and was in-place for all this time and everything worked. Then, the Verizon tech changes from B8ZS to AMI and everything failed. I had Verizon change the it from AMI back to B8ZS with framing and without framing and the fax/modems still didn't work. So, the circuit is being rebuilt end-to-end as ESF/B8ZS and I will configure paradyne 3160 and 100DCD card as ESF/B8ZS and hope for the best. In summary, while working with Verizon they had mentioned that the Fujitzu MUX that was changed from B8ZS to AMI has multiple banks of (4) circuits. Each bank must be configured as the same (either AMI or B8ZS). The bank should not be configured with any one of the (4) circuits being different. In this case the bank that has the circuit feeding the customer was originally set to all B8ZS until Verizon tech changed one of the circuits (my customer) to AMI. So this created a mis-match in the bank of 4 circuits. When I had Verizon change the AMI back to B8ZS nothing worked (although I never reset the phone system/CSU and I probably should have). I guess we may never know why the fax/modems worked before (perhaps the new 100DCD is less tolerant for errors?) with the mismatch but I'm hoping that a new, clean ESF/B8ZS, and modifying 100DCD and external CSU will correct the problems with fax/modems. By the way Gregarican - I'm still getting 255 (the max) under SLP/ES/BS. As far as BPV, I didn't notice it once your checking the error events for the 100DCD card. Is it a displayed value on the Legend or is hidden somewhere? In any case I will keep everyone updated!
gregarican
IS-IT--Management
It definitely sounds as if Verizon misprovisioned the circuit. I'm surprised you had even acceptable voice quality calls with the errors streaming down that pipe!
A lot of times it takes days to get telco to realize that the problem is on their end. One recent circuit I purchased kept to sending our end a Blue Alarm. Telco told me for two days that it was a problem with my equipment. It's like, hello, that AIS signal is coming from you guys. Wound up telco handed off to another carrier and the two points weren't linked up.
Persistence and statistics help get things done though. Hopefully you will have resolution soon!
A lot of times it takes days to get telco to realize that the problem is on their end. One recent circuit I purchased kept to sending our end a Blue Alarm. Telco told me for two days that it was a problem with my equipment. It's like, hello, that AIS signal is coming from you guys. Wound up telco handed off to another carrier and the two points weren't linked up.
Persistence and statistics help get things done though. Hopefully you will have resolution soon!
- Thread starter
- #30
Okay people - here is the deal. I am completely frustrated at this point. Telco re-provisioned the complete circuit for ESF/B8ZS. They brought in the T-Bird and ran an all-zeros test for a few hours and everything according to them was clean. I re-programmed legend for B8ZS (as well as trunks for tie-emulation/wink/wink as that is how the original circuit was originally configured and even if I try loop or ground configurations nothing works some I'm confident it is still tie-emulation). I then reconfigured external Paradyne 3160 for B8ZS and guess what? Nothing worked! Not until I put in a hard-loop on the network side of Paradyne and then tried a CSU-loopback from Legend did I then confirm that CSU was bad! Go figure..... the CSU wasn't even aware of its problems! I purchased new Paradyne 3160 and replaced it yesterday. Now all communications work EXCEPT the darn faxes/modems on the 016 cards!!!!! After correcting the mis-match of AMI/B8ZS, replacing 100D card, replacing CSU, all voice is working fine except fax/modem! I've had Avaya working directly on this problem along with myself, etc.. with no luck yet. The only thing I noticed is that when I cleared the error events from the 100D then watched them when I made a phone-call, it jumped from 0 to 93 errors (SLP) BS/ES also increased. Then I continued to make calls with no change in errors until probably the 5th or 6th phone call which jumped the SLP errors to 255. What is going on here? Is it possible telco is still provisioned incorrectly somewhere? I beleive the impossible now that I saw the old CSU not even give one hint that it was bad and until I ran a manual test did I find issues! After the power issues damaged the 100D card (and the old CSU as well apparently) is it possible that something else is haywire in the Legend? I can fax internally all day long but cannot communicate with the outside world. Does telco have equipment that can be placed on CPE side of DMARC that can test as well as break-out the 24 DSO's so that I can prove that a fax will work at that point? Any and all suggestions is greatly appreciated at this point because customer is looking at some very grim options as time goes on with this issue. I confirmed with Avaya engineers that all configurations are in place and correct. What would be the purpose of tie-emulation versus standard ground or loopstart? Would this be a recommendation of telco or what? I'm not sure if this might play a role or maybe I'm stabbing at anything? As a recap .... All configurations according to Avaya/Telco seem to be correct (although I can't prove much on the Telco side with having some other equipment to prove that fax/modem signals can be sent over the T). All voice works flawlessly. Avaya cannot even be transfered into the system when calling in from the T so this confirms fax/modem troubles. I did prove to see max errors of SLP's when watching while making telephone calls but not sure where to prove what side they are coming from. I have a new CSU 3160 and new 100DCD card. When I connect 100DCD directly to DMARC I get the same results (voice ok but fax/modem is no good). Gregarican - I've seen better days!
gregarican
IS-IT--Management
This is definitely something else. If I were you I'd be banging my head against the phone board! Here's another of my two cents...
1) Typically slips of this rate are due to lack of consistent framing and clocking. If this is a PSTN circuit then Verizon definitely needs to be providing both.
2) If there was a B8ZS -vs- AMI provisioning issue then typically the circuit would show Bipolar Violations. It would test out fine with All Ones. But test patterns such as 3-in-24 and QRS would fail due to improper provisioning. It doesn't sound like this issue is present. If the All Zeros test is passing then the circuit should be provisioned correctly for ESF/B8ZS.
3) There are two different tests that you should be able to run on both the Paradyne and the Merlin. Payload and Line Loopback tests. These will help narrow down where the signaling is failing. Testing Line Loopback just mirrors back the signal that's coming into the equipment. No reprocessing. If this test passes then you are receiving what you should be. Then Payload Loopback testing will take the signal and regenerate it using the internal equipment. If this test passes then your equipment is doing what it should.
Here's a stab in the dark. Perhaps the Paradyne is internally trying to provide clocking? If the circuit went down for a period of time then the Paradyne could have tried to take over and provide clocking back to Merlin. If so, then it could be interfering with what Verizon is trying to send you for clocking. Checking this setting in the docs I see that by default the Tx Clock is defined as being Internal (TXC) and not External (XTXC). If this is still the case in your situation then this CSU is interfering with what Verizon is sending you.
If the Merlin 100DCD board passes all of its own tests run through WinSPM, Maintenance-->Slot and Verizon's testing of the circuit to the smartjack is fine then I would look closer at the Acculink. Perhaps my guess is on target.
Keep us posted...
1) Typically slips of this rate are due to lack of consistent framing and clocking. If this is a PSTN circuit then Verizon definitely needs to be providing both.
2) If there was a B8ZS -vs- AMI provisioning issue then typically the circuit would show Bipolar Violations. It would test out fine with All Ones. But test patterns such as 3-in-24 and QRS would fail due to improper provisioning. It doesn't sound like this issue is present. If the All Zeros test is passing then the circuit should be provisioned correctly for ESF/B8ZS.
3) There are two different tests that you should be able to run on both the Paradyne and the Merlin. Payload and Line Loopback tests. These will help narrow down where the signaling is failing. Testing Line Loopback just mirrors back the signal that's coming into the equipment. No reprocessing. If this test passes then you are receiving what you should be. Then Payload Loopback testing will take the signal and regenerate it using the internal equipment. If this test passes then your equipment is doing what it should.
Here's a stab in the dark. Perhaps the Paradyne is internally trying to provide clocking? If the circuit went down for a period of time then the Paradyne could have tried to take over and provide clocking back to Merlin. If so, then it could be interfering with what Verizon is trying to send you for clocking. Checking this setting in the docs I see that by default the Tx Clock is defined as being Internal (TXC) and not External (XTXC). If this is still the case in your situation then this CSU is interfering with what Verizon is sending you.
If the Merlin 100DCD board passes all of its own tests run through WinSPM, Maintenance-->Slot and Verizon's testing of the circuit to the smartjack is fine then I would look closer at the Acculink. Perhaps my guess is on target.
Keep us posted...
Burlyman,
A few years Back,I had Installed a new legend With a T1 that was fine for voice, but modems always got kicked off (probably faxes would too but I never checked).
It was a brand new Legend R6.1 and it was a new install. Well the modems never worked (only a day of trying) so verizon came out and checked the circuit and it was OK then they monitored the sysytem side and, it turned out that the SYSTEM was bringing up "activity" on every channel ever second or so. I Ended up Replacing the Processor and It was fixed. Back then, Lucent was More then Willing to Replace that card. They didn't offer a firmware upgrade Just "We'll have a new one for you in the morning", which makes my think there was a Hardware problem.
Well anyway I have a customer I am going to today because in the backround on their PRI (MLR7V14.2) They faintly hear a Vroom Vroom Vroom sound. Maybe it is related maybe not. I am going to try a CKE 5 to see if it clears it.
Don
A few years Back,I had Installed a new legend With a T1 that was fine for voice, but modems always got kicked off (probably faxes would too but I never checked).
It was a brand new Legend R6.1 and it was a new install. Well the modems never worked (only a day of trying) so verizon came out and checked the circuit and it was OK then they monitored the sysytem side and, it turned out that the SYSTEM was bringing up "activity" on every channel ever second or so. I Ended up Replacing the Processor and It was fixed. Back then, Lucent was More then Willing to Replace that card. They didn't offer a firmware upgrade Just "We'll have a new one for you in the morning", which makes my think there was a Hardware problem.
Well anyway I have a customer I am going to today because in the backround on their PRI (MLR7V14.2) They faintly hear a Vroom Vroom Vroom sound. Maybe it is related maybe not. I am going to try a CKE 5 to see if it clears it.
Don
Sorry to dwell on this item but, I still think that you do not have the Paradyne 3160 dsu/csu set up correctly to allow for both voice and data calls per port.
I am assuming the ports are all configured for RBS.
Chapter 4 in the paradyne manual explains the port allocation and what it might block or what 8k or 4k overhead each channel may use for call setup and tear down.
Hear are some key notes:
The DSU/CSU arrives with two preset factory default configuration settings. These settings are based on the following:
— Factory 1 – ESF framing format with B8ZS line coding format for both the network and the DTE Drop/Insert (DSX-1) interfaces. Data ports are unassigned.
— Factory 2 – D4 framing format with AMI line coding format for both the network and the DTE Drop/Insert (DSX-1) interfaces. Data ports are unassigned.
Specify DTE Drop/Insert (DSX-1) Voice Channels. Specifies which DS0 channels from the DTE Drop/Insert (DSX-1) interface are voice channels and should pass Robbed Bit
Signaling information to the network interface.
Line 1 displays the 24 channels for the DTE Drop/Insert (DSX-1) interface. Line 2 displays whether the DS0 channel indicated in Line 1 is a voice or data channel. Possible values for Line 2 are:
Value Meaning
RBS This DS0 channel is a voice channel carrying RBS information. When this DS0 channel is assigned to a network DS0 channel, RBS information is preserved across the connection.
Data This DS0 channel is a data channel that does not contain RBS information.
Signaling is not preserved across the connection.
Press the Function key below the desired channel to toggle between RBS and Data.
I would cut out the middle man and call Paradyne's support group and have them go through the programming of that DSU/CSU.
Failing that, upgrade the processor.
(I knew I saw that voice/data think somewhere before, as I mentioned in my last post. It was on these damn Paradyne DSU/CSU 3160's
Netcon1
I am assuming the ports are all configured for RBS.
Chapter 4 in the paradyne manual explains the port allocation and what it might block or what 8k or 4k overhead each channel may use for call setup and tear down.
Hear are some key notes:
The DSU/CSU arrives with two preset factory default configuration settings. These settings are based on the following:
— Factory 1 – ESF framing format with B8ZS line coding format for both the network and the DTE Drop/Insert (DSX-1) interfaces. Data ports are unassigned.
— Factory 2 – D4 framing format with AMI line coding format for both the network and the DTE Drop/Insert (DSX-1) interfaces. Data ports are unassigned.
Specify DTE Drop/Insert (DSX-1) Voice Channels. Specifies which DS0 channels from the DTE Drop/Insert (DSX-1) interface are voice channels and should pass Robbed Bit
Signaling information to the network interface.
Line 1 displays the 24 channels for the DTE Drop/Insert (DSX-1) interface. Line 2 displays whether the DS0 channel indicated in Line 1 is a voice or data channel. Possible values for Line 2 are:
Value Meaning
RBS This DS0 channel is a voice channel carrying RBS information. When this DS0 channel is assigned to a network DS0 channel, RBS information is preserved across the connection.
Data This DS0 channel is a data channel that does not contain RBS information.
Signaling is not preserved across the connection.
Press the Function key below the desired channel to toggle between RBS and Data.
I would cut out the middle man and call Paradyne's support group and have them go through the programming of that DSU/CSU.
Failing that, upgrade the processor.
(I knew I saw that voice/data think somewhere before, as I mentioned in my last post. It was on these damn Paradyne DSU/CSU 3160's
Netcon1
- Thread starter
- #34
Well after numerous days of troubleshooting I bit the bullet for my customer after convincing them that they needed to make a decision as to whether or not they were going to start replacing critical boards one at a time (of course at their expense because the system is not under warranty). After putting a hard loop (plug in network side of Paradyne) the csu/loopback on legend worked perfectly. I then had Verizon put their circuit in CO in loopback and the test ran fine. However, no matter how I had circuit connected to legend (with or without the CSU) I constantly got SLP's and quite rapidly as I mentioned before. I reconfigured a standard in-bound LS trunk in a seperate pool and assigned dialcode to fax extension and all worked fine. I concluded (without Avaya at this point!) that the processor was probably ok. So, I convinced client to partially eat cost of another 100DCD if I openend it and it wasn't the problem but ..... guess what? - THE FRICKEN CARD WAS BAD ALL ALONG!!!!#@$@@&*! All my configurations were correct from day one with the new DCD board, it was just fate that it was bad out of the box. Also it was fate that the original CSU was bad and nothing suggested it was bad until I put a hard loop on the network side. Luckily I gambled with a new $1500 board and it all panned out perfectly. It amazes me that with all the on-board diagnostics/registers/logging, etc... that in my situation, nothing lead to the problem as quick as I would expect. I worked on this problem for numerous hours with Avaya, Verizon, etc.. and it all came down to a shot-in-the-dark! I want to thank all members who have contributed to my questions (especially Gregarican! Thanks for the emails).
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question