On Thu, Sep 18, 2008 at 1:29 PM, Robert Joly <[EMAIL PROTECTED]> wrote: >> 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. > > 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
As an exercise I would like to understand how this would work. However, I do agree with Robert in wanting to keep the two sides of the SBC ( sipxbridge in this case ) independent. > > 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 I think this is a solid point in favor not introducing any dependencies > 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. I would like to understand how that would work. The simplest solution is usually the best. There is also the scaling issue. Given that sipxbridge has to register with ITSPs from a single place, there can only be one instance of it whereas there can be many instances of relay / proxy server. Since the proxy has more information about what processing has to be done, it is also best that it implements this solution. > >> >> 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. Does so through a local search and recursive callback rather than dispatch message out to wire and back. Quite straightforward. > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
