search

jambonz / sbc-inbound

SBC application that handles inbound calls
MIT License
5 stars 20 forks source link

Wrong scheme in Contact header after re-INVITE #166

Open Catharsis68 opened 1 week ago

Catharsis68 commented 1 week ago

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 commented 6 days ago

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

AndreHeber commented 6 days ago

@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 commented 6 days ago

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