On Fri 15.01.16 15:40, Gautier Pelloux-Prayer wrote: > Hi Christian, > > Thanks for the patch! However I cannot apply yet for two reasons: > > - firstly, and the most important point, we would need a scenario where this > use case happens to understand why Linphone is behavying like that; if you > can provide us logs (you can sent it to me directly if it should not be > public) it would ease the patch integration > - secondly, due to licence issue, we would need you to sign the contributor > agreement (see > http://www.belledonne-communications.com/downloads/Belledonne_communications_CA.pdf). > > Have a nice weekend, > > Gautier Pelloux-Prayer > Software Engineer @ Belledonne Communications >
Hi Gautier, to be clear: I think this is a problem more general than in my case. And my case is only one that leads to this segfault. I am not a bellesip/linphone specialist. The question is, in which cases process_dialog_terminated is called and belle_sip_dialog_get_previous_state(op->dialog) is BELLE_SIP_DIALOG_EARLY or BELLE_SIP_DIALOG_NULL. I believe, when a failure in SIP handshake happens. Our case (Be warned, it's complicated.): We have a linhone application, that is registered to a Starface sip server. The error message in the log output is: "Your listener did not ACK'd the 200Ok for your INVITE request" error. The linphone application needs too much time to answer the "401 Unauthorized" from Starface. This is because the LinphoneCallOutgoingInit initiates a lot of work in the target device (not in same process) which leads to a peak in CPU load. Then Starface sends a second "401 Unauthorized". This leads to a second out of sync ACK from linphone. It seems that from now on starface does not include the "Contact:" data in the header. And SIP Status messages without a "Contact:" data are not accepted by linphone. ---> This leads to the error message above and to the early call release in linphone. Yes, this is a Starface/asterisk issue. So, our application takes too much time between sending INVITE and be responsive for further SIP Status message processing. This can only be if, the LinphoneCallOutgoingInit processing is done in other processes. If you do every- thing in one process (e.g. GUI update, ...), this problem will not appear, because the INVITE is sent after leaving the call_state_changed callback function. Of course this problem is addressed to our application, but this is the situation that leads to the segfault in linphone. Logs+pcap, contributor agreement: Will follow directly to you. Expected behavour: Linphone should report LinphoneCallError, then LinphoneCallRelease. Cleanly free all call resources. Current behavour: Linphone reports LinphoneCallRelease. Then the next call to linphone_core_iterate leads to a segfault. The patch: I am really not sure if it is the right solution, but it seems to work. The application gets a LinphoneCallError before the LinphoneCallRelease, what is absolutely what we want. And the linphone_core_iterate does not run into a segfault, as it was the case without the patch. Furthermore, I believe that there should be no case where call_set_released is called without prior call_failure or call_terminated, right? Regards, Christian. _______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
