[asterisk-dev] T38 woes, possible answer

[Dan Austin]

Perhaps I have too much time on my hands, but I have been
monitoring the T38 bugs, reviewing the logs and the code
in chan_sip to see if I could help move those bugs along.
I don't have any T38 capable endpoints, so I didn't expect
to make much progress.

However, I think I see an issue that might explain the
current failure mode.

In bug-id 7844 the logs show what appears to be a successful
T38 negotiation followed by an immediate RTP re-invite.

The issue appears to be in one or both of these functions:

handle_request() case SIP_ACK: calls check_pending() which has
no idea of t38.state

-- or --
handle_request_invite() case 200: calls check_pending() which has
no idea of t38.state

check_pending() likely does not need to know about t38.state,
but perhaps sip_handle_t38_reinvite() should clear the 
SIP_NEEDREINVITE flag so that check_pending will not start the
whole process over.

Thoughts?

Dan