Jump to content

sandeep

Members
  • Posts

    17
  • Joined

  • Last visited

sandeep's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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.
  2. 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.
  3. 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. No, but they claim there's no such limitation from server hardware or network connection on their side. Yes, only essential windows services, and IBM backup manager are running on the server. We checked the hardware and also used some benchmarking utilities, it's genuine. Yes, physical drives, two 250GB SATA drives configured as a RAID1 (mirroring) array using a 3Ware RAID card. 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. I'll work on this. Currently personnel at remote location are also facing the issues. But i have no idea of their internet connection.
  4. 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?
  5. Hi There, We've updated to the latest version 3.1.2.3120 So far, no issues have popped up
  6. Firewall appliance: Juniper NetScreen-5GT.
  7. Yes, the Ethernet adapter shows the Public IP addresses of the server.
  8. The server is on Public IP. I'll confirm this and also get the make of the firewall, from our service provider.
  9. 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. This not very clear. Can you drill down a bit more. I didn't know from where to start. I came here seeking guidance from the members It's fine with me. NO, It's a physical box. Yes, we have several Windows Server 2003 in our offices. Both Physical and Virtual.
  10. 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.
  11. 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. 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. 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...
  12. 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?
  13. 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.
  14. 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?
  15. 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
×
×
  • Create New...