Deadlock between PJSUA LOCK and conference mutex

[ming]

The old issue of #2115 and #1464 still persists, because it can affect other callbacks as well, not just on_call_state(). If inside any pjsua callback which holds PJSUA LOCK, the app calls any pjsua conference/video conference API (which will try to acquire conference mutex), the deadlock can potentially occur with media ports' callbacks, which hold conference mutex, and if the app calls any pjsua API from there.

The best solution seems to be not holding the conference lock when calling media port's eof callbacks. In this ticket, we will try to achieve this by using media event mechanism to call those callbacks.

IMPORTANT: Note that this ticket will deprecate pjmedia_*_set_eof_cb() and pjmedia_*_set_cb() and replace it with pjmedia_*_set_eof_cb2()/set_cb2(), and the callbacks will now be called asynchronously.

[ming]

The old issue of #2115 and #1464 still persists, because it can affect other callbacks as well, not just on_call_state(). If inside any pjsua callback which holds PJSUA LOCK, the app calls any pjsua conference/video conference API (which will try to acquire conference mutex), the deadlock can potentially occur with media ports' callbacks, which hold conference mutex, and if the app calls any pjsua API from there.

The best solution seems to be not holding the conference lock when calling media port's eof callbacks. In this ticket, we will try to achieve this by using media event mechanism to call those callbacks.

[ming]

In 6112:

Fixed #2251: Deadlock between PJSUA LOCK and conference mutex

[nanang]

In 6131:

Re #2251: Fixed bug in memory player, wrong user data passed in invoking callback. Thanks to Marcus Froeschl for the report and the fix.

[nanang]

In 6132:

Re #2251: Fixed bug in memory capture, wrong user data passed in invoking callback.