trigger on progress indication ("Progress tones available") and this is
how chan_capi actually worked before revision 101 (2005-09-04).
Q.931 (05.98) sections 5.1.2 and 5.4 also specify similar handling on lower
level (they also add "Call is not end-to-end ISDN; further call progress
information may be available in-band" as possible triggering indication).
This patch adds 't' option to dial string that allows switching chan_capi
to such mode of operation.
Without this option set chan_capi works as it did previously.
While we are at it also let's clean up handling of 'DISCONNECT' message
received via INFO_IND - 'case 2' had unnecessary dependency on 'doB3' variable
(only one value is possible by this point in code with i->outgoing being set),
'case 4' had unreachable branch and unnecessary predicates (which were always
true).
These changes should not cause any differences in operation.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
i->lock was taken firsst and ast_channel_lock after by call to one of asterisk functions (get variable, set variable).
As result CAPI thread was blocked in one deadlock condition and stopped the processing of CAPI messages.
The resulting behavior is reported by: http://www.ipphoneforum.eu/showthread.php?t=220051.
Timeouts for CONNECT_CONF and DISC with 'incompatible destination' for opposite side.
But this is still problem: this is delayed channel work which is done without ast_channel_lock held (or channel reference count increassed in
asterisk 1.8(). As result this iss still possible that channel is freed (by asterisk) before the delayed work is executed.
This should be addressed in the next time.
MelwareDE