sandeep
-
Posts
17 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by sandeep
-
-
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.
-
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.
-
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?
-
Hi There,
We've updated to the latest version 3.1.2.3120
So far, no issues have popped up
-
Which Firewall do you have at the server location? Is the server behind NAT?
Firewall appliance: Juniper NetScreen-5GT.
-
You can easily confirm it is on a public IP, just by logging in remotely and doing an ipconfig from a command prompt.
Yes, the Ethernet adapter shows the Public IP addresses of the server.
-
Which Firewall do you have at the server location? Is the server behind NAT?
The server is on Public IP.
I'll confirm this and also get the make of the firewall, from our service provider.
-
Let me share with you my basic rules of analysis - regardless of how complex the system.
1. Don't ask questions that cannot be answered yes or no. - If the answer isn't yes or no, simplify the question.
I would surely like to do this.
Only thing, I don't know what are the question to be asked.
If initially you can put down the questions, may be I'll also be able to come up with some.
2. The goal of every question must be to determine those parts of the system that are working. Thus reducing the target area.This not very clear. Can you drill down a bit more.
The questions so far very high level questions and any answers are simply guesses.I didn't know from where to start. I came here seeking guidance from the members
Let's start over..It's fine with me.
Is this a VIRTUAL MACHINE in the hosting facility?NO, It's a physical box.
Have you successfully configured and tested a Server 2003 in your offices?Yes, we have several Windows Server 2003 in our offices. Both Physical and Virtual.
-
Moreover, the server is now on for several days, now the disconnection is more likely and frequent as well. Is there any thing we can check on over here.
-
Well, SIP packets don't count for RTP. By receiving the SIP packet the PBX cannot learn the address (especially the port number) of the device.
I checked the logs again. Your right, there wasn't any RTP packet from the Phone to Server, when the call had failed. But, there were when calls were successful.
Check the phone settings. Or check the SIP packets coming from the phone. If they appear to have public IP addresses (while the phone has a private IP address), then there is probably someone messing with STUN.I'm not clear of what you meant.
The SIP header looks like this:
Via: SIP/2.0/UDP 192.168.1.21:2051;
branch=z9hG4bK-8ril183od97h;
rport=50570;
received=<Firewall Public IP Address>
I think this is fine, as the server should know where to find the Phone...
For the Phone Setting we have Polycom IP 330 and SNOM 360 phones.
For the SNOM: We have left the STUN settings blank.
For the Polycom: There is no such setting.
Not that I am aware of. There are so many devices in the market. If you have another router, I would just try that other one to see if that makes a difference.We use different firewalls as we have multiple locations. Since all of us are facing similar issues there may be something to do on the server.
Some Phones are also on a Public IP...
-
It is okay if the PBX first attempts to send the RTP to a private address. As soon as it gets RTP from another location it will change the destination. It seems that no RTP packet makes it from the phone to the PBX.
What firewall are you using? Maybe all ports are in use? Is it a "low-quality" firewall? We have seen products that just have NAT 32 entries.
Are you using the old troublemaker called STUN on the phones? The problem with STUN is that it is so unstable. 99 % of the cases it works and troubleshooting the other 1 % is extremly difficult. That is why we recommend not to use STUN.
I've check the report. During the call, three SIP packets were received by server from the calling phone with a '200' status code. The outgoing IP did not change.
More over this happened only during the first call(~24hrs gap between the last usage). After that I had 5 calls with intervals of more than 30m, it worked fine.
We are using an LinkSys RVS4000. Is this an issue causing device?
I'm sure we aren't using STUN, how do i confirm this?
-
I've Captured some calls using WireShark.
For the call where we do not hear audio. We've found the RTP packets going to the phones IP (an private IP address) instead of the public IP of the firewall, behind which we have the IP-Phones.
The media was coming fine from the trunk provider, but the RTP packets between the server and the IP-Phones was being sent to an private IP address (192.168.1.x).
For the call that work fine, it goes to a socket on the firewall only.
-
It really makes sense to use a tool to troubleshoot this. Try Wireshark, run it on your PBX. This will tell you if the PBX gets media when it should.
Otherwise we are just shooting in the dark!
The behavior is very unpredictable. I tried it about 20 mins back and everything was working fine.
Is there any software which will run as a service. So that, as soon as we face a disconnection we can retrieve the captures.
Are the PBX logs of use for this?
-
I would also open TCP 5061 (TLS port).
We have assembled a checklist at http://wiki.pbxnsip.com/index.php/One-way_Audio, anything from there? Maybe something "stupid" as a IP address conflict.
IP Address Conflict is not a case, we've reviewed the configuration several times. Also, we have Phones, not within a single location or network.
We've not loaded a certificate on the server, but still we'll open the port.
I'll check the Codec Mismatch section. This may be related to us.
Secondly, when receiving a call, the first call has no audio, but the immediate next call works fine. What could be causing this?
Thanks
-
Thanks for your reply,
We have a dedicated firewall and we have opened ports:
TCP: 5060, 80, 443
UDP: 5060, 49152-65534
As for the Personal firewall, we have none on the system. We do have McAfee Enterprise 8.5i, we'll uninstalled it to check.
We have also disabled TCP/IP filtering on the server.
Anything else we may check for...
-
Hi There,
We have setup a PBXnSIP server, on Windows Server 2003 SP2 at Peer1 hosting services (www.peer1.com).
We are facing one way audio, also for extensions. External calls initiate for 15-20secs and then disconnect or have one way audio.
Once the server is restarted the problem seems resolved. The calls made after that are quite stable. But still unpredictable.
We are unsure of the problem, any guidance to troubleshoot will be very helpful.
We are using the windows version of PBXnSIP v3.1.1.3110.
Thanks,
Sandeep
Require to Restart PBXnSIP server
in General Setup
Posted
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.