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. 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 would like to propose to track both options via JIRA tracker. Each option has its value independently of the other. Thanks, Mark. _______________________________________________ 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/
