18 May
2020
18 May
'20
3:03 a.m.
Hello again,
In continuation of this topic, just today I decide to try
out nat_keepalive(), it sounded like a nice-to-have feature for my edge
proxies.
I can also confirm that when using contact_match=1 && set_contact_alias()
the keepalives are being sent out correctly. However, not so much when
using fix_nated_contact(). Rightfully so one may argue why use it in 1st
place, however in some cases rewriting the Contact's addresses is necessary.
If it's not too much trouble, can the contact_match modparam be adjusted to
account for this scenario as well?
Thanks.
On Sat, Apr 4, 2020 at 12:39 PM Daniel W. Graham <dan(a)cmsinter.net> wrote:
I pulled master branch and tested with contact_match=1
and it resolved the
issue. I am using path with loose_route as well, but seems to be an issue
with the endpoint not honoring path. I’m going to do further testing later
today to make sure it doesn't have negative impact on invite keepalives,
but looks good so far.
Thanks for your commits, they are much appreciated! Thanks to all others
that offered input as well!
On Apr 4, 2020, at 4:06 AM, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
I looked a bit a the code of the nat_traversal module and it takes the
Expires values from SIP replies, when REGISTER is forwarded (it has to be
with tm t_relay()), but at that moment it compares the contacts with the
headers in request (taken from transaction structure) via string comparison
and in case of mismatch, they are ignored.
So, when you change the contacts during REGISTER request processing, then
you get different values in the replies.
The solution is to not touch the contact at all, but use Path (see path
module) when routing out REGISTERs, then call loose_route() for initial
requests as well.
An alternative is to try to use the keepalive module instead of
nat_traversal, maybe it gives what you need.
And the last one, in master branch I pushed 2 commits (one to core and one
to nat_traversal module) to add an option to match the contact URI by
comparing type, user, host, port and proto. You can try with master branch
by setting contact_match=1 for nat_traversal param and see if works.
Cheers,
Daniel
On 04.04.20 03:05, Daniel W. Graham wrote:
Register time is not detected when add_contact_alias() is enabled:
With add_contact_alias() :
Apr 3 20:45:01 host /usr/local/sbin/kamailio[28022]: DEBUG: {2 2 REGISTER
103104ZDUxMzk3ZTg4OTM4ZGFhM2M1NmI3ZjBjYTQ3NWM1NWI} nat_traversal
[nat_traversal.c:963]: get_register_expire(): maximum expire for all
contacts: 0
Without add_contact_alias():
Apr 3 20:56:52 edgedev /usr/local/sbin/kamailio[28104]: DEBUG: {2 2
REGISTER 103104ZmRiZTI0Y2NkNjUxNDRiYzg5Njc1MzI1NjRkZTM3MTI} nat_traversal
[nat_traversal.c:963]: get_register_expire(): maximum expire for all
contacts: 300
-dan
*From: *"miconda(a)gmail.com" <miconda(a)gmail.com>
<miconda(a)gmail.com>
<miconda(a)gmail.com>
*Reply-To: *"miconda(a)gmail.com" <miconda(a)gmail.com>
<miconda(a)gmail.com>
<miconda(a)gmail.com>
*Date: *Friday, April 3, 2020 at 4:03 PM
*To: *Daniel Graham <dan(a)cmsinter.net> <dan(a)cmsinter.net>et>, "Kamailio
(SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
<sr-users(a)lists.kamailio.org>
*Subject: *Re: [SR-Users] nathelper without usrloc
OK, so there were some messages I still missed in the middle of the
discussion...
Can you get all log messages with debug=3 when the keepalive is attempted
to be sent?
Cheers,
Daniel
On 03.04.20 21:51, Daniel W. Graham wrote:
I resolved all of the routing issues. Only issue I’ve got now is
nat_keepalive not working when used with set/add_contact_alias().
-dan
*From: *"miconda(a)gmail.com" <miconda(a)gmail.com>
<miconda(a)gmail.com>
<miconda(a)gmail.com>
*Reply-To: *"miconda(a)gmail.com" <miconda(a)gmail.com>
<miconda(a)gmail.com>
<miconda(a)gmail.com>
*Date: *Friday, April 3, 2020 at 1:43 PM
*To: *Daniel Graham <dan(a)cmsinter.net> <dan(a)cmsinter.net>et>, "Kamailio
(SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
<sr-users(a)lists.kamailio.org>
*Subject: *Re: [SR-Users] nathelper without usrloc
Somehow I thought that the keepalive is not working and you look for
fixing it. Now I read the full thread and actually the routing of requests
within dialog doesn't work.
Can you send a pcap with such a call taken on Kamailio system? ACK and BYE
should be routed based on Contact of INVITE/200ok and record-route headers,
no longer related to REGISTER (only initial INVITE should rely on
registration data).
Cheers,
Daniel
On 02.04.20 22:11, Daniel W. Graham wrote:
Same behavior with add_contact_alias()
-dan
*From: *"miconda(a)gmail.com" <miconda(a)gmail.com>
<miconda(a)gmail.com>
<miconda(a)gmail.com>
*Reply-To: *"miconda(a)gmail.com" <miconda(a)gmail.com>
<miconda(a)gmail.com>
<miconda(a)gmail.com>
*Date: *Thursday, April 2, 2020 at 2:59 PM
*To: *"Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
<sr-users(a)lists.kamailio.org>rg>, Daniel Graham <dan(a)cmsinter.net>
<dan(a)cmsinter.net>
*Subject: *Re: [SR-Users] nathelper without usrloc
Hello,
can you try with add_contact_alias() instead of set_contact_alias()? The
second one updates the contact URI in a way that is visible for the couple
of local modules immediately, typically needed when having dialog/presence
module in that instance (still no changes to the header itself, it uses
some internal mechanism to signal contact value should be taken from a
special field). The first one uses the lumps system that makes the changes
over the contact URI not visible immediately (unless msg_apply_changes() is
used).
Maybe nat_keepalive() needs the original contact URI, not the one updated
by set_contact_alias().
Cheers,
Daniel
On 02.04.20 18:45, Daniel W. Graham wrote:
I was able to fix all issues, but have one partially lingering.
For register only, if I apply: set_contact_alias() with nat_keepalive(),
keepalives are not sent. Removing set_contact_alias() fixes this.
I *shouldn’t need this if the pbx was saving received and rport params as
a result of add_path_received().
Can anyone explain why these two functions conflict?
Test scenario -
# Doesn’t result in register keepalive –
route[NATDETECT] {
force_rport();
set_contact_alias(); # removal of this enables keepalive
nat_keepalive();
return;
}
I’ve tested this with and without calls to handle_ruri_alias() elsewhere
in cfg script with same result.
-dan
*From: *sr-users <sr-users-bounces(a)lists.kamailio.org>
<sr-users-bounces(a)lists.kamailio.org> on behalf of Sergiu Pojoga
<pojogas(a)gmail.com> <pojogas(a)gmail.com>
*Reply-To: *"Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org> <sr-users(a)lists.kamailio.org>
*Date: *Wednesday, April 1, 2020 at 8:58 AM
*To: *"Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
<sr-users(a)lists.kamailio.org>
*Subject: *Re: [SR-Users] nathelper without usrloc
Nothing else comes to mind based on info provided. May be you can send
some sip traffic captures and elaborate?
Regards,
--Sergiu
On Tue, Mar 31, 2020 at 10:29 PM Daniel W. Graham <dan(a)cmsinter.net>
wrote:
Thanks, yeah I had already changed that, but registration works with
either. I’m not asking for a solution, just looking for suggestions on
anything that needs attention, so I appreciate your pointers.
-dan
On Mar 31, 2020, at 8:55 PM, Sergiu Pojoga <pojogas(a)gmail.com> wrote:
Oh and almost forgot - try *add_path_received()* instead of add_path()
Good luck!
On Tue, Mar 31, 2020 at 8:48 PM Sergiu Pojoga <pojogas(a)gmail.com> wrote:
A lot of things may not be 'right' here, unfortunately your question is
too broad to answer and too little info, the topology is indeed non-default
and I doubt someone will present you with a final solution (there's
business support, if you're looking for that).
Otherwise, if I were to just throw a guess:
- try fix_nated_register() (instead of set_contact_alias) just for
Register method on the way to the registrar
- in the Registrar, make sure the Contact's Path address is correct
Cheers,
--Sergiu
On Tue, Mar 31, 2020 at 7:34 PM Daniel W. Graham <dan(a)cmsinter.net> wrote:
It did help, I read that a couple times already but something is still not
right, and its only because of the decoupling of the registrar. I need to
do more debugging and see if Im loosing the flag value. Hoping something
sticks out that someone sees and can point me in the right direction.
-dan
On Mar 31, 2020, at 7:15 PM, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
_______________________________________________
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
_______________________________________________
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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel,
Might this article be of aid?
http://www.evaristesys.com/blog/server-side-nat-traversal-with-kamailio-the…
-- Alex
> On Tue, Mar 31, 2020 at 11:12:23PM +0000, Daniel W. Graham wrote:
>
> It does but doesn't work as well as kamailio, and since the proxy is
the
entry point.
>
> The biggest issue here isnt the keepalive, as I did have that working.
The
main issue is the routing of messages, utilizing set_contact_alias and
handle_ruri_alias, as Ive been unable to get ack and bye messages to make
it past the proxy. I’m assuming these functions are not being used at the
right locations or I need to rely on another mechanism to accomplish it. I
also question my use of the PBX flag and the natmanage logic.
>
> -dan
>
> On Mar 31, 2020, at 7:01 PM, Sergiu Pojoga <pojogas(a)gmail.com> wrote:
>
>
> Hi Daniel,
>
> From what you are describing, my understanding is that the Registrar is
the
PBX, kamailio is acting as an edge proxy. If so, doesn't the
PBX/registrar have NAT traversal/keepalive mechanisms of its own?
>
> Regards,
> --Sergiu
>
> On Tue, Mar 31, 2020 at 1:55 PM Daniel W. Graham <dan(a)cmsinter.net
<mailto:dan@cmsinter.net>> wrote:
> I’ve been missing with this for a while and
seem to be missing
something. Any suggestions on what is missing here?
>
> Trying to use set_contact_alias() and handle_ruri_alias() from
nathelper
module and nat_keepalive from nat_traversal module, without
registrar.
>
> I had register keepalive working, that has since broke. When register
keepalive was working, I was able to place call in either direction but ACK
and BYE was not being routed past kamailio.
>
> Registrations are forwarded to the PBX using add_path() and is working.
>
> Also not included below is the routing to the PBX, that is just setting
$du
and t_relay, and is also working.
>
> Topology is: UA1 -> NAT -> kamailio -> PBX -> UA2
>
> Using default config file as the example, modified with above changes.
I also
removed RTP config as that is a non-issue.
request_route {
……
# FLAG MESSAGES FROM PBX
setflag(FLT_PBX);
route(NATDETECT);
……
route[NATDETECT] {
if (nat_uac_test("19")) {
force_rport();
set_contact_alias();
nat_keepalive();
}
return;
}
route[WITHINDLG] {
if (!has_totag()) return;
if (loose_route()) {
route(DLGURI);
} else if ( is_method("ACK") ) {
route(NATMANAGE);
} else if ( is_method("NOTIFY") ) {
record_route();
}
route(RELAY);
exit;
}
if (is_method("SUBSCRIBE") && uri == myself) {
route(PRESENCE);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
route(RELAY);
exit;
} else {
exit;
}
}
sl_send_reply("404","Not here");
exit;
}
route[NATMANAGE] {
if(isflagset(FLT_PBX)) {
handle_ruri_alias();
}
if(!isflagset(FLT_PBX)) {
set_contact_alias();
} return;
}
route[DLGURI] {
if(!isdsturiset()) {
handle_ruri_alias();
}
return;
}
branch_route[MANAGE_BRANCH] {
route(NATMANAGE);
}
onreply_route[MANAGE_REPLY] {
if(status=~"[12][0-9][0-9]") {
route(NATMANAGE);
}
}
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) exit;
-dan
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org<mailto:sr-users@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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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