Handle a SIP re-INVITE for mid-call media renegotiation (hold, codec change, or transfer preparation)

Verified steps

1. Detect an in-dialog re-INVITE by checking that the INVITE contains the same Call-ID and From tag as the established dialog; respond immediately with 100 Trying to prevent retransmission timeouts while you process the new SDP offer.
2. Inspect the new SDP: a hold is signaled by a=sendonly or a=inactive in the offer (or an IP address of 0.0.0.0 in the connection line for older implementations); respond with 200 OK and a=recvonly or a=inactive in the answer accordingly and pause media sending.
3. For a codec change, compare the offered codec list against the established codecs; if the intersection is non-empty, select the new preferred codec, update your RTP sessions, and include the updated codec in the 200 OK answer.
4. After sending 200 OK, wait for the ACK to confirm the renegotiation is complete before switching media; do not change the RTP stream until the ACK arrives.
5. If your endpoint cannot accept the re-INVITE (e.g., unsupported codec, resource unavailable), respond with an appropriate 4xx or 5xx response; the existing media session continues unchanged as per RFC 3261.
6. For attended transfer, a re-INVITE from the transferring party may arrive with a Replaces header referencing a different dialog; validate the Replaces dialog exists and replace the media session atomically.