> On Thu, 2008-08-14 at 14:28 -0400, Robert Joly wrote: > > 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. > > Did you ever get a response to this?
Congratulations, you are the first one to reply :) > Although I don't see why NAT traversal would have a problem with this. > An SBC makes the call appear to be a call on the internal > network, so NAT traversal mechanisms in sipX shouldn't be triggered. I understand what you are saying and at first glance it appears to be exact however, like most things, this is not as straight forward as it looks in practice. I will provide a detailed description of the problem here to hopefully convince the community of the importance of recognizing SBCs. For my example, I will use 4 components: - an SBC; - a sipXecs box sitting in a private network behind an SBC; - a phone registered to sipXecs also sitting in the private network behind the SBC; - a gateway sitting on the public Internet. The sipXecs is configured with a dialplan to access the gateway via the SBC. 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. When the phone makes an outgoing call that matches the dialplan to the gateway, the INVITE coming out of sipXecs will have a R-URI of <resulting_digits>@<gw_IP> and a Route: header to <SBC_private_IP>. This is the INVITE that the NAT traversal feature will need to process to do NAT compensation. In your statement you say that all calls involving an SBC "appear to be a call on the internal network". There is nothing in the INVITE that the NAT Traversal feature sees that could unambiguously lead it to that conclusion. From its point-of-view, the location of the request target is unknown (i.e. it does not have a private<->public address mapping for the gateway as it is a registration-less device) and as a result will apply NAT compensation and involve sipXecs's Media Relay. So in summary, the NAT Traversal sees that this call as leaving the internal network and involve its Media Relay for NAT compensation - now let's discuss the consequences of that. There are two consequences to the NAT traversal feature not being able tell if a given call will enlist the services of a SBC - these are detailed below. Consequence #1- Voice quality impact: We have already seen that the NAT Traversal feature will use a Media Relay for this call. The problem is that the SBC may involve one as well. This effectively inserts two Media Relays in the media path when one would have sufficed. Besides being sub-optimal, this adds jitter and delay to the media packets and therefore degrades voice quality. Consequence #2 [much trickier] Potential for one-way speech path: When the NAT Traversal feature decides to insert the Media Relay in the media path for NAT compensation, it manipulates the SDP of the INVITE sent toward the gateway. It manipulates the SDP in such a way to attract the gateway's media packets to sipXecs's Media Relay. Given that the gateway is not part of the private network that sipXecs is in, it will supply the public IP address of sipXecs's Media Relay in the SDP to ensure that the gateway can reach it (indeed, the Media Relay's private IP address is not routable from the gateway!). Now, enter the SBC. It sees an INVITE and decides it needs to do NAT compensation and therefore will involve its own media relay. The SBC's media relay will relay packets between the gateway and the media endpoint described in the SDP of the INVITE which happens to be the public IP address of our Media Relay. This means that the SBC's media relay is going to send packets to sipXecs's Media Relay be addressing packets to its public IP address. That public address belongs to the edge router/NAT and unless it can do packet hairpinning, the call will have one-way speech path. Given that not all routers are capable of doing hairpinning, that is a major issue. [note: this example is easier to picture when sipXbridge is used as an SBC] If the NAT Traversal feature could tell that a given call will use an SBC, then it could put logic in place to avoid these consequences at the source. 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. Hoping that I convinced you of the relevance of identifying SBCs, may I restate my original request here: >From my original post of August 14th: "...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..." _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
