Hello,
We found a situation where an exception would occur if a timeout timer
for a transaction fires when the transaction is still pending in send
(tsx->last_tx->is_pending == 1). This is easiest to reproduce when you
call from remote UA using TCP and unplug the remote UA's connection
(thereby breaking the TCP connection but not causing an immediate socket
close notification from the transport).
When the timeout timer fires, it sets the transaction state to
PJSIP_TSX_STATE_DESTROYED, which destroys the transaction. When the
transport finally fails and calls the callback, it uses the transaction
token but causes an exception because the transaction is already
deleted. Has anyone else seen this?
We fixed it by adding similar handling to that of the
TSX_HAS_PENDING_TRANSPORT flag where we defer the transports deletion by
using the TSX_HAS_PENDING_DESTROY flag when the last_tx->ispending == 1.
Here's an example:
static pj_status_t tsx_on_state_terminated( pjsip_transaction *tsx,
pjsip_event *event)
{
pj_assert(tsx->state == PJSIP_TSX_STATE_TERMINATED);
pj_assert(event->type == PJSIP_EVENT_TIMER);
if (tsx->transport_flag & TSX_HAS_PENDING_TRANSPORT || (tsx->last_tx
!= NULL && tsx->last_tx->is_pending)) {
tsx->transport_flag |= TSX_HAS_PENDING_DESTROY;
}
else {
/* Destroy this transaction */
tsx_set_state(tsx, PJSIP_TSX_STATE_DESTROYED,
event->type, event->body.user.user1 );
}
return PJ_SUCCESS;
}
Can anyone see a problem with doing this?
Christian Gan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100218/3e36fed6/attachment.html>
