Jump to content

CS410 unresponsive


Dave
 Share

Recommended Posts

I just got a CS410, setup was nice and easy works the way I want it to. The problem I am having is this ... Call in to the CS410, call goes to a hunt group, phones ring, if nobody answers call goes to to voice mail on an ext. Simple setup. I can only get one call in, after that the system becomes very slow, can't open the web interface or ping the PBX. sometimes I can get two calls in before it becomes unresponsive. The only way to fix it is a reboot of the system. I tried to run a top via ssh but ssh dies so I can't see what process it is hanging on. firmware version is 3.2.0.3143 ...

 

Thanks

Dave

Link to comment
Share on other sites

I just got a CS410, setup was nice and easy works the way I want it to. The problem I am having is this ... Call in to the CS410, call goes to a hunt group, phones ring, if nobody answers call goes to to voice mail on an ext. Simple setup. I can only get one call in, after that the system becomes very slow, can't open the web interface or ping the PBX. sometimes I can get two calls in before it becomes unresponsive. The only way to fix it is a reboot of the system. I tried to run a top via ssh but ssh dies so I can't see what process it is hanging on. firmware version is 3.2.0.3143 ...

 

If you cannot ping the system anymore we are talking about a problem at the lower levels. Maybe you can log in through SSH right after startup and then start top to see if we have a problem with the memory, CPU or something else looking strange. Anything else strange? If the network in good shape?

Link to comment
Share on other sites

If you cannot ping the system anymore we are talking about a problem at the lower levels. Maybe you can log in through SSH right after startup and then start top to see if we have a problem with the memory, CPU or something else looking strange. Anything else strange? If the network in good shape?

 

Hello,

 

I have the same problem that the cs410 will run for a couple minutes then I can't even ping it.

Seems like 10 minutes or less.

After a reboot it works for about 10 minutes and becomes unpingable again.

 

(initially i also noticed that i needed to plug the cat5 cable into the WAN port for the unit to get an ip via dhcp.)

 

its a black unit. Just got it. I upgraded it to the latest firmware/image.

 

matt

Link to comment
Share on other sites

I have the same problem that the cs410 will run for a couple minutes then I can't even ping it.

Seems like 10 minutes or less.

After a reboot it works for about 10 minutes and becomes unpingable again.

 

(initially i also noticed that i needed to plug the cat5 cable into the WAN port for the unit to get an ip via dhcp.)

 

its a black unit. Just got it. I upgraded it to the latest firmware/image.

 

Again very strange. Can you SSH in and run top?

Link to comment
Share on other sites

Top shows you what processes are active, how much memory is used and all kinds of other interesting stuff about the healthyness of the system. The command line is just "top" <enter>.

 

Hi,

 

Ok, just had the cs410 running overnight.

Once again the LAN port failed to respond after approx. 10 minutes...but i left the cs410 run overnight.

This morning on a whim I plug the cat5 cable into the WAN port and it works...

 

So...a faulty LAN port?

 

matt

Link to comment
Share on other sites

I've seen many posts with similar symptoms reported on CS410's and we have deployed more than a few over the last year or so and have never experienced any of these issues. Lucky perhaps, but here is how we have avoided these troubles.

 

1. We exclusively use SMART MANAGED SWITCHES and we take full advantage of all 802.1PQ tools and weighted Queues, and SNMP remote management.

2. We NEVER.. (Seldom) .....use a NATTED FIREWALL ahead of a CS410 or any PBX. When forced to do so for one REASON only.. The client has a SINGLE IP address. We specifically use an Intertex IX series router with SIP detection. We are presently reviewing an alternative for 1 reason only. Intertex does not support SNMP access or TRAPS.

3. ROUTERS FIREWALL ETC that have PNP autoconfigs enabled like residential LINKSYS, DLINK ETC gave a previous poster 3 weeks of really crappy performance.

4. DON'T Log anything unless it's in the act of diagnosing or Tweaking a feature.

5. USE SNMP wherever possible to gauge performance.

6. USE PBXnSIP PNP with all deployments

7. Know (Don't Assume) anything about the configuration of the analog lines by the telco provider and have the tools to verify the POTS lines are you hope they are. We see more and more POTS coming from IAD's and the config options for disconnect detections, ring volts and tones are many. REMEMBER the CS410 has a seperate 4 PORT ANALOG gateway in much the same way you would use an audiocode mp114 or other gateway.

Link to comment
Share on other sites

I've seen many posts with similar symptoms reported on CS410's and we have deployed more than a few over the last year or so and have never experienced any of these issues. Lucky perhaps, but here is how we have avoided these troubles.

 

1. We exclusively use SMART MANAGED SWITCHES and we take full advantage of all 802.1PQ tools and weighted Queues, and SNMP remote management.

2. We NEVER.. (Seldom) .....use a NATTED FIREWALL ahead of a CS410 or any PBX. When forced to do so for one REASON only.. The client has a SINGLE IP address. We specifically use an Intertex IX series router with SIP detection. We are presently reviewing an alternative for 1 reason only. Intertex does not support SNMP access or TRAPS.

3. ROUTERS FIREWALL ETC that have PNP autoconfigs enabled like residential LINKSYS, DLINK ETC gave a previous poster 3 weeks of really crappy performance.

4. DON'T Log anything unless it's in the act of diagnosing or Tweaking a feature.

5. USE SNMP wherever possible to gauge performance.

6. USE PBXnSIP PNP with all deployments

7. Know (Don't Assume) anything about the configuration of the analog lines by the telco provider and have the tools to verify the POTS lines are you hope they are. We see more and more POTS coming from IAD's and the config options for disconnect detections, ring volts and tones are many. REMEMBER the CS410 has a seperate 4 PORT ANALOG gateway in much the same way you would use an audiocode mp114 or other gateway.

 

 

Good tips.

 

We are getting a replacement cs410 and I'll report if it is ok.

 

tx

matt

Link to comment
Share on other sites

  • 3 months later...
Good tips.

 

We are getting a replacement cs410 and I'll report if it is ok.

 

tx

matt

 

 

I had this problem also. In the testbed I had a CS410 with a default config. Initially I was working with a windows 2003 DHCP server, Cisco Cat2950T on a isolated vlan un untagged mode and a cisco pix on the vlan. The box would acquire an IP address and would respond properly. After some random time interval I found that the unit would stop responding To isolate the problem I installed a replacement CS410 from a completely different batch and it displayed the same issues.

 

Remembering back in the the day when there were competing "standards" for 100baseT transceivers. I had LOTS of problems with equipment that used National Semi's nWay chips. I then decided to utilize different ethernet switches. I tried the same setup as above using an HP Procurve 4000, HP Procurve 2626 L3 Switch. I believe the 2626 and the 2950T both use a broadcom based solution. Still no luck.

 

I also tried it using a Adtran NetVanta 1355/6355 in an isolated vlan with only the adtran doing routing and dhcp services. Same problem. Also using a broadcom solution.

 

I decided to put into a clients network. I had a Netgear L2 Managed PoE switch and a netopia adsl router and win 2003 dhcp. It has been happy so far. Great!

 

I think it is a problem in the ethernet chips the CS410 uses. I dont think they are defective, their just not designed to a good spec. I have yet to look at lspci or crack open the case. I bet it has some of thoes crab-claw (realtek) chips. I still have problems with thoes across all environments. I hate getting crabs! 8-)

 

Oh well, food for thought!

 

-Isaac

Link to comment
Share on other sites

I think it is a problem in the ethernet chips the CS410 uses. I dont think they are defective, their just not designed to a good spec. I have yet to look at lspci or crack open the case. I bet it has some of thoes crab-claw (realtek) chips. I still have problems with thoes across all environments. I hate getting crabs! 8-)

 

Unfortunately, we cannot change the chips with a software update. B) But at least it would be good to know what exactly is the problem. I know from other cases that it might help to set the link speed to 10 MBit/s, which is a lot less critical than 100 MBit/s.

Link to comment
Share on other sites

The OEM technology behind the CS410 is made by http://www.mindspeed.com/web/home.html they are perhaps one of the largest manufacturers of this type of technology that serves as the basis for many different PBX platforms. Technically 10/100 BaseT L1/L2 stacks have been around for a very long time and I do not arbitrarily agree without some very strong evidence the chipset is to blame. For the most part all previous bugs or features within PBXnSIP have been addressed by the PBXnSIP development team.

 

However, Since PBXnSIP has offered such a product onto the market they need to create clearly understood documentation and setting recommendations for use on a wide variety of Analog Lines. They are competing with traditional PBX systems that have operated on the same analog lines that continually take much of the blame in many posts. well over 1,000,000 Lucent Partner phone systems have been sold and installed throughout the world and I'll guess 75% may still be in use today and they are on the same crappy analog lines.

 

So the challenge is to make the system tolerant of a wide range of potential issues and to know them ahead of time as to prevent problems for customers considering PBXnSIP.

 

Cheers,

Link to comment
Share on other sites

The OEM technology behind the CS410 is made by http://www.mindspeed.com/web/home.html they are perhaps one of the largest manufacturers of this type of technology that serves as the basis for many different PBX platforms. Technically 10/100 BaseT L1/L2 stacks have been around for a very long time and I do not arbitrarily agree without some very strong evidence the chipset is to blame. For the most part all previous bugs or features within PBXnSIP have been addressed by the PBXnSIP development team.

 

However, Since PBXnSIP has offered such a product onto the market they need to create clearly understood documentation and setting recommendations for use on a wide variety of Analog Lines. They are competing with traditional PBX systems that have operated on the same analog lines that continually take much of the blame in many posts. well over 1,000,000 Lucent Partner phone systems have been sold and installed throughout the world and I'll guess 75% may still be in use today and they are on the same crappy analog lines.

 

So the challenge is to make the system tolerant of a wide range of potential issues and to know them ahead of time as to prevent problems for customers considering PBXnSIP.

 

Cheers,

 

</RANT>

Ethernet performance / reliability totally depends on not only on the "[L3-L7 software] stacks" but also in the MAC (Layer 2) and PHY (Layer 1) design in hardware. The first two layers are critical for system design. The PHY and MAC still require actual engineering, you cant just plunk down a commodity IC and be done. I wish it were that easy, then I would not have to be as picky when choosing products.

 

As for the partner systems, I love them to death. I have installed many over the years, but I would not say they were super reliable. I had alot of issues with them until the ACS series was released. An still had issues whenever I used a backplane (2 or 5). Usually once all the modules were happy (after a month or so of use) then I would have little or no problems for years. My favorite were the Nortel CICS/ICS systems. Clean single pair digital sets and 0 replacements over ALL of my my installs. Liked the Meridian also but hated the programming. LD Whats that damn number??? 8-)

 

Analog lines (POTS) for the most part are very reliable and quality is usually good. Where I see the problems are where the line usually has acquired a defect over time. Bad termination, unbalanced line, shielding degradation or metallurgy reaction. The problems can usually be fixed quickly once the problem has been isolated unless you have a bad LEC.

 

PRI/T1 lines are amazing but they are more sensitive to line problems than pots are. They are usually very touchy when bit errors occur easly dropping ALL calls. I am seeing many more circuits with high bit error rates. Most circuits I had installed prior to 2000 have a 0 BER over many weeks. My guess is the HDSL technology the carriers use to deliver a T1 now a days are no match to true T1 with repeaters.

 

SIP trunking is nice now and will only get better with time. It is nice because it eliminates the direct use of L1&L2. Once you have a good IP network connection its mostly happy. The only gripe I have is the lack of true vendor %100 feature compatability/ standard implementation. SIP does let you work in a basic mode if need be, but stuff like how to send the dialed number to the other party still can be interpretated in different ways. I think we need a thing like National-ISDN did for BRI & PRI lines.

 

</ENDRANT>

Link to comment
Share on other sites

A realists reply to a RANT.

 

Crack one open and you'll find the following http://www.mindspeed.com/web/product/categ...;trail=562,1039 A Single chip (no stand-alone Realtek), designed and in use by hundreds of thousands of OEM devices around the world. This isn't a 2-bit organization building a clone on a chip, but an internationally recognized leader in voice processing. See their line-card http://www.mindspeed.com/web/download/down...jsp?docId=30526

The have an embedded release of Debian 3.x and core technology to support their integrated analog gateway and LAN interfaces. It's really a matter of PBXnSIP working with their provider to further expose capabilities to the development team without making a code that would be specific to the CS410.

 

As the the rest of the commentary on T1's etc, OK.

 

Cheers

Link to comment
Share on other sites

A realists reply to a RANT.

 

Crack one open and you'll find the following http://www.mindspeed.com/web/product/categ...;trail=562,1039 A Single chip (no stand-alone Realtek), designed and in use by hundreds of thousands of OEM devices around the world. This isn't a 2-bit organization building a clone on a chip, but an internationally recognized leader in voice processing. See their line-card http://www.mindspeed.com/web/download/down...jsp?docId=30526

The have an embedded release of Debian 3.x and core technology to support their integrated analog gateway and LAN interfaces. It's really a matter of PBXnSIP working with their provider to further expose capabilities to the development team without making a code that would be specific to the CS410.

 

As the the rest of the commentary on T1's etc, OK.

 

Cheers

andrewgroup,

 

Please read what I posted, Its not all about the chip! Mindspeed uses IP cores from multiple vendors, just look at their block diagram from the link you gave me. They just licensed different cores and put them together on a single ic, no big deal there. Also if you read further it only has a RMII (WAN PORT) and MII (LAN PORT). MII/RMII interfaces still need an engineered analog front end (PHY). This is where the Taiwaneese or Chineese company engineers the PCB. This is where the QA plays a big roll, any where my problem might be.

 

I have worked in telecommunications doing EE, ID and embedded systems for many years, for companies like AT&T Bell Labs, Ameritech, Compuserve, Glennayre/Western Multiplex. I know how things SHOULD be designed. Most of the IC and parts have become such a commodity which is great by bringing the prices down drastically. The side effect is the quality control and or tolerances parts are manufactured to have drastically decreased. At Bell Labs/ Lucent we even manufactured our own parts. ICs, CPUs and even resistors (wire wrapped by hand!) to overcome the sloppy tolerances of these commodity suppliers. Every device before leaving the factory was tested in a stack oven for burnin. QA was always pulling assemblies out to analyze them to optimize the process and quality. So Parts can be an issue, but the overall engineering and QA are what make a difference.

 

I dont care for linux on an embeded device, I would prefer a RTOS like VxWorks or QNX. If a problem occurs it needs to recover immediately. If you look at the most reliable phone systems, usually they are running VxWorks. The systems I have had problems with are ones who use a linux desktop os kluged into being a embeded os. Not to say its not possible to create a great product using linux. Development of the actual product or IP is what matters most. If you are outsourcing/licensing an os to run your app why should you have to waste time correcting problems in the OS? Thats what you are trying to avoid by utilizing a 3rd party OTS/COTS embedded environment.

 

In this situation as a enduser / reseller I am not suppose to care what is inside (software or hardware) just if the widget will complete the task required..... being an engineer I like to find out why things failed, hence my testing and posts on forums like this. Please dont get wound up over my posts, they were not an insult directed to you. I did want to know from matt if getting a replacement solved the issue. If the replacement worked, is it a design flaw or bad QA. As per PBXnSIP, policy, communications and training, the forum is the first official step to work problems with PBXnSIP.

 

The bottom line... Reliability is everything for a phone system. If I have a product that acts in an unreliable and inconsistent manor I will not recommend it. simple as that.

 

-Isaac

Link to comment
Share on other sites

This is fun.

Why did two of the largest PBX developers in the World Select Linux as opposed to a RTOS? Avaya, Nortel BCM and Nortel Just announce Linux is going into the VSP9000 series equipment. Any guess as to how may installations of Asterisk/Linux are deployed around the world?

I'm not suggesting that any of these are on par with the long list of superior products you have listed, but it does indicate a trend according to my understanding of statistics. The way I see it, is that PBXnSIP, Linux, and MindSpeed are fully consistent with these trends.

 

I do hope the replacement unit addresses your problem.

 

I do think the most common problem with most VoIP installations is a lack of understanding and poor diagnostic skills. Of course things must be configured to leave traces to indicate the problems too. this is where managed devices and monitoring systems come into play.

Cheers,

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...