On Fri, Dec 30, 2011 at 11:55 AM, Kevin P. Fleming <kpflem...@digium.com> wrote: > On 12/30/2011 12:29 PM, James Lamanna wrote: >> >> On Fri, Dec 30, 2011 at 8:35 AM, James Lamanna<jlama...@gmail.com> wrote: >>> >>> 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. >>> >> >> 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@yyy.7>;tag=80f427ae9e884ado0..To:<sip:yyy >> .7>..Call-ID: 4fa38a62-b7d76...@10.132.38.19..cseq: 1 >> NOTIFY..Max-Forwards: 70..Contact: "1316" >> <sip:1316@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@yyy.7>;tag=80f427ae9e884 >> ado0..To:<sip:yyy.7>;tag=as07ad17b5..Call-ID: >> 4fa38a62-b7d76...@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 -- _____________________________________________________________________ -- 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