[Freeswitch-users] Registration problem with multiple IP phones behind Linux NAT firewall router
wchao at yahoo.com
wchao at yahoo.com
Mon May 4 10:02:14 PDT 2009
I am having a problem with getting multiple Polycom IP phones to register
to my Freeswitch server. Here is my setup (IP addresses are not actual
ones, but are consistent throughout):
Freeswitch server in colo facility
IP addr: 1.1.1.1 (publicly routable)
Linux NAT firewall router with iptables in office building
external IP: 2.2.2.2 (publicly routable)
internal IP: 192.168.1.1 (internal only, not publicly routable)
Polycom IP301 phone A
extension: 1001
IP addr: 192.168.1.2
Polycom IP301 phone B
extension: 1002
IP addr: 192.168.1.3
snom 320 phone C
extension: 1003
IP addr: 192.168.1.4
The Freeswitch server configuration has not changed much from the default
installation. I tried changing NDLB-received-in-nat-reg-contact and it
doesn't make a difference (although the register line adds a
";received=<ip>:<port>" tag). Here is what happens:
Polycom phone A registers successfully. If I execute "sofia status profile
internal", I see this:
Call-ID: f905cac7-125f0b1d-87aff436 at 192.168.1.2
User: 1001 at 1.1.1.1
Contact: "user" <sip:1001 at 2.2.2.2:5060;received=2.2.2.2:5060;fs_nat=yes>
Agent: PolycomSoundPointIP-SPIP_301-UA/2.1.0.2708
Status: Registered(UDP-NAT)(unknown) EXP(2009-05-04 13:06:47)
Host: 1.1.1.1
IP: 2.2.2.2
Port: 5060
Auth-User: 1001
Auth-Realm: 1.1.1.1
When Polycom phone B attempts to register, it cannot and I get the
hollowed out phone icon on the phone display. I took a Wireshark capture
and discovered that phone B does communicate with Freeswitch, but it is
getting denied access. First phone B sends a REGISTER request:
No. Time Source Destination Protocol Info
15114 117.617280 2.2.2.2 1.1.1.1 SIP Request: REGISTER sip:1.1.1.1:5060
Frame 15114 (561 bytes on wire, 561 bytes captured)
Arrival Time: May 3, 2009 16:46:45.728592000
[Time delta from previous captured frame: 0.007070000 seconds]
[Time delta from previous displayed frame: 10.505373000 seconds]
[Time since reference or first frame: 117.617280000 seconds]
Frame Number: 15114
Frame Length: 561 bytes
Capture Length: 561 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:sip]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Xensourc_55:2a:dd (00:16:3e:55:2a:dd), Dst: D-Link_61:f2:9a (00:11:95:61:f2:9a)
Destination: D-Link_61:f2:9a (00:11:95:61:f2:9a)
Address: D-Link_61:f2:9a (00:11:95:61:f2:9a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Xensourc_55:2a:dd (00:16:3e:55:2a:dd)
Address: Xensourc_55:2a:dd (00:16:3e:55:2a:dd)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 2.2.2.2 (2.2.2.2), Dst: 1.1.1.1 (1.1.1.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xb0 (DSCP 0x2c: Unknown DSCP; ECN: 0x00)
1011 00.. = Differentiated Services Codepoint: Unknown (0x2c)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 547
Identification: 0x02ae (686)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: UDP (0x11)
Header checksum: 0x3ff3 [correct]
[Good: True]
[Bad : False]
Source: 2.2.2.2 (2.2.2.2)
Destination: 1.1.1.1 (1.1.1.1)
User Datagram Protocol, Src Port: qsm-proxy (1164), Dst Port: sip (5060)
Source port: qsm-proxy (1164)
Destination port: sip (5060)
Length: 527
Checksum: 0xdb1b [correct]
[Good Checksum: True]
[Bad Checksum: False]
Session Initiation Protocol
Request-Line: REGISTER sip:1.1.1.1:5060 SIP/2.0
Method: REGISTER
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bK73c1d1c2BF65B36B
Transport: UDP
Sent-by Address: 192.168.1.3
Branch: z9hG4bK73c1d1c2BF65B36B
From: "Rahim Orazkuliyev" <sip:1002 at 1.1.1.1>;tag=807917B4-BA73B497
SIP Display info: "Rahim Orazkuliyev"
SIP from address: sip:1002 at 1.1.1.1
SIP tag: 807917B4-BA73B497
To: <sip:1002 at 1.1.1.1>
SIP to address: sip:1002 at 1.1.1.1
CSeq: 1 REGISTER
Sequence Number: 1
Method: REGISTER
Call-ID: 76909a58-dd169e7e-a7c5da19 at 192.168.1.3
Contact: <sip:1002 at 192.168.1.3>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER"
Contact Binding: <sip:1002 at 192.168.1.3>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER"
URI: <sip:1002 at 192.168.1.3>
SIP contact address: sip:1002 at 192.168.1.3
User-Agent: PolycomSoundPointIP-SPIP_301-UA/2.1.0.2708
Max-Forwards: 70
Expires: 3600
Content-Length: 0
The Freeswitch server responds as follows:
No. Time Source Destination Protocol Info
15117 117.655406 1.1.1.1 2.2.2.2 SIP Status: 401 Unauthorized (0 bindings)
Frame 15117 (698 bytes on wire, 698 bytes captured)
Arrival Time: May 3, 2009 16:46:45.766718000
[Time delta from previous captured frame: 0.023210000 seconds]
[Time delta from previous displayed frame: 0.038126000 seconds]
[Time since reference or first frame: 117.655406000 seconds]
Frame Number: 15117
Frame Length: 698 bytes
Capture Length: 698 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:sip]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: D-Link_61:f2:9a (00:11:95:61:f2:9a), Dst: Xensourc_55:2a:dd (00:16:3e:55:2a:dd)
Destination: Xensourc_55:2a:dd (00:16:3e:55:2a:dd)
Address: Xensourc_55:2a:dd (00:16:3e:55:2a:dd)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: D-Link_61:f2:9a (00:11:95:61:f2:9a)
Address: D-Link_61:f2:9a (00:11:95:61:f2:9a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xb8 (DSCP 0x2e: Expedited Forwarding; ECN: 0x00)
1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (0x2e)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 684
Identification: 0xd2e8 (53992)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: UDP (0x11)
Header checksum: 0x7627 [correct]
[Good: True]
[Bad : False]
Source: 1.1.1.1 (1.1.1.1)
Destination: 2.2.2.2 (2.2.2.2)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Source port: sip (5060)
Destination port: sip (5060)
Length: 664
Checksum: 0x1fb5 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Session Initiation Protocol
Status-Line: SIP/2.0 401 Unauthorized
Status-Code: 401
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bK73c1d1c2BF65B36B;received=2.2.2.2
Transport: UDP
Sent-by Address: 192.168.1.3
Branch: z9hG4bK73c1d1c2BF65B36B
Received: 2.2.2.2
From: "Rahim Orazkuliyev" <sip:1002 at 1.1.1.1>;tag=807917B4-BA73B497
SIP Display info: "Rahim Orazkuliyev"
SIP from address: sip:1002 at 1.1.1.1
SIP tag: 807917B4-BA73B497
To: <sip:1002 at 1.1.1.1>;tag=FXNpXtFFBBSpF
SIP to address: sip:1002 at 1.1.1.1
SIP tag: FXNpXtFFBBSpF
Call-ID: 76909a58-dd169e7e-a7c5da19 at 192.168.1.3
CSeq: 1 REGISTER
Sequence Number: 1
Method: REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.0.4pre4-hacked
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH
Supported: timer, precondition, path, replaces
WWW-Authenticate: Digest realm="1.1.1.1", nonce="066baa69-aebb-4a39-a972-6d20625a79e0", algorithm=MD5, qop="auth"
Authentication Scheme: Digest
Realm: "1.1.1.1"
Nonce Value: "066baa69-aebb-4a39-a972-6d20625a79e0"
Algorithm: MD5
QOP: "auth"
Content-Length: 0
Interestingly, the snom 320 phone registers fine:
Call-ID: 3c26702fbd8b-3wozzv3bd908
User: 1003 at 1.1.1.1
Contact: "Wellie Chao" <sip:1003 at 2.2.2.2:2058;line=5gjot59h;received=2.2.2.2:2058;fs_nat=yes>
Agent: snom320/7.3.14
Status: Registered(UDP-NAT)(unknown) EXP(2009-05-04 14:32:50)
Host: 1.1.1.1
IP: 2.2.2.2
Port: 2058
Auth-User: 1003
Auth-Realm: 1.1.1.1
I suspect that the snom 320 phone is working fine because the port is not
5060. The first Polycom (phone A) registered from port 5060. It appears
that Freeswitch thinks the second Polycom (phone B) also is coming from
port 5060 and is getting confused, thinking that phone B is trying to
hijack phone A's registration.
The packet capture was taken when running Freeswitch 1.0.4pre4, but I
subsequently upgraded to 1.0.4pre6 and it didn't make a difference. The
Linux NAT firewall router is running CentOS 5.3 with the most recent
updates, and I have tried with ip_nat_sip and ip_conntrack_sip turned on
and turned off. When ip_nat_sip and ip_conntrack_sip are turned on, I have
included the 4 iptables rules needed:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 2.2.2.2
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 5060 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --dport 5060 -j ACCEPT
It didn't make a difference no matter what I did. I am not sure why
Freeswitch thinks that the source port is 5060 when it appears from
the packet capture that the source port is 1164.
Does anyone have any insights into why this is happening and what I can
try to fix the problem?
Regards,
Wellie
More information about the FreeSWITCH-users
mailing list