[asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting
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. -- 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
Re: [asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting
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. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- 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
Re: [asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting
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
Re: [asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting
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 -- _ -- 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
Re: [asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting
On 12/30/2011 12:29 PM, James Lamanna wrote: On Fri, Dec 30, 2011 at 8:35 AM, James Lamannajlama...@gmail.com wrote: On Fri, Dec 30, 2011 at 6:02 AM, Kevin P. Flemingkpflem...@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: 1316sip: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. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- 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
Re: [asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting
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 Lamannajlama...@gmail.com wrote: On Fri, Dec 30, 2011 at 6:02 AM, Kevin P. Flemingkpflem...@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: 1316sip: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
Re: [asterisk-users] Asterisk 1.4.42 NOTIFY replies ignore NAT setting
On 12/30/2011 03:09 PM, James Lamanna wrote: On Fri, Dec 30, 2011 at 11:55 AM, Kevin P. Flemingkpflem...@digium.com wrote: On 12/30/2011 12:29 PM, James Lamanna wrote: On Fri, Dec 30, 2011 at 8:35 AM, James Lamannajlama...@gmail.comwrote: On Fri, Dec 30, 2011 at 6:02 AM, Kevin P. Flemingkpflem...@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: 1316sip: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) 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. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- 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
