Wrong scheme in Contact header after re-INVITE

[Catharsis68]

We have the following setting in the carrier:

SIP Gateways
Outbound: true
TLS/SRTP
Use sips scheme: false

In a re-INVITE we still have `Contact:

2024-09-17 07:00:35.464460 SipDialogController::doSendRequestOutsideDialog - contact: <sips:20.xx.xx.xxx:5061;transport=tls>

[davehorton]

@Catharsis68 do you know if this re-invite was on an inbound leg or an outbound leg?

[AndreHeber]

@davehorton The re-invite was on an outbound leg.
The scenario: Call is coming in and a dial transfer is made. The other end of the dial transfer requests a re-invite. We send the wrong sips scheme in the "200 OK" and we don't get the ACK.

[davehorton]

ok this issue really belongs in sbc-outbound repo then. However, I have tested using the latest code from sbc-outbound and the problem does not happen -- the Contact header in the 200 OK to the re-INVITE is the same as that originally sent in the INVITE by us, so if the latter had "sip" scheme so does the former.

@AndreHeber @Catharsis68 Can you check your code to see if you have this:

First, when we send the INVITE we capture the exact Contact header that went out over the wire here:
https://github.com/jambonz/sbc-outbound/blob/62fb716236cd004e372127dbacd0d1128d4e08c6/lib/call-session.js#L578

Then, when responding 200 OK to a re-INVITE we use that exact same Contact header:
https://github.com/jambonz/sbc-outbound/blob/62fb716236cd004e372127dbacd0d1128d4e08c6/lib/call-session.js#L862