From the original report* on ASTERISK-24915:
> The problem occurs because the handle_incoming function updates
p->method to req->method (p being a struct sip_pvt *) before
checking if the CSeq makes sense, and if the CSeq is unexpected, it
does not reset p->method to its old value before returning. Then,
when asterisk sends the 200 OK response for the original INVITE,
since p->method is now equal to SIP_ACK (instead of SIP_INVITE), the
resp_need_contact function (called from respprep) says "its a SIP
ACK, no need to add a Contact header for the response", which is
wrong, since it's not a SIP ACK but a SIP INVITE dialog.
I have confirmed that the analysis is correct and that the patch fixes
the behavior.
*: https://issues-archive.asterisk.org/ASTERISK-24915
Resolves: #1711
} else if (req->method != SIP_ACK) {
transmit_response(p, "500 Server error", req); /* We must respond according to RFC 3261 sec 12.2 */
}
+ p->method = oldmethod;
return -1;
}
} else if (p->icseq &&