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/
