mike.smith Posted February 27, 2007 Report Share Posted February 27, 2007 Hi - We have several Snom 360's (v6.2.3) connecting to PBXnSIP (v2.0.0.1611). Some of the phones ring when an incoming call is received (using a hunt group). If anyone is in a call when an incoming call is received, the sound drops out for about half a second each time the phones ring. It's not just the phones in the hunt group that are dropping out - all the phones are doing it. This problem started when we upgraded to v2. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 2, 2007 Report Share Posted March 2, 2007 Whow. Sounds like the CPU gets overloaded? There was a problem with the multithreaded priorities in Linux. I think the 1611 might still have that problem, maybe you can try a newer build. We still have a problem with the embedded versions. The Linux scheduler seems to have its own mind. Windows seems to be easier... Quote Link to comment Share on other sites More sharing options...
Keven Vachon Kiptel Posted March 19, 2007 Report Share Posted March 19, 2007 Hi - We have several Snom 360's (v6.2.3) connecting to PBXnSIP (v2.0.0.1611). Some of the phones ring when an incoming call is received (using a hunt group). If anyone is in a call when an incoming call is received, the sound drops out for about half a second each time the phones ring. It's not just the phones in the hunt group that are dropping out - all the phones are doing it. This problem started when we upgraded to v2. Linux Version? Quote Link to comment Share on other sites More sharing options...
mike.smith Posted March 25, 2007 Author Report Share Posted March 25, 2007 Linux Version? No - we're using the Windows version. We've upgraded to 2.0.2.1676, but we're still having the problem. I don't think it's the CPU - it's a fast dual opteron server with no other applications running on it. Quote Link to comment Share on other sites More sharing options...
Keven Vachon Kiptel Posted March 26, 2007 Report Share Posted March 26, 2007 No - we're using the Windows version. We've upgraded to 2.0.2.1676, but we're still having the problem. I don't think it's the CPU - it's a fast dual opteron server with no other applications running on it. Something weird here , could you provide us more info about your setup ( switch model and brand ) , Quote Link to comment Share on other sites More sharing options...
mike.smith Posted April 9, 2007 Author Report Share Posted April 9, 2007 Something weird here , could you provide us more info about your setup ( switch model and brand ) , OK I've been doing extensive testing today (I'm surrounded with phones!). I've found a very simple way to reproduce the problem. I've also confirmed that the problem does NOT happen with PBXnSIP v1.5.1.6. You can reproduce the problem without using an external trunk like this: Extention 200 Extention 201 Extention 202 Extention 203 Extention 204 Extention 205 Hunt group 300 -> rings 203, 204, 205 1) Make a call from 200 to 201. Leave it on speaker-phone. 2) On extention 201, put the call on hold. 3) Extention 200 should be playing hold music out of the loudspeaker. 4) On extention 202, dial 300 (the hunt group). This should ring 203, 204 and 205. 5) As they start ringing, the music playing out of 200 will break up for a second or so. There's also some break-up when they stop ringing. The more extentions in the hunt group, the worse the break up will be. If you're just ringing one extention there's only a small amount of break up. I've tested this on Windows Server 2003, and Windows XP - they all have the same result. All v2.x versions give the same result. The handsets are Snom 360. I've tested it on Netgear and DLink switches. Most importantly, when using v1.5.1.6, there is no break up at all. This pretty much proves it's nothing to do with our network here, and it must be a bug in PBXnSIP. Can you reproduce this behavior? Is there a work-around? I really don't want to downgrade to v1.5, because we now archive all our calls (an excellent new v2.x feature). Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 9, 2007 Report Share Posted April 9, 2007 Well, in the end we can see what is going on only by looking at the Ethereal traces locally on the PBX. If there is significant jitter on RTP already locally on the PBX, we have a CPU overload problem. If it is not the case, we have to drill down into the network and see where the packets get congested. Divide and conquer the problem. Quote Link to comment Share on other sites More sharing options...
Andrew D Kirch Posted May 1, 2007 Report Share Posted May 1, 2007 The Linux scheduler seems to have its own mind. Windows seems to be easier... Exactly, the linux scheduler is significantly smarter and more flexible than it's windows counterpart. Documentation on the scheduler can be found in the documentation directory of the linux kernel source tree. A friend of mine who works on the linux scheduler recommended: "Understanding the Linux Kernel 3rd edition" by O'Riely press. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.