]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res_pjsip_pubsub: re-re-fix persistent subscription storage. 69/1169/2
authorMark Michelson <mmichelson@digium.com>
Tue, 1 Sep 2015 14:05:34 +0000 (09:05 -0500)
committerMark Michelson <mmichelson@digium.com>
Tue, 1 Sep 2015 14:41:24 +0000 (09:41 -0500)
commit2f2c35e91d84e1b688c0357f7aea2b215f6c6f5f
tree59b8ef216e12619eff0b8ba3fcd9060e69f92e2b
parent88ee3b3ef2e9ba4382be19730b38501d152d659e
res_pjsip_pubsub: re-re-fix persistent subscription storage.

A recent change to res_pjsip_pubsub switched to using pjsip_msg_print as
a means of writing an appropriate packet to persistent storage. While
this partially solved the issue, it had its own problems.
pjsip_msg_print will always add a Content-Length header to the message
it prints. Frequent restarts of Asterisk can result in persistent
subscriptions being written with five or more Content-Length headers. In
addition, sometimes some apparent corruption of individual headers could
be seen.

This aims to fix the problem by not running a parsed message through an
interpreter but rather by taking the raw message and saving it. The
logic for what to save is going to be different depending on whether a
SUBSCRIBE was received from the wire or if it was pulled from
persistence. When receiving a packet from the wire, when using a
streaming transport, the rdata->pkt_info.packet may contain multiple SIP
messages or fragments. However, the rdata->msg_info.msg_buf will always
contain the current SIP message to be processed. When pulling from
persistence, though, the rdata->msg_info.msg_buf will be NULL since no
transport actually handled the packet. However, since we know that we
will always ever pull one SIP message from persistence, we are free to
save directly from rdata->pkt_info.packet instead.

ASTERISK-25365 #close
Reported by Mark Michelson

Change-Id: I33153b10d0b4dc8e3801aaaee2f48173b867855b
res/res_pjsip_pubsub.c