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

[James Lamanna]

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)

Thanks.

-- James