We use Kamailio 5.5.0 and topos/topos_redis as well as the uac module to register with sipconnect 1.1 based trunks. When we want to originate a call via such a trunk, we encounter the following problem with ACK routing.
200 OK sent by Trunk
`U 217.10.68.150:5060 -> 172.31.16.103:5060 #7583 SIP/2.0 200 OK. Via: SIP/2.0/UDP 3.67.244.157:5060;branch=z9hG4bK496f.744a3c48b24be1ba5fdda68cf5fe3878.1. Record-Route: sip:172.20.40.8;lr. Record-Route: sip:217.10.68.150;lr. Call-ID: 7cd83e052202a97f4e28728276e0c758@35.157.121.101:5060. From: "01705441258" sip:2908206t0@sipconnect.sipgate.de;tag=as010d26b4. To: sip:+493046996025@voip.sandbox.aaron.ai;tag=221f5413-4c48-4f53-97e8-d96ea6413f26. CSeq: 102 INVITE. Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER. Contact: sip:217.10.77.61:5060. Supported: replaces. Content-Type: application/sdp. Content-Length: 242. .. v=0. o=- 56188352 56188354 IN IP4 212.9.44.180. s=sGW. c=IN IP4 212.9.44.180. t=0 0. m=audio 27558 RTP/AVP 8 101. a=maxptime:150. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=sendrecv. a=rtcp:27559. a=ptime:20. `
ACK sent by Kamailio
`ACK sip:217.10.68.150:5060 SIP/2.0. Via: SIP/2.0/UDP 3.67.244.157:5060;branch=z9hG4bK496f.af6a45e3907d2bea8ea65cc42f223fb2.0. Max-Forwards: 69. From: "01705441258" sip:01705441258@35.157.121.101;tag=as010d26b4. To: sip:+493046996025@voip.sandbox.aaron.ai:5060;tag=221f5413-4c48-4f53-97e8-d96ea6413f26. Call-ID: 7cd83e052202a97f4e28728276e0c758@35.157.121.101:5060. CSeq: 102 ACK. User-Agent: Asterisk PBX 13.38.1. Content-Length: 0. Route: sip:217.10.68.150;lr. Route: sip:172.20.40.8;lr. Contact: sip:btpsh-61a6122b-a-1@3.67.244.157. .. `
The ACK is not accepted by the trunk, because the R-URI does not contain the address fromt the 200 OK/Contact. 200 OK is then retransmitted by the trunk. [kamailio-uac-topos-bug-report.zip](https://github.com/kamailio/kamailio/files/7625990/kamailio-uac-topos-bug-re...)
The R-URI is the next hop address like in the first Route header, which indicates that your config might do wrong NAT traversal processing, like using fix_nated_contact(), when the proxy is not the first hop after the NAT router.
There is no indication of a bug in the c code, therefore I suggest to discuss about your config and this behaviour on sr-users@lists.kamailio.org mailing list. Once it is sorted out what happens and if proves to be a C code problem, an issue can be created with the clear details of the bug.
Closed #2961.