Jump to content

Require to Restart PBXnSIP server


sandeep
 Share

Recommended Posts

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...