summaryrefslogtreecommitdiff
path: root/rest-api/api-docs/deviceStates.json
diff options
context:
space:
mode:
authorMark Michelson <mmichelson@digium.com>2014-12-08 16:41:45 +0000
committerMark Michelson <mmichelson@digium.com>2014-12-08 16:41:45 +0000
commit1712694817cfa4cfdf9cbf5dedf679b9e56140a9 (patch)
tree4278187b8894432b6002912d2a8074c94bd22c46 /rest-api/api-docs/deviceStates.json
parent93b1df3bf6c6832053fc7444cd07640c273cb1df (diff)
Fix a crash that would occur when receiving a 491 response to a reinvite.
The reviewboard description does a fine job of summarizing this, so here it is: A reporter discovered that Asterisk would crash when attempting to retransmit a reinvite that had previously received a 491 response. The crash occurred because a pjsip_tx_data structure was being saved for reuse, but its reference count was not being increased. The result was that the pjsip_tx_data was being freed before we were actually done with it. When we attempted to re-use the structure when re-sending the reinvite, Asterisk would crash. The fix implemented here is not to try holding onto the pjsip_tx_data at all. Instead, when we reschedule sending the reinvite, we create a brand new pjsip_tx_data and send that instead. Because of this change, there is no need for an ast_sip_session_delayed_request structure to have a pjsip_tx_data on it any more. So any code referencing its use has been removed. When this initial fix was introduced, I encountered a second crash when processing a subsequent 200 OK on a rescheduled reinvite. The reason was that when rescheduling the reinvite, we gave the wrong location for a response callback. This has been fixed in this patch as well. ASTERISK-24556 #close Reported by Abhay Gupta Review: https://reviewboard.asterisk.org/r/4233 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'rest-api/api-docs/deviceStates.json')
0 files changed, 0 insertions, 0 deletions