Asterisk is an open source framework for building communications applications. Asterisk turns an ordinary computer into a communications server. Asterisk powers IP PBX systems, VoIP gateways, conference servers and other custom solutions. It is used by small businesses, large businesses, call centers, carriers and government agencies, worldwide. Asterisk is free and open source.
18.2.205 Mar 2021 18:05
AST-2021-006 - res_pjsip_t38.c: Check for session_media on reinvite.
When Asterisk sends a reinvite negotiating T38 faxing, it's possible a.
Crash can occur if the response contains a m=image and zero port. The
Reinvite callback code now checks session_media to see if it is null or
Not before trying to access the udptl variable on it.
18.2.120 Feb 2021 01:45
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
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. rtp: Enable srtp replay protection.
Add option "srtpreplayprotection" rtp.conf to enable srtp.
Replay protection. res_pjsip_diversion: adding more than one histinfo to Supported
New responses sent within a PJSIP sessions are based on those that were.
Sent before. Therefore, adding/modifying a header once causes it to be
Sent on all responses that follow.
Sending 181 Call Is Being Forwarded many times first adds "histinfo".
Duplicated more and more, and eventually overflows past the array
This commit adds a check preventing adding "histinfo" more than once.
And skipping it if there is no more space in the header.
Similar overflow situations can also occur in res_pjsip_path and.
Res_pjsip_outbound_registration so those were also modified to
Check the bounds and suppress duplicate Supported values. res_rtp_asterisk.c: signed mismatch that leads to overflow
18.1.124 Dec 2020 02:45
Update for 18.1.1
res/res_pjsip_diversion: prevent crash on tel: uri in History-Info.
Add a check to see if the URI is a Tel URI and prevent crashing on
trying to retrieve the reason parameter.
18.0.106 Nov 2020 19:36
AST-2020-002 - res_pjsip: Stop sending INVITEs after challenge limit.
If Asterisk sends out an INVITE and receives a challenge with a.
Different nonce value each time, it will continuously send out INVITEs,
Even if the call is hung up. The endpoint must be configured for
Outbound authentication for this to occur. A limit has been set on
Outbound INVITEs so that, once reached, Asterisk will stop sending
INVITEs and the transaction will terminate. AST-2020-001 - res_pjsip: Return dialog locked and referenced.
Pjproject returns the dialog locked and with a reference. However,
in Asterisk the method that handles this decrements the reference.
And removes the lock prior to returning. This makes it possible,
Under some circumstances, for another thread to free said dialog
Before the thread that created it attempts to use it again. Of
Course when the thread that created it tries to use a freed dialog
a crash can occur.
This patch makes it so Asterisk now returns the newly created.
Dialog both locked, and with an added reference. This allows the
Caller to de-reference, and unlock the dialog when it is safe to
In the case of a new SIP Invite the lock, and reference are now.
Held for the entirety of the new invite handling process.
Otherwise it's possible for the dialog, or its dependent objects.
Like the transaction, to disappear. For example if there is a TCP