Asterisk 1.4.42 NOTIFY replies ignore NAT setting

Home » Asterisk Users » Asterisk 1.4.42 NOTIFY replies ignore NAT setting
Asterisk Users 6 Comments

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.

Thanks.

6 thoughts on - Asterisk 1.4.42 NOTIFY replies ignore NAT setting

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

  • 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”
    ;tag=80f427ae9e884ado0..To:
    .7>..Call-ID: 4fa38a62-b7d76189@10.132.38.19..CSeq: 1
    NOTIFY..Max-Forwards: 70..Contact: “1316”
    ..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”
    ;tag=80f427ae9e884
    ado0..To: ;tag=as07ad17b5..Call-ID:
    4fa38a62-b7d76189@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.

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