SIP NAT port mismatch to peers

General Help
1

I am helping (?) an organization that is running FreePbx FreePBX 2.5.1.1 atop Asterisk 1.4.21.2, servicing 120 peered extensions (Polycom 430s, bootblock 2.70, bootrom 3.2.3.0002, sip.ld 3.0.3.0.0401)

the server, a fat, screaming 64-bit G4 HP box, is public, static IP - it is the PBX-in-a-Flash distro, built on that box.

clusters of these peers are at remote locations, behind DSL, Motorola Netopia router/gateways. All the remote peers are NAT-ed (PAT-ed, I would say), all the extension settings are the same, qualify=yes, very rare that a peer goes unreachable, the SIP debug headers on the “good” peers read very consistent, to my eye.

They work fine! occasional gripes about static or echo, but a completely functional, working architecture - almost no surprising problems with basic telephony and voicemail, ring-groups and follow-me, IVRs, etc. All good, no errors of any consequence.

Adding 1 more remote location has not worked - the extensions go unreachable (as soon as there is any activity) - transferred calls go to wrong extensions, inbounds go right to voicemail, phones don’t ring but voicemail arrives, etc.

this location has AT&T (Bellsouth) DSL and they provisioned a “2Wire” router/gateway, model 2701hg – it is non-functional, although outbound calls work, most inbounds ring correctly, but the main problem is the UNREACHABLE

I can never quite get my head around NAT/PAT, certainly not as it relates to SIP and Asterisk – the SIP headers from the bad location look like this:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Reliably Transmitting (NAT) to 70.147.7.115:50819:
OPTIONS sip:[email protected]:49482 SIP/2.0
Via: SIP/2.0/UDP 64.20.189.199:5060;branch=z9hG4bK52f8c28d;rport
From: “Unknown” sip:[email protected];tag=as53745fc3
To: sip:[email protected]:49482
Contact: sip:[email protected]
Call-ID: [email protected]
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sat, 28 Aug 2010 16:56:23 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0

ps01*CLI>
<— SIP read from 70.147.7.115:50819 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.20.189.199:5060;branch=z9hG4bK52f8c28d;rport
From: “Unknown” sip:[email protected];tag=as53745fc3
To: sip:[email protected]:5060;tag=19243662-43DEFE3
CSeq: 102 OPTIONS
Call-ID: [email protected]
Contact: sip:[email protected]
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomSoundPointIP-SPIP_430-UA/3.0.3.0401
Content-Length: 0

<------------->
— (10 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]’ Method: OPTIONS
Reliably Transmitting (NAT) to 70.147.7.115:50819:
OPTIONS sip:[email protected]:49482 SIP/2.0
Via: SIP/2.0/UDP 64.20.189.199:5060;branch=z9hG4bK6763b53b;rport
From: “Unknown” sip:[email protected];tag=as69654bd7
To: sip:[email protected]:49482
Contact: sip:[email protected]
Call-ID: [email protected]
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sat, 28 Aug 2010 16:57:23 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0

ps01*CLI>
<— SIP read from 70.147.7.115:50819 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.20.189.199:5060;branch=z9hG4bK6763b53b;rport
From: “Unknown” sip:[email protected];tag=as69654bd7
To: sip:[email protected]:5060;tag=EA5F800D-BF8BF536
CSeq: 102 OPTIONS
Call-ID: [email protected]
Contact: sip:[email protected]
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomSoundPointIP-SPIP_430-UA/3.0.3.0401
Content-Length: 0

<------------->
— (10 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]’ Method: OPTIONS
ps01*CLI>

none of the other good locations ever show this mismatch in port numbers for the remote peer, as in:

Method: OPTIONS
Reliably Transmitting (NAT) to 70.147.7.115:50819:
OPTIONS sip:[email protected]:49482 SIP/2.0

above

I think that the NAT/PAT is wrong here - SIP SHOW PEERS has 50819 for this extension, yet the message is directed to 49482

I don’t even know which device “creates” the port assignment in the first place – the DHCP manager? It must be the phone that requests a port and Asterisk assigns one? I am lost on this sequence, and how Asterisk gets 2 different port numbers for 1 device

Is the above dialog expressing a problem? The location certainly is experiencing problems unlike all the other locations that are all configured the same way:

dtmfmode RFC2833
canreinvite no
context from-internal
host dynamic
type friend
nat yes
port 5060
qualify yes

Anyone know what should be tried to pin down this problem? I think swapping in the Netopia will fix it - it might be simply not enough bandwidth (512 Kb upstream) at this location, other similar sites have 768 Kb - but the OPTIONS messages retransmit UDP 7 times before declaring the peer unreachable, and those messages have the same port differences as above.

anyone have an opinion on FreePBX paid support for stuff like this? would it be useful to me in solving this problem?

thanks in advance -

rldel99

2

Do you have SIP ALG enabled on 2Wire ? If yes, you should disable it.

3

thanks for the read and reply Obelisk

so far I’ve been working blind from the distance, with no real talent at the far end. I thought the same thing, that there is an ALG running, and there may be, but I don’t yet know that. Cannot get the 2Wire to allow Remote Management so that I could look (even though the Remote Management checkbox is checked on one of its screens) - tried :8088, :8080, etc. (I see now that it is https: on port 50001! I will look tonight)

we tried to get a tech on site Friday, but he ran late and the office closed at 4.

  • I think the 2Wire is the culprit, maybe on more than one level, as I have had pretty easy success with Netopia 3347-type RGs, even though I can honestly say that I don’t understand the SIP UDP port assignment/creation, or even whether the SIP OPTIONS contact headers that I pasted above are actually in error, with port mismatches. They don’t look right, to my experience with other locations.

The 2Wire is a residential solution, a UVerse solution, as far as I know - AT&T should never have deployed it in a business account.

I am wondering if there is anything else that I can do to prove the point, or simply wait until I can get a tech on site to swap in the Netopia.

??

4

replaced the suspect 2Wire box with the correct Netopia 3347, and all of the SIP port mismatches and the UNREACHABLE peers ceased immediately - the SIP debug messages were somehow coming up with different port numbers for the destination of the message and the port number in the contact header for the remote PEERs - maddening problem, and I still do not understand just how these port numbers become assigned to an endpoint User Agent, and how they are then conveyed to Asterisk for storage and message processing.

but it is fixed and the remote site behaves normally, even with very tight bandwidth available for 7 endpoints (512 Kb DSL)