25 Oct
2019
25 Oct
'19
5:37 p.m.
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?
--
Oded Arbel
25 Oct
25 Oct
5:58 p.m.
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(a)cloudonix.io> wrote:
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?
--
Oded Arbel
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:47 p.m.
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(a)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.
--
Oded Arbel
CTO, VP R&D
Cloudonix
On Oct 25, 2019, at 10:37 AM, Oded Arbel
<odeda(a)cloudonix.io> wrote:
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?
--
Oded Arbel
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
8:04 p.m.
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
28 Oct
28 Oct
1:33 p.m.
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!
--
Oded
On Fri, Oct 25, 2019 at 8:06 PM Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On Fri, Oct 25, 2019 at 06:47:38PM +0300, Oded Arbel
wrote:
--
Oded Arbel
CTO, VP R&D
Cloudonix
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1858
days inactive
1861
days old
4 comments
2 participants
participants (2)
-
Alex Balashov -
Oded Arbel