| | 17 | During fixing this issue, we found a couple of quite major issues: |
| | 18 | |
| | 19 | 1. Dialog being created by {{{pjsip_dlg_create_uas()}}} may be destroyed by other thread before the function returns, so application has no chance to lock the dialog. It may happen with this scenario: |
| | 20 | 1. Initial INVITE is coming, {{{pjsip_dlg_create_uas()}}} is being executed to create UAS dialog. |
| | 21 | 1. {{{pjsip_dlg_create_uas()}}} created transaction for the incoming message and registered the just created dialog. |
| | 22 | 1. Transport disconnected event received by other thread, it triggers transaction to move its state to ''terminated''. |
| | 23 | 1. The just created dialog receives {{{on_tsx_state()}}} and get destroyed! |
| | 24 | |
| | 25 | This is a quite fatal bug, so we decided to deprecate {{{pjsip_dlg_create_uas()}}} immediately and introduced {{{pjsip_dlg_create_uas_and_inc_lock()}}}. Application not affected by this bug, e.g: app with a single worker thread, can continue using {{{pjsip_dlg_create_uas()}}} by setting {{{DEPRECATED_FOR_TICKET_1902}}} to zero in {{{config_site.h}}}. |
| | 26 | |
| | 27 | 2. In case of transport error on multi worker threads application, there is a possibility of a transaction user receiving two {{{on_tsx_state()}}} callbacks concurrently, one for ''terminated'' state notification and another for ''destroyed'' state notification, this is due to delayed ''terminated'' state notification when transport error occurs (the delay was introduced to avoid deadlock, see #1646). For dialog, this can be harmful as one of {{{pjsip_dlg_on_tsx_state()}}} may destroy the dialog, while another {{{pjsip_dlg_on_tsx_state()}}} is waiting for dialog lock. |
| | 28 | |
| | 29 | This ticket fixes this issue by serializing the transaction state notifications. |
![(please configure the [header_logo] section in trac.ini)](/repos/chrome/site/pj.jpg)
