[asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting

[James Lamanna]

On Fri, Dec 30, 2011 at 6:02 AM, Kevin P. Fleming <kpfleming at digium.com> wrote:
> 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.

Thanks Kevin.
I'll have to turn rport on on all my Linksys/Cisco phones and give it a shot.

-- James