ACK and BYE to wrong target

@jonasswiatek I too have the similar setup and same issue while migration.
For some reason chan_sip asterisk 17, doesn’t send ACK and BYE based on Record-route, but uses contact header. So it was working earlier.
My kamailio is stateless and depends on rr

The flow is like below

Carrier --Invite-->Kamailio--Invite(Record-Route: <sip:172.31.3.1;ftag=as1de8fcb8;lr=on>)-->asterisk
Carrier<---200(lRecord-Route: <sip:172.31.3.1;ftag=as1de8fcb8;lr=on>)---Kamilio<--200(Record-Route: <sip:172.31.3.1;ftag=as1de8fcb8;lr=on>)--asterisk

New problem after advertising the local ip in record_route_advertised_address, the carrier not able to send ACK. but BYE from asterisk pjsip is working since the RR is local ip of kamailio.

How do solve this issue while Kamailio talking to public? Some insight might help me.

chan_sip is, effectively, no longer supported. Please use chan_pjsip instead. The zombie thread you referenced was for chan_pjsip.

Your problem is that the proxy is not obeying this part of the RFC:

P1 rewrites its Record-Route header parameter to provide a value that
U1 will find useful, and sends the following to U1:

https://www.rfc-editor.org/rfc/rfc3261#section-16.12.1.3

@david551 thanks for the RFC link, I migrated to chan_pjsip only. I tried saying the same setup was working in chan_sip but not in chan_pjsip. chan_sip ignored the RR header and used only contact header path.
My setup is docker containerised kamailio and asterisk in same machine. Now i’m moved Kamailio out of the asterisk host machine and given a separate Public IP to solve this issue with asterisk chan_pjsip

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.