]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res_pjsip_pubsub: More accurately persist packet. 45/1045/2
authorMark Michelson <mmichelson@digium.com>
Thu, 6 Aug 2015 17:48:07 +0000 (12:48 -0500)
committerMark Michelson <mmichelson@digium.com>
Thu, 6 Aug 2015 18:15:53 +0000 (13:15 -0500)
commitbfb15bea06d99294ea496ad5e23dd98c244a43b8
treeba44590159afe2229b5a9a857a1b2b7507f4d9b1
parentf6dcbd9707eef32af106c64beca41ac1388b424b
res_pjsip_pubsub: More accurately persist packet.

The pjsip_rx_data structure has a pkt_info.packet field on it that is
the packet that was read from the transport. For datagram transports,
the packet read from the transport will correspond to the SIP message
that arrived. For streamed transports, however, it is possible to read
multiple SIP messages in one packet.

In a recent case, Asterisk crashed on a system where TCP was being used.
This is because at some point, a read from the TCP socket resulted in a
200 OK response as well as an incoming SUBSCRIBE request being stored in
rdata->pkt_info.packet. When the SUBSCRIBE was processed, the
combination 200 OK and SUBSCRIBE was saved in persistent storage. Later,
a restart of Asterisk resulted in the crash because the persistent
subscription recreation code ended up building the 200 OK response
instead of a SUBSCRIBE request, and we attempted to access
request-specific data.

The fix here is to use the pjsip_msg_print() function in order to
persist SUBSCRIBE requests. This way, rather than using the raw socket
data, we use the parsed SIP message that PJSIP has given us. If we
receive multiple SIP messages from a single read, we will be sure only
to save off the relevant SIP message. There also is a safeguard put in
place to make sure that if we do end up reconstructing a SIP response,
it will not cause a crash.

ASTERISK-25306 #close
Reported by Mark Michelson

Change-Id: I4bf16f7b76a2541d10b55de82bcd14c6e542afb2
res/res_pjsip_pubsub.c