> On Thu, 2008-09-18 at 10:29 -0400, Robert Joly wrote: > > > 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..." > > Thanks for the more complete description, Robert... I think I > understand the situation better now. > > Might it also be possible to address this by having the proxy > NAT compensation tag the forwarded INVITE such that > sipXbridge (and the > sipXrelay) can recognize that some transformations have > already been applied and compensate accordingly?
This approach was looked at and deemed sub-optimal for the following reasons: 1- This introduces coupling between two applications (sipXproxy and sipXbridge) that otherwise would not have to know or care about each other. Sometimes, coupling of applications is necessary but I try to avoid it when I can. 2- The bigger issue is that this does not work for SBCs other than sipXbridge 3- The solution I propose is much simpler to implement. Provided I can recognize Routes to SBCs, I can 'fix' things with about 4 lines of code in one method and the fix is clean. I've been running with this prototype in my working directory for more than a month and know that it works. Doing it in sipXbridge would be more complex. > > If not, I think that what we really need is a tag that means > "do not NAT-compensate this request" (as opposed to one that > is specific to SBCs). But I think I still want to do NAT compensation is some cases. The case that comes to mind is when a remote NATed phone is placing a call. Neither sipXbridge nor basic SBCs do remote NAT compensation so I do want to apply my own NAT compensation for this call at the sipXproxy. If the call happens to out through an SBC, it will also apply its own media relay which will cause 'consequence #1' however if I know that the call will go to an SBC, I can prevent 'consequence #2' which is the one I really care about as it breaks calls. Not to make things more confusing but if the SBC we use is the sipXbridge then the scenario I describe will result in double media relaying inside the sipXrelay. Thanks to Ranga, sipXrelay is smart enough to detect two media relay sessions in series and optimize one out in its logic - very clever. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
