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

[James Lamanna]

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