GNOME Bugzilla – Bug 640703
Ekiga does not re-send ACK message - Not able to dial out from Ekiga - answering calls no problems
Last modified: 2011-05-30 03:41:51 UTC
Test have been performed as a result of the above issue (in summary) based on Alcatel cal server PBX. 1. Making a call from Ekiga (Linux) to the iptouch hard phone 2. Making a call from Ekiga (Windows) to the iptouch hard phone While performing tests connection has been lost when a call tried to be answered on a iptouch phone. On the bottom of the Ekiga window the following error message appears: “Could not connect to remote host” (screenshot-ekiga.jpg) Tracerouts captured during those tests available in files attached (traces gathered on both sides: operating system with softphone installed <-> call server system) 1. ekigalinux and oxeekigalinux files 2. ekigawindows and oxeekigawindows files In addition to that, SIP communication traces that has been made on SIP call server are included: • siptrace-ekigalinux • siptrace-ekigawindows Summarizing, the issue may be described this way: During correct communication between softphone and call server, messages switched between those two are: INVITE, 100 TRYING, 180 RINGING, 200 OK, ACK During INCORRECT connection it looks like this: INVITE, 100 TRYING, 180 RINGING, 200 OK, 200 OK 200 OK….and Ekiga does not send back the ACK message that causes call server to disconnect the other side, (as there is no confirmation for PBX that the call may be maintained).
Please test with latest ekiga on Windows (http://eugen.dedu.free.fr/ekiga-setup-3.3.1-git-64_gb8c9352-debug.exe) and tell us if the problem is still there. If yes, then send us the debug output (-d 4), cf. http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_get_a_debug_output_2.
Created attachment 179420 [details] Files mentioned in the issue description - compressed Unfortunatelly files attached are only siptrace, trace pcap file and screenshot - pcap from call server side is too large and available via email if required.
Could you do as said in comment #1?
Will do on Monday as Alcatel Lab call server will be ready agin. Thanks
Marcin: Any news?
Hey guys, Sorry for the long-time-no-update. We've got tests with Alcatel PBX on Wednesday 08.02 and I will get back to you then. Thanks for the intrest.
Created attachment 180880 [details] Requested Ekiga Windows 3.3.1 debug output Hey Guys, sorry that it took so long but finally here is the debug output you advised me to provide. Looking forward to getting your comments. Thanks Marcin
Information no longer needed as we gave up on Ekiga for our implementation needs. Thanks a lot. Cheers
That does not make the problem itself OBSOLETE, hence reopening.
Sorry for the delay. I see in the attachment of comment 7 that the ACK is sent in fact: At 6:52.475 200 OK is received At 6:52.492 the ACK is sent. So the bug does not appear with ekiga 3.3.1?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!