res_pjsip_t38: Don't crash on authenticated reinvite after originated T.38 FAX.
authorMark Michelson <mmichelson@digium.com>
Thu, 23 Apr 2015 17:54:30 +0000 (12:54 -0500)
committerJoshua Colp <jcolp@digium.com>
Thu, 23 Apr 2015 18:09:49 +0000 (13:09 -0500)
commit89a3fc0572222bda44b0cd5d950ebe3ab57f3aca
treef8e27a50cf9c7200b2a0d981dd18a1dc8c968e47
parent7ccaf8aa46ae98be8289180d6b68c17f177e4f2f
res_pjsip_t38: Don't crash on authenticated reinvite after originated T.38 FAX.

When Asterisk originates a channel to an application, the channel is
hung up once the application finishes executing. When the application
in question is SendFax, the Asterisk PJSIP code will attempt to reinvite
the T.38 session to audio after the FAX completes. The hangup of the
channel happens in the midst of this reinvite transaction. In most
circumstances, this works out okay because the BYE is delayed until the
reinvite transaction can complete.

However, if the reinvite that Asterisk sends receives a 401/407
response, then Asterisk's attempt to re-send the reinvite with
authentication will fail. This is because the session supplement in
res_pjsip_t38 makes the assumption that the channel on the session will
always be non-NULL. Since the channel has been hung up, though, the
channel is now NULL. Attempting to operate on the channel causes a
crash.

This patch fixes the issue by ensuring that the channel on the session
is not NULL before attempting to mess with the T.38 framehook.

This patch also contains some corrections for comments that were
incorrect and really confused me when I first started looking at the
code.

ASTERISK-25004 #close
Reported by Mark Michelson

Change-Id: Ic5a1230668369dda4bb13524098aed9306ab45a0
res/res_pjsip_t38.c