]> git.ipfire.org Git - thirdparty/asterisk.git/commit
AST-2021-002: Remote crash possible when negotiating T.38
authorKevin Harwell <kharwell@sangoma.com>
Mon, 1 Feb 2021 21:24:25 +0000 (15:24 -0600)
committerGeorge Joseph <gjoseph@digium.com>
Thu, 18 Feb 2021 16:37:57 +0000 (10:37 -0600)
commitb4f221dcf3a57b0787654de4f6e4bae3fe940452
treeb3051076c2db2189b10e7bd1a30d6e9e79c55cc0
parent251e50a1322be1276355b77c2c97ea578d91eec8
AST-2021-002: Remote crash possible when negotiating T.38

When an endpoint requests to re-negotiate for fax and the incoming
re-invite is received prior to Asterisk sending out the 200 OK for
the initial invite the re-invite gets delayed. When Asterisk does
finally send the re-inivite the SDP includes streams for both audio
and T.38.

This happens because when the pending topology and active topologies
differ (pending stream is not in the active) in the delayed scenario
the pending stream is appended to the active topology. However, in
the fax case the pending stream should replace the active.

This patch makes it so when a delay occurs during fax negotiation,
to or from, the audio stream is replaced by the T.38 stream, or vice
versa instead of being appended.

Further when Asterisk sent the re-invite with both audio and T.38,
and the endpoint responded with a declined T.38 stream then Asterisk
would crash when attempting to change the T.38 state.

This patch also puts in a check that ensures the media state has a
valid fax session (associated udptl object) before changing the
T.38 state internally.

ASTERISK-29203 #close

Change-Id: I407f4fa58651255b6a9030d34fd6578cf65ccf09
res/res_pjsip_session.c
res/res_pjsip_t38.c