17 Sep
2024
17 Sep
'24
11:25 p.m.
Hello community!
I would like to ask for your help in solving a case. I thank you in advance
for any collaboration.
I have the following setup:
- *Asterisk (internal)* → *Kamailio (Proxy)* → *SIP Provider (PSTN)*
Both Asterisk and Kamailio are under my responsibility.
*Problem:*
When I initiate a call from Asterisk, I use Kamailio as the *outbound proxy*.
The *INVITE* is sent to the SIP provider, and the dialogue proceeds
normally until the provider responds with a *200 OK*, indicating the call
was answered.
However, the *200 OK* received from the provider contains a modification in
the *Contact* header, introducing a new IP address into the dialogue.
Presumably, this new IP is where the subsequent *ACK* should be sent.
The issue arises when Kamailio receives this *200 OK*: it overwrites the
*Contact* field, replacing the received IP with its own LAN IP, used for
communication with Asterisk. As a result, Asterisk sends the *ACK* back to
Kamailio, which, instead of forwarding it to the new IP from the *Contact*
in the *200 OK*, sends it to the SIP provider at the same address used for
the initial *INVITE*.
Since the *ACK* does not reach the IP expected by the provider (the new IP
introduced in the *Contact*), the provider continues to send repeated *200
OK* responses, until the call is disconnected due to a timeout, as a valid
*ACK* was never received.
I looked for conceptual answers in *RFC 3261* to support my conclusions,
but I couldn’t clearly relate the information there to the behavior
observed in this scenario.
*Key Questions:*
1.
*Should Kamailio forward the ACK to the new IP provided in the Contact
header of the 200 OK?*
2.
*Is the SIP provider correct in expecting the ACK to be sent to a
different address from the original one used in the INVITE?*
3.
*How can I configure Kamailio to ensure the dialogue proceeds correctly
and the ACK is sent to the correct IP?*