Inbound SIP calls dropping
-
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
