Inbound SIP calls dropping
-
If you have nat on this firewall, you will need to configure cisco nat options.
-
Cisco NAT options? The Cisco router is not doing any NATing. Please elaborate, and point me in the right direction. I will gladly research it.
Brian
-
When you use voip and have nat between sip server/device and internet, you need to configure sip nat options. When using asterisk, configurarion stays in sip.conf.
Look for cisco sip nat options.
-
http://doc.pfsense.org/index.php/VoIP_Configuration
I would be quite surprised if the steps in that document don't fix your problem. I had the same issue myself until I set up static port mapping for my pbx. (Ok, so that's the opposite from the advice given in step 1, but the point is that you may have to experiment with static vs rewritten ports in your outbound NAT.)
-
Marcello,
I checked for Cisco SIP NAT articles and configurations, and found an article entitled "NAT support for SIP". But the command they are referencing "ip nat service sip" is on by default and (if I interpret it correctly) is only applicable if the routed in question is performing NAT. My is not. It is only performing routing and call control (Sip trunk to my service provider, and SCCP to my IP phones). This was working before I inserted the pfsense firewall (to eliminate any sccp to sip issues). BTW this is on by default.
Clarknova,
as for the link it makes reference to only one change, Firewall Optimization Options should be set to to Conservative , which I did change, everything else was default settings for version 2.0. If my understanding is correct this would prevent existing calls from being torn down prematurely. And my outbound calls (calls originating on my Cisco router thru the pfSense firewall to my cell phone) are still being dropped after 10 seconds. Which would not help my inbound sip calls.
Now for the sipproxd plug in, I have installed it, but am unclear as to some of the settings.
SIPproxy settings:
Inbound interface WAN Assuming this needs to be from the perspective of the SIP Trunk Service provider
Outbound Interface LANRTP Proxy: Enabled
Port Range Lower: 16384
Port Range Upper: 32768 This is standard ports for Cisco.Everything else is default. Did I miss something?
How about my FW rules?
Currently they allow SIP on 5060 and UDP/RTP on 16384 thru 32768. The SIP is also forwarded to 172.16.1.2 (my router) .Brian
-
I saw the exact symptoms you describe, and the fix for me was to (using advanced outbound NAT) create a rule to use static port for the pbx's IP address. This is probably not a good fix for you however, because you have more than one SIP device using outbound NAT.
I'm afraid I'm not much help with sip proxies as I've never used one.
Are you doing double NAT (Cisco + pfsense)?
-
If there is no nat, forget nat config on cisco. Sorry for that.
For just routing, check via tcpdump At lan and wan what happens with packages.
You can also capture some packages and try to see sip flow in wireshark.
-
Nope, Just a single NAT (on pfSense).
Time to capture a tcpdump on both the wan and the lan interface simultaneously. and examine it using wireshark.
Will let ya'll know what I find. -
So, there is a nat. It's get confusing to me.
If you have any nat between internet and your cisco, you have to configure sip nat settings.
Inside sip, there are some info about RTP data. If you don't tell sip about your nat, then RTP data will be sent to an invalid or non exist host.
-
Marcello, yes there is a NAT box, it is pfSense, not the cisco router.
I decided to break down the problem in to 2 different problems; 1) outbound calls dropping after 10 seconds. 2) inbound calls not connecting.
As I look deeper into problem #2, with inbound calls not connecting, I found that the SDP information in the SIP packet still has my private IP address. This should be a public IP. Thus causing the rtp stream to never connect. So why is the SIPproxd is not doing his job? Hum…needs further analysis.
Now that lead me to another issue....>:(.. I was hoping to capture all udp traffic on both interfaces (WAN & LAN) to a single file, so I could analyze it further with Wireshark and follow what the siproxd is or is not Translating (ip address/ports) for SIP/SDP and the RTP packets. The WebGUI packet capture worked fine but only supports a single interface at a time, and that won't let me capture both inbound and outbound SIP traffic and write it to a single file. So I decided to use the command line instead. tcpdump with freebsd doesn't support the ability to capture traffic from all interfaces to a single file.
Again my goal with tcpdump is to capture all udp packets on both interfaces and write it to a single file called sipnat.pcap. Does anybody know how to achieve this?
Brian
-
Sipproxy is usefull when you have many sip devices behind nat and you have to config this proxy on device. Its not transparent.
I still think that configuring cisco and removing/disabling sipproxy your setup will work.
This is a very usual scenario.
-
marcello,
I did a debug ip nat sip , and confirmed that the cisco is not NATing any sip (or udp packets for that matter). So I do not believe my problem is over there.
But now I propose a question for everyone: Isn't the pfSense (siproxd service) supposed to be handling all NATing for the SIP signaling going thru the firewall?
From the capture listed below (captured on the WAN interface), with the inbound call (originating on the internet) the INVITE, followed by the 100 TRYING, and finally the 180 RINGING response. But notice on the 180 RINGING response (originating from the LAN side of the pfSense) it still has a internal private ip address of 172.16.1.2 on the Contact information. I would expect the Sipproxd service to rewrite this private address to the public one used on the WAN. So the originator could route the rtp stream to me.
INVITE sip:8015597350@67.42.24.249 SIP/2.0
Record-Route: sip:+18015597350@66.23.129.253:5060;nat=yes;ftag=gk07730407;lr=onVia: SIP/2.0/UDP 66.23.129.253:5060;branch=z9hG4bK5fee.fbe888c3.0
Via: SIP/2.0/UDP 4.55.4.163:5060;branch=z9hG4bK07Be855526a5cef1a04
From: "MAHLER BRIAN " sip:+18016731440@4.55.4.163:5060;tag=gK07730407
To: sip:+18015597350@66.23.129.253:5060Call-ID: 1980221689_50045037@4.55.4.163
CSeq: 5941 INVITE
Max-Forwards: 16
Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: "MAHLER BRIAN " sip:+18016731440@4.55.4.163:5060Remote-Party-ID: "MAHLER BRIAN " sip:+18016731440@4.55.4.163:5060;privacy=off
Supported: 100rel
Content-Length: 301
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 2538 7200 IN IP4 4.55.4.163
s=SIP Media Capabilities
c=IN IP4 4.55.4.130
t=0 0
m=audio 19128 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20SIP/2.0 100 Trying
Via: SIP/2.0/UDP 66.23.129.253:5060;branch=z9hG4bK5fee.fbe888c3.0,SIP/2.0/UDP 4.55.4.163:5060;branch=z9hG4bK07Be855526a5cef1a04
From: "MAHLER BRIAN " sip:+18016731440@4.55.4.163:5060;tag=gK07730407
To: sip:+18015597350@66.23.129.253:5060Date: Sat, 22 Oct 2011 21:31:08 GMT
Call-ID: 1980221689_50045037@4.55.4.163
CSeq: 5941 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 66.23.129.253:5060;branch=z9hG4bK5fee.fbe888c3.0,SIP/2.0/UDP 4.55.4.163:5060;branch=z9hG4bK07Be855526a5cef1a04
From: "MAHLER BRIAN " sip:+18016731440@4.55.4.163:5060;tag=gK07730407
To: sip:+18015597350@66.23.129.253:5060;tag=111D637C-D63
Date: Sat, 22 Oct 2011 21:31:08 GMT
Call-ID: 1980221689_50045037@4.55.4.163
CSeq: 5941 INVITE
Require: 100rel
RSeq: 7042
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Brian N Susan" sip:1001@172.16.1.2;party=called;screen=no;privacy=off
Contact: sip:8015597350@172.16.1.2:5060Record-Route: sip:+18015597350@66.23.129.253:5060;nat=yes;ftag=gk07730407;lr=onServer: Cisco-SIPGateway/IOS-12.x
Content-Length: 0Or is my thinking all wrong.
Brian</sip:+18015597350@66.23.129.253:5060;nat=yes;ftag=gk07730407;lr=on></sip:8015597350@172.16.1.2:5060></sip:1001@172.16.1.2></sip:+18015597350@66.23.129.253:5060></sip:+18016731440@4.55.4.163:5060></sip:+18015597350@66.23.129.253:5060></sip:+18016731440@4.55.4.163:5060></sip:+18016731440@4.55.4.163:5060></sip:+18016731440@4.55.4.163:5060></sip:+18015597350@66.23.129.253:5060></sip:+18016731440@4.55.4.163:5060></sip:+18015597350@66.23.129.253:5060;nat=yes;ftag=gk07730407;lr=on>
-
What I think you are not understanding is that configuring sip nat info on cisco, does not means that cisco will nat sip. This configurarion will help cisco sip communication.
Did you configured sipproxy info on cisco?
Did you configured sipproxy on pfsense?
-
As for configuring SIPproxy on cisco? No. not sure I follow what you mean with configuring sipproxy on the router. Can you give me an example configuration commands?
As for configuring SIPproxy on PFsense? Yes. but not sure if I did it correctly.
-
On cisco it will be something like 'outbound proxy server'
-
Marcello,
I did a little research on the cisco "outbound sip proxy" . And I don't believe it is applicable. According to the documentation this command is used when using SIP endpoints (ip phones) with a CME router. This is the default mode, and on inbound calls to a SIP endpoint would cause to hairpin back out, thus causing the call to fail. So if one is using SIP endoints one might want to disable this feature. My IP phones are using SCCP, thus it doesn't apply.But, what the hell, I did try it any ways. So I configured it globally and it had not effect on the SDP contact information being rewritten to a public ip address. And thus did not change the symptoms in any way. It is my understanding that it is the responsibility of the sip proxy daemon (sipproxd) plug-in running in pfSense to rewrite the SDP contact address information from the private to the public address. Is seams that this plugin is just not working.
Is there a way to verify or view the activity of the siproxd service. I have restarted it. But beyond that what can I do? What about debugs on the PFSense server? I'm sure there is something, just not familiar with BSD.
Brian
