Jump to content

Isaac Schneider

Members
  • Posts

    29
  • Joined

  • Last visited

Isaac Schneider's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. There is no cron service running nor installed on the cs410 only configfiles. The distro is an ancient debian that has long since been dropped from support. I was the one who posted about the ntp bug. This is just one of many issues i have notified PBXnSIP to correct.
  2. I also have a need for multiple greetings: A client running 3.4 has a vmb for a reception calling group. If has flags set to control the ringing. It would be nice to have a flag for lunch and trigger the lunch greeting. But at minimum they would like the ability to select from pre-recorded greetings. I wanted to keep the messages in a single vmb, to reduce confusion and cost of licenses. Any Ideas? Thanks, Isaac
  3. I am familiar with cron, being able to schedule tasks. I was looking for a graceful shutdown of PBXnSIP first then a reboot. I hate doing kill. Is there a url / soap request to restart pbxnsip task? I have been doing a triple sync then do a shutdown -r now. The reboot command is not graceful and I have seen other systems corrupt.
  4. Hello, After working with the CS410s, they work better if they are rebooted frequently. Soft resets, or killing process helps timeout registration problems. Hard reset prevents port busy outs improves audio quality. Has anyone come up with a reliable way to restart units. Ideally I would request the feature be added in under the maintenance, just like clearing the dnd flags. Any linux scripts or recommended options anyone can suggest? Thanks, Isaac
  5. I did just capture a 408 from an invite. System was rebooted just yesterday. Am now seeing 408s and 487s Anyone?
  6. Hello, I have an environment where we switched from a key system to a CS410 running in pbx mode. I have run into frustration on the end users part when dialing out I get a call failed. They do not know if it is a system error or trunk availability. I know it is from trunk availability but they need to have a recording. 1. I ended up creating an extension 599 and placing a recording of "All Trunks are Busy, Please Hang up and try your call again" 2. For trunks I have one group of the builtin POTS ports, I have enabled failover on all error codes. 3. In the dial plan I have created an entry after the POTS trunk: 300:EXTENSION:*:599 It will not fail over to the 599 message. Any Ideas? Thanks, Isaac.
  7. Hello, Has anyone out there come across the problem where phone will drop a call in progress with a message of "Call Failed" on the screen. My guess is that some sip timer value has timed out. It has been difficult problem to capture in a packet trace. This is happening on a CS410 with Aastra 9143i and 57i phones. Network is a small swithed lan with QoS enabled and am doing local POTS trunks on the CS410. Any Ideas?
  8. Richard, All hope is not lost!! If you downloaded 3.3.1.3177 or other current firmwares there is good a chance you can still work with it. In one of my other threads, I was able to determine that there is a bug in the code for networking. http://forum.pbxnsip.com/index.php?showtopic=2696 There are a couple of ways to go about finding or changing the ip address. TouchTone, Factory Reset, Packet sniffing, Educated Guess and last resort... brute force. Lets try a few before giving up hope. I do like the pbxnsip system and I think it is worth trying a few more thing before sending it to its final rest. Determining the IP address using Touch Tone http://wiki.pbxnsip.com/index.php/Installing_the_IP-PBX_Appliance#Determining_the_IP_address_of_the_system Factory Reset: By holding in the reset button until the fxo lights come on solid and then power cycle the box http://forum.pbxnsip.com/index.php?s=&...ost&p=11789 System should now default to 192.168.1.99 mask 255.255.255.0 Packet Sniffing: Connect the appliance directly to your computer with a crossover cable. Run Wireshark (or any packet sniffing software), start capture, fire up cs410 unit. Look for any traffic, specifically the system does some dns lookups and also some NTP requests. This should show the source IP the unit is using. Educated Guess: We know the unit has several default and or internal addresses it could be using. Try pinging the ip addresses from the list below. I would recommend the use of an ethernet crossover cable to limit any external influences. Also dont forget to change your computers IP and subnet mask to match the ones below. PBX IP address:192.168.1.99 Mask:255.255.255.0 PBX IP address:192.168.192.168 Mask:255.255.255.0 PBX IP address:1.1.1.1 Mask:255.255.255.0 One more i cannot find right now.. Brute Force: Get a Hammer..... NO! wait there is a console port that forum member Kevin made a comment to: http://forum.pbxnsip.com/index.php?s=&...ost&p=11753 The system I believe is an OEM reference board, I did have a diagram or URL somewhere. I'll try to get a pinout for the console port. Hope one of these helped. -Isaac
  9. Hello, I have run across a bug when changing the network settings, system is not updating the OS config files. System is running v3.3.1.3177 with a single ethernet cable connected to lan port. Unit by default seems to be stuck with WAN port @ 192.168.1.99 and LAN DHCP. To bypass the gui I edited the following file. /etc/network/interfaces #This file was automatically generated by the IP PBX. auto lo iface lo inet loopback #eth0 is LAN Port auto eth0 iface eth0 inet static address 192.168.0.190 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.0.254 #eth1 is POTS-gateway Net auto eth1 iface eth1 inet static address 1.1.1.1 network 1.1.1.0 netmask 255.255.255.0 broadcast 1.1.1.255 #eth2 is WAN auto eth2 iface eth2 inet dhcp -Isaac
  10. Good News! I seem to have a a bit of insight as to why the box is not syncing ntp properly. The CS410 running pbxnsip v3.3.1.3177 looks like it is using ntpclient http://doolittle.icarus.com/ntpclient/ for a lightweight ntp client. Unlike newer clients who use TCP as well as UDP, ntpclient only works using UDP for queries. Also the source port of 123 can cause issues for return packets. Some ISPs for network and or client protection filter the "server" ports (the first 1024 ports). This can cause the client to fail on routers that do not have an alg with dynamic source ports for NTP. Also due to a bug between windows 2003 server NTP server (w32time) and ntpclient (and others) there is a miscommunication. This has been possibly addressed in a previous hotfix for Server 2003 http://support.microsoft.com/?kbid=830092 . The envirnment I am running in has a 2003 R2 server and contains a newer w32time.dll (version 5.2.3790.3959) than the hotfix. It still has compatability problems with the ntpclient but nothing else on the network. The startup flow goes as follows... The system runs the DHCP client if configured to do so. PBXnSIP box does not receive an NTP server option in a DHCP response, it does not update the system variable. The startup script then defaults the NTPServer variable to use pool.ntp.org The systems startup script /etc/rc5.d/S20pbxnsip contains a rule to set the date to Jan 1st 2008 and then run ntpclient using the NTPServer variable to update the clock. This can work but can cause some problems when NTP is not functioning. You would notice problems registering with sip trunks and external UAs. To get arround the rest of the issues listed above I did the following. Configure a new server pool: I chose to use a more optimized pool - us.pool.ntp.org . This keeps the traffic arround the continental us. to change the pool edit /etc/rc5.d/S20pbxnsip got to line 14 or line as listed below.. if [ -z "$NTPSERVER" ]; then NTPSERVER=pool.ntp.org; fi change to .. if [ -z "$NTPSERVER" ]; then NTPSERVER=us.pool.ntp.org; fi For a full list of optimized pools please visit the following... http://support.ntp.org/bin/view/Servers/NTPPoolServers Change client UDP ports and Poke a hole in firewalll: 1. Add a rule to forward a UDP port from the external wan interface and have the same UDP port for the internal destination. When adding the rule select a port above 1024 and below 65536 2. In the PBXnSIP webgui go to the Admin> Settings> Ports 3. Locate the field named NTP port, enter the port number you selected for your port forwarding rule on step 1. 4. Click on the Save Button 5. Reboot unit (in ssh: sync;sync;sync , reboot) (webgui goto Admin>System>PSTN-Gateway, click reboot) This all seems to have fixed my specific environment and hopefully yours too!. I believe by using another ntp client this problem can be eliminated. Ps. A nice side story, When ntp clients go wrong - http://www.cs.wisc.edu/~plonka/netgear-sntp/ Thanks, Isaac.
  11. Hello, I was troubleshooting a system flag issue and found that the clock is different. The system is set for EST but is 30minutes behind. When going in via ssh, running the date command I show "UTC 2008" at the end of the string. Anyone seen this before? Thanks, Isaac.
  12. 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
  13. </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>
  14. 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
×
×
  • Create New...