Comment 1 for bug 601420

There are several reasons why this may happen. The one I am most familiar with is a consequence of Empathy using ephemeral ports. What happens is that while the SIP port of the Empathy client is bound to port 5060 to receive SIP messages, when sending a message (such as registration), the backend for Empathy instead creates a new socket (on an ephemeral port) to send SIP messages. Some SIP servers, to support NAT, assume the UDP port (and address) the incoming SIP message from the client "appears" from is the place to route return messages, and since this is a transitory socket, the response is of course lost and the chain of operation is broken.

Some argue this is a defect of the SIP server, or not standard compliant behavior, and for this reason upstream (nokia SIP stack) will not change it, while others point out true standard-compliant behavior would fail behind NAT, and indeed further, by Empathy not using the same socket to send registration refreshes, there is also no keyhole keep-alive possible for NAT on UDP. However, this does not offer a solution for your real and immediate issue, but rather simply background as to why it is currently broken.

One thing I had talked about with the Telepathy developers at UDS is using sipwitch as a local SIP proxy to solve this, since SIP Witch actually can deal with the ephemeral port behavior already. Another possibility we discussed was perhaps replacing the Nokia SIP stack with eXosip2. However, none of these are "immediate" options to fix this. A third choice would be to try and get a patch accepted for Nokia SIP. The SIP Witch approach is one I do have control over, being the upstream, and I can look at seeing how we can resolve these scenarios.