sipXecs

Dale Worley added a comment - 2008-05-29 13:25 When a process creates a TCP connection to some other system, the socket on this end is dynamically-allocated. I don't think there's a way to avoid this, since the socket has to be not shared with any other TCP connection. But once the TCP connection is running, I think that incoming messages pass through NATs correctly. I suspect that the conditions for this failure are more complicated than have been presented. Could you provide an example?

Scott Lawrence added a comment - 2008-09-03 19:32 Robert - can you please be more specific about where and when this is a problem?

Robert Joly added a comment - 2008-09-30 09:06 This may not be an issue after all as mentioned in previous comments.

Robert Joly added a comment - 2009-06-08 13:37 I'm reopening this issue based on issues that have been recently observed on a sipXecs 3.0 trial system. This comment will describe the scenario and show how it can be addressed by using symmetric TCP ports instead of ephemeral ports. Scenario: sipXecs (S1) behind a firewall trying to set up a call to a sipXecs on the public internet (S2). When sipXproxy on S1 sends out a message over TCP, it creates a new TCP connection on an ephemeral port, say 1234. The INVITE is sent from TCP port 1234 towards port 5060 of S2 - this creates a pinhole in the firewall fronting S1 between S1:1234 and S2:5060. The INVITE also contains a Record-Route parameter stipulating that any further in-dialog requests should be sent to S1 on TCP port 5060. When S2 wants to send an in-dialog request to S1, it will route that request based on the content of the Record-Route which contains S1:5060 however, a pinhole does not exist to S1:5060 at the firewall and will cause it to drop the packet. If sipXecs utilized symmetric TCP ports instead of asymmetric ones, the initial INVITE from S1->S2 would have been sent from S1:5060 to S2:5060 and would have been sufficient to create the firewall pinhole that would have allowed in any responses and eventual in-dialogs requests. For the time being, this problem can be worked around by forcing the use of UDP instead of TCP. Specifically, if S1 was linked to S2 by a site-to-site dialplan designating S2 as an unmanaged gateway, that gateway's transport in 'show advanced settings' should be set to UDP.