GNOME Bugzilla – Bug 586775
Ekiga can't make calls through an OpenSER proxy
Last modified: 2009-07-09 06:42:20 UTC
Please describe the problem: When running through an OpenSER proxy, the one of the ACK packets gets dropped. It looks like the proxy can't identify what transaction the ACK refers to. This basically means the call never gets set up properly. When making a call via a proxy we see the following sequence of SIP traffic: * -> INVITE sip:foo@pabx.nexusuk.org (no authentication credentials) * <- 100 Giving a try * <- 401 Unauthorized * -> ACK sip:foo@pabx.nexusuk.org * -> INVITE sip:foo@pabx.nexusuk.org (with authentication credentials) * <- 100 Giving a try * <- 200 OK * -> ACK sip:foo@28.33.96.201 The proxy drops the final ACK, and it appears that this is because it can't identify the transaction it refers to. All of the packets contain the same Call-ID header. The only thing that jumps out at me is that Ekiga suddenly switches to using the IP address of the server instead of the name; I don't know enough about SIP to know if this is allowed, but if the proxy server is using both the callee address and the Call-ID header to identify the transaction then this is going to cause problems. I don't actually know if this is a bug with Ekiga or a problem with OpenSER, but Ekiga 3.0.1 worked fine with the same proxy. Steps to reproduce: 1. Set Ekiga to use an OpenSER SIP proxy 2. Make a SIP call Actual results: The call never gets set up properly - I'm calling a Callweaver server and since the ACK gets dropped by OpenSER, Callweaver never starts sending RTP traffic and eventually times the call out. Expected results: Does this happen every time? Yes Other information:
Isn't this a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=582840 ?
It is not. But I remember I have recently seen a commit by Robert fixing problems related to ACK requests. Eugen, could you check ?
I see this in opal master: 2009-05-12 10:23 rjongbloed * ., src/sip/sipcon.cxx, src/sip/sippdu.cxx: Fixed issue with outgoing re-INVITE that gets a 401/407 authentication required error, the re-transmitted INVITE was not a re-INVITE but another normal INVITE, so "hold" doesn't work. Fixed issue with incoming re-INVITE that has no SDp in the INVITE, if the eventual ACK has the same streams but only changed the IP address/port for RTP, then we did not change our RTP send addresss/port. Added more logging for determining Product Info from User-Agent/Server mime field. 2009-04-16 09:23 rjongbloed * ., src/sip/sipep.cxx: Fixed issue with SIP call hairpinning back into the same stack, the ACK is sent to the wrong internal connection, as the from/to fields are around the other way every other command. ACK truly is special. 2009-03-30 07:08 rjongbloed * src/sip/sippdu.cxx: Reversed out two commits changing the updating of target URI (12.2.1.2 says only 2xx does this) and location of ACK transmission (13.2.2.4 says we update the location). This is a hideously complex part of SIP, every time it is touched it is broken! 2009-03-30 04:48 csoutheren * src/sip/sippdu.cxx: Fix problem with ACK going to wrong address
Could fix the issue. Is that already in the new opal stable ?
On 3_6 branch: 2009-06-05 04:24 rjongbloed * version.h: Update release version number to 3.6.3 2009-05-19 09:53 rjongbloed * version.h: Update release version number to 3.6.2 2009-05-12 10:18 rjongbloed * ., src/sip/sipcon.cxx, src/sip/sippdu.cxx: Fixed issue with outgoing re-INVITE that gets a 401/407 authentication required error, the re-transmitted INVITE was not a re-INVITE but another normal INVITE, so "hold" doesn't work. Fixed issue with incoming re-INVITE that has no SDp in the INVITE, if the eventual ACK has the same streams but only changed the IP address/port for RTP, then we did not change our RTP send addresss/port. Added more logging for determining Product Info from User-Agent/Server mime field. 2009-04-16 09:08 rjongbloed * src/sip/sipep.cxx: Fixed issue with SIP call hairpinning back into the same stack, the ACK is sent to the wrong internal connection, as the from/to fields are around the other way every other command. ACK truly is special. 2009-03-24 01:26 rjongbloed * src/sip/sipcon.cxx: Fixed problem with not waiting till ACK arrives before destroying connection object when sending a terminating response (300 and up), some implementations get offended if the ACK gets a transaction does not exist error. Thanks hongsion for the report. 2009-03-18 03:47 rjongbloed * version.h: Update release version number to 3.6.1 2009-02-16 00:23 rjongbloed * Fixed issues with CANCEL: ACK not sent at all if remote sends a 100 in response to CANCEL No resends of ACK on multiple 487 responses, so if ACK gets lost call is not correctly cancelled. Found by hongsion etc.