Gents, I was testing the latest version of the NAT traversal feature with sipXbridge. The testing revealed a need for the NAT Traversal feature to recognize calls that will exit sipX's local private network through an SBC (e.g. a call initiated by a local user to an ITPS via sipXbridge). Failure to recognize that will result in no-way speech path when sipXbridge is used as an SBC and sipXecs is deployed behind a NAT that cannot do hairpinning.
The purpose of this post is to discuss the best way for the NAT traversal feature to recognize calls that are routed to one of the SBCs provisioned on the system. The simplest way would be to look at dialog-forming INVITEs as they are about to leave sipXecs, check for the presence of Route: header(s) and treat the top Route as an SBC. The problem with that approach is that it is making an assumption that the top Route, when present, points to an SBC which is not guaranteed to always be true. A better approach might be to explicitly label the Routes to SBCs as such through the addition of a custom URL parameter. More specifically, when the sipXconfig generates forwardingrules.xml or fallbackrules.xml with rules that include a route to an SBC, the Route that gets included to these rules could be of the format "route=<IPAddr>[:port][;transport];routetosbc". The presence of that "routetosbc" Url parameter could be used by the NAT traversal feature to unambiguously recognize top Routes pointing to configured SBCs. I welcome your inputs in this approach and would like to hear about alternatives as well. Thanks in advance, bob
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
