SIP & RTP Passthrough

Unanswered Question
Apr 12th, 2010

I have an issue I hope someone can help with. I am not sure of the entire setup but I will try and explain what I know. A client has an application through which they login and somehow calls are pushed to them. They are able to receive the call but it timeouts out after about 30secs during which time neither side can hear each other. The remote end says that they see the setup (SIP is being used) but the audio is not working and they say that ports need to be opened to allow RTP.

The setup at the client is pretty simple, it is a switch connected to a PIX running 8.0(4), which then connects to the Internet. I am not sure how I am suppose to open these ports because it's not inbound traffic so I would not need any static nat entries or an acl on the outisde interface to permit the traffic. I don't get why it does not work either because the pix is configured to allow a SIP trunk from a different external party to the pbx and that works fine.

If I do a sh conn the following is displayed (ip address changed). It seems that it is "SIP transient and incomplete." not sure what that means.

UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:01:02, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:01:02, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:01:06, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:01:52, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:04:14, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:11:07, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:11:42, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:15:50, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:16:01, bytes 0, flags ti
UDP outside 1.1.1.1:0 inside 192.168.45.233:5060, idle 0:25:48, bytes 0, flags ti

Also when I check the logs (set to debugging) there is nothing being denied.

Config is attached. You can ignore the lines in the acl outside_access_in with all the "any any" I just did that to see if it would work. Any help at all would be very appreciated.

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
KWillacey_2 Tue, 04/13/2010 - 11:08

Hi can anyone tell me how to modify the SIP inspection to exempt certain IP addresses. Also if I were to disable sip inspection completely, would that affect any of the existing SIP trunks? Thanks.

KWillacey_2 Wed, 04/14/2010 - 20:20

Ok so I made some progress or not much at all. As mentioned before there is an application that resides on end user PCs and when they login it registers with a sip server and they are able to pull calls. According to the admins on the other end, they are currently using an Astericks pbx and as such it is a requirement that sip inspection be turned off in order for it to work, however I have an existing sip trunk.

The exising sip trunk is a static nat which forwards traffic to the pbx with the accompanying acl on the outside interface and this works fine with the sip inspection.

So at first I tried to only allow the existing sip trunk to be inspected while denying anything else from being inspected. See change below.

access-list SIP extended permit tcp host 192.168.50.1 any eq sip

access-list SIP extended permit udp host 192.168.50.1 any eq sip

access-list SIP extended permit tcp any host 192.168.50.1 eq sip

access-list SIP extended permit udp any host 192.168.50.1 eq sip
access-list SIP extended deny tcp any any eq sip
access-list SIP extended deny udp any any eq sip

class-map SIP
match access-list SIP

policy-map global_policy

class inspection_default

no inspect sip

class SIP

inspect sip

As soon as this change was made I started receiving a lot of land attacks in the syslog from ip 192.168.50.1 to 192.168.50.1 and the sip trunk immediately stops working, while the new sip connection would work fine. So I thought maybe I should disable sip inspection all together but once again the land attacks start appearing in the syslog again and the sip trunk stops working, while the one that requires sip inspection turned off works fine.

It seems to me that sip inspection is not enabled at all even with the changes that were made to the global policy to try and match the specific traffic.

So what I would really like to know is if it is even possible to do selective sip inspection on a pix or asa? Any responses to this would be greatly appreciated, please, thanks.

KWillacey_2 Fri, 04/16/2010 - 09:03

After some looking around I am thinking I should try the following.

regex SIP1 "2.2.2.122"
regex SIP2 "2.2.2.123"
regex SIP3 "5.5.5.36"
regex SIP4 "5.5.5.38"

class-map type inspect sip match-any SIP-CLIENTS
match calling-party regex SIP1
match calling-party regex SIP2
match calling-party regex SIP3
match calling-party regex SIP4


policy-map global_policy
no class inspection_default
class SIP-CLIENTS
inspect sip
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect xdmcp

Will the class map defined allow only those IP addresses specified to be inspected and allow any other addresses (inbound and outboud) to bypass sip inspection?

Any help would be greatly appreciated, it has been weird talking to myself for the last four posts lol, thanks.

Actions

This Discussion