Inconsistent RequestUri Behavior in drachtio-server Proxy when Using Different --contact Configuration

[elasticrash]

I have a question rather than an issue at hand. I'm currently seeking to comprehend the specific behaviour exhibited by the drachtio-server.

I am using drachtio-server as a simple proxy, and I noticed that when I start drachtio server using drachtio --contact "sip:*;transport=udp" and using the following code

srf.invite(async (req, res) => {
    let result = await srf.proxyRequest(
     req,
     ['sip:+xxxxxxxx@SOME_EXTERNAL_IP:5060;transport=UDP'],
     {
              remainInDialog: true,
              followRedirects: false
          });
// ...
}

The initial INVITE requestUri looks like INVITE sip:+xxxxxxxx@PROXY_IP:5060 SIP/2.0

The proxied INVITE correctly goes out with the expected requestUri
INVITE sip:+xxxxxxxx@SOME_EXTERNAL_IP:5060;transport=UDP SIP/2.0

Now if I start drachtio server using drachtio --contact "sip:{LOCAL_IP};transport=udp"

It seems like the proxied INVITE requestUri is staying the same as the initial invite INVITE sip:+xxxxxxxx@PROXY_IP;transport=UDP SIP/2.0

My question is: Why does the --contact argument affect the requestUri?

versions I tried 0.8.22-0.8.24

[xquanluu]

Hi @elasticrash cc @davehorton

I'm trying to reproduce you reported issue but I cannot do that by this PR: https://github.com/drachtio/drachtio-srf/pull/167

UAC INVITE:

INVITE sip:service@172.29.0.10:5060 SIP/2.0
Via: SIP/2.0/UDP 172.29.0.2:5060;branch=z9hG4bK-1-1-0
From: sipp <sip:sipp@172.29.0.2:5060>;tag=1SIPpTag001
To: service <sip:service@172.29.0.10:5060>
Call-ID: 1-1@172.29.0.2-1
CSeq: 1 INVITE
Contact: sip:sipp@172.29.0.2:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length:   131

v=0
o=user1 53655765 2353687637 IN IP4 172.29.0.2
s=-
c=IN IP4 172.29.0.2
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

PROXY INVITE

INVITE sip:123124123@sipp-uas;transport=udp SIP/2.0
Via: SIP/2.0/UDP 172.29.0.10;rport;branch=z9hG4bKdfc2056d-f634-461f-abe2-0dbcf9cf8cb1
Via: SIP/2.0/UDP 172.29.0.2:5060;branch=z9hG4bK-1-1-0;rport=5060
Record-Route: <sip:172.29.0.10:5060;lr>
Max-Forwards: 69
From: sipp <sip:sipp@172.29.0.2:5060>;tag=1SIPpTag001
To: service <sip:service@172.29.0.10:5060>
Call-ID: 1-1@172.29.0.2-1
CSeq: 1 INVITE
Contact: <sip:sipp@172.29.0.2:5060>
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 131

v=0
o=user1 53655765 2353687637 IN IP4 172.29.0.2
s=-
c=IN IP4 172.29.0.2
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Could you please help to comment on that PR to help me reproduce the issue.

[elasticrash]

I am happy to create a small repository first thing tomorrow (it's pretty late here at the moment) that replicates the issue.

[elasticrash]

@xquanluu

Here is the repository. It might be that the setup is unconventional, but this is the setup I have been asked to investigate. Let me know if there is any way I can provide more information.

I choose not to use sipp because I felt it would be less indicative of the issue.

Never the less I'll try to reproduce it, in your PR as well

https://github.com/elasticrash/drachtio_331 I included some of the application logs

[xquanluu]

Thanks @elasticrash

2024-01-22 18:29:27 2024-01-22 11:29:27.541686 isLocalSipUri: checking to see if this is one of mine: sip:+443332222@127.0.0.1:5060
2024-01-22 18:29:27 2024-01-22 11:29:27.542446 ProxyCore::ClientTransaction::forwardRequest - replacing request uri because incoming request uri is local: sip:+443332222@127.0.0.1:5060

Drachtio proxy need to know if the initial request come to him or to someone else by comparing request URI with the list of his contact list. If the initial request is for him, he will replace the URI, if not, he keep the URI as initial request.

In local.yml, if you change proxy command: drachtio --contact "sip:172.29.0.10;transport=udp" --contact "sip:127.0.0.1;transport=udp" --loglevel debug --sofia-loglevel 9

I will work.

This will make sure the request with uri is 127.0.0.1 is identified and proxied properly.

[elasticrash]

@xquanluu Thank you very much for the explanation, now it is a lot more clear.