On Mon, 2009-06-15 at 15:27 -0400, Mark Gertsvolf wrote: > Hi, > > In the last few weeks we have seen several reports about remote worker > issues due to SIP aware devices between remote worker and sipXecs or due > to service providers blocking SIP traffic on standard SIP ports. > In my sipXecs setup I have experienced cases with remote workers > connecting from various parts of the world either > - have a local SIP-aware layer 3 device or > - service provider either deploying a SIP-aware device or blocking SIP > traffic in their network > > In the above cases the SIP-aware devices are doing damage, while in the > later case the service provider is effectively shutting down remote > worker setup. > > I am looking at two options for solving this problem: > > 1. Allow admin to change the SIP proxy port from standard 5060 to > non-standard port. This works around SIP-aware devices and non-network > neutral service providers. Combined with the ability to configure the > phone to use non-standard SIP port, we can isolate ourselves from and > issues introduced by the network.
> In this first case, I would like to have a way to change the standard > listening SIP ports (both UDP and TCP) via admin UI. At the moment there > is no way to do that without manually modifying configuration files, > which then get overwritten by configuration changes. I see no reason not to have an Advanced Setting for changing the proxy port (it's already in the proxy configuration file). We would also need to modify how the corresponding SRV records are generated... > 2. At least in one case of an unsophisticated ISP I was able to work > around the blocking UDP port 5060 issue by having the phone to switch to > TCP. > > I have experimented with Polycom and Counterpath SMC clients, configured > to use TCP as a transport, trying to force them to only use TCP > transport communicating with sipXecs. However, I was not able to achieve > this in all cases. > > Apart from documented case, where Polycom switches to UDP during MWI > subscription refresh (http://track.sipfoundry.org/browse/XTRN-609) I > have the most basic call scenario of Polycom or SMC calling VM. > 200OK from the VM has: Contact with transport=tcp, but record-route with > no transport parameter. > Both Polycom and SMC send ACK via UDP. > > I realize sipXecs is not obligated to set transport in RR, but at least > in the case of remote worker, who registered via TCP, in may be the > logical thing to do. We already send out-of-dialog requests toward the > remote worker using the transport protocol taken from registration > record. Why not modify the RR based on the registration. > > Even though one can argue that the phone configured to use TCP protocol > should stick to TCP even when facing the freedom on using either UDP or > TCP, there is no harm in forcing the transport to TCP in the case of a > remote worker registered via TCP. I think that this latter issue is a special case of XX-5896, which tracks the need to add a separate Record-Route to support NAT traversal. Having that one specify the transport explicitly is probably a good idea. Do you see any subtlety here that wouldn't catch? _______________________________________________ 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/
