[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