You're welcome. What's TAPI?
-- Sent from mobile device On Jul 17, 2009, at 5:38 AM, jonas kellens <[email protected]> wrote: > Thanks Alex for your explanation. > > Does this NAT-mapping means that TAPI would also be possible ?? > > Jonas. > > On Tue, 2009-07-14 at 06:33 -0400, Alex Balashov wrote: >> >> >> 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 _______________________________________________ -- 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
