Asterisk can 'ping' the clients behind NAT with the qualify-option so the NAT-tables and routes are kept open.
What happens when one resets the router (where the NAT-tables are kept) ?? Do NAT-tables get flushed when a router is reset ?? Does the public IP-address needs to be a static IP-address ??? How can Asterisk use qualify to clients that are behind a dynamic public IP-address once registered ?? The clients are not aware that the public IP-address has changed and will not re-register automatically ?! Would dyndns be a solution ? Thanks for the feedback ! Jonas. On Tue, 2009-07-14 at 06:33 -0400, Alex Balashov wrote: > jonas kellens wrote: > > > Is it possible to have several clients behind NAT to register to an > > Asterisk-server with a public IP-address ? > > > > When Asterisk receives an incoming call, how will it know @ which > > private IP-address the client is reachable ? > > > > I guess it is impossible for Asterisk to directly contact the private > > client behind the NAT ?! Or to distinguish between the private clients ?! > > > > Is there an easy solution to this ? How does hosted IP-PBX services work > > then ?! > > Yes, this problem has a solution. The NAT gateway creates a UDP state > mapping between internal source ports and external source (and > destination, since most user agents are symmetrical nowadays) ports. > > The NAT gateway then allocates different external UDP ports for > different "connections" being tracked in this manner. > > Consider, for example, two phones - 192.168.1.10 and 192.168.1.11 - > registering to an outside SIP UAS through a NAT gateway whose public > address is 67.194.23.55. The NAT gateway maps the source ports in a > random or pseudorandom manner akin to: > > 192.168.1.10:5060 --> 67.194.23.55:32947 > 192.168.1.11:5060 --> 67.194.23.55:47948 > > If far-end NAT traversal is enabled on the UAS (in the case of Asterisk, > that's nat=yes in sip.conf), the Contact URI supplied in the REGISTER > message is ignored and the actual "received" IP and port on the network > and transport layer is used in its place. The latter is what is stored > as the contact binding. > > Later, a call comes in and the UAS maps it back to 67.194.23.55:47948 or > 32947 depending on which registrant it is destined to go to. > > This scenario is not without its problems. Some user agents do not > behave symmetrically. Some firewall/NAT router ALGs (application layer > gateways) break this process, though they mean well and try to be > helpful. But by far the most pressing problem is that many NAT gateways > rather quickly age the temporary state information (internal:external > UDP port mapping) out after a relatively short period of inactivity. > That is why many far-end NAT traversal approaches implement a policy of > periodically "pinging" the stored ("received") contact with some sort of > message that causes a bidirectional exchange of communication, and > therefore causes the NAT gateway to reset its expiration timer for that > "connection" state. In Asterisk, the OPTIONS messages generated when > the qualify=yes option is enabled in sip.conf fulfill this function. > > Hope that helps, >
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users