On Fri, Dec 30, 2011 at 8:35 AM, James Lamanna <[email protected]> wrote: > On Fri, Dec 30, 2011 at 6:02 AM, Kevin P. Fleming <[email protected]> > 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:[email protected]>;tag=80f427ae9e884ado0..To: <sip:yyy .7>..Call-ID: [email protected]: 1 NOTIFY..Max-Forwards: 70..Contact: "1316" <sip:[email protected]: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:[email protected]>;tag=80f427ae9e884 ado0..To: <sip:yyy.7>;tag=as07ad17b5..Call-ID: [email protected]: 1 NOTIFY..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTI FY, INFO..Supported: replaces..Content-Length: 0.... -- _____________________________________________________________________ -- 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
