Louie
2009-10-06
Customer Service:%
Product Quality:%
Delivery Time:%
Site Usability:%
Pricing:%
Overall Satisfaction:%
| Contacted Netgear on 2009-10-06
I bought a few 1gbs WNR3500 Netgear routers to replace 100mbs WGU624.
WNR3500 firmware V1.0.30_8.0.30.
This is my setup, which I'll point out was working for years prior to installing the new WNR3500's.
I have two NAT routers, one behind the other.
The nat routers are configured to port forward the data to an asterisk / callweaver software PBX.
In my case I'm forwarding udp port 5060 (the SIP port configured in sip.conf) and 5061-5099 (the RTP ports as configured in rtp.conf).
The pbx sip.conf has externhost and localnet set to allow SIP messages to be sent using the publicly addressable IPs.
It took several wireshark packet dumps to determine that the packets were being corrupted by the Netgear router. It appears as though the router does a trivial ascii replace of the private ip address in the SIP packets without regard to their context. In this case, the internal NAT router is stuffing its private IP address into the SIP packet. Let me point out that, even though double NAT complicates things, the packet dumps show that corruption exists behind one router.
I can configure Asterisk hacks to ignore the IP addresses within the SIP packets. However it is not possible to configure asterisk to correct for the erroneous corruption of the unique session id by the router.
Call-ID: .......................@192.168.100.51 (correct)
Call-ID: .......................@192.168.99.2 (Netgear)
The result is that the Asterisk PBX does not recognize the (corrupted) response from the SIP Provider, and those packets get dropped, in my case on the "register" command. A naive observer might be put on the wrong path by the "Unauthorized" message. However this is normal, and would normally be followed by an authenticated retry, if it were not for the fact that call-id has been corrupted.
I've attempted to correct this behavior from the WNR3500 web interface, disabling SPI, etc in hopes that something would work, but the WNR3500 has no Application Layer Gateway configuration screen and the use of SIP port 5060 was mandatory for my application.
I managed to work around the issue by recompiling the chan_sip.c build_callid function to generate a modified Call-Id parameter so that the router wouldn't try to mess with it. To my relief, this works!!!!
While it is a simple change, compiling asterisk is non-trivial and I couldn't recommend this for most people. The Call-Id generated by asterisk is expressly permitted by rfc3261, and this workaround is a real hack. Until this is fixed, I would regard the WNR3500 as being incompatible with SIP.
If anyone has a better solution, I'd love to hear it.
Session Initiation Protocol
Status-Line: SIP/2.0 401 Unauthorized
Status-Code: 401
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=.......;received=xx.xx.xx.xx;rport=5060
Transport: UDP
Sent-by Address: xx.xx.xx.xx
Sent-by port: 5060
Branch: ........
Received: xx.xx.xx.xx
RPort: 5060
From: <sip:phone@xyz.service.com>;tag=....
SIP from address: sip:phone@xyz.service.com
SIP tag: ........
To: <sip:phone@xyz.service.com>;tag=....
SIP to address: sip:phone@xyz.service.com
SIP tag: ....
Call-ID: .......................@192.168.99.2
CSeq: 122 REGISTER
Sequence Number: 122
Method: REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="....."
Authentication Scheme: Digest
Algorithm: MD5
Realm: "asterisk"
Nonce Value: "......"
|