Hello, I'm trying to run an ATA behind a NAT device, and am confused on exactly what the qualify config option does, other than send NOTIFY packets. Outbound calls work fine, but inbound calls do not go through. With qualify=yes and nat=yes, my show sip peers looks like: 7771111001/7771111001 10.0.0.10 D N 255.255.255.255 1222 OK (36 ms) So, it has established a connection with the peer on port 1222, however, when an incoming call comes in, it instead tries to go to port 5060, which doesn't work. I know I could use port forwarding, but that won't work well for multiple ATAs. So, am I right in thinking Asterisk should automagically forward the call to the port listed in show sip peers or am I missing something? Any help DEFINATELY appreciated!! Brian
Brian McCrary wrote:> Hello, > > I'm trying to run an ATA behind a NAT device, and am confused on exactly > what the qualify config option does, other than send NOTIFY packets. > > Outbound calls work fine, but inbound calls do not go through. With > qualify=yes and nat=yes, my show sip peers looks like: > > 7771111001/7771111001 10.0.0.10 D N 255.255.255.255 > 1222 OK (36 ms) > > So, it has established a connection with the peer on port 1222, however, > when an incoming call comes in, it instead tries to go to port 5060, > which doesn't work. > > I know I could use port forwarding, but that won't work well for > multiple ATAs. So, am I right in thinking Asterisk should automagically > forward the call to the port listed in show sip peers or am I missing > something? Any help DEFINATELY appreciated!!Qualify will make Asterisk send an OPTIONS packet. This allows Asterisk to see latency of the response to the OPTIONS packet (this does NOT test ICMP latency like ping does). This gives Asterisk a GENERAL idea of how lagged the device is. Since Qualify sends packets every once in a while (every 2 seconds?) it will also cause the dynamic port forwarding of your NAT router to keep the UDP translation active. You could set the registration interval for your SIP device to some really low number like 60 seconds and that will accomplish the same thing as the qualify=yes option. Remember clients send packets from a random high port number which changes. Port forwarding on your router is pretty useless. nat=yes combined with qualify=yes should cause enough traffic on the right ports to keep the NAT translations open on your NAT router. Now, if ASTERISK is behind NAT it's a whole other set of issues and fixes, but you don't mention that so I won't cover it. --Eric -- Always do right. This will gratify some people and astonish the rest. Mark Twain
Eric Wieling wrote:> Qualify will make Asterisk send an OPTIONS packet. This allows > Asterisk to see latency of the response to the OPTIONS packet (this > does NOT test ICMP latency like ping does). This gives Asterisk a > GENERAL idea of how lagged the device is. > > Since Qualify sends packets every once in a while (every 2 seconds?) > it will also cause the dynamic port forwarding of your NAT router to > keep the UDP translation active. You could set the registration > interval for your SIP device to some really low number like 60 seconds > and that will accomplish the same thing as the qualify=yes option.Ok, I think I see what is going on from that standpoint, basically all qualify does is send the OPTIONS packet to keep the NAT up and running between the ATA and the NAT router.> Remember clients send packets from a random high port number which > changes. Port forwarding on your router is pretty useless. nat=yes > combined with qualify=yes should cause enough traffic on the right > ports to keep the NAT translations open on your NAT router.In theory, it sounds as if should work pretty easily, since there is a connection already established between the ATA and Asterisk. One big think I forgot to mention is my NAT device is a MC3810 with a PRI attached to it, so it already is running it's own SIP user agent. So, when the ATA gets a call, Asterisk forwards it to the MC3810 (since it's IP registered with the ATA through NAT.) Since the MC3810 doesn't know about the ATAs it just returns "404 Not Found", and that's the end of it. So, I'm guessing, perhaps having a SIP user agent running on the NAT router itself could be causing some of the problem? It's frustrating to see Asterisk talking to the phone with OPTIONS packets, but then not be able to send a call to it, seems like I must be close.> Now, if ASTERISK is behind NAT it's a whole other set of issues and > fixes, but you don't mention that so I won't cover it.Nope, the Asterisk server itself isn't, it has a direct path to the MC3810, but then the ATAs are behind it. Brian