sandeep Posted December 26, 2008 Report Share Posted December 26, 2008 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 Quote Link to comment Share on other sites More sharing options...
shopcomputer Posted December 26, 2008 Report Share Posted December 26, 2008 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 Firewall? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 27, 2008 Report Share Posted December 27, 2008 Firewall? It could be the personal firewall on the server... Maybe some local firewall on the server kicking in and stopping the networking on the process. I don't believe and external firewall would do that. Quote Link to comment Share on other sites More sharing options...
sandeep Posted December 30, 2008 Author Report Share Posted December 30, 2008 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... Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 30, 2008 Report Share Posted December 30, 2008 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... 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. Quote Link to comment Share on other sites More sharing options...
sandeep Posted December 31, 2008 Author Report Share Posted December 31, 2008 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 31, 2008 Report Share Posted December 31, 2008 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? 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! Quote Link to comment Share on other sites More sharing options...
sandeep Posted December 31, 2008 Author Report Share Posted December 31, 2008 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? Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 2, 2009 Author Report Share Posted January 2, 2009 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 2, 2009 Report Share Posted January 2, 2009 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 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. Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 2, 2009 Author Report Share Posted January 2, 2009 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? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 2, 2009 Report Share Posted January 2, 2009 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. 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. 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. Hmm. No pattern to me... We are using an LinkSys RVS4000. Is this an issue causing device? 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. I'm sure we aren't using STUN, how do i confirm this? 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. Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 2, 2009 Author Report Share Posted January 2, 2009 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... Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 2, 2009 Author Report Share Posted January 2, 2009 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. Quote Link to comment Share on other sites More sharing options...
shopcomputer Posted January 2, 2009 Report Share Posted January 2, 2009 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. Which Firewall do you have at the server location? Is the server behind NAT? Quote Link to comment Share on other sites More sharing options...
Friedom-Tech Posted January 2, 2009 Report Share Posted January 2, 2009 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. i have had this issue in the past and it fixed the issue when i unchecked the SIP ALG protocol on the router. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 5, 2009 Report Share Posted January 5, 2009 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. 2. The goal of every question must be to determine those parts of the system that are working. Thus reducing the target area. The questions so far very high level questions and any answers are simply guesses. Let's start over.. Is this a VIRTUAL MACHINE in the hosting facility? Have you successfully configured and tested a Server 2003 in your offices? Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 5, 2009 Author Report Share Posted January 5, 2009 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. Quote Link to comment Share on other sites More sharing options...
shopcomputer Posted January 5, 2009 Report Share Posted January 5, 2009 Which Firewall do you have at the server location? Is the server behind NAT? Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 5, 2009 Author Report Share Posted January 5, 2009 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. Quote Link to comment Share on other sites More sharing options...
shopcomputer Posted January 5, 2009 Report Share Posted January 5, 2009 The server is on Public IP. I'll confirm this and also get the make of the firewall, from our service provider. You can easily confirm it is on a public IP, just by logging in remotely and doing an ipconfig from a command prompt. Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 5, 2009 Author Report Share Posted January 5, 2009 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. Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 5, 2009 Author Report Share Posted January 5, 2009 Which Firewall do you have at the server location? Is the server behind NAT? Firewall appliance: Juniper NetScreen-5GT. Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 6, 2009 Author Report Share Posted January 6, 2009 Hi There, We've updated to the latest version 3.1.2.3120 So far, no issues have popped up Quote Link to comment Share on other sites More sharing options...
sandeep Posted January 7, 2009 Author 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? 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.