Jump to content

Changed to CISCO ASA router and NO SOUND


cmrabet

Recommended Posts

Hi

 

Our PBXnSIP server has been working pretty good for more than one year so far, installed in a very stable Linux server and under DMZ in a home use Linksys WAG router.

 

We have replaced the router by a CISCO ASA 5500 box. Everything is working except the fact that we have no sound when we dial to any internal extension our outside destination. All the extensions are successfully registered on PBXnSIP domain panel, and when dialing you can hear the destination extension ringing, but when somebody picks up the phone, no sound, however the call is counting the time as if we were talking. Also if you call from outside, you can hear the auto attendant, but when you dial any of the options offered, nothing happens, it keeps talking.

 

In the CISCO box we already created the following Access Rules:

 

- 5060 (TCP/UDP)

- 5061 (TCP/UDP)

- 49152-64512: (TCP/UDP)

- 5004: (TCP/UDP)

- 10000: (TCP/UDP)

 

And the same were used to create NAT rules too. There are no errors on the Call Logs in the PBXnSIP software.

 

Before we used to have the server under DMZ, but now we can not, so we have to set the ports manually.

 

Do you think this is a PORTS issue? Any recommendation?

 

Thanks.

Link to comment
Share on other sites

In the CISCO box we already created the following Access Rules:

 

- 5060 (TCP/UDP)

- 5061 (TCP/UDP)

- 49152-64512: (TCP/UDP)

- 5004: (TCP/UDP)

- 10000: (TCP/UDP)

 

And the same were used to create NAT rules too. There are no errors on the Call Logs in the PBXnSIP software.

 

I first guess is that the ATA has problems detecting what ports should be open. AFAIK the ATA monitors the traffic and then makes a decision which ports should be opened for RTP. This would mean that you dont have to explicitly set them up IMHO.

 

Is the PBX still running on a public IP address (routable, in the DMZ)? Maybe there something went wrong during the migration.

Link to comment
Share on other sites

I first guess is that the ATA has problems detecting what ports should be open. AFAIK the ATA monitors the traffic and then makes a decision which ports should be opened for RTP. This would mean that you dont have to explicitly set them up IMHO.

 

Is the PBX still running on a public IP address (routable, in the DMZ)? Maybe there something went wrong during the migration.

 

Correct, the ASA does sip inspection, so as long as 5060 is open, then it will dynamically open the RTP ports as needed. Make sure you have sip inspection turned on. What IOS version are you running on the ASA? I would recommend something at least as new as 8.22 My guess is it is a configuration issue. I know tons of people using ASA firewalls with SIP, and they work wonderfully.

Link to comment
Share on other sites

I first guess is that the ATA has problems detecting what ports should be open. AFAIK the ATA monitors the traffic and then makes a decision which ports should be opened for RTP. This would mean that you dont have to explicitly set them up IMHO.

 

Is the PBX still running on a public IP address (routable, in the DMZ)? Maybe there something went wrong during the migration.

 

We have a public static IP where we used to set the PBX under DMZ before we switched to the CISCO ASA (we used to use a WAG Linksys regular router). Everything worked fine then.

 

Now we have installed an ADSL bridge modem and a CISCO ASA 5500 box hooked to it. The PBX server is connected to the ASA box, and we are not setting any DMZ to it. We opened and forwarded the ports to the PBX IP as shown above. That is all what we have done.

 

I would understand ports problems with outgoing and incoming calls, but what about internal calls? Why when one internal extension calls to another one, there is no sound? The phones ring, but no sound.

 

Thanks for your response.

Link to comment
Share on other sites

Correct, the ASA does sip inspection, so as long as 5060 is open, then it will dynamically open the RTP ports as needed. Make sure you have sip inspection turned on. What IOS version are you running on the ASA? I would recommend something at least as new as 8.22 My guess is it is a configuration issue. I know tons of people using ASA firewalls with SIP, and they work wonderfully.

 

Well the 5060 is already opened as shown in the picture attached (Access Rules in the ASDM interface). Also the ASA version we have is 8.2(2).

 

I don't know what you mean with "sip inspection turned on". I thought that is just opening the sip port.

 

Thanks for your response.

post-1972-1287564331_thumb.png

Link to comment
Share on other sites

I noticed also that the PBX failed to register with external trunks we have such CallWithUS.... mmm

 

Is this fact any help to locate the issue?

 

Thanks.

 

There was an issue related to the trunk registration that we fixed recently (it was not a problem with all the providers though)

Please use the version depending on the OS you are using from -

http://forum.pbxnsip.com/index.php?showtop...amp;#entry17029

Link to comment
Share on other sites

There was an issue related to the trunk registration that we fixed recently (it was not a problem with all the providers though)

Please use the version depending on the OS you are using from -

http://forum.pbxnsip.com/index.php?showtop...amp;#entry17029

 

But it was registering correctly just 5 minutes before switching from the regular Linksys WAG router. This started to happen when using the CISCO ASA 5500.

 

Thanks.

Link to comment
Share on other sites

But it was registering correctly just 5 minutes before switching from the regular Linksys WAG router. This started to happen when using the CISCO ASA 5500.

 

Thanks.

 

I see that you have the firewall set to allow the traffic, how about the port forward rules so that it knows where to send the traffic that is allowed by the firewall? You are correct, the ASA should have no effect on internal extension to extension calling. Sip inspection is usually enabled as one of the global inspection policies. Do you have the config of the ASA. The ASDM is pretty useless at showing the config as a whole.

Link to comment
Share on other sites

I still don't understand:

 

1) All the SIP phones (internal extensions) register correctly to the PBX server (a computer in the same LAN)

2) All SIP phones (internal extensions) can ring to others (you can hear the ringing sound)

3) When an extension calls to another one and this one answers, you can see the time ticking (so the call is taking place), BUT NO SOUND (the media ports??)

 

I can understand a FIREWALL problem if this was happening from an outsider extension trying to register to our internal PBXnSIP server, but the issue is internally!!!!

 

Another thing that I don't understand is that when the PBXnSIP was under DMZ with the former router everything was working great. Now with the CISO ASA box, with all the ports required correctly open, no MEDIA is transfered between PBXnSIP server and rest of extensions.

 

Two more details:

 

4) If you call from outside (using a regular phone line) to our number, our PBXnSIP auto attendant answers correctly and you can hear all the different options you can dial. However it doesn't matter if you click any number, nothing happens, the auto attendant keeps talking and talking.

5) The PBXnSIP can not register with CallWithUS and other providers we have. With the former router it could (but we have all the ports opened!)

 

Any advice please? Don't you think there is something wrong at the PBXnSIP side?

 

Thanks.

Link to comment
Share on other sites

Any advice please? Don't you think there is something wrong at the PBXnSIP side?

 

I would install Wireshark on the PBX host and see what is going on on the packet level. Maybe just a simple problem with the routing table. At least you can make sure that everything is okay on the pbxnsip side.

Link to comment
Share on other sites

I still don't understand:

 

1) All the SIP phones (internal extensions) register correctly to the PBX server (a computer in the same LAN)

2) All SIP phones (internal extensions) can ring to others (you can hear the ringing sound)

3) When an extension calls to another one and this one answers, you can see the time ticking (so the call is taking place), BUT NO SOUND (the media ports??)

 

I can understand a FIREWALL problem if this was happening from an outsider extension trying to register to our internal PBXnSIP server, but the issue is internally!!!!

 

Another thing that I don't understand is that when the PBXnSIP was under DMZ with the former router everything was working great. Now with the CISO ASA box, with all the ports required correctly open, no MEDIA is transfered between PBXnSIP server and rest of extensions.

 

Two more details:

 

4) If you call from outside (using a regular phone line) to our number, our PBXnSIP auto attendant answers correctly and you can hear all the different options you can dial. However it doesn't matter if you click any number, nothing happens, the auto attendant keeps talking and talking.

5) The PBXnSIP can not register with CallWithUS and other providers we have. With the former router it could (but we have all the ports opened!)

 

Any advice please? Don't you think there is something wrong at the PBXnSIP side?

 

Thanks.

 

Looks like outbound media is flowing properly (caller can hear the AA message).The inbound traffic is being blocked somewhere. It could be the router/firewall or the host/firewall. I have seen on Windows when you switch/change the network, the firewall rules gets reassigned.

Link to comment
Share on other sites

Looks like outbound media is flowing properly (caller can hear the AA message).The inbound traffic is being blocked somewhere. It could be the router/firewall or the host/firewall. I have seen on Windows when you switch/change the network, the firewall rules gets reassigned.

 

This is driving me crazy.

 

I have switched back to our former router and set up the PBXnSIP server the same way I did with the CISCO ASA box. It did not work! it behaved the same exact way.

 

However I moved the PBXnSIP server under a DMZ configuration, and guess what. IT WORKED.

 

I think this is what is happening in the CISCO firewall too. I need to set a DMZ for the PBXnSIP server.

 

But the question is WHY? Is there any other port that we the user do not know ????

 

5060, 5061, etc...???

Link to comment
Share on other sites

UPDATE:

 

The CISCO ASA reseted to factory defaults, working perfectly with a Web server (NAT for port 80), allowing ping between all the machines in the netwrok, everything brand new from scratch, no ACCESS RULES (so all the traffic is allowed):

 

- PBXnSIP server can not register to CallWithUs or other services we have like VOIPRAIDER (Timeout)

- No sound when placing calls

 

There is no limitation in the traffic but the PBXnSIP server still can not work.

 

DOES THIS THING MANDATORY NEED A DMZ?

 

WHAT IS THE REASON THE CALLS CAN NOT TAKE PLACE INTERNALLY WHEN NO ACCESS RULES ?

 

PLease, I will really appreciate your help, since this is really a desperate situation.

Link to comment
Share on other sites

Well, without being a ATA expert IMHO it all comes down to the simple question if the PBX ports are publically visible (inbound) and the PBX knows about it (advertizing the right address on outbound traffic/SDP). Having a public IP address for the PBX on a configured interface makes life so much easier; if you have to play tricks with NAT you pay the high price of trying to fiddle around and end up in a potentially instable system.

 

It is like the question can you ping the PBX? Which means does the packet make it to the PBX and does the response make it back (netmask, default IP gateway).

 

One beautiful day we have IPv6 in place and having a couple of IPv6 addresses for the PBX will make life so much easier.

Link to comment
Share on other sites

Well, without being a ATA expert IMHO it all comes down to the simple question if the PBX ports are publically visible (inbound) and the PBX knows about it (advertizing the right address on outbound traffic/SDP). Having a public IP address for the PBX on a configured interface makes life so much easier; if you have to play tricks with NAT you pay the high price of trying to fiddle around and end up in a potentially instable system.

 

It is like the question can you ping the PBX? Which means does the packet make it to the PBX and does the response make it back (netmask, default IP gateway).

 

One beautiful day we have IPv6 in place and having a couple of IPv6 addresses for the PBX will make life so much easier.

 

Yes I can ping the PBX server, actually I use the Web interface to control it. As a matter of fact all the SIP phones are correctly registered to it....so obvisouly it is available to at least the internal network.

 

On the other hand, there is a question that nobody answered yet: Why this happens internally? I can understand if happened from an external caller (a SIP phone in internet trying to access to my LAN in order to register to the PBX server), but INTERNAL extensions? I mean, SIP phones that are located at 192.168.1.100 or 192.168.1.101 that are registered to a PBX server at 192.168.1.3, but no sound when calling.... ???

Link to comment
Share on other sites

On the other hand, there is a question that nobody answered yet: Why this happens internally? I can understand if happened from an external caller (a SIP phone in internet trying to access to my LAN in order to register to the PBX server), but INTERNAL extensions? I mean, SIP phones that are located at 192.168.1.100 or 192.168.1.101 that are registered to a PBX server at 192.168.1.3, but no sound when calling.... ???

 

There is a feature called "hairpinning" in routers which means that the device is available through the public address. Maybe that feature need to be enabled.

 

We had installations where it came down to something simple like the default gateway (thats on IP routing level) was wrong and thats why the PBX could not send replies back the right way. IP routing can be tricky!

Link to comment
Share on other sites

There is a feature called "hairpinning" in routers which means that the device is available through the public address. Maybe that feature need to be enabled.

 

We had installations where it came down to something simple like the default gateway (thats on IP routing level) was wrong and thats why the PBX could not send replies back the right way. IP routing can be tricky!

 

I found the PBXnSIP configuration setup field "SIP IP Replacement List" set to 192.168.1.3/80.34.X.X (private static PBnSIP IP/our public static IP). I erased the content of this field, restarted the PBXnSIP server and voila!, sound during the calls and everything working now, except:

 

- 408 Request Timeout (Registration failed, retry after 60 seconds), when trying to register to CallWithUS

- 408 Request Timeout (Registration failed, retry after 60 seconds), when trying to rgister to TelSome

 

The PBXnSIP had no issue before to register to these services when it was working under DMZ with the former router. Also the SIP port is opened 5060, so I don't understand what could be the reason for this.

 

Any clue?

 

Thanks.

Link to comment
Share on other sites

I found the PBXnSIP configuration setup field "SIP IP Replacement List" set to 192.168.1.3/80.34.X.X (private static PBnSIP IP/our public static IP). I erased the content of this field, restarted the PBXnSIP server and voila!, sound during the calls and everything working now

 

Not using the SIP IP Replacement List is a good thing.

 

except:

 

- 408 Request Timeout (Registration failed, retry after 60 seconds), when trying to register to CallWithUS

- 408 Request Timeout (Registration failed, retry after 60 seconds), when trying to rgister to TelSome

 

The PBXnSIP had no issue before to register to these services when it was working under DMZ with the former router. Also the SIP port is opened 5060, so I don't understand what could be the reason for this.

 

Did you set the outbound proxy in the trunk? I guess so. Maybe you need to tell the ASA now that it really can trust the PBX and there is no need to filter the traffic...

Link to comment
Share on other sites

  • 2 weeks later...
Not using the SIP IP Replacement List is a good thing.

 

 

 

Did you set the outbound proxy in the trunk? I guess so. Maybe you need to tell the ASA now that it really can trust the PBX and there is no need to filter the traffic...

 

For the cisco ASA you need to make it sip aware. Just having a por tope is not going to help fro the out side. Here is a link to the 3 lines you need to add to the config. First set a global policy map then tell it to inspec sip. Yopu can trouble shoot more after.

 

http://www.cisco.com/en/US/products/ps6120....shtml#configs1

 

Happy firewalling.

 

Tom Waterman, CCNA

Link to comment
Share on other sites

For the cisco ASA you need to make it sip aware. Just having a por tope is not going to help fro the out side. Here is a link to the 3 lines you need to add to the config. First set a global policy map then tell it to inspec sip. Yopu can trouble shoot more after.

 

http://www.cisco.com/en/US/products/ps6120....shtml#configs1

 

Happy firewalling.

 

Tom Waterman, CCNA

 

Greatly appreciated!

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.

×
×
  • Create New...