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

[Kevin P. Fleming]

On 12/30/2011 12:29 PM, James Lamanna wrote:
> On Fri, Dec 30, 2011 at 8:35 AM, James Lamanna<jlamanna at gmail.com>  wrote:
>> 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.
>>
>
> Hi Kevin,
> That doesn't appear to work correctly:
> The response does not come back to 34972 even though rport is in the Via.
>
> U xxx.234:34972 ->  yyy..7:5060
>    NOTIFY sip:yyy.7 SIP/2.0..Via: SIP/2.0/UDP
> 10.132.38.19:6957;branch=z9hG4bK-25ea41f0;rport..From: "1316"
> <sip:1316 at yyy.7>;tag=80f427ae9e884ado0..To:<sip:yyy
>    .7>..Call-ID: 4fa38a62-b7d76189 at 10.132.38.19..CSeq: 1
> NOTIFY..Max-Forwards: 70..Contact: "1316"
> <sip:1316 at 10.132.38.19:6957>..Event: keep-alive..User-Agent:
> Linksys/SPA942-6.1.3(
>    a)..Content-Length: 0....
> #
> U yyy.7:5060 ->  xxx.234:6957
>    SIP/2.0 481 No subscription..Via: SIP/2.0/UDP
> 10.132.38.19:6957;branch=z9hG4bK-25ea41f0;received=xxx.234;rport=34972..From:
> "1316"<sip:1316 at yyy.7>;tag=80f427ae9e884
>    ado0..To:<sip:yyy.7>;tag=as07ad17b5..Call-ID:
> 4fa38a62-b7d76189 at 10.132.38.19..CSeq: 1 NOTIFY..User-Agent: Asterisk
> PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTI
>    FY, INFO..Supported: replaces..Content-Length: 0....

That would be a bug then; the 481 response was not sent to the proper 
port. It's strange though, because the rport parameter was properly 
updated with the 'perceived port', and the received parameter was added 
as well.

-- 
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