[asterisk-dev] T38 woes, possible answer

[Johansson Olle E]

9 nov 2006 kl. 23.31 skrev 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?

The whole idea that the T38 is related to the canreinvite setting
is propably something we need to take away. The NEEDREINVITE
and CANREINVITE setting is more aimed toward RTP redirect to other
IPs than related to re-inviting to another media stream, same IP.

Accidentally, I changed parts of this yesterday in Pineapple and have on
my todo-list to check for chan_sip, but did not note what you write  
above.
Please continue this investigation!

/O