ACK message not coming in

[yogitaB99]

Hi
We have configured our sip environment to communicate with drachtio and rtp-engine (both running as docker containers in a AWS cluster) and almost everything seems to work as expected except for the ACK message not being properly sent by drachtio (rerouting per se). For further context, we're having multiple instances of our sip service and a DNS resolver as our middleware which sends the SIP messages from drachtio to one of the sip server instances (as resolved by DNS). Currently, both the invite and ok messages are being communicated properly, but when drachtio sends the ack message, it gets rerouted to another IP address. I think we're missing some config settings while making the nat work properly in our hosted environment, would you be able to help us with this?

[davehorton]

show logs of the INVITE - ACK along with details on AWS ip addresses

[ChockalingamS]

Hey @davehorton , I have sent out the logs on an email on behalf of Yogita. Looking forward to your reply. Thanks

[davehorton]

Yes, drachtio is receiving the 200 OK and concluding that the far end server is behind a NAT device

SipDialogController::processResponse - (UAC) detected downstream client; contact ip: 172.18.XX.XX differs from recv address: 10.100.XX.XX
SipDialogController::processResponse - (UAC) detected nat setting route to: sip:10.100.XX.XX:23010

Therefore it is sending the ACK to the 10.100 address

It's interesting that your server accepted the INVITE at that address (so it is clearly reachable), but not the ACK.

Is your conclusion that you want the ACK to be sent to the 172.18 address in the Contact header?

[ChockalingamS]

Yes, I would like the ACK to be sent to 172.18 address in the contact header.

On another note, the initial invite message reaches the addresses as we append "transport=tcp" while for ack it isn'tthis is why it is failing.

[davehorton]

Hmm, yes upon inspection it seems like the issue is that the ACK is being sent over UDP.

What version of drachtio server are you running? You can do drachtio -v to find out

[ChockalingamS]

I use v0.8.9-rc2-3-gfb3deb3c6.

Also, anyways I would like the ACK to be sent to the IPAddress available in the contact header only.

[ChockalingamS]

@davehorton did you get a chance to check on this? Any guidance would be much helpful please. Thanks

[davehorton]

this looks like a bug. I will try to recreate.

[ChockalingamS]

ohhh ok. Excellent, thanks and when can we expect this @davehorton .

[davehorton]

hope to have time to look at it this week. Do you have the ability to test a potential fix on your system?

[ChockalingamS]

Sure, should be fine from my end anytime and we are looking for the solution ASAP so anything real soon would be much helpful please @davehorton .

Also, I would like to just reconfirm once again the main requirement around here - The ACK mesg should reach the IPAddress available in the contact header.

[ChockalingamS]

Any updates around it @davehorton .

[davehorton]

Not yet. I've got a lot of work on my plate at the moment with my commercial clients. Still hope to get to it soon

[ChockalingamS]

oops sorry for the rush, thanks very much appreciated. will wait for your updates. :)

[ChockalingamS]

Hi @davehorton

Any updates please? Also, if I want to pickup and check which branch would be best?

Thanks

[davehorton]

I've pushed a branch called bugfix/162. Could you build from this branch, retest and send me the resulting drachtio log file?

[davehorton]

Oh, I forgot to mention -- you need to set the command line arg --disable-nat-detection

[ChockalingamS]

Hi Dave, Thanks a lot, the calls are getting connected, in between I had a quick fix as well in place, editing the sip-dialog-controller both works but when multiple calls are tested on parallel the calls are connecting but the response is coming back after quite a while for example I made 20th call parallel the response came back like after 30 seconds, now trying to find the cause on this.

Have you ever come across this issue faced by any of the users?

Irrespective, thank you so much for taking time to look at this and fixing, great help. :)

[davehorton]

No, have not heard of that issue before.