Fwiw, if an internal phone attempted to url dial to a phone not registered on the system it didn't work either. Don't know if that helps any in diagnostics or not.
-----Original Message----- From: Scott Lawrence [mailto:[email protected]] Sent: Friday, January 01, 2010 2:12 PM To: Picher, Michael Cc: Scott Lawrence; Tony Graziano; [email protected]; sipXecs developers Subject: RE: config problem or sipxbridge problem? 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. _______________________________________________ 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/
