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

[Kevin P. Fleming]

On 12/30/2011 03:09 PM, James Lamanna wrote:
> On Fri, Dec 30, 2011 at 11:55 AM, Kevin P. Fleming<kpfleming at digium.com>  wrote:
>> 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.
>
> Could this be because this is sent through a "temporary' response,
> rather than the
> traditional allocation? (it uses transmit_response_using_temp)

I'm sure that is related, but it's still a bug :-) Unfortunately you've 
reported this against an Asterisk 1.4.x release, which is in security 
fix only mode, so even though it's a bug, there won't be a new 1.4.x 
release available with a fix for it.

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