Looking at the branch version of 1.8, the following code in
handle_request_refer appears to blatantly breach the pre-conditions for
ast_cel_report_event, namely that no locks be held.
/* XXX - what to we put in CEL 'extra' for attended transfers to
external systems? NULL for now */
ast_channel_lock(current.chan1);
ast_cel_report_event(current.chan1, p->refer->attendedtransfer?
AST_CEL_ATTENDEDTRANSFER : AST_CEL_BLINDTRANSFER, NULL,
p->refer->attendedtransfer ? NULL : p->refer->refer_to, current.chan2);
ast_channel_unlock(current.chan1);
It looks like a lock has existed since the initial inclusion of CEL in trunk,
as the unlock follows the CEL call there, but the lock moved closer to the call
in a later version.
--
David Woolley
BTS Holdings Plc
Tel: +44 (0)20 8401 9000 Fax: +44 (0)20 8401 9100
http://www.bts.co.uk<http://www.bts.co.uk/>
BTS Holdings PLC - Registered office: BTS House, Manor Road, Wallington, SM6
0DD - Registered in England: 1517630--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
