local-net setting not being honoured

[WhiteyDude]

Hi Dave, hope you're well!

I'm running a drachtio-server container with the following exec line (1.1.1.1 substituting the real public IP):

drachtio --contact "sip:*:5060;transport=udp" --local-net 192.168.0.0/24 --external-ip 1.1.1.1 --contact "sip:*:8080;transport=ws" --local-net 192.168.0.0/24 --external-ip 1.1.1.1

Note the container is on a NATed host, so we have 172.18.0.2 (drachtio-server - docker), 192.168.0.110 (docker host) and 1.1.1.1 (public IP).

When sending a UDP INVITE from a SIP client on 192.168.0.100 to 192.168.0.110 5060, I get a 200 (a lot of them, I presume because the ACK gets lost) like this:

2023/07/23 13:14:37.539334 172.18.0.2:5060 -> 192.168.0.100:53064
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.100:53064;rport=53064;branch=z9hG4bKPjijybkKhPOP6MY5gifoeHpAb7Vjf8Bq24
From: "test" <sip:a@192.168.0.110>;tag=K1y2JsZKNlMv1xZpk.OAadksMM.v3qSY
To: <sip:1234@192.168.0.110>;tag=Fv8ppNZ2FBNga
Call-ID: efJftvnA81k9H3dAChj8esPooDfc2top
CSeq: 10787 INVITE
Contact: <sip:1.1.1.1:5060>
Content-Length: 0

The --local-net option is only briefly mentioned in the README, but looking at the binary usage flags, I seem to be specifying it correctly. However I'm working on the assumption that it modifies the Contact header (and any others appropriate) based on the original point of the call to be the internal/external IP whenever appropriate. Is this how this works? In hindsight, given we can't specify an "internal IP", maybe I'm wrong on this.

I'm not great at C++, but having a look at sip-transports.cpp, maybe I'm mistaken in how this works.

Thanks!

[davehorton]

will take a look at this..