]> git.ipfire.org Git - thirdparty/asterisk.git/commitdiff
chan_sip.c: Ensure Contact header is set on responses to INVITE.
authorEtienne Lessard <elessard@proformatique.com>
Fri, 9 Jan 2026 16:41:14 +0000 (11:41 -0500)
committergithub-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Tue, 13 Jan 2026 15:08:58 +0000 (15:08 +0000)
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

channels/chan_sip.c

index 9365b1fda4326635f69a139d8dbf80b6dd133ff9..f3f0971ff77939d4acfe3a67e46b139cc0fd428b 100644 (file)
@@ -29233,6 +29233,7 @@ static int handle_incoming(struct sip_pvt *p, struct sip_request *req, struct as
                        } 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 &&