pbx support Posted January 7, 2009 Report Share Posted January 7, 2009 Hi, We were monitoring a few calls, and we found that some calls use UDP for transfer rather than RTP. Is it alright or there's some issue that this happens? RTP uses UDP. So that is not a problem. Monitoring tool such as wireshark lets to view/decode those packets as RTP. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 8, 2009 Report Share Posted January 8, 2009 The server is on Public IP. I'll confirm this and also get the make of the firewall, from our service provider. Hopefully no more troubles pop up, but many of the questions I would be asking are below... A Server on a Public IP wouldn't have a firewall...............Correct? Did the Hosting Service present a package saying that they are VoIP - SIP Ready? We have setup all client premise based PBXnSIP systems regardless of Windows or Linux directly on a Public IP...another Internal IP serves the premise.... Have you disabled all unnecessary Windows Services? As I recall, some hosting services had either a software or hardware method allowing them to use cheap hardware to get the features of HP Lights Out Management. I'm not sure how that worked but I could the Hosting Service shed some light on possible problems caused by their management overhead? Is the Disk on this Server physical or part of an ISCSI shared disk space? I would want to know what lies between the Server and the phones - You can determine this using "trace routes" to identify various gateways and perhaps BGP routes out of the Hosting site. Can you put phones on another network (Eliminate your office ISP) and determine what the affects are? The question being asked by doing this is, "Does it improve when on another Network?" Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 9, 2009 Author Report Share Posted January 9, 2009 A Server on a Public IP wouldn't have a firewall...............Correct? We have setup all client premise based PBXnSIP systems regardless of Windows or Linux directly on a Public IP...another Internal IP serves the premise.... It's very odd but this is what they have to say, Our server is currently behind a Netscreen 5 firewall. This is a dedicated hardware firewall and for VoIP applications, we have ensured the appropriate ports are open. Did the Hosting Service present a package saying that they are VoIP - SIP Ready? No, but they claim there's no such limitation from server hardware or network connection on their side. Have you disabled all unnecessary Windows Services? Yes, only essential windows services, and IBM backup manager are running on the server. As I recall, some hosting services had either a software or hardware method allowing them to use cheap hardware to get the features of HP Lights Out Management. I'm not sure how that worked but I could the Hosting Service shed some light on possible problems caused by their management overhead? We checked the hardware and also used some benchmarking utilities, it's genuine. Is the Disk on this Server physical or part of an ISCSI shared disk space? Yes, physical drives, two 250GB SATA drives configured as a RAID1 (mirroring) array using a 3Ware RAID card. I would want to know what lies between the Server and the phones - You can determine this using "trace routes" to identify various gateways and perhaps BGP routes out of the Hosting site. Trace from the server to our firewall (Where the phones are located) 1 <1 ms <1 ms <1 ms fl1rt1.dialtoneinternet.net [216.150.24.3] 2 <1 ms <1 ms <1 ms 216.87.0.46 3 <1 ms <1 ms <1 ms 216.187.124.149 4 1 ms 1 ms 1 ms 10ge-xe0-0-0.mia-tmrk-cor-1.peer1.net [216.187.124.130] 5 1 ms 1 ms 1 ms so-9-1.car1.Miami1.Level3.net [4.79.96.209] 6 1 ms 14 ms 1 ms ae-32-52.ebr2.Miami1.Level3.net [4.69.138.126] 7 14 ms 14 ms 17 ms ae-2.ebr2.Atlanta2.Level3.net [4.69.140.142] 8 18 ms 18 ms 18 ms ae-63-60.ebr3.Atlanta2.Level3.net [4.69.138.4] 9 34 ms 36 ms 35 ms ae-2.ebr1.Washington1.Level3.net [4.69.132.86] 10 34 ms 36 ms 36 ms ae-81-81.csw3.Washington1.Level3.net [4.69.134.138] 11 29 ms 28 ms 29 ms ae-3-89.edge2.Washington4.Level3.net [4.68.17.147] 12 38 ms 36 ms 36 ms if-8-0.icore1.AEQ-Ashburn.as6453.net [206.82.139.65] 13 29 ms 29 ms 29 ms if-2-0-0-457.core3.AEQ-Ashburn.as6453.net [209.58.27.129] 14 34 ms 33 ms 34 ms if-5-0.core2.NTO-NewYork.as6453.net [216.6.51.6] 15 34 ms 34 ms 34 ms if-1-0-0.core1.NTO-NewYork.as6453.net [216.6.97.14] 16 34 ms 33 ms 34 ms ix-8-0.core1.NTO-NewYork.as6453.net [216.6.82.42] 17 227 ms 228 ms 228 ms segment-124-7.sify.net [124.7.187.29] 18 227 ms 229 ms 227 ms segment-124-7.sify.net [124.7.187.5] 19 228 ms 228 ms 227 ms segment-124-7.sify.net [124.7.187.1] 20 227 ms 227 ms 228 ms 119.227.4.61 21 227 ms 229 ms 228 ms 210.18.5.141.sify.net [210.18.5.141] I've taken out the Firewall IP at the end of the trace. Can you put phones on another network (Eliminate your office ISP) and determine what the affects are? The question being asked by doing this is, "Does it improve when on another Network?" I'll work on this. Currently personnel at remote location are also facing the issues. But i have no idea of their internet connection. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 9, 2009 Report Share Posted January 9, 2009 16 34 ms 33 ms 34 ms ix-8-0.core1.NTO-NewYork.as6453.net [216.6.82.42]17 227 ms 228 ms 228 ms segment-124-7.sify.net [124.7.187.29] Whow that is a very long delay. When you make a phone call echo will be very obvious and it will be difficult to have a natural conversation. Just a side note... Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 10, 2009 Report Share Posted January 10, 2009 The way I see this is you have a US hosted PBX, with hope of extending US dialing to India. Right? Seems the final links on the journey are introducing 200ms plus delays - and we have found anything over 60ms has the potential to cause troubles. Several companies specialize in India VoIP service as we'll be doing the same this for a client in the next 3 months. Fix that problem. Our first attempt for this project will be with http://www.telifu.com Two Comments and a Wrap 1. Early you commented you had a Public IP, and now we hve a firewall. I would request a 1-1 NAT on the Public IP on the Firewall to your server. Opening RTP ports, adds processor and memory overhead to the SPI firewall and a 1:1 nat gets out of the way and passed all traffic far more effeciently. 2. For Everyone who reads this post, - this affirms the need to have a quality preinstallation plan - checklist. You can't built a square house on crooked bricks. Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 12, 2009 Author Report Share Posted January 12, 2009 The way I see this is you have a US hosted PBX, with hope of extending US dialing to India. Right? Seems the final links on the journey are introducing 200ms plus delays - and we have found anything over 60ms has the potential to cause troubles. Several companies specialize in India VoIP service as we'll be doing the same this for a client in the next 3 months. Fix that problem. Our first attempt for this project will be with http://www.telifu.com Two Comments and a Wrap 1. Early you commented you had a Public IP, and now we hve a firewall. I would request a 1-1 NAT on the Public IP on the Firewall to your server. Opening RTP ports, adds processor and memory overhead to the SPI firewall and a 1:1 nat gets out of the way and passed all traffic far more effeciently. 2. For Everyone who reads this post, - this affirms the need to have a quality preinstallation plan - checklist. You can't built a square house on crooked bricks. We are using several Vonage phones http://www.vonage.com/ in India with out any problems past 3 years. We do not face lag or echo problems in the service. Secondly, We have offices in both US and India. Correct me here if am wrong, IP-PBX systems are supposed to give a user Geographical Independence. Which means any where in the world (Depending on the laws of the country) I can use a Phone extension, provided I have an internet connection. We do have successful calls using the system, from India to US, without any lags, delays, jitters, echos, problems. Only thing is the reliability for a new call, even in the US. So, I would conclude Geography should NOT be a hurdle. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 12, 2009 Report Share Posted January 12, 2009 So, I would conclude Geography should NOT be a hurdle. Did you not see the 200ms delays in your tracerts? 14 34 ms 33 ms 34 ms if-5-0.core2.NTO-NewYork.as6453.net [216.6.51.6] 15 34 ms 34 ms 34 ms if-1-0-0.core1.NTO-NewYork.as6453.net [216.6.97.14] 16 34 ms 33 ms 34 ms ix-8-0.core1.NTO-NewYork.as6453.net [216.6.82.42] 17 227 ms 228 ms 228 ms segment-124-7.sify.net [124.7.187.29] 18 227 ms 229 ms 227 ms segment-124-7.sify.net [124.7.187.5] 19 228 ms 228 ms 227 ms segment-124-7.sify.net [124.7.187.1] 20 227 ms 227 ms 228 ms 119.227.4.61 21 227 ms 229 ms 228 ms 210.18.5.141.sify.net [210.18.5.141] I could be next door and if my ISP or router injected 200ms+ of delay I would experience troubles. Tracert occurred at the bottom three layers of the stack and is application agnostic. You need to focus you attention on this issue. http://www.hinduonnet.com/seta/2002/04/18/...41800050300.htm Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 12, 2009 Author Report Share Posted January 12, 2009 Did you not see the 200ms delays in your tracerts?14 34 ms 33 ms 34 ms if-5-0.core2.NTO-NewYork.as6453.net [216.6.51.6] 15 34 ms 34 ms 34 ms if-1-0-0.core1.NTO-NewYork.as6453.net [216.6.97.14] 16 34 ms 33 ms 34 ms ix-8-0.core1.NTO-NewYork.as6453.net [216.6.82.42] 17 227 ms 228 ms 228 ms segment-124-7.sify.net [124.7.187.29] 18 227 ms 229 ms 227 ms segment-124-7.sify.net [124.7.187.5] 19 228 ms 228 ms 227 ms segment-124-7.sify.net [124.7.187.1] 20 227 ms 227 ms 228 ms 119.227.4.61 21 227 ms 229 ms 228 ms 210.18.5.141.sify.net [210.18.5.141] I could be next door and if my ISP or router injected 200ms+ of delay I would experience troubles. Tracert occurred at the bottom three layers of the stack and is application agnostic. You need to focus you attention on this issue. http://www.hinduonnet.com/seta/2002/04/18/...41800050300.htm The article is 6 years old. Moreover Latency will cause delay in the calls, not problems. Also, a latency of upto 250 ms is not very noticeable. Since, you are so concerned for Geography, why do our US counter parts also face the same problems? They have latency in 20's and 30's ms. The least you can do is help me identify and resolve their issues; rather than pointing out Geographical problems. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 13, 2009 Report Share Posted January 13, 2009 The article is 6 years old.Moreover Latency will cause delay in the calls, not problems. Also, a latency of upto 250 ms is not very noticeable. Since, you are so concerned for Geography, why do our US counter parts also face the same problems? They have latency in 20's and 30's ms. The least you can do is help me identify and resolve their issues; rather than pointing out Geographical problems. I'm sorry, you've confused me with someone you might be paying for support. The least I can do is to do nothing and ignore your plea's for help. Instead, I've tried to point in the right direction. Best of luck to you. Cheers. 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.