On Fri, Dec 30, 2011 at 6:02 AM, Kevin P. Fleming <kpflem...@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. -- James -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users