I reproduced this error with SipXecs 3.11.12-014925 and created issue XECS-2408. Logfiles with "INFO"-loglevel have been attached.
This is the first issue that i created. I hope i did everything right. René > On Wed, 2009-03-25 at 13:25 +0100, Rene Pankratz wrote: > >> Hello, >> >> We figured out a serious issue, that causes the sipXproxy process to >> take 100% CPU-usage and and breaks down the whole SipXecs. >> We can reproduce this behaviour on SipX 3.10.2, SipX 3.10.3 and >> 3.11.12-014925. >> >> The following steps lead to this problem: >> Create a hunt-group (e.g.extension 800) in SipX that consists of 3 >> telephones (e.g. 801, 802, 803). All phones shall ring at the same time, >> don't allow call forwarding. >> Modify the call forwardings of the hunt-group members via Webinterface, >> so that the other phones ring if user is busy or activated DND. >> >> Extension 801: >> Forward to 802 if no response and ring 803 at the same time. >> >> Extension 802: >> Forward to 803 if no response and ring 801 at the same time. >> >> Extension 803: >> Forward to 801 if no response and ring 802 at the same time. >> >> With this setting SipX soon starts to act in an unexpected way. >> Unfortunately some phones seemed to ring forever and soon the whole SipX >> broke down. >> Background is that the members of the hunt group shall forward their >> calls to the others when they leave their desk. We expected this could >> be done by configuring SipX in the way described above and activating >> DND when leaving the desk. >> >> Setting the call forwarding of the users to the hunt-group-extension >> causes the same beahviour. >> >> Any suggestions to solve this problem? We want to avoid setting call >> forwardings on the phones. >> > > I'd be very interested in seeing this reproduced, especially on either > 3.10.3 or any recent 3.11. In 3.10.3 we added loop detection that > should have prevented this... > > If you can, set your logging to INFO and configure this, then stop the > sipxpbx, delete your logs (/var/log/sipxpbx/*), restart the services, > make this call and let it fail, then take a snapshot. Open an issue in > the tracker and attach the snapshot. If it's too large to attach, > contact me and we'll find a way to get it, but if you delete the logs > before you start this it probably won't be. > > > > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
