-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock when using ZRTP as transport in pjsip_2.5-trunk #31
Comments
The ZRTP intercal sync makes sure that the state engine handle only one packet Looking at the stack trace I see that bot threads perform a "zrtp_startZrtpEngine(..). Why Werner Am 31.03.2016 um 14:59 schrieb Jamil:
Werner Dittmann |
Situation seems like following: For solving our problem we are thinking about possible solution to add synchronisation to zrtp->started checking and setting calls. As an architect and developer of this great software we need your advise. Thanks in advance. |
@efendizadeh did you get a solution for this? I'm seeing the same deadlock. |
@aylesm see attached patch |
@efendizadeh thanks. Looks like synchEnter/Leave are only called in that function. So commenting out the callback impl has the same effect as your patch. |
First of all thank you for great work.
We are using pjsip in connection with ZRTP4PJ+ZRTPCPP for delivering secure calls. In development we faced with deadlock problem. After some investigation we found following situation:
As you can see from attached logs (start from thread 20). Pjsip initiates sending of rtp and passes it to zrtp transport over transport_send_rtp function for further processing. Via zrtp4pj API zrtpcpp processEvent(event_t *ev) method (zrtp/ZrtpStateClass.cpp Line 81). In processEvent method synchEnter is called, which locks zrtp mutex (let’s call it mutex_1). After that we returning back to pjsip transport_send_rtp where we have internal pjsip mutex lock (let’s call it mutex_2). At the same in thread 15, Pjsip, before calling srtp_rtp_cb, locks mutex_2, then process goes to start zrtp transport and we come in processEvent method's synchEnter call, where mutex_1 is already locked. Sample diagram attached.
After some investigation we decided that, internal zrtp synchronisation is not needed any more, pjsip is responsible for packet processing synchronisation now. We removed synchEnter and synchLeave and have tested most cases. At this time flight is success :) And the question is that, is this approach is correct?
The text was updated successfully, but these errors were encountered: