I will attach a full SIP conversation to this e-mail, but here is the summary of what seems to be happening.
I place a call from my phone here, behind NAT. This contacts a SER server with nathelper/rtpproxy out on the 'net, which then forwards the requests to Masergy (www.masergy.com), who provide us with LD VoIP service. Everything proceeds fine until the "OK" reply from Masergy signalling the call has been answered. Here's the transaction there:
Masergy port 29436 -> SER port 5060 "OK" SER port 5060 -> My Phone port 5060 "OK" My Phone port 5060 -> SER port 5060 "ACK" SER port 5060 -> Masergy port 29436 "ACK"
Masergy never receives that last packet.
However, my phone receives all of the information it needs to establish the RTP connection. It does so, and the call appears to be working fine. Meanwhile, Masergy's SIP server continues to resend "SIP/2.0 200 OK" messages (still from port 29436) every few seconds, waiting for a reply. After ~35 seconds of not hearing back, it assumes the worst and sends a "BYE", tearing down a call that was going swell, as far as the two humans involved were concerned.
I've spoken with the relevant tech at Masergy, and their determination is that our SIP proxy should be sending all SIP traffic to port 5060, regardless of what they may be transmitting from.
I just built the very latest CVS version of SER (0.8.99-dev8), and am seeing the same behavior. Is this a protocol violation on either side? (Transmitting to a non-5060 port, or not listening for a reply on a port that was just transmitted from). Is there a way to force SER to always use 5060? (Which itself probably breaks protocol for some cases, which we aren't currently dealing with).
Thank you for any info.
Jeremy