Scott wrote: > On Fri, 2010-01-01 at 07:29 -0500, Picher, Michael wrote: > > > The 'Enable Internet Calling' setting does break remote users if > > sipXbridge is used as the SBC. > > > > If you enable the 'Enable Internet Calling' setting remote > users show > > as not being behind NAT. If you disable that setting the NAT works > > properly and the remote users are correctly identified as > being behind > > a NAT'd device. > > I've thought more about this, and worked out for myself what > I think the problem is (replies directed to sipx-dev to carry > on the discussion about what to do about it): > > The Internet Calling checkbox causes a configuration change > in forwardingrules.xml, which configures some early routing > decisions in the proxy. Specifically, enabling Internet > Calling adds routes that match local addresses and domains > and add routes to keep them in the proxy, and any other > address or domain is routed directly to the SBC, like these: > > <route mappingType='local ip address'> > <description>Any host address in the local subnets is > routed to the auth proxy.</description> > <routeIPv4subnet>192.168.10.0/16</routeIPv4subnet> > <routeDnsWildcard>*.home.skrb.org</routeDnsWildcard> > <routeTo authRequired="true"/> > </route> > > <route mappingType="external destinations"> > <description>Any foreign domain - route via session > border.</description> > <routeDnsWildcard>*</routeDnsWildcard> > <routeIPv4subnet>0/0</routeIPv4subnet> > <routeTo authRequired="true">192.168.10.10:5090</routeTo> > </route> > > The point of those rules is that they allow one to make a > call to an arbitrary SIP URL and route it through the SBC (in > the examples above, that SBC is sipXbridge). > > I think that what's going wrong is that these rules are > matching because NATted addresses are not local, causing them > to be routed to the bridge. > That won't work, because the NAT mappings are to the proxy > port, not the bridge port, so those packets don't get > through. Register works because it only uses a externally > initiated request/response and the response follows the Vias, > not any routing rule. But making a call requires that > requests work in both directions, and any outbound request > (including the ACK for an inbound call) is misrouted. > > The reason that the behavior is different with an SBC other > than sipXbridge is that if you're using some other SBC you > usually use it both for remote phones, arbitrary SIP url > calling, and ITSP connections. > Since sipXbridge is not used for remote phones, those routing > rules cause a problem. > > Now that we have NAT traversal in the sipXproxy, I think that > those rules are no longer needed if NAT traversal is active. > They would still be needed if an external SBC was being used, > but I suspect that there are no sites that have remote phones > using sipXproxy for NAT traversal and also using some external SBC.
So we should omit those routes when the selected "Default SBC" is an instance of sipXbridge? If you are only using sipXbridge, then do you ever need the "Internal Calling" screen? (I'm pretty sure you would need the "NAT Traversal" screen...) -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
