Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

I can confirm that I am able to access the server_id attribute in the ulc pvar 
now. 
Thanks for sorting that out too :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-344194823___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

I just want to confirm that those 3 patches applied to v5.0.4 release seem to 
have done the trick. I don't see any rogue keep alive messages being sent now. 
Thank you for looking into this issue Charles, much appreciated.

On the question of exposing the servid_id attribute to the $ulc psuedo 
variable, can we do this as part of this ticket, or shall I create a new issue 
for that?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-343428419___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Charles thanks, I'll apply the patch and come back to you.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-343185320___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Hmm, just seen one happen now.
```
U 2017/11/09 13:25:56.263541 10.6.0.189:5060 -> 10.7.0.186:5062

OPTIONS sip:example_user@78.143.152.30:59947 SIP/2.0.
Via: SIP/2.0/UDP 10.6.0.189:5060;branch=z9hG4bK5844925.
Route: .
From: sip:keepal...@example.com;tag=uloc-1-5a042966-4d55-1-6821c98a-af4da324.
To: sip:example_user@78.143.152.30:59947.
Call-ID: 8ad70ab7-8e92721-ffcfa07@10.6.0.189.
CSeq: 1 OPTIONS.
Content-Length: 0.
.
```

What looks like happened here is that the server_id is set to 1, but the socket 
is not set, so nathelper is getting the default interface from the os and 
sending the ping on the wrong interface.

Here's the aor on registrar_1:
```
{
  "jsonrpc":  "2.0",
  "result": {
"AoR":  "example_u...@example.com",
"Contacts": [{
"Contact":  {
  "Address":  "sip:example_user@78.143.152.30:59947",
  "Expires":  58,
  "Q":  -1,
  "Call-ID":  "1af6284f-59888f215eb1ff0e91850080f0808080@KX-HDV430X",
  "CSeq": 1288,
  "User-Agent": "BF/IE/KX-HDV430X/06.001/BCC3422AAF2C",
  "Received": "sip:78.143.152.30:59947",
  "Path": "",
  "State":  "CS_NEW",
  "Flags":  2,
  "CFlags": 64,
  "Socket": "[not set]",
  "Methods":  8095,
  "Ruid": "uloc-1-5a042966-4d55-1",
  "Instance": "[not set]",
  "Reg-Id": 0,
  "Server-Id":  1,
  "Tcpconn-Id": -1,
  "Keepalive":  1,
  "Last-Keepalive": 1510233939,
  "Last-Modified":  1510233939
}
  }]
  },
  "id": 20508
}
```

This contact is serviced by registrar_2 and it looks like it has its socket set 
to its local interface, but the server_id is still that of registrar_1 so 
registrar_1 is trying to ping it.

here's the aor on registrar_2 (this one "saved" the location, why is it's 
server_id still 1?).
```
{
  "jsonrpc":  "2.0",
  "result": {
"AoR":  "example_u...@example.com",
"Contacts": [{
"Contact":  {
  "Address":  "sip:example_user@78.143.152.30:59947",
  "Expires":  68,
  "Q":  -1,
  "Call-ID":  "1af6284f-59888f215eb1ff0e91850080f0808080@KX-HDV430X",
  "CSeq": 1290,
  "User-Agent": "BF/IE/KX-HDV430X/06.001/BCC3422AAF2C",
  "Received": "sip:78.143.152.30:59947",
  "Path": "",
  "State":  "CS_NEW",
  "Flags":  0,
  "CFlags": 64,
  "Socket": "udp:10.7.0.190:5060",
  "Methods":  8095,
  "Ruid": "uloc-1-5a042966-4d55-1",
  "Instance": "[not set]",
  "Reg-Id": 0,
  "Server-Id":  1,
  "Tcpconn-Id": -1,
  "Keepalive":  1,
  "Last-Keepalive": 1510234052,
  "Last-Modified":  1510234052
}
  }]
  },
  "id": 20758
}
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-343155712___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Sure, here is an example of an aor replicated to registrars_1:
```
{
  "jsonrpc":  "2.0",
  "result": {
"AoR":  "example_u...@example.com",
"Contacts": [{
"Contact":  {
  "Address":  
"sip:example_user@212.2.172.228:43356;rinstance=4dc262b9af47682f;transport=UDP",
  "Expires":  98,
  "Q":  -1,
  "Call-ID":  "4HEiFls2hkky2XR6hL8Nrg..",
  "CSeq": 30,
  "User-Agent": "Z 3.15.40006 rv2.8.20",
  "Received": "sip:212.2.172.228:43356",
  "Path": "",
  "State":  "CS_NEW",
  "Flags":  2,
  "CFlags": 64,
  "Socket": "[not set]",
  "Methods":  -1,
  "Ruid": "uloc-2-5a04296d-4ed0-e1",
  "Instance": "[not set]",
  "Reg-Id": 0,
  "Last-Keepalive": 1510227057,
  "Last-Modified":  1510227057
}
  }]
  },
  "id": 20184
}
```
This aor is being serviced by registrar_2 and I can see the server_id being 
sent in the kdmq message to registrar_1, server_id is clearly set to 2:
```
KDMQ sip:usrloc@10.6.0.189:5060 SIP/2.0.
Via: SIP/2.0/UDP 
10.6.0.190;branch=z9hG4bK5568.b7ee8e11.0.
To: .
From: ;tag=21afb82da9b0dd18e43e09ed8956ffc8-9f49.
CSeq: 10 KDMQ.
Call-ID: 1a806e9948d055d0-20402@10.6.0.190.
Content-Length: 514.
User-Agent: kamailio (Registrar 2).
Max-Forwards: 1.
Content-Type: application/json.
.
{"action":1,"aor":"example_u...@example.com","ruid":"uloc-2-5a04296d-4ed0-e1","c":"sip:example_user@212.2.172.228:43356;rinstance=4dc262b9af47682f;transport=UDP","received":"sip:212.2.172.228:43356","path":"","callid":"4HEiFls2hkky2XR6hL8Nrg..","user_agent":"Z
 3.15.40006 
rv2.8.20","instance":"","expires":1510227474,"cseq":34,"flags":0,"cflags":64,"q":-1,"last_modified":1510227361,"methods":4294967295,"reg_id":0,"server_id":2}
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-343129653___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

hmm, running this for a while longer and I still see some pings on registrars 
that were replicated to, I have the nathelper server_id filtering enabled now 
too. So there is still something amiss:
nathelper parameter
```
modparam("nathelper", "filter_server_id",   1)
```

Ping being sent from registrar that was replicated to:
```
U 2017/11/09 10:16:50.143477 10.6.0.189:5060 -> 10.7.0.186:5062

OPTIONS sip:example_user@78.143.152.30:59947 SIP/2.0.
Via: SIP/2.0/UDP 10.6.0.189:5060;branch=z9hG4bK1016964.
Route: .
From: sip:keepal...@example.com;tag=uloc-1-5a042966-4d55-1-6821c98a-e1450563.
To: sip:example_user@78.143.152.30:59947.
Call-ID: ad921322-9fd17d71-2782516@10.6.0.189.
CSeq: 1 OPTIONS.
Content-Length: 0.
.
```

Could this be down to the srv_id not showing up in the usrloc database?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-343111548___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

No I did not, let me try that quick


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-343107462___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

I've just updated my test registrars with 5.0.4 with the above patch, I've not 
enabled server_id_filetering in nathelper yet. Is there a way I can see if the 
server_id is being replicated with the aor? Will I be able to see it in the 
usrloc database (kamctl ul show)?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-343097779___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: force_socket not being honoured (#1298)

[00Asgaroth00]

Ok, thanks for the clarification, however, if the Path header does exist in the 
userloc record, why does nathelper need to resolve the best interface to use 
based on the received parameter? Should it not need to resolve the interface to 
be used based on the first hop in the Path header as this is where it will be 
sending to directly, it is the next hop that then needs to decide where best to 
route the message?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1298#issuecomment-342741606___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: force_socket not being honoured (#1298)

[00Asgaroth00]

Just thinking about this issue and #1297 a little and I have a question, when 
the registrar modules has "use_path" enabled, as we do here, is nathelper aware 
of this? If it is not, then, I'm guessing it will try to resolve the best 
interface to send over based on the "received" parameter, which, in our case, 
the OS will tell it to use the interface which has the default gateway, 
however, if nathelper is aware that we need to use the Path uri as the next 
hop, then nat helper does not need to decide which interface to use for the 
recieved parameter, it just needs to decide which interface to use for the 
destination in the Path uri. Could this be what is happening here?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1298#issuecomment-342737411___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: Transformation param.value, name: Returning incorrect result (#1305)

[00Asgaroth00]

Thanks for the correct usage explanation, sorry for the noise on the issue 
tracker.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1305#issuecomment-342734241___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] v5.0.4: Transformation param.value, name: Returning incorrect result (#1305)

[00Asgaroth00]

### Description

Given the following Path header:
```
Path: 
```

When logging with the following log line
```
xlog("L_INFO", "received_address: '$(hdr(Path){param.value,received})'");
```

I am seeing the following being logged in the logs:
```
INFO: 

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Thanks Charles, I'll try to build in the morning and get back to you tomorrow 
with some results.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-342568536___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Hi, at the moment we cannot test with the master or 5.1.x branches as they are 
not "released" yet, which is a requirement here unfortunately.

I see that Daniel mentioned in an email on the mailing lists that 5.1.x should 
be release soon (couple weeks time), will this patch make it into that release? 
If it does then I can test against the 5.1.0 release when it is made available.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-342566824___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Hi,

I'm trying to apply this patch against the 5.0.4 source release and I'm getting 
the following errors:

patch -p1 < dmq_usrloc.patch
```
patching file src/modules/dmq_usrloc/usrloc_sync.c
Hunk #1 FAILED at 323.
Hunk #2 succeeded at 412 (offset 37 lines).
Hunk #3 succeeded at 434 (offset 38 lines).
Hunk #4 FAILED at 649.
Hunk #5 FAILED at 686.
Hunk #6 succeeded at 551 (offset -181 lines).
```
I downloaded the commit with ".patch" added to the end url into the above 
mentioned dmq_usrloc.patch file.

I must be missing something here, I just cannot see what it is. Any thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-342507471___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Thanks again, I will recompile with this patch and update this issue with 
testing.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-342422293___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Thanks for the addition, do I need to recompile with this patch and test it 
out, or, are there other elements that need to be updated before I can test?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-342402437___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Hi, yes, server_id filtering is what I was referring to. 

It looks like this is the current way the shared db scheme overcomes all 
registrars from pinging an available aor. I cannot see, from the module docs, 
if there are any other ways to overcome this issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-342161313___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Currently our 3 registrar servers are not configured for fail-over at all. When 
we have a planned/unplanned outage we rely on the proxies dispatcher set to 
route the message to an available registrar. We also shorten the registration 
interval to take into account that the nat pings wont be available for those 
endpoints that don't re-register on an available registrar, although, this 
method isn't completely foolproof. 

Once the "failed" registrar is brought back into service dmq_usrloc replicates 
state back to it when it comes back and we are in service again.

On the other-hand, we do have an ha setup for the proxies involving 
corosync/pacemaker where there are floating addresses assigned to each kamailio 
instance, but for the registrars we don't run the ha setup.

Would it be possible to have dmq_usrloc updated to reflect what is currently 
done in shared-db mode? Shared-db mode currently has some flaws in the 
scenarios identified in previous posts above, but, at least, for this 
particular issue, it should, hopefully, resolve the current issue at hand, 
whereby we have one registrar servicing the nat keep alives for a particular 
endpoint.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-341799026___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

With regards dmq/dmq_usrloc and in-memory replication, doesn't dmq know when a 
node is down/removed from the bus? If it does, then maybe a background thread 
could fire to (e|se)lect one of the remaining nodes to take over from the node 
that is down and manipulate/override aor's of the downed host on the 
(ese)lected registrar. I don't think this would work for shared-db mode though.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-341722924___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: Errors sending ping messages when no default route set on host. (#1297)

[00Asgaroth00]

ahh okay, if you think we can close this one then, sure, we can close it. 
Originally I was not using udp ping's I just tried it out to see if it would 
work in this case.

I am interested in getting the SIP method pings working (OPTIONS/INFO etc), if 
the force_socket ticket is the right place to progress this, then lets close 
this one.

If we can get force_socket to work, then I can test it again by removing the 
default gateway and seeing if kamailio is able to send a keep-alive out.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1297#issuecomment-341705601___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: force_socket not being honoured (#1298)

[00Asgaroth00]

Hi, I just set udp4_raw=0 on all 3 registrars and remove udpping_from_path from 
the settings, but the same behaviour persists.

registrar that processed the request (ping is successfull)
```
U 2017/11/03 13:28:33.770754 10.7.0.190:5060 -> 10.7.0.186:5062

OPTIONS 
sip:example_user@212.2.172.228:39808;rinstance=ee53f90ba8a5d171;transport=UDP 
SIP/2.0.
Via: SIP/2.0/UDP 10.7.0.190:5060;branch=z9hG4bK2645058.
Route: .
From: sip:keepal...@example.com;tag=uloc-2-59fc6eab-1ce0-1-9968b2da-3f810117.
To: 
sip:example_user@212.2.172.228:39808;rinstance=ee53f90ba8a5d171;transport=UDP.
Call-ID: 538b85e1-b0cecc34-ba1f4f1@10.7.0.190.
CSeq: 1 OPTIONS.
Content-Length: 0.
.


U 2017/11/03 13:28:33.810519 10.7.0.186:5062 -> 10.7.0.190:5060

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 10.7.0.190:5060;rport=5060;branch=z9hG4bK2645058.
Record-Route: 
.
Record-Route: 
.
Contact: .
To: 
;tag=134de75f.
From: sip:keepal...@example.com;tag=uloc-2-59fc6eab-1ce0-1-9968b2da-3f810117.
Call-ID: 538b85e1-b0cecc34-ba1f4f1@10.7.0.190.
CSeq: 1 OPTIONS.
Accept: application/sdp, application/sdp.
Accept-Language: en.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, 
SUBSCRIBE.
Supported: replaces, norefersub, extended-refer, timer, outbound, path, 
X-cisco-serviceuri.
User-Agent: Z 3.15.40006 rv2.8.20.
Allow-Events: presence, kpml, talk.
Content-Length: 0.
.
```

1st registrar replicated to (tries to ping, but wrong interface)
```
U 2017/11/03 13:28:49.675297 10.6.0.189:5060 -> 10.7.0.186:5062

OPTIONS 
sip:example_user@212.2.172.228:39808;rinstance=ee53f90ba8a5d171;transport=UDP 
SIP/2.0.
Via: SIP/2.0/UDP 10.6.0.189:5060;branch=z9hG4bK2611596.
Route: .
From: sip:keepal...@example.com;tag=uloc-2-59fc6eab-1ce0-1-9968b2da-d35cdfe1.
To: 
sip:example_user@212.2.172.228:39808;rinstance=ee53f90ba8a5d171;transport=UDP.
Call-ID: dd9e8af5-a56efaa6-913d294@10.6.0.189.
CSeq: 1 OPTIONS.
Content-Length: 0.
.
```

2nd registrar replicated to (tries to ping, but wrong interface)
```
U 2017/11/03 13:27:37.204775 10.6.0.191:5060 -> 10.7.0.186:5062

OPTIONS 
sip:example_user@212.2.172.228:39808;rinstance=ee53f90ba8a5d171;transport=UDP 
SIP/2.0.
Via: SIP/2.0/UDP 10.6.0.191:5060;branch=z9hG4bK4520144.
Route: .
From: sip:keepal...@example.com;tag=uloc-2-59fc6eab-1ce0-1-9968b2da-1052c4a3.
To: 
sip:example_user@212.2.172.228:39808;rinstance=ee53f90ba8a5d171;transport=UDP.
Call-ID: ca2e8ec2-db7eb9a-63a17d6@10.6.0.191.
CSeq: 1 OPTIONS.
Content-Length: 0.
.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1298#issuecomment-341703874___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

Thanks for the info, just a quick question, if the same situation was in place 
when running 3 registrar's in db-only mode, then we can use the server_id and 
filter_server_id so that only 1 registrar will ping the contact. At lease, that 
is what I am interpreting in the module documentation. Is that correct? 

I think that if you don't have the server_id and filter_server_id parameters 
set for nathelper, then all 3 database-only registrars will also ping the 
contact? Is that correct? Or, does nathelper/registrar us the aor "socket" 
parameter to decide if it need to send the ping from the local registrar? What 
i mean is, if the socket is set, and is a local socket, then send the ping, if 
there is not a socket set, or, if there is a socket set and is not local, then 
don't send the keep-alive message.

How does nathelper currently decide if it needs to send a keep-alive message 
from the local registrar?

Currently, I'm lucky that only 1 keep-alive message is actually making it 
through to the endpoint, however, if kamailio used the force_socket parameter 
correclty then all 3 keep-alives would make it through to the endpoint, which, 
I'm guessing, is not desired behaviour, or am I wrong with that assumption?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1299#issuecomment-341700749___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.4: nathelper: Errors sending ping messages when no default route set on host. (#1297)

[00Asgaroth00]

Thanks for the opinion. I originally was not running with "udpping_from_path" 
(it was disabled). Even with it disabled and only using SIP OPTIONS ping method 
the following log was generated:
```
Nov  1 18:58:01 localhost kam_registrar_1[2896]: ERROR:  
[core/udp_server.c:591]: udp_send(): 
raw_iphdr_udp4_send(12,0x7f5be79587e6,4,...,212.2.172.228:39808,1500): Network 
is unreachable(101)
Nov  1 18:58:01 localhost kam_registrar_1[2896]: ERROR: nathelper 
[nathelper.c:2077]: nh_timer(): udp_send failed
```
Lets progress this issue assuming I am not using "udpping_from_path" and only 
using SIP OPTIONS ping method.

I guess what I am asking here is that, if kamailio has a socket defined on the 
local network, and its $du is on the same network, then, nathelper should be 
able to send the message. However, in this case, it cannot. It looks like it is 
trying to work out which interface to send the destination contact (external 
address: 212.2.172.228) to, but, because we are behind a proxy on a private 
lan, then kamailio needs to send via the PATH definition, in this case all 
OPTIONS messages will go out via an address on the local lan. 

In my humble opinion, we should not need to define a default gateway so that 
kamailio can resolve which interface to use (in this case the wrong one 
(10.6.0.x because the default gateway is a 10.6.0.x address), only for 
nathelper/registrar to realize that it needs to use the PATH parameter for 
sending the messages, and only then relay the message.

I'm not sure if I am explaining myself correctly, please let me know if I am 
not being clear in my explanation and I'll try to explain better.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1297#issuecomment-341697328___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] v5.0.4: nathelper: dont ping replicated aor's (#1299)

[00Asgaroth00]

### Description
We have 3 registrar servers storing location information in memory only. The 
registrations are replicated between each other using DMQ/DMQ USRLOC. When one 
of these registrars processes a registration it is saved and then replicated to 
the remaining two nodes.

When nat pinging is enabled then all three of these registrars attempt to send 
options pings to the endpoints. Ideally, only the registrar that serviced the 
registration should be sending the ping out.

I see that there is a core parameter to set the server_id for each server, and 
I also see that nathelper has a "filter_server_id" parameter as well, however, 
this appears to only work in database mode, it does not work with in memory 
mode. Would it be possible to extend this to work for in-memory mode too?

### Troubleshooting
Module definitions

registrar
```
modparam("registrar", "method_filtering",  1)
modparam("registrar", "case_sensitive",1)
modparam("registrar", "append_branches",   0)
modparam("registrar", "use_path",  1)
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local",  1)
modparam("registrar", "max_contacts",  1)
```

usrloc
```
modparam("usrloc", "db_mode",  0)
modparam("usrloc", "use_domain",   1)
modparam("usrloc", "timer_interval",   60)
modparam("usrloc", "timer_procs",  4)
modparam("usrloc", "nat_bflag",6)
```

nathelper
NOTE: force_socket is set to match each registrar server
```
modparam("nathelper", "natping_interval",   20)
modparam("nathelper", "natping_processes",  4)
modparam("nathelper", "ping_nated_only",0)
modparam("nathelper", "sipping_from",   "sip:keepal...@example.com")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "sipping_bflag",  6)
modparam("nathelper", "force_socket",   "10.7.0.189:5060")
modparam("nathelper", "udpping_from_path",   1)
```

Kamailio listen directives:
NOTE: These are set to match the interfaces on each registrar
```
listen=udp:10.6.0.189:5060
listen=udp:10.7.0.189:5060
listen=tcp:10.6.0.189:80
```

dmq
```
modparam("dmq", "server_address", DMQ_ADDRESS)
modparam("dmq", "notification_address", DMQ_NOTIFY_ADDRESS)
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 4)
```

dmq_usrloc
```
modparam("dmq_usrloc", "enable", 1)
```

 Reproduction

Using the settings above, when the location information is replicated to a 
server, the servers that are replicated to should not send options messages for 
that AOR, only the registrar that serviced the registration should send nat 
keepalives out.

 Log Messages

 SIP Traffic

Here is the traffic from the registrar that serviced the registration, this is 
expected and working:
```
U 2017/11/02 07:50:54.191717 10.7.0.190:5060 -> 10.7.0.186:5062

OPTIONS 
sip:example_user@212.2.172.228:39808;rinstance=d74acdb581467154;transport=UDP 
SIP/2.0.
Via: SIP/2.0/UDP 10.7.0.190:5060;branch=z9hG4bK5526436.
Route: .
From: sip:keepal...@example.com;tag=uloc-2-59fa1f9d-711-3-9968b2da-c2c36781.
To: 
sip:example_user@212.2.172.228:39808;rinstance=d74acdb581467154;transport=UDP.
Call-ID: d9993f61-a1fd4752-73cdc76@10.7.0.190.
CSeq: 1 OPTIONS.
Content-Length: 0.
.


U 2017/11/02 07:50:54.192896 194.213.29.33:5062 -> 212.2.172.228:39808

OPTIONS 
sip:example_user@212.2.172.228:39808;rinstance=d74acdb581467154;transport=UDP 
SIP/2.0.
Max-Forwards: 10.
Record-Route: 
.
Record-Route: 
.
Via: SIP/2.0/UDP 
194.213.29.33:5062;branch=z9hG4bK13ab.9ccb0733fcecc331893d95f2e09485ee.0.
Via: SIP/2.0/UDP 10.7.0.190:5060;rport=5060;branch=z9hG4bK5526436.
From: sip:keepal...@example.com;tag=uloc-2-59fa1f9d-711-3-9968b2da-c2c36781.
To: 
sip:example_user@212.2.172.228:39808;rinstance=d74acdb581467154;transport=UDP.
Call-ID: d9993f61-a1fd4752-73cdc76@10.7.0.190.
CSeq: 1 OPTIONS.
Content-Length: 0.
.


U 2017/11/02 07:50:54.248234 212.2.172.228:39808 -> 194.213.29.33:5062

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 
194.213.29.33:5062;branch=z9hG4bK13ab.9ccb0733fcecc331893d95f2e09485ee.0.
Via: SIP/2.0/UDP 10.7.0.190:5060;rport=5060;branch=z9hG4bK5526436.
Record-Route: 
.
Record-Route: 
.
Contact: .
To: 
;tag=726ffa30.
From: sip:keepal...@example.com;tag=uloc-2-59fa1f9d-711-3-9968b2da-c2c36781.
Call-ID: d9993f61-a1fd4752-73cdc76@10.7.0.190.
CSeq: 1 OPTIONS.
Accept: application/sdp, application/sdp.
Accept-Language: en.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, 
SUBSCRIBE.
Supported: replaces, norefersub, 

[sr-dev] [kamailio/kamailio] v5.0.4: nathelper: force_socket not being honoured (#1298)

[00Asgaroth00]

### Description

The force_socket parameter is not always used when set. If I understand the 
module documentation correctly, when setting the force_socket parameter, then 
all nathelper udp traffic will be forced to use this socket definition.

The issue here is a result of another issue first described 
[here](http://sip-router.1086192.n5.nabble.com/NatHelper-ignoring-force-socket-module-parameter-tp139883p162791.html)
 in 2015 but is still present in current stable kamailio v5.0.4. 

We have 3 registrars running in "memory only" mode, using dmq_usrloc to 
replicate registrations to the remaining two nodes. On the remaining two nodes 
there is no socket parameter set for the AOR, but nathelper still wants to ping 
these AOR's. It is on these two systems where this issue exhibits itself. I 
will open another ticket for this scenario and try to reference it here as they 
are related.

Each registrar has two interfaces, one is our "admin" lan, the other is our 
"voice" lan. The default route is set on these hosts and is a gateway on our 
"admin" lan. See issue #1297 

When the registrars that are replicated to receive the AOR, they attempt to 
ping the endpoint (ideally they should not ping them). nathelper seems to think 
that the best interface to send them over is the "admin" lan even though 
force_socket is defined.

I would have expected that the message should have been sent via the socket 
defined in the "force_socket" parameter.

### Troubleshooting
Module definitions

registrar
```
modparam("registrar", "method_filtering",  1)
modparam("registrar", "case_sensitive",1)
modparam("registrar", "append_branches",   0)
modparam("registrar", "use_path",  1)
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local",  1)
modparam("registrar", "max_contacts",  1)
```

usrloc
```
modparam("usrloc", "db_mode",  0)
modparam("usrloc", "use_domain",   1)
modparam("usrloc", "timer_interval",   60)
modparam("usrloc", "timer_procs",  4)
modparam("usrloc", "nat_bflag",6)
```

nathelper
```
modparam("nathelper", "natping_interval",   20)
modparam("nathelper", "natping_processes",  4)
modparam("nathelper", "ping_nated_only",0)
modparam("nathelper", "sipping_from",   "sip:keepal...@example.com")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "sipping_bflag",  6)
modparam("nathelper", "force_socket",   "10.7.0.189:5060")
modparam("nathelper", "udpping_from_path",   1)
```

Kamailio is listening on the same socket that is defined for the "force_socket" 
parameter above
```
listen=udp:10.6.0.189:5060
listen=udp:10.7.0.189:5060
listen=tcp:10.6.0.189:80
```

dmq
```
modparam("dmq", "server_address", DMQ_ADDRESS)
modparam("dmq", "notification_address", DMQ_NOTIFY_ADDRESS)
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 4)
```

dmq_usrloc
```
modparam("dmq_usrloc", "enable", 1)
```
 Reproduction

Using the above settings register a user and once they are replicated to the 
registrar that did not service the request, the options pings on the nodes that 
were replicated to will exhibit this issue.

Example AOR where the registration was serviced (options pings should come from 
this host, and do, and flow as expected)
```
{
  "jsonrpc":  "2.0",
  "result": {
"Domain": "location",
"Size": 1024,
"AoRs": [{
"Info": {
  "AoR":  "example_u...@example.com",
  "HashID": -1389656423,
  "Contacts": [{
  "Contact":  {
"Address":  
"sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP",
"Expires":  66,
"Q":  -1,
"Call-ID":  "wE-GD4GzkrtuDAJUBJf1Jg..",
"CSeq": 58,
"User-Agent": "Z 3.15.40006 rv2.8.20",
"Received": "sip:212.2.172.228:39808",
"Path": 
"",
"State":  "CS_NEW",
"Flags":  0,
"CFlags": 64,
"Socket": "udp:10.7.0.190:5060",
"Methods":  -1,
"Ruid": "uloc-2-59fa1f9d-714-17",
"Instance": "[not set]",
"Reg-Id": 0,
"Last-Keepalive": 1509615136,
"Last-Modified":  1509615136
  }
}]
}
  }
  ],
"Stats":  {
  "Records":  1,
  "Max-Slots":  1
}
  },
  "id": 4836
}
```

example AOR of the above registration on a registrar that was replicated to by 
dmq/dmq_usrloc, ideally these AOR's should not be pinged at all, but, currently 
they do, but, in this case, when they do get ping'd, they do not use the socket 
as defined in the "force_socket" parameter.
```
{
  "jsonrpc":  "2.0",
  "result": {
"Domain": "location",
"Size": 1024,
"AoRs": [{
"Info": {
  

[sr-dev] [kamailio/kamailio] v5.0.4: nathelper: Errors sending ping messages when no default route set on host. (#1297)

[00Asgaroth00]

### Description

When the nathelper module attempts to send OPTIONS ping messages on a host that 
has no default route set, the module errors out with one of two error messages.

```
Nov  1 18:58:01 localhost kam_registrar_1[2896]: ERROR:  
[core/udp_server.c:591]: udp_send(): 
raw_iphdr_udp4_send(12,0x7f5be79587e6,4,...,212.2.172.228:39808,1500): Network 
is unreachable(101)
Nov  1 18:58:01 localhost kam_registrar_1[2896]: ERROR: nathelper 
[nathelper.c:2077]: nh_timer(): udp_send failed
```
or, when I enable udpping_from_path the error message is as follows

```
Nov  1 18:57:29 localhost kam_registrar_1[2793]: ERROR: nathelper 
[nathelper.c:2073]: nh_timer(): send_raw from path failed
Nov  1 18:57:49 localhost kam_registrar_1[2793]: ERROR: nathelper 
[nathelper.c:2073]: nh_timer(): send_raw from path failed
```

I am sending nat pings from a registrar behind a proxy. The registrar is on an 
internal network, the proxy has an interface on the internal network too. 

I am storing the path information in location so that it can be used for the 
nat pings. The path information has the local internal address and port of the 
proxy to send the keepalive message via.

I have the "force_socket" parameter option set, which, I assume, is the socket 
to be used for all nat ping messages. This does not work as expected, I will 
open a seperate issue for this particular case.

I would have expected that the messages should be able to send to the proxy 
weather I have a default route set or not. NOTE: The default route, in this 
instance, is not on the same network that the sip traffic is flowing on.

I guess my expectation here is that if the destination to be sent to is on the 
same network as a socket that kamilio is listening on, then we should be able 
to send. In this case, the path is going to contain where to send to, but the 
actual contact of the aor is totally external.

### Troubleshooting

Module settings are as follows:
registrar
```
modparam("registrar", "method_filtering",  1)
modparam("registrar", "case_sensitive",1)
modparam("registrar", "append_branches",   0)
modparam("registrar", "use_path",  1)
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local",  1)
modparam("registrar", "max_contacts",  1)
```
usrloc
```
modparam("usrloc", "db_mode",  0)
modparam("usrloc", "use_domain",   1)
modparam("usrloc", "timer_interval",   60)
modparam("usrloc", "timer_procs",  4)
modparam("usrloc", "nat_bflag",6)
```

nathelper
```
modparam("nathelper", "natping_interval",   20)
modparam("nathelper", "natping_processes",  4)
modparam("nathelper", "ping_nated_only",0)
modparam("nathelper", "sipping_from",   "sip:keepal...@example.com")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "sipping_bflag",  6)
modparam("nathelper", "force_socket",   "10.7.0.190:5060")
modparam("nathelper", "udpping_from_path",   1)
```

Nathelper force_socket is set to a socket that kamailio is listening on:
```
listen=udp:10.7.0.190:5060
```

An example registered user we are trying to ping:
kamctl ul show
```
{
  "jsonrpc":  "2.0",
  "result": {
"Domain": "location",
"Size": 1024,
"AoRs": [{
"Info": {
  "AoR":  "example_u...@example.com",
  "HashID": -1389656423,
  "Contacts": [{
  "Contact":  {
"Address":  
"sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP",
"Expires":  66,
"Q":  -1,
"Call-ID":  "wE-GD4GzkrtuDAJUBJf1Jg..",
"CSeq": 58,
"User-Agent": "Z 3.15.40006 rv2.8.20",
"Received": "sip:212.2.172.228:39808",
"Path": 
"",
"State":  "CS_NEW",
"Flags":  0,
"CFlags": 64,
"Socket": "udp:10.7.0.190:5060",
"Methods":  -1,
"Ruid": "uloc-2-59fa1f9d-714-17",
"Instance": "[not set]",
"Reg-Id": 0,
"Last-Keepalive": 1509615136,
"Last-Modified":  1509615136
  }
}]
}
  }
  ],
"Stats":  {
  "Records":  1,
  "Max-Slots":  1
}
  },
  "id": 4836
}
```
 Reproduction

With the above settings, when I do *not* have a default route set for the host 
then I encounter the following error in the logs when attempting to ping:

```
Nov  1 18:57:29 localhost kam_registrar_1[2793]: ERROR: nathelper 
[nathelper.c:2073]: nh_timer(): send_raw from path failed
Nov  1 18:57:49 localhost kam_registrar_1[2793]: ERROR: nathelper 
[nathelper.c:2073]: nh_timer(): send_raw from path failed
```

If I comment out the "udpping_from_path" module parameter and restart kamailio, 
again, with *no* default route set, I get the 

[sr-dev] [kamailio/kamailio] v5.0.3: "kamdbctl create" fails to grant permissions on drouting sequences. (#1256)

[00Asgaroth00]

When attempting to create the extra modules tables using "kamdbctl create" 
using the PGSQL DBENGINE the create fails when kamdbctl tries to set the 
permissions on the sequences that are to be created with the table.

Example output (dr_gateways):
```
# kamdbctl create
INFO: creating database kamailio_alexia ...
INFO: Core Kamailio tables succesfully created.
INFO: creating presence tables into kamailio_alexia ...
INFO: Presence tables succesfully created.
INFO: creating extra tables into kamailio_alexia ...
ERROR:  relation "dr_gateways_id_seq" does not exist
ERROR:  relation "dr_gateways_id_seq" does not exist
ERROR: Grant privileges to extra tables failed!
```

Example output (dr_rules)
```
# kamdbctl create  
INFO: creating database kamailio_alexia ...
INFO: Core Kamailio tables succesfully created.
INFO: creating presence tables into kamailio_alexia ...
INFO: Presence tables succesfully created.
INFO: creating extra tables into kamailio_alexia ...
ERROR:  relation "dr_rules_id_seq" does not exist
ERROR:  relation "dr_rules_id_seq" does not exist
ERROR: Grant privileges to extra tables failed!
```

This appears to be related to to primary key being being different in these two 
tables compared to what kamdbctl expects.

drouting-create.sql
```
# cat drouting-create.sql 
CREATE TABLE dr_gateways (
gwid SERIAL PRIMARY KEY NOT NULL,
type INTEGER DEFAULT 0 NOT NULL,
address VARCHAR(128) NOT NULL,
strip INTEGER DEFAULT 0 NOT NULL,
pri_prefix VARCHAR(64) DEFAULT NULL,
attrs VARCHAR(255) DEFAULT NULL,
description VARCHAR(128) DEFAULT '' NOT NULL
);

INSERT INTO version (table_name, table_version) values ('dr_gateways','3');

CREATE TABLE dr_rules (
ruleid SERIAL PRIMARY KEY NOT NULL,
groupid VARCHAR(255) NOT NULL,
prefix VARCHAR(64) NOT NULL,
timerec VARCHAR(255) NOT NULL,
priority INTEGER DEFAULT 0 NOT NULL,
routeid VARCHAR(64) NOT NULL,
gwlist VARCHAR(255) NOT NULL,
description VARCHAR(128) DEFAULT '' NOT NULL
);

INSERT INTO version (table_name, table_version) values ('dr_rules','3');

CREATE TABLE dr_gw_lists (
id SERIAL PRIMARY KEY NOT NULL,
gwlist VARCHAR(255) NOT NULL,
description VARCHAR(128) DEFAULT '' NOT NULL
);

INSERT INTO version (table_name, table_version) values ('dr_gw_lists','1');

CREATE TABLE dr_groups (
id SERIAL PRIMARY KEY NOT NULL,
username VARCHAR(64) NOT NULL,
domain VARCHAR(128) DEFAULT '' NOT NULL,
groupid INTEGER DEFAULT 0 NOT NULL,
description VARCHAR(128) DEFAULT '' NOT NULL
);

INSERT INTO version (table_name, table_version) values ('dr_groups','2');
```

Then in kamdbctl.pgsql we see the following section for granting permissions 
and this is where it appears to fail:

kamdbctl.pgsql
```
241 for TABLE in $EXTRA_TABLES; do
242 sql_query "$1" "GRANT ALL PRIVILEGES ON TABLE $TABLE TO 
$DBRWUSER;"
243 sql_query "$1" "GRANT SELECT ON TABLE $TABLE TO $DBROUSER;"
244 if [ $TABLE != "route_tree" ] ; then
245 sql_query "$1" "GRANT ALL PRIVILEGES ON TABLE 
"$TABLE"_id_seq TO $DBRWUSER;"
246 sql_query "$1" "GRANT SELECT ON TABLE "$TABLE"_id_seq TO 
$DBROUSER;"
247 fi
248 if [ $? -ne 0 ] ; then
249 merr "Grant privileges to extra tables failed!"
250 exit 1
251 fi
252 done
```

Here it clearly expects the primary key of each table to be called "id", and 
thus the associated sequences created will be ${TABLE}_id_seq, however in this 
case these fail as the primary keys for these two tables are named differently.

If I modify the primary keys for the dr_gateways and dr_rules tables to be 
"id", then kamdbctl is able to complete creating the tables.

Looking at the drouting module documentation it appears that the module expects 
these primary keys to be called "gwid" and "ruleid".

Can someone take a look please.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1256___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.3: "kamctl domain show" not showing all domains (#1251)

[00Asgaroth00]

Hi, I can confirm that the output of domain show now works as expected with 
your patch. Thank you for taking a look at the issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1251#issuecomment-333093196___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] v5.0.3: "kamctl domain show" not showing all domains (#1251)

[00Asgaroth00]

okay, thanks, i will report back once i have it built and tested.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1251#issuecomment-333085395___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] v5.0.3: "kamctl domain show" not showing all domains (#1251)

[00Asgaroth00]

### Description

Using the DBTEXT database engine I add a couple domains to the table, issue a 
reload and the attempt to list the domains loaded. The output of the listing 
only shows the 1st entry in the domain table, however, testing with a sip 
client, I can confirm that all domains are actually loaded, it appears that the 
listing of the domains is what is at fault here.

domain data:
```
# cat domain
id(int,auto) domain(string) did(string,null) last_modified(int)
1:testing.one.two:1:1506437399
2:testing.one.three:2:1506437399
3:testing.two.one:3:1506437399
4:testing.two.two:3:1506437399
```

domain showdb
```
# kamctl domain showdb
[1, 'testing.one.two', '1', 1506437399]
[2, 'testing.one.three', '2', 1506437399]
[3, 'testing.two.one', '3', 1506437399]
[4, 'testing.two.two', '3', 1506437399]
```

domain show
```
# kamctl domain show  
{
  "jsonrpc":  "2.0",
  "result": {
"domain": "testing.one.two",
"did":  "1"
  },
  "id": 32341
}
```

If I add some domain attribues the output is different again, data is the same 
above with the addition of some domain attrs.

domain_attrs:
```
# cat domain_attrs
id(int,auto) did(string) name(string) type(int) value(string) last_modified(int)
1:1:test_name:2:test_value:1506535015
```

domain show:
```
# kamctl domain show
{
  "jsonrpc":  "2.0",
  "result": {
"did":  "1",
"attr": "test_name"
  },
  "id": 32468
}
```

I'm using the following version of kamailio, compiled from the kamailio v5.0.3 
src code.

kamailio version:
```
# kamailio -V
version: kamailio 5.0.3 (x86_64/linux) 
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, 
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, 
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown 
compiled on 17:43:41 Sep 15 2017 with gcc 4.8.5
```

Running onCentOS 7:
```
# uname -a
Linux klb01.home.ie 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux
```

Any thoughts?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1251___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev