asterisk users - Dec 2011 - Asterisk 1.4.42 NOTIFY replies ignore NAT setting

Hi,
I've been trying to fix NOTIFY replies (specifically keep-alives) in 1.4.42
(I can't upgrade to 1.8.x at the moment for various reasons).

I've noticed for user agents that have a VIA header with a different
port than the port the NOTIFY was sent from,
the NOTIFY reply will always be sent back to that port, which is incorrect.
(Sonicwalls and other routers love to do this, even with "Symmetric
NAT" on).
The reason for this is that the NOTIFY reply does not attempt to
lookup the SIP peer and check
its NAT flags.
I've seen some nasty From: header string parsing code + find_peer()
that does this, but I was wondering
if there's an easier way.

Thanks.

-- James

On 12/30/2011 04:07 AM, James Lamanna wrote:
> Hi,
> I've been trying to fix NOTIFY replies (specifically keep-alives) in
1.4.42
> (I can't upgrade to 1.8.x at the moment for various reasons).
>
> I've noticed for user agents that have a VIA header with a different
> port than the port the NOTIFY was sent from,
> the NOTIFY reply will always be sent back to that port, which is incorrect.
> (Sonicwalls and other routers love to do this, even with "Symmetric
NAT" on).
> The reason for this is that the NOTIFY reply does not attempt to
> lookup the SIP peer and check
> its NAT flags.
> I've seen some nasty From: header string parsing code + find_peer()
> that does this, but I was wondering
> if there's an easier way.
Since Asterisk does not initiate subscriptions, these NOTIFY requests 
arriving to the Asterisk system must be 'unsolicited'. As such, they 
don't have an associated SIP dialog structure, so there's no simple way 
to know whether they are associated with a known peer or not.

You say that Asterisk's behavior is 'incorrect', but it's only 
'incorrect' because you believe it should be looking up any associated 
peer and using that peer's NAT setting; Asterisk's behavior as
you've
quoted is *correct* according to the RFC3261 rules for how replies 
should be sent, assuming that the top-most Via header does not have an 
'rport' parameter present in it.

The *proper* way to solve this problem is to have the UA sending the 
NOTIFY request include the 'rport' parameter in the top-most Via header 
of the request; if that is done, then whatever UA receives the request 
will be able to properly respond, even if the request crosses a NAT. 
Another way to solve it, if the sending UA cannot be changed to emit 
proper SIP requests, is to modify Asterisk to attempt a peer lookup when 
it is going to reply to request that it cannot associate with any known 
dialog, and then have the peer configured with 'nat=yes' (in the case of
1.4.42). A third option is to set 'nat=yes' in the [general] section of 
sip.conf, so that Asterisk will reply using rport-style behavior 
regardless of whether the request could be associated with a peer or not.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org