Dale Worley wrote: > On Thu, 2008-09-18 at 10:29 -0400, Joly, Robert (CAR:9D30) wrote: > > The sipXecs NAT Traversal feature is enabled and is configured with > > the public IP address of the SBC as its 'public address' as > it should. > > I don't see why NAT Traversal is enabled.
[copied from my last post on the subject]: "Important note: Some people may wonder why one would use sipXecs's NAT Traversal feature if you have a full-blown SBC sitting in your network. The answer is that you wouldn't use the feature in such a scenario. However, if you are using a basic SBC that is not capable of Remote NAT traversal or a pseudo-SBC like sipXbridge, you would want to use sipXecs's NAT Traversal feature to handle remote NAT traversal and in this case would be subject to the consequences explained above." > The *purpose* of > the SBC is to adjust all the SIP signaling so that sipX sees > everything on the far side of the SBC as if it were on the > local network. Hence, if the SBC sends an INVITE to the > gateway's address, the SBC will take care of all the > signaling work, and sipX can act as if the gateway was on a > local network. ...if it knows that an SBC is in the picture. You are right and that is exactly what I'm trying to promote in this e-mail - a mechanism that will let sipX know that an SBC will get involved for a given call so it can get out of the way. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
