Hi, we are having a problem with a network change use case. It goes on something like this:
1. Kamailio receives INVITE from caller. 2. Kamailio sends INVITE to callee MUA. 3. MUA response with 100, then 183. 4. MUA then loses network connectivity and re-establishes access with another IP address. 5. MUA sends 200 OK from the new IP address, but with `Contact` still set as the old address (which I think it should, because you aren't allowed to change contact in the middle of dialog?) 6. Kamailio forwards 200 OK to caller and receives ACK. 7. Kamailio sends ACK to old IP address of MUA.
The last step is obviously a problem as the MUA will not be able to see the ACK.
I'm trying to see how to resolve this issue. I can capture the "$si" and "$sp" of the new address in the reply route (I also tried to get the MUA to send OPTIONS immediately after reestablishing connectivity, and capture "$si"/"$sp" there, which also works), but I can't figure out how to update the destination of the ACK. I've tried running `fix_nated_contact()` as well as trying to write into various pseudo variables - in either the OPTIONS request handler or the 200 reply handler - which either errors or does nothing.
Any suggestions?
Hi,
I may be mistaken, but my reading of 3261 is that a final dialog-forming response may update the remote target (Contact) previously sent by an early dialog-forming provisional reply.
That having been said, apart from using nathelper techniques (add_contact_alias() and handle_ruri_alias()), I can’t see a good way to deal with this problem. In general, SIP doesn’t really contemplate situations where the network and transport-layer reachability information of an endpoint changes mid-dialog except as part of a target refresh request (UPDATE, re-INVITE).
— Sent from mobile, with due apologies for brevity and errors.
On Oct 25, 2019, at 10:37 AM, Oded Arbel odeda@cloudonix.io wrote:
Hi, we are having a problem with a network change use case. It goes on something like this:
- Kamailio receives INVITE from caller.
- Kamailio sends INVITE to callee MUA.
- MUA response with 100, then 183.
- MUA then loses network connectivity and re-establishes access with another IP address.
- MUA sends 200 OK from the new IP address, but with `Contact` still set as the old address (which I think it should, because you aren't allowed to change contact in the middle of dialog?)
- Kamailio forwards 200 OK to caller and receives ACK.
- Kamailio sends ACK to old IP address of MUA.
The last step is obviously a problem as the MUA will not be able to see the ACK.
I'm trying to see how to resolve this issue. I can capture the "$si" and "$sp" of the new address in the reply route (I also tried to get the MUA to send OPTIONS immediately after reestablishing connectivity, and capture "$si"/"$sp" there, which also works), but I can't figure out how to update the destination of the ACK. I've tried running `fix_nated_contact()` as well as trying to write into various pseudo variables - in either the OPTIONS request handler or the 200 reply handler - which either errors or does nothing.
Any suggestions?
Oded Arbel
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Thanks for the reply. I haven't used add_contact_alias/handle_ruri_alias before - how would I make use of them?
Should I call add_contact_alias() in the 200 reply route? And if so - when do I call handle_ruri_alias()?
On Fri, Oct 25, 2019 at 6:00 PM Alex Balashov abalashov@evaristesys.com wrote:
Hi,
I may be mistaken, but my reading of 3261 is that a final dialog-forming response may update the remote target (Contact) previously sent by an early dialog-forming provisional reply.
That having been said, apart from using nathelper techniques (add_contact_alias() and handle_ruri_alias()), I can’t see a good way to deal with this problem. In general, SIP doesn’t really contemplate situations where the network and transport-layer reachability information of an endpoint changes mid-dialog except as part of a target refresh request (UPDATE, re-INVITE).
— Sent from mobile, with due apologies for brevity and errors.
On Oct 25, 2019, at 10:37 AM, Oded Arbel odeda@cloudonix.io wrote:
Hi, we are having a problem with a network change use case. It goes on
something like this:
- Kamailio receives INVITE from caller.
- Kamailio sends INVITE to callee MUA.
- MUA response with 100, then 183.
- MUA then loses network connectivity and re-establishes access with
another IP address.
- MUA sends 200 OK from the new IP address, but with `Contact` still
set as the old address (which I think it should, because you aren't allowed to change contact in the middle of dialog?)
- Kamailio forwards 200 OK to caller and receives ACK.
- Kamailio sends ACK to old IP address of MUA.
The last step is obviously a problem as the MUA will not be able to see
the ACK.
I'm trying to see how to resolve this issue. I can capture the "$si" and
"$sp" of the new address in the reply route (I also tried to get the MUA to send OPTIONS immediately after reestablishing connectivity, and capture "$si"/"$sp" there, which also works), but I can't figure out how to update the destination of the ACK. I've tried running `fix_nated_contact()` as well as trying to write into various pseudo variables - in either the OPTIONS request handler or the 200 reply handler - which either errors or does nothing.
Any suggestions?
Oded Arbel
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Fri, Oct 25, 2019 at 06:47:38PM +0300, Oded Arbel wrote:
Thanks for the reply. I haven't used add_contact_alias/handle_ruri_alias before - how would I make use of them?
Should I call add_contact_alias() in the 200 reply route? And if so - when do I call handle_ruri_alias()?
Try set_contact_alias() (it might make more sense than add_contact_alias() here, though they are substantially the same) in the onreply_route handling both the 18x and the 200 OK, and call handle_ruri_alias() in the section of the config with loose_route() route and friends, which handles in-dialog request routing.
One nice thing about handle_ruri_alias() is it silently returns if there is no ;alias URI parameter, so you can call it without a bunch of conditional logic around whether it is appropriate to call it.
-- Alex
Hi Alex, we've tested the suggested changes and it works great!
I've called `set_contact_alias()` in `reply_route` and `handle_ruri_alias()` in `if(loose_route()) ...`, and that solved the problem - the `ACK` is now sent correctly to the IP address that sent the reply.
Great job and thank you very much.
BTW, Nir S. sends his regards.
Cheers!
-
Alex Balashov -
Oded Arbel