Host part of a Contact header not replaced to the external ip
spointer opened this issue · 5 comments
Hello Dave,
If drachtio has external-ip(--external-ip), i think drachtio is intended to replace the host part of a few well-known headers to that external-ip.
I found drachtio does not replace the host part of a contact header to the external ip inside the doRespondToSipRequest function.
(sip-dialog-controller.cpp)
// external ip is not set when calling makeTags function.
tags = makeTags( headers, transportDesc ) ;
Here is the debug log ::
2024-01-24 11:32:19.017153 Client::processMessage - got request with 4 tokens
2024-01-24 11:32:19.017166 Client::processMessage - request id bafe06b3-e132-4fbd-9111-e0ba6d5cfb74, request type: sip transaction id: 3e13bfcd-493a-4868-a143-a7e46bab0247, dialog id:
2024-01-24 11:32:19.017178 ClientController::addApiRequest: clientMsgId bafe06b3-e132-4fbd-9111-e0ba6d5cfb74; size: 1
2024-01-24 11:32:19.017226 SipDialogController::doRespondToSipRequest thread 140192544079552
2024-01-24 11:32:19.017264 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - searching transactionId 3e13bfcd-493a-4868-a143-a7e46bab0247
2024-01-24 11:32:19.017276 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - failed to find transactionId 3e13bfcd-493a-4868-a143-a7e46bab0247, most likely this is a response to an invite we sent
2024-01-24 11:32:19.017304 pending-request: removing entry, prior to removal length: 1
2024-01-24 11:32:19.017324 pending-request: removed entry, timer not set (queue is empty after removal), length: 0
2024-01-24 11:32:19.017347 nta.c:1428 set_timeout() nta: timer shortened to 200 ms
2024-01-24 11:32:19.017366 tport.c:1181 tport_ref() tport_ref(0x55f7b1dda500): refcount is now 5
2024-01-24 11:32:19.017403 nta.c:4604 nta_leg_tcreate() nta_leg_tcreate(0x55f7b1e06780)
2024-01-24 11:32:19.017422 DrachtioController::setupLegForIncomingRequest - created leg: 0x55f7b1e06780, irq: 0x55f7b1dfc8c0, for transactionId: 3e13bfcd-493a-4868-a143-a7e46bab0247, tag:
2024-01-24 11:32:19.017443 tport.c:1181 tport_ref() tport_ref(0x55f7b1dda500): refcount is now 6
2024-01-24 11:32:19.017458 SipDialog::SipDialog - (UAS) detected client behind nat, using 10.178.104.101:28504 as route for requests within this dialog
2024-01-24 11:32:19.017480 SipDialog::SipDialog - creating dialog for inbound INVITE sent from UDP/172.16.177.234:3417
2024-01-24 11:32:19.017502 adding IIP inbound tid:3e13bfcd-493a-4868-a143-a7e46bab0247 alive:0s leg:0x55f7b1e06780 irq:0x55f7b1dfc8c0 orq:0 rel:0
2024-01-24 11:32:19.017527 IIP_Insert incoming - ref count: 1 inserting inbound tid:3e13bfcd-493a-4868-a143-a7e46bab0247 alive:0s leg:0x55f7b1e06780 irq:0x55f7b1dfc8c0 orq:0 rel:0
2024-01-24 11:32:19.017546 tport.c:1194 tport_unref() tport_unref(0x55f7b1dda500): refcount is now 5
2024-01-24 11:32:19.017565 SipDialogController::doRespondToSipRequest found invite or subscribe in progress 0x55f7b1dde9a0
2024-01-24 11:32:19.017582 tport.c:1181 tport_ref() tport_ref(0x55f7b1dda500): refcount is now 6
2024-01-24 11:32:19.017601 SipTransport::getContactUri - created Contact header: sip:10.3.15.184:3417
2024-01-24 11:32:19.017625 tport.c:1194 tport_unref() tport_unref(0x55f7b1dda500): refcount is now 5
2024-01-24 11:32:19.017711 makeTags - Adding well-known header 'Call-ID' with value '008B4552-9279-1368-B6B9-B368B20AAA77-332971@10.178.104.101'
2024-01-24 11:32:19.017739 makeTags - Adding well-known header 'cseq' with value '1 INVITE'
2024-01-24 11:32:19.017759 makeTags - Adding well-known header 'from' with value 'sip:1111@test.com;user=phone;tag=008B4570-9279-1368-B6B9-B368B20AAA77-433212'
2024-01-24 11:32:19.017778 makeTags - Adding well-known header 'to' with value 'sip:1111205@10.178.104.101:5060'
2024-01-24 11:32:19.017797 makeTags - hdr 'contact' replacing host with 172.16.177.234
2024-01-24 11:32:19.017815 makeTags - Adding well-known header 'contact' with value 'sip:2412@172.16.177.234:3417'
2024-01-24 11:32:19.017853 SipDialogController::doRespondToSipRequest - client provided contact header so we wont include our internally-generated one
2024-01-24 11:32:19.017871 SipDialogController::doRespondToSipRequest - UAC is refresher, interval will be 180
2024-01-24 11:32:19.017884 SipDialog::setSessionTimer: 008B4552-9279-1368-B6B9-B368B20AAA77-332971@10.178.104.101 Session expires has been set to 180 seconds and refresher is them
Hello Dave,
Any update on this please?
In this case, drachtio-srf app adds custom Contact header like below:
res.send(200, {
headers: {
Contact: `<sip:${req.calledNumber}@localhost>`
}
});
can you include more of the log showing the incoming invite and the 200 OK that is sent back
Here is the SIP messages:
My drachtio is on the k8s(host ip address is "10.3.15.184" and pod ip address is "172.16.177.197") and drachtio has the 10.3.15.184 external ip.
My drachtio-srf app sends 200 OK like below.
dialog = await srf.createUAS(req, res, {
localSdp: endpoint.local.sdp,
headers: {
Contact: `<sip:${req.calledNumber}@localhost>`
}
});
Drachtio-server sets contact header with external IP first(in getContactUri function) and then replace the localhost part of my custom contact header to pod ip(in makeTags function) and finally use the custom contact header(not using the first contact header which has external ip address)
So it seems remote server(in this case 10.178.104.101) send ACK message to wrong address(in this case, to my pod ip)
INVITE sip:2413@10.3.15.184:5060;transport=udp SIP/2.0
From: <sip:660221@test.com;user=phone>;tag=008B4570-9279-1368-B6B9-B368B20AAA77-477291
To: <sip:11024@10.178.104.101:5060>
Call-ID: 008B4552-9279-1368-B6B9-B368B20AAA77-366855@10.178.104.101
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 10.178.104.101:5060;branch=z9hG4bK008B4584-9279-1368-B6B9-B368B20AAA77-3051836
Contact: <sip:660221@10.178.104.101:5060>
X-Genesys-CallInfo: routed
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
Max-Forwards: 68
X-Genesys-CallUUID: 02534FI49MHDLPMDKB42LAES00OHJ
Session-Expires: 180;refresher=uac
Min-SE: 90
Supported: uui,replaces,100rel,timer
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.178.104.101:5060;branch=z9hG4bK008B4584-9279-1368-B6B9-B368B20AAA77-3051836;rport=2546
From: <sip:660221@test.com;user=phone>;tag=008B4570-9279-1368-B6B9-B368B20AAA77-477291
To: <sip:11024@10.178.104.101:5060>
Call-ID: 008B4552-9279-1368-B6B9-B368B20AAA77-366855@10.178.104.101
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.178.104.101:5060;branch=z9hG4bK008B4584-9279-1368-B6B9-B368B20AAA77-3051836;rport=2546
From: <sip:660221@test.com;user=phone>;tag=008B4570-9279-1368-B6B9-B368B20AAA77-477291
To: <sip:11024@10.178.104.101:5060>;tag=7e330yS0jgZBr
Call-ID: 008B4552-9279-1368-B6B9-B368B20AAA77-366855@10.178.104.101
CSeq: 1 INVITE
Contact: <sip:2413@172.16.177.197:5060>
User-Agent: cog
Session-Expires: 180;refresher=uac
Content-Type: application/sdp
Content-Length: 244
v=0
o=cog 1707860183 1707860184 IN IP4 10.3.15.184
s=cog
c=IN IP4 10.3.15.184
t=0 0
m=audio 12122 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
Hello Dave,
Any updates on this issue?
Thank you so much.