When audio frames are given to the audio transcoding support in Asterisk the number of samples are examined and as part of this a message is output to indicate that no samples are present. A change was done to suppress this message for a particular scenario in which the message was not relevant. This change assumed that information about the origin of a frame will always exist when in reality it may not. This issue presented itself when an RTP packet containing no audio (and thus no samples) was received. In a particular transcoding scenario this audio frame would get turned into a frame with no origin information. If this new frame was then given to the audio transcoding support a crash would occur as no samples and no origin information would be present. The transcoding scenario requires the “genericplc” option to be set to enabled (the default) and a transcoding path from the source format into signed linear and then from signed linear into another format.
When Asterisk sends a re-invite initiating T.38 faxing, and the endpoint responds with a declined media stream a crash will then occur in Asterisk.
When T.38 faxing is done in Asterisk a T.38 reinvite may be sent to an endpoint to switch it to T.38. If the endpoint responds with an improperly formatted SDP answer including both a T.38 UDPTL stream and an audio or video stream containing only codecs not allowed on the SIP peer or user a crash will occur. The code incorrectly assumes that there will be at least one common codec when T.38 is also in the SDP answer. This requires Asterisk to initiate a T.38 reinvite which is only done when executing the ReceiveFax dialplan application or performing T.38 passthrough where a remote endpoint has requested T.38.
A specially crafted SIP in-dialog MESSAGE message can cause Asterisk to crash.