From: Etienne Lessard <elessard@proformatique.com>
Date: Fri, 9 Jan 2026 16:41:14 +0000 (-0500)
Subject: chan_sip.c: Ensure Contact header is set on responses to INVITE.
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b235d908dd587ba543c217e61cdb3788cb6cac53;p=thirdparty%2Fasterisk.git

chan_sip.c: Ensure Contact header is set on responses to INVITE.

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
---

diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index 9365b1fda4..f3f0971ff7 100644
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -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 &&