[sr-dev] Re: [kamailio/kamailio] Warnings emitted when calling functions from dialplan module (Issue #3851)

[Joel Serrano via sr-dev]

I was able to "get around" that warning by changing the memory manager. 

Not sure if this is the correct solution/workaround, but having the constant 
warnings in the logs seems wrong. 

I added `-x fm -X fm` to the kamailio run command. 

Any downside to this change?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3851#issuecomment-2120550940
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] Add support for Linux kernel anyIP feature (Issue #3394)

[Joel Serrano]

AFAIR, depending on the number of `children` or `socket_workers` combined with 
the amount `listen=` and the `PKG_SIZE` setting, RAM would be the limitation.

In an example where you have say 16mb of `PKG_SIZE ` combined with `children=1` 
you would need (16mb * 1 children * 65535 IPs) 1TB of RAM for a /16. 





-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3394#issuecomment-1475181249
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] Add support for Linux kernel anyIP feature (Issue #3394)

[Joel Serrano]

Is there any limitation that stops you from using multiple `listen=` directives?

In fact, given enough resources, is there even a limit on the number of 
`listen=` directives that Kamailio can handle?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3394#issuecomment-1474588295
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

Re: [sr-dev] [kamailio/kamailio] segfault at f8 ip 00007fd49cf02f72 sp 00007ffea6e37e70 error 4 in dmq_usrloc.so[7fd49cef0000+17000] (Issue #3242)

[Joel Serrano]

Hi @miconda, I wanted to confirm I haven't seen any more cores since applying 
the fix!

Thank you for looking into this.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3242#issuecomment-1265720910
You are receiving this because you are subscribed to this thread.

Message ID: ___
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] segfault at f8 ip 00007fd49cf02f72 sp 00007ffea6e37e70 error 4 in dmq_usrloc.so[7fd49cef0000+17000] (Issue #3242)

[Joel Serrano]

Hi Daniel, 

I have one of the three nodes with `v5.7.0~dev1+bpo10.20220920005412.2299` 
(installed today from `kamailiodev-nightly` repo) and I haven't seen any more 
crashes so far.

I will observe the node tomorrow and let you know how it goes.

Once confirmed OK, would it be possible to backport the fix to 5.6 branch? 
Thanks!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3242#issuecomment-1251840331
You are receiving this because you are subscribed to this thread.

Message ID: ___
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] segfault at f8 ip 00007fd49cf02f72 sp 00007ffea6e37e70 error 4 in dmq_usrloc.so[7fd49cef0000+17000] (Issue #3242)

[Joel Serrano]

Hi Daniel, 

here is the output:

```
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kamailio...
Reading symbols from 
/usr/lib/debug/.build-id/56/b8c9f5a3c31e6a1813f0c59adb02c922c60137.debug...

warning: Can't open file /dev/zero (deleted) during file-backed mapping note 
processing
[New LWP 53605]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f 
/etc/kamailio/csbc.cfg -m 5'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fd49cf02f72 in usrloc_dmq_send_multi_contact (ptr=0x7fd49d8f6ea0, 
aor=..., action=1, node=0x7fd49d84f5f8) at usrloc_sync.c:685
685 usrloc_sync.c: No such file or directory.
(gdb) frame 0
#0  0x7fd49cf02f72 in usrloc_dmq_send_multi_contact (ptr=0x7fd49d8f6ea0, 
aor=..., action=1, node=0x7fd49d84f5f8) at usrloc_sync.c:685
685 in usrloc_sync.c
(gdb) p *ptr
$1 = {domain = 0x7fd49d5b32d8, ruid = {s = 0x7fd49d8f7240 
"uloc-3-6326536b-abf4-663", len = 24}, aor = 0x7fd49d8e86b8, c = {s = 
0x7fd49d8f7000 "sip:1070500@192.168.1.201;transport=UDP;user=phone", len = 50},
  received = {s = 0x7fd49d8f71c0 "sip:45.225.71.102:5060", len = 22}, path = {s 
= 0x0, len = 0}, expires = 1663464479, q = -1, callid = {s = 0x7fd49d8f70a0 
"45776c982344d3e367a0325e7fafb494@192.168.1.201",
len = 46}, cseq = 2146305210, state = CS_SYNC, flags = 0, cflags = 12, 
user_agent = {s = 0x7fd49d8f7138 "OXO032/043.001 GW_032/043.001", len = 29}, 
uniq = {s = 0x0, len = 0}, sock = 0x0,
  last_modified = 1663460879, last_keepalive = 1663462640, ka_roundtrip = 0, 
methods = 7823, instance = {s = 0x0, len = 0}, reg_id = 0, server_id = 3, 
tcpconn_id = -1, keepalive = 1, xavp = 0x0,
  next = 0x7fd49d96d2c0, prev = 0x0}
(gdb) p ptr->sock
$2 = (struct socket_info *) 0x0
(gdb) p *ptr->sock
Cannot access memory at address 0x0
(gdb)
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3242#issuecomment-1250375760
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] segfault at f8 ip 00007fd49cf02f72 sp 00007ffea6e37e70 error 4 in dmq_usrloc.so[7fd49cef0000+17000] (Issue #3242)

[Joel Serrano]

### Description

We have a cluster of two Kamailio nodes on Debian 10 + v5.5.2.

We have added a node and updated to v5.6.1. So now it's a cluster of:

2x debian10 + v5.6.1
1x debian11 + v5.6.1

### Troubleshooting

I'm not sure what is the issue but per `dmesg` logs it seems related to 
`dmq_usrloc` module. We have a lot of cores, so it's happening constantly since 
the upgrade and the extra node addition.

 Debugging Data


[core.kamailio.53605.1663462643.txt](https://github.com/kamailio/kamailio/files/9592884/core.kamailio.53605.1663462643.txt)


 Log Messages



```
[155017.987497] kamailio[53605]: segfault at f8 ip 7fd49cf02f72 sp 
7ffea6e37e70 error 4 in dmq_usrloc.so[7fd49cef+17000]
[155017.987527] Code: 40 38 01 d0 89 05 12 95 00 00 48 8b 05 cf 8f 00 00 8b 00 
83 f8 01 0f 85 80 00 00 00 48 8b 85 48 ff ff ff 48 8b 80 a0 00 00 00 <8b> 90 f8 
00 00 00 48 8b 85 48 ff ff ff 48 8b 80 a0 00 00 00 48 8b
```

 SIP Traffic



```
(paste your sip traffic here)
```

### Possible Solutions



### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.6.1 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, 
USE_MCAST, DNS_IP_HACK, 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_BLOCKLIST, HAVE_RESOLV_RES, 
TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, 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 with gcc 10.2.1
```

* **Operating System**:



```
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye

Linux sip03.example.com 5.18.0-0.deb11.4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
5.18.16-1~bpo11+1 (2022-08-12) x86_64 GNU/Linux
```


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3242
You are receiving this because you are subscribed to this thread.

Message ID: ___
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] [Feature Request] Add reload capability for geoip2 module (#2029)

[Joel Serrano]

Hello, 

It's been a while so I thought I'd re-ask to see if this is something that can 
be implemented?

Thanks!

-- 
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/2029#issuecomment-934618213___
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] [FEATURE REQUEST] Add reload functionality for the configured database (path) in GeoIP2 module (#2870)

[Joel Serrano]

Closed #2870.

-- 
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/2870#event-5412341062___
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] [FEATURE REQUEST] Add reload functionality for the configured database (path) in GeoIP2 module (#2870)

[Joel Serrano]

Closing as duplicate of another feature request I opened myself back in 2019: 
https://github.com/kamailio/kamailio/issues/2029

My bad, I totally forgot I had already opened a ticket for this!

-- 
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/2870#issuecomment-934617345___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] [FEATURE REQUEST] Add reload functionality for the configured database (path) in GeoIP2 module (#2870)

[Joel Serrano]

### Description

Currently there is no way to tell Kamailio to reload the GeoIP database that is 
configured without a restart. This feature request is for adding the 
possibility to hot-reload the GeoIP2 database.

### Possible Solutions

Implement a RPC command to reload the database, similar to the way the TLS 
module implements `tls.reload` to reload the configured certificates without 
needing a restart.

### Example

`kamcmd geoip2.reload` / `kamctl rpc geoip2.reload`

-- 
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/2870___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Parsing a number using `phonenum_match_cn()` doesn't restrict the rules with the country name code (#2495)

[Joel Serrano]

### Description

Parsing a number using `phonenum_match_cn()` doesn't honor the country code 
filter.

 Reproduction

I have the following in code:

```
if (phonenum_match_cn("$fU", "PA", "src")) {
if($phn(src=>valid)==1) {
xlog("L_NOTICE", "Caller is type: (V=$phn(src=>valid) | 
N=$phn(src=>number) | NN=$phn(src=>normalized) | CC=$phn(src=>cctel) | 
ISO=$phn(src=>ccname) | T=$phn(src=>ltype) | D=$phn(src=>ndesc))\n");
return;
}
}
```

Using `+15162085XXX` as an example, I'm getting the following when passing that 
snippet of code:

```
Oct  1 19:31:11 sbc01 sbc[17850]: NOTICE: {1 102 INVITE 
05d2e55e06832c71060e69b630cd5c6d@A.B.C.D} 

[sr-dev] [kamailio/kamailio] [FEATURE REQUEST] - Add RTT metric to usrloc for measuring subscriber latency (#2223)

[Joel Serrano]

## Description

### Add RTT metric to usrloc for measuring subscriber latency

This has been discussed several times in the mailing list. As I personally need 
this too I though it would be a good idea to open this issue for tracking. 
Unfortunately I'm not aware of the complexity of implementing this and I cannot 
code it myself, I'm happy to do any testing though or help with any other tasks.
 
Some threads were this has been commented and some solutions proposed by 
@miconda:

https://lists.kamailio.org/pipermail/sr-users/2015-April/088031.html (1st post, 
see complete thread)
https://lists.kamailio.org/pipermail/sr-users/2019-January/104291.html (1st 
post, see complete thread)

Thanks!

-- 
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/2223___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Avoid full table scan for dispatcher table using db_redis using ds_reload() from config script In (#2149)

[Joel Serrano]

# Description

Trying to avoid getting this warning:

Nov 22 20:36:35 test COPS[25531]: WARNING: db_redis [redis_dbase.c:1098]: 
db_redis_perform_query(): performing full table scan on table 'dispatcher' 
while performing query

### Troubleshooting

Having: 
```
modparam("db_redis", "keys", "version=entry:table_name")
modparam("db_redis", "keys", "dispatcher=entry:id")
```

And debug logs showing the key being found:

```

 Reproduction


zz
 Debugging Data



```
(paste your debugging data here)
```

 Log Messages



```
(paste your log messages here)
```

 SIP Traffic



```
(paste your sip traffic here)
```

### Possible Solutions



### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
(paste your output here)
```

* **Operating System**:



```
(paste your output 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/2149___
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] listen advertise using ACL (#2131)

[Joel Serrano]

Nice idea, as a workaround what I'm doing for the same problem is using 
different ports for different "types of sources" (vpn/internet/private/etc.)

Not the best solution, but at least you can have different advertise settings.

I'm subscribing to this feature request!

-- 
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/2131#issuecomment-554562561___
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] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

[Joel Serrano]

Hi @miconda thanks for clarifying, now I know for next time :)

I just tested and now it works as expected:

```
"message":" NOTICE: {1 20 INVITE lR5kTpx06q} 

Re: [sr-dev] [kamailio/kamailio] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

[Joel Serrano]

Hi @miconda / @henningw , not sure if you get notifications when tickets are in 
closed state, please confirm, if not I'll open a new issue to check this.

The `$tcp(c_si)` and `$tcp(c_sp)` are not working as expected, see my previous 
comment for details.

-- 
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/2103#issuecomment-548131406___
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] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

[Joel Serrano]

Hi @miconda, 

I believe something might not be working as expected...

I have added the following:

```
...
loadmodule "tcpops.so"
...
tcp_accept_haproxy=yes
...
xlog("L_NOTICE", "New request - M=$rm UAC-IP=$si:$sp 
LB-IP=$tcp(c_si):$tcp(c_sp) UA='$ua' ID=$ci\n");
...
```

And this is what I see:
```
message":" NOTICE: {1 21 INVITE zgtu-ae~qO} 

Re: [sr-dev] [kamailio/kamailio] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

[Joel Serrano]

I'm building from master as we speak to test, as the ticket is now closed, I'll 
only reopen if anything doesn't work.

Thanks Daniel for implementing this! ;) 👍 

-- 
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/2103#issuecomment-547047810___
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] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

[Joel Serrano]

Correct! The idea is to have a way to keep the LB "in the path", you got it!

Thanks @henningw, let me know if you need any other info, clarification, tests, 
or whatever :)

-- 
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/2103#issuecomment-543830889___
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] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

[Joel Serrano]

Hi @henningw, 

AFAIK: As we are talking about TCP + Proxy Protocol here, this means that most 
likely the LB between Kam and the UAC only understands connections (pure TCP 
proxy). Although I have access to the UAC's IP:Port (which is the goal of 
tcp_accept_haproxy=yes, and this shouldn't change), if I have to send a msg to 
the UAC and I don't want to go directly (Kam->UAC) but I want to go via the LB 
where the request came from (KAM->LB->UAC) I need to send the msg to the 
IP:Port KAM received, and the LB will send that to the IP:Port it received. 

For certain scenarios just using `force_rport()` works, but not for all.

Following previous example of:

UAC (1.1.1.1:45621) -> (2.2.2.2:5060) LB with Proxy Protocol (3.3.3.3:57482) -> 
(4.4.4.4:5060) Kamailio.

```
UAC: REGISTER ->
KAM: <- 200OK
```

Now I want to send an INVITE from Kam to UAC, for correct flow I would need to 
send it from Kam to LB:

`4.4.4.4:5060 -> 3.3.3.3:57482`

And LB would make the translation and send it to UAC:

`2.2.2.2:5060 -> 1.1.1.1:45621`

To be able to do this, I need a way to know that the connection came from 
`3.3.3.3:57482`.  Does this make sense so far or am I fundamentally wrong? 


RE: var naming --> I agree that $Ci and $Cp are more appropriate, I would also 
go with those. Thanks for suggestion!

RE: $Ri and $Rp --> I didn't _try_ these because according to docs they provide 
received _interface_ IP/Port, not received _source_ IP/Port.

Let me know what you think about this.

Thanks again!
Joel.

-- 
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/2103#issuecomment-543764153___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

[Joel Serrano]

### Description

When using Kamailio with `tcp_accept_haproxy=yes`, the `$si` and `$sp` 
variables have the 
 real IP & Port information from the original connection to the LB leaving no 
way to access the connection IP & Port from where the packet is received from 
Kamailio perspective.

### Possible Solutions

Create two new pseudovariables that contain the connection IP & Port where the 
packet was received for use cases where `tcp_accept_haproxy=yes`.

Suggested names (but could be any): $CI and $CP meaning -> Connection IP and 
Connection Port.

### Example

With `tcp_accept_haproxy=yes`:

UAC (1.1.1.1:45621) -> (2.2.2.2:5060) LB **with** Proxy Protocol 
(3.3.3.3:57482) -> (4.4.4.4:5060) Kamailio.

```
$si = 1.1.1.1
$sp = 45621
$CI = 3.3.3.3
$CP = 57482
```

With `tcp_accept_haproxy=no`:

UAC (1.1.1.1:45621) -> (2.2.2.2:5060) LB **without** Proxy Protocol 
(3.3.3.3:57482) -> (4.4.4.4:5060) Kamailio.

```
$si = 3.3.3.3
$sp = 57482
$CI = 3.3.3.3
$CP = 57482
```


I don't think there is any way to get the `3.3.3.3:57482` IP and Port from the 
example above when using `tcp_accept_haproxy=yes` but I could be wrong.

Thanks!
Joel.



-- 
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/2103___
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] dialog: failover database loading behaviour in shared DB scenario, expiration of dialogs (#2080)

[Joel Serrano]

Maybe this is irrelevant, but I'd like to add another scenario (not sure if you 
have contemplated this one @henningw): replicating dialogs exclusively via DMQ 
(with no database at all).

* Proxy1 creates a dialog (let's call it **dialogA**) and replicates it via DMQ 
to Proxy2.
* Proxy1 is restarted/crashes/something.
* Proxy1 comes back up before **dialogA** has expired.
* Proxy1 receives all dialogs from Proxy2 via DMQ (including **dialogA**).

What would happen when expiration for the **dialogA** is due?

1- Would Proxy1 send the BYE and then "tell" via DMQ to Proxy2 to remove it 
from its memory?  
2- What if Proxy1 never came back up in time, would Proxy2 know that **it** 
should take care of sending out a BYE for that expired dialog? 
3- Would both Proxy1 and Proxy2 send a BYE and then tell the other proxy via 
DMQ to remove it? (this would be a race-condition I believe, and one would end 
up logging a *non-existent dialog* on syslog?)

I know the subject of this issue clearly talks about scenarios **with** a 
database, so if you believe this database-less scenario shouldn't be discussed 
here let me know and I can create a new 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/2080#issuecomment-537294709___
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] $Au incorrectly contains domain or realm (#2056)

[Joel Serrano]

@miconda: RE description: I set it while thinking on the discrepancy between 
docs and code but typed the behavior instead haha my bad, I updated it to be 
more specific, you are correct that it didn't really match the real issue. 

Using `$(Au{s.select,0,@})` works for me, I probably should have thought of it 
myself, thanks for the suggestion 👍 




-- 
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/2056#issuecomment-528592199___
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] $Au incorrectly contains domain or realm (#2056)

[Joel Serrano]

Sounds good! I hope it can make it to 5.3 :)




-- 
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/2056#issuecomment-528544772___
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] $Au incorrectly contains domain or realm (#2056)

[Joel Serrano]

Great news! I'll locally build new packages from master and test. 

I'll report back my results, thank you Henning!

-- 
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/2056#issuecomment-528495220___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] $Au incorrectly contains domain or realm (#2056)

[Joel Serrano]

### Description

Testing on latest master deb nightly build 
(`5.3.0~dev7+0~20190904005559.1479+buster`) I've noticed that `$Au` is not 
being set correctly, at least according to my tests.

>From the documentation 
>(https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#au_-_acc_username):
> 

_$Au - Acc username: username for accounting purposes. It's a selective pseudo 
variable (inherited from acc module). It returns auth username ($au) if exists 
or From username ($fU) otherwise._

I have the following log statement in several places in a test box:

xlog("L_NOTICE", "[DEBUG] Au=$Au au=$au aU=$aU ar=$ar fU=$fU fu=$fu - \n");

And when I run through them I get the following:

Initial log (at the beginning of request_route):

```
Sep  5 01:54:39 csbc01 csbc[20380]: NOTICE: {1 1 REGISTER 
f597522fd7e52fe99f2a54a834101efa@0:0:0:0:0:0:0:0} 

[sr-dev] [kamailio/kamailio] [Feature Request] Add reload capability for geoip2 module (#2029)

[Joel Serrano]

### Description

Currently, the `geoip2` module loads the IP database at startup and keeps it in 
cache and there is no way to tell Kamailio to reload the database without a 
full restart.

### Possible Solutions

To keep this module inline with other modules that use external datasources, I 
would suggest to implement a new RPC command and a new geoip2 function to 
reload the database defined in the `path` geoip2 modparam without the need of a 
restart.

I'm not aware of the effort required for implementing either of them, but only 
having an RPC command would effectively solve this issue as you can call RPC 
commands from within Kamailio conf, thus, the reload function would not be 
something strictly required but more of a nice-to-have.

### Examples:

Function:
```
geoip2_reload()
```

RPC command:
```
kamctl rpc gip2.reload / kamctl rpc geoip2.reload
```

Kamcmd command:
```
kamcmd geoip2.reload
```

-- 
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/2029___
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] unquoted value in global vars got segafult or error at cfg files (#1779)

[Joel Serrano]

I’m sure the community would appreciate if you would send a PR to update the 
documentation and improve it. 

You could also just suggest that it’s incomplete, and someone might do it for 
you. 

I don’t see the need to attack the quality of the documentation of Kamailio.

There is also an email list where you could ask these questions... 
sr-us...@lists.kamailio.org

Happy holidays :-)

-- 
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/1779#issuecomment-449980318___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [SR-Users] Merry Christmas and Happy Holidays!

[Joel Serrano]

+1!

Merry Christmas & happy new year!

On Mon, Dec 24, 2018 at 09:51 Daniel-Constantin Mierla 
wrote:

> With the season holiday just starting, it's again a good time to express
> my thanks and greetings to all the friends, developers and community
> members that made 2018 another great year for Kamailio project.
>
> Enjoy the holidays! Merry Christmas!
>
> Daniel
>
> * Santa is flying Kamailio! *
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 - www.kamailioworld.com
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-us...@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
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] db_check_table_version(): invalid version 6 for table subscriber found, expected 7 (check table structure and table "version") (#1270)

[Joel Serrano]

The subscriber table is used by kamailio, what does asterisk have to do 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/1270#issuecomment-449797871___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [SR-Users] RFC: updates to some core functions

[Joel Serrano]

+1 for option #2


On Wed, Dec 19, 2018 at 04:35 Carsten Bock  wrote:

> Hi,
>
> given the fact, that we do a lot of "non-sip" related stuff with Kamailio
> (we are using Kamailio as a Diameter HSS, Diameter Charging-Server (OCS),
> Diameter Routing-Agent (DRA)), I would also vote for number (2):
>
> > 2) remove the function export from the core and export one with the
> same
> > name from the corex module
>
> Thanks,
> Carsten
> --
>
> Carsten Bock
> CEO (Geschäftsführer)
>
> ng-voice GmbH
> Millerntorplatz 1
> 20359 Hamburg / Germany
>
> http://www.ng-voice.com
> mailto:cars...@ng-voice.com
>
> Office +49 40 5247593-40
> Fax +49 40 5247593-99
>
> Sitz der Gesellschaft: Hamburg
> Registergericht: Amtsgericht Hamburg, HRB 120189
> Geschäftsführer: Carsten Bock
> Ust-ID: DE279344284
>
> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
> http://www.ng-voice.com/imprint/
>
>
> Am Mi., 19. Dez. 2018 um 12:55 Uhr schrieb YAS0 CANER <
> caner_y...@hotmail.com>:
>
>> TmEXIT , kEXIT and corEXIT is failed 😊
>> --
>> *From:* sr-users  on behalf of Olle
>> E. Johansson 
>> *Sent:* Wednesday, December 19, 2018 2:38 PM
>> *To:* Daniel-Constantin Mierla
>> *Cc:* Kamailio (SER) - Development Mailing List; Kamailio (SER) - Users
>> Mailing List
>> *Subject:* Re: [SR-Users] [sr-dev] RFC: updates to some core functions
>>
>>
>>
>> > On 19 Dec 2018, at 12:26, Daniel-Constantin Mierla 
>> wrote:
>> >
>> >
>> > On 19.12.18 09:47, Olle E. Johansson wrote:
>> >>
>> >>> On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla 
>> wrote:
>> >>>
>> >>> corex module was added to hold the functions that otherwise would be
>> >>> more or less "in the core", like those that were updated to support
>> >>> variables in the parameters, so this is the one to take the place of
>> >>> core in regard to exporting functions.
>> >>>
>> >>> tmx was added because tm module became very big, but also to try to
>> >>> separate a bit between transaction management code and some functions
>> in
>> >>> top of it, in the way that tmx can work only with exported api by tm,
>> so
>> >>> if one adds a function there doesn't get access to all internals of
>> >>> transaction and it is safer not to mess up things there. It is more or
>> >>> less like usrloc and registrar, usrloc does internal management of
>> >>> location records, registrar is the interface to configuration file
>> (but
>> >>> there are other modules on top of usrloc, like pua_usrloc,
>> dmq_usrloc, ...).
>> >>>
>> >>> kex is the one that collected some functions that use to be in
>> kamailio
>> >>> (or better said openser at that time) but not in ser during 2005-2008
>> >>> and can be a module that be analyzed to see if can be merged into
>> other
>> >>> modules. A big chunk of it used to be related to MI commands, but as
>> we
>> >>> got rid of MI, might be easier now to split parts of it and relocate.
>> >>>
>> >> Ok, so removing kex is a good first step for the coming release.
>> >>
>> >> It’s really hard explaining TMX and TM for new Kamailians.
>> >
>> > We can add a note at the top of docs for each of these modules to refer
>> > to the other.
>> >
>> > On the other hand, I do not like to have a huge module. It is not
>> > suitable for small embedded systems. Also, there are other modules using
>> > the tm api, so it is a common approach. The tmx is exporting mostly
>> > functions at higher level of transaction interaction, one can build a
>> > transaction stateful sip routing without it, only using tm.
>> >
>> Damn it. My campaign for exit of the x modules just died. Sad story.
>>
>> Thanks for all the responses!
>>
>> /O
>> > Cheers,
>> > Daniel
>> >
>> >>
>> >> /O :-)
>> >>
>> >>> Cheers,
>> >>> Daniel
>> >>>
>> >>> On 19.12.18 09:25, Olle E. Johansson wrote:
>>  Going back one step, are there any reasons to keep tmx, kex and
>> corex modules at all?
>> 
>>  At this point in the project I think many of the functions should be
>> merged into
>>  the main modules and core.
>> 
>>  If I remember correctly, they exist because of a multi-brand history
>> that is not
>>  really the case any more.
>> 
>>  /O
>>  “The campaign to remove Kamailio extensions to Kamailio”
>> 
>> 
>> > On 19 Dec 2018, at 09:11, Henning Westerholt 
>> wrote:
>> >
>> > Am Mittwoch, 19. Dezember 2018, 09:03:26 CET schrieb Sergey Safarov:
>> >> I prefer second way. Without any duplication.
>> >> For old configs branches 4.4, 5.0, 5.1 is always available.
>> > Hello,
>> >
>> > I would prefer also the second way, for the same reason: less
>> duplicated
>> > functions.
>> >
>> > Best regards,
>> >
>> > Henning
>> >
>> >
>> >> ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla <
>> mico...@gmail.com>:
>> >>> Hello,
>> >>>
>> >>> it was brought into discussions several times in the past about
>> core
>> >>> functions not accepting variables in the parame

Re: [sr-dev] [kamailio/kamailio] assign CSeq header for REGISTER generation (#1768)

[Joel Serrano]

Have you tried setting `track_cseq_updates` from dialog module?

https://kamailio.org/docs/modules/5.2.x/modules/dialog.html#dialog.p.track_cseq_updates


-- 
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/1768#issuecomment-447655035___
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] Issues with single Kamailio process in two networks/vlans (#1703)

[Joel Serrano]

Hi @ThomasLobker have you tried setting the `mhomed=1` in your kamailio.cfg?

https://www.kamailio.org/wiki/cookbooks/5.1.x/core#mhomed

I think this is what you are missing.

-- 
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/1703#issuecomment-435238660___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

@miconda kamailio has **not** died since the patch. Let's keep this issue 
closed then, if something happens I'll open a new one with new backtraces.  

Sorry for the confusion. 👍 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1687#issuecomment-433487377___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

Closed #1687.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1687#event-1929432327___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

I just verified and removing DB_URL and DB_MODE from dialog modparams has the 
same behavior. In order to keep the thread in sync with the topic, I have 
created #1692 to track the metric not being updated. As for *this* issue we can 
either close it or continue troubleshooting on why the dialog counter from 
`stats.get_statistics` goes below 0.

@miconda what do you think?




-- 
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/1591#issuecomment-433486369___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Active dialog stats stays static on a passive kamailio node that replicates dialogs via DMQ (#1692)

[Joel Serrano]

### Description

In a setup with 2 kamailios in active/passive with a virtual IP that failovers 
between them:

sbc01 (active) is handling calls.
sbc02 (passive) is started, and does an initial dialog sync via DMQ

```
root@sbc01:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 39",
"dialog:early_dialogs = 2",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 583",
"dialog:processed_dialogs = 2527",
root@sbc01:~#
```

```
root@sbc02:/etc/kamailio# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 39",
"dialog:early_dialogs = 0",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 0",
"dialog:processed_dialogs = 0",
root@sbc02:/etc/kamailio#
```

>From that point onwards, as long as sbc01 stays as active, sbc02 stays as 
>passive, and no restarts occur anywhere, the values for `dialog` metrics in 
>sbc02 will not change and remain as they are, in the previous example, 
>active_dialogs would remain as 39.

### Troubleshooting

This was discovered during some tests from #1591

 Reproduction

Setup 2 kamailio instances that replicate dialogs via DMQ.

1- On Kamailio1 put some traffic to have some active dialogs (must call 
`dlg_manage()` in routing script for these test calls)
2- Start Kamailio2
3- Compare output of: `kamcmd stats.get_statistics dialog:` on both nodes.
4- Alter the amount of active dialogs on Kamailio1 (either end some or create 
new ones).
5- Repeat step 3.

Kamailio1 --> Step5 will have different values from Step3.
Kamailio2 --> Step5 will have exactly the same values from Step3.


### Possible Solutions

`dialog:active_dialogs` should remain as 0 on Kamailio2, as technically there 
are no dialogs being handled by that server, it only has information of 
replicated dialogs and those stats are available in the `dlg.stats_active` 
metric.


### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
# kamailio -V
version: kamailio 5.2.0-pre1 (x86_64/linux) 2ecf60-dirty
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_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 2ecf60 -dirty
compiled with gcc 6.3.0
```

* **Operating System**:



```
root@sbc02:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 9.5 (stretch)
Release:9.5
Codename:   stretch
root@sbc02:~# uname -a
Linux sbc02 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 
GNU/Linux
root@sbc02:~#
```


-- 
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/1692___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

BTW, @henningw:

If I build myself kamailio I have the commit id in kamailio -V

But from nightly-deb packages it's not available:

DEB install:

```
root@sbc01:~# kamailio -V
version: kamailio 5.2.0-pre1 (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_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0
root@sbc01:~#
```

Source install:

```
root@sbc02:~# kamailio -V
version: kamailio 5.2.0-pre1 (x86_64/linux) 2ecf60-dirty
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_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 2ecf60 -dirty
compiled with gcc 6.3.0
root@sbc02:~#
```
 Note the 2ecf60-dirty !!!

I guess I wasn't going crazy after all! 😄 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1687#issuecomment-433478094___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

Reopened #1687.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1687#event-1929351829___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

Reopening for now!

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1687#issuecomment-433475803___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

>From the logs I also thought it was something in the To: header but I don't 
>know how to read the backtraces :(

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1687#issuecomment-433475689___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

BTW, @henningw:

If I build myself kamailio I have the commit id in `kamailio -V`

But from nightly-deb packages it's not available:

DEB install:
```
root@sbc01:~# kamailio -V
version: kamailio 5.2.0-pre1 (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_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0
root@sbc01:~#
```

Source install:
```
root@sbc02:~# kamailio -V
version: kamailio 5.2.0-pre1 (x86_64/linux) 2ecf60-dirty
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_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 2ecf60 -dirty
compiled with gcc 6.3.0
root@sbc02:~#
```

I guess I wasn't going crazy after all! :D

-- 
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/1591#issuecomment-433468833___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Hi guys.. the `dlg.stats_active` is definitely working nicely. But the 
stats.get_statistics() still gets out of sync with its peer node...:

![image](https://user-images.githubusercontent.com/16212586/47570680-97c53c80-d8eb-11e8-8e67-6d93af693fbf.png)

So I see the situation like this:

- `dlg.stats_active` works. Thanks! <--- I'm using this for now.
- `stats.get_statistics` has 2 issues:
1- The counter at some point still hits <0 and goes to ULONG_MAX value, 
blablabla...
2- On startup it counts the active dialogs (not sure if via DMQ or database) 
and that number stays static. (NOTE: this we are talking on the backup node, 
which has 0 traffic, and therefor should say 0). <--- This I yet have to 
confirm if it happens because of DMQ or dialog modparam DB_MODE=3

I'll update here later on.


-- 
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/1591#issuecomment-433467049___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

Closed #1687.

-- 
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/1687#event-1927363924___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

Yeah this is my bad, it was there all the time, and only because you said so 
now I actually see it:

```
root@sbc02:~# kamailio -V
version: kamailio 5.2.0-pre1 (x86_64/linux) 2ecf60-dirty
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_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 2ecf60 -dirty
compiled with gcc 6.3.0
root@sbc02:~#
```

Commit --> 2ecf60

Thanks @henningw 

-- 
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/1687#issuecomment-433205047___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

Hi @miconda, I've just deployed K with this patch, I'll let you know if this 
happens again. 

Out of curiosity, if I wanted to test with the nightly builds, how can I know 
if for example:

`5.2.0~pre1+0~20181025005757.1239+stretch` deb package contains commit 5e76302?

Thanks!

-- 
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/1687#issuecomment-433123753___
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] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

To add a more specific version as `5.2.0-pre1` doesn't say much...:

```
root@sbc01:/var/tmp# dpkg -l | grep kam
ii  kamailio5.2.0~pre1+0~20181020005754.1238+stretch 
amd64very fast, dynamic and configurable SIP server
ii  kamailio-dbg:amd64  5.2.0~pre1+0~20181020005754.1238+stretch 
amd64very fast and configurable SIP server [debug symbols]
ii  kamailio-extra-modules:amd645.2.0~pre1+0~20181020005754.1238+stretch 
amd64Extra modules for the Kamailio SIP Server
ii  kamailio-geoip2-modules:amd64   5.2.0~pre1+0~20181020005754.1238+stretch 
amd64The geoip2 module for the Kamailio SIP Server
ii  kamailio-mysql-modules:amd645.2.0~pre1+0~20181020005754.1238+stretch 
amd64MySQL database connectivity module for Kamailio
ii  kamailio-outbound-modules:amd64 5.2.0~pre1+0~20181020005754.1238+stretch 
amd64SIP Outbound module for the Kamailio SIP server
ii  kamailio-phonenum-modules:amd64 5.2.0~pre1+0~20181020005754.1238+stretch 
amd64phonenum modules for the Kamailio SIP server
ii  kamailio-utils-modules:amd645.2.0~pre1+0~20181020005754.1238+stretch 
amd64Utility functions for the Kamailio SIP server
root@sbc01:/var/tmp#
```

-- 
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/1687#issuecomment-432853857___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Core generated by Kamailio when a bad char is found in header (#1687)

[Joel Serrano]

### Description

Kamailio dies complaining about a bad char in some header.  I can say that I 
just updated from the nightly-devel apt repo, this problem never happened in 
latest v5.1 release.

### Troubleshooting

 Reproduction

I don't know how to reproduce yet.

 Debugging Data



[BT-FULL_core.kamailio.3329.1540415468.txt](https://github.com/kamailio/kamailio/files/2512570/BT-FULL_core.kamailio.3329.1540415468.txt)
[BT-FULL_core.kamailio.3330.1540415471.txt](https://github.com/kamailio/kamailio/files/2512571/BT-FULL_core.kamailio.3330.1540415471.txt)
[BT-FULL_core.kamailio.3331.1540415467.txt](https://github.com/kamailio/kamailio/files/2512572/BT-FULL_core.kamailio.3331.1540415467.txt)
[BT-FULL_core.kamailio..1540415469.txt](https://github.com/kamailio/kamailio/files/2512573/BT-FULL_core.kamailio..1540415469.txt)
[INFO-LOCALS_core.kamailio.3329.1540415468.txt](https://github.com/kamailio/kamailio/files/2512574/INFO-LOCALS_core.kamailio.3329.1540415468.txt)
[INFO-LOCALS_core.kamailio.3330.1540415471.txt](https://github.com/kamailio/kamailio/files/2512575/INFO-LOCALS_core.kamailio.3330.1540415471.txt)
[INFO-LOCALS_core.kamailio.3331.1540415467.txt](https://github.com/kamailio/kamailio/files/2512576/INFO-LOCALS_core.kamailio.3331.1540415467.txt)
[INFO-LOCALS_core.kamailio..1540415469.txt](https://github.com/kamailio/kamailio/files/2512577/INFO-LOCALS_core.kamailio..1540415469.txt)
[LIST_core.kamailio.3329.1540415468.txt](https://github.com/kamailio/kamailio/files/2512578/LIST_core.kamailio.3329.1540415468.txt)
[LIST_core.kamailio.3330.1540415471.txt](https://github.com/kamailio/kamailio/files/2512579/LIST_core.kamailio.3330.1540415471.txt)
[LIST_core.kamailio.3331.1540415467.txt](https://github.com/kamailio/kamailio/files/2512580/LIST_core.kamailio.3331.1540415467.txt)
[LIST_core.kamailio..1540415469.txt](https://github.com/kamailio/kamailio/files/2512581/LIST_core.kamailio..1540415469.txt)

 Log Messages


The relevant log lines are:

```
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  
[core/parser/parse_addr_spec.c:718]: parse_addr_spec(): unexpected char [<] in 
status 6: ["910609864"  [core/parser/msg_parser.c:164]: 
get_hdr_field(): bad to header
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  [core/parser/msg_parser.c:337]: 
parse_headers(): bad header field [To: "910609864" 
64@138.99.136.3>;tag=as664d068c#015#012Call-ID: 
032f010653fed9170365045a4e1002]
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  
[core/parser/parse_addr_spec.c:718]: parse_addr_spec(): unexpected char [<] in 
status 6: ["910609864"  [core/parser/msg_parser.c:164]: 
get_hdr_field(): bad to header
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  [core/parser/msg_parser.c:337]: 
parse_headers(): bad header field [To: "910609864" 
64@138.99.136.3>;tag=as664d068c#015#012Call-ID: 
032f010653fed9170365045a4e1002]
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  
[core/parser/parse_addr_spec.c:718]: parse_addr_spec(): unexpected char [<] in 
status 6: ["910609864"  [core/parser/msg_parser.c:164]: 
get_hdr_field(): bad to header
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  [core/parser/msg_parser.c:337]: 
parse_headers(): bad header field [To: "910609864" 
64@138.99.136.3>;tag=as664d068c#015#012Call-ID: 
032f010653fed9170365045a4e1002]
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR: pv [pv_core.c:1892]: pv_get_hdr(): 
error parsing headers
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  
[core/parser/parse_addr_spec.c:718]: parse_addr_spec(): unexpected char [<] in 
status 6: ["910609864"  [core/parser/msg_parser.c:164]: 
get_hdr_field(): bad to header
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR:  [core/parser/msg_parser.c:337]: 
parse_headers(): bad header field [To: "910609864" 
64@138.99.136.3>;tag=as664d068c#015#012Call-ID: 
032f010653fed9170365045a4e1002]
Oct 24 16:11:11 sbc01 sbc[3330]: ERROR: pv [pv_core.c:704]: pv_get_callid(): 
cannot parse Call-Id header
```

 SIP Traffic



I have enabled a mirror server to capture all traffic, once the problem happens 
again I will be able to update this issue with SIP traffic.


### Possible Solutions

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
root@sbc01:/var/tmp# kamailio -v
version: kamailio 5.2.0-pre1 (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_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0
root@sbc01:/var/tmp#
```

* **Operating System**:



```
root@sbc01:/var/tmp# uname -a
Linux sbc01.vozelia.com.pa 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 
(2018-10-08) x86_64 GNU/Linux
root@sbc01:/var/tmp#

root@sbc01:/var/tmp# lsb_rele

Re: [sr-dev] [kamailio/kamailio] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Hi @miconda, sorry for the delay, it's taken me a while until I have been able 
to test this..

I can confirm so far that `dlg.stats_active` works correctly, it's in sync 
between both nodes all the time, so any changes to the dialogs are reflected 
there instantly on both nodes. 

But, something must be wrong with `stats.get_statistics`:

Active K node:

```
root@sbc01:/etc/kamailio# kamcmd stats.get_statistics all | grep dialog
dialog:active_dialogs = 30
dialog:early_dialogs = 2
dialog:expired_dialogs = 14
dialog:failed_dialogs = 12176
dialog:processed_dialogs = 44907
root@sbc01:/etc/kamailio#
```

Backup K node (newly restarted):

```
root@sbc02:/etc/kamailio# kamcmd stats.get_statistics all | grep dialog
dialog:active_dialogs = 27
dialog:early_dialogs = 0
dialog:expired_dialogs = 0
dialog:failed_dialogs = 0
dialog:processed_dialogs = 0
root@sbc02:/etc/kamailio#
```

that `27` seems to me like an "initial sync" from the peer node, but that 
number won't change after that (which makes sense as this node is a backup and 
doesnt' handle any traffic unless there is a failover).

Does this make sense?

Thanks!



-- 
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/1591#issuecomment-432767538___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Hi @miconda , I can absolutely test this.

Would your patch apply to return values for `dlg.stats_active` or to the dialog 
entries for `stats.get_statistics` ?? Or maybe to both? :)



-- 
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/1591#issuecomment-420415071___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Hi @charlesrchance, thanks for the time to look into this.

What you say totally matches the "weird" behaviors I was seeing. You really 
gave me a lot of clarity understanding what is going on behind the scenes.

To answer your questions:

1. Yes, I have database but my idea was to move away from it for each thing I 
handle using DMQ. This also matches chronology of events, I have been 
restarting nodes here and there, I wasn't "losing" dialogs, but making them 
"orphaned" instead without knowing.

2. So there are (at least) a couple different options here:
2a) stat counters would have all dialogs (local + replicated), which in reality 
is the true value, as from kamailio's perspective, those dialogs are there and 
they are active aren't they?
2b) stat counters would only have local dialogs, so if you want to have full 
dialog count you would have to stack the values from all nodes.

Now there is also a `dlg.stats_active` that gives you current dialogs (not sure 
if it also shows replicated ones)  so maybe we can benefit from both options, a 
counter that includes both local and replicated dialogs, and a different 
counter (dlg.stats_active?) that has only the current-local-count of dialogs.

Since I fully restarted both SBCs (which in fact, that was clearing the 
orphaned dialogs) I haven't seen a spike (negative counter).

At this point I don't know what the best options is, I do understand perfectly 
the problem though.

@miconda what do you think about all this?







-- 
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/1591#issuecomment-409303111___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

More info:

On another cluster, same setup..., during this troubleshooting I disabled DMQ 
and enabled MySQL for dialog replication, I also left one node outside of 
rotation to see replication behavior.

Well, with 0 traffic I can see this:

```
root@sbc01:~# kamctl rpc dlg.stats_active
{
  "jsonrpc":  "2.0",
  "result": {
"starting": 0,
"connecting": 0,
"answering":  0,
"ongoing":  0,
"all":  0
  },
  "id": 2634
}
root@sbc01:~#
```

Which is correct, but...:

```
root@sbc01:~# kamctl rpc stats.fetch all | grep dialog
"dialog.active_dialogs":  "38",
"dialog.early_dialogs": "0",
"dialog.expired_dialogs": "38",
"dialog.failed_dialogs":  "0",
"dialog.processed_dialogs": "1",
root@sbc01:~#
```

I wonder if it's correct that those 38 `expired` dialogs still count towards 
the `active` counter? Could that have something to do? Maybe those 
non-existent-expired-dialogs because they are somewhere in the "active" 
counter, they get replicated only when DMQ is enabled?

So far I have clear that:

1- For sure there is a scenario where counters go below 0.
2- It only happens (so far) when DMQ is enabled
3- In my initial look, I found some logs about dialogs created on node1 were 
timed-out on node2 (see previous posts)
4- Now I see a discrepancy on active vs expired dialogs on a node with 0 active 
dialogs.

I feel we are slowly narrowing down what the possible problem can be, but I 
still don't have a clear picture what causes what.


-- 
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/1591#issuecomment-408690103___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Could it have something to do with "old-non-expired-non-removed" dialogs?

So today I applied latest @charlesrchance patch, and what I normally do (so I 
don't lose dialogs) is:

1- Restart one node
2- Wait for DMQ replication dialog sync
3- Restart other node

Right after restarting both nodes in that sequence, I already could see values 
close to ULONG_MAX, so I did a `watch` every second and I could see the values 
move around.

I decided to compare the dialogs to see if I could find anything interesting, 
what I found is that there were a lot of dialogs with the `init_ts` from like 
11th and 13th July and being today 28th, those dialogs should not be there.

So I wonder if those "bad" dialogs could be the cause of the counters going 
below 0.

Maybe some timer to remove those dialogs didn't happen? and because of the way 
I perform restarts to not lose dialogs, they were constantly there replicated 
backwards and forwards...

That said, I did a full restart (both nodes at the same time, losing dialogs) 
and since then the metrics are looking good.

I hope this info helps.

-- 
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/1591#issuecomment-408629258___
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] coredumps possibly generated by DMQ in kamailio v5.1.4 (#1594)

[Joel Serrano]

Closed #1594.

-- 
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/1594#event-1752743784___
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] coredumps possibly generated by DMQ in kamailio v5.1.4 (#1594)

[Joel Serrano]

Hi Daniel, just checked and so far no more core files. Closing this, if I find 
new ones I'll open a new ticket. Thanks for the help!

-- 
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/1594#issuecomment-407773395___
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] Reply code in $uac_req(evcode) remains 401 instead of 200 when using uac_req_send() with authentication (#1598)

[Joel Serrano]

Closed #1598.

-- 
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/1598#event-1748426825___
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] Reply code in $uac_req(evcode) remains 401 instead of 200 when using uac_req_send() with authentication (#1598)

[Joel Serrano]

Closing this one...

-- 
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/1598#issuecomment-407158055___
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] Reply code in $uac_req(evcode) remains 401 instead of 200 when using uac_req_send() with authentication (#1598)

[Joel Serrano]

@miconda: tested, works:

```
Jul 23 13:10:22 sbc01 sbc[5374]: NOTICE: 

Re: [sr-dev] [kamailio/kamailio] Reply code in $uac_req(evcode) remains 401 instead of 200 when using uac_req_send() with authentication (#1598)

[Joel Serrano]

Absolutely! Building with this commit right now. I'll report back in a bit :)

-- 
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/1598#issuecomment-407103455___
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] Reply code in $uac_req(evcode) remains 401 instead of 200 when using uac_req_send() with authentication (#1598)

[Joel Serrano]

Hi Daniel, that would be awesome. Thank you. 

Offtopic but related question, does this mean also that if the final reply 
would be a 5XX or a different 4XX a failure_route would no be called for 
uac_req_send()?

How do you failover to registrar_server2 if registrar_server1 is dead if you 
have no failure_route execution? 

-- 
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/1598#issuecomment-406872049___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Reply code in $uac_req(evcode) remains 401 instead of 200 when using uac_req_send() with authentication (#1598)

[Joel Serrano]

### Description

Following this scenario:

Softphone <-> Kamailio <-> Asterisk

1- Softphone registers with kamailio (REGISTER)
2- Kamailio challenges... (401)
3- Softphone registers with kamailio (REGISTER + Auth info)
4- Kamailio accepts (200)
5- If Kamailio accepted, it sends a REGISTER to asterisk (REGISTER)
6- Asterisk challenges... (401)
7- Kamailio authenticates (REGISTER + Auth info)
8- Asterisk accepts (200)

(NOTE: I know you can avoid Asterisk re-requesting for authentication, but in 
this case it's mandatory.)

kamailio.cfg has this:

```
$var(rip) = $(avp(s:dsp_uri_list){uri.host});
$var(rip_port) = $(avp(s:dsp_uri_list){uri.port});
$uac_req(method)="REGISTER";
$uac_req(auser)=$avp(customer_user);
$uac_req(apasswd)=$avp(customer_pass);
$uac_req(ruri)="sip:" + $var(rip) + ":" + $var(rip_port);
$uac_req(furi)="sip:" + $au + "@" + $var(rip);
$uac_req(turi)="sip:" + $au + "@" + $var(rip);
$uac_req(hdrs)="Contact: \r\n";
$uac_req(evroute)=1;
if ($sel(contact.expires) != $null) {
$uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + 
$sel(contact.expires) + "\r\n";
} else {
$uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $hdr(Expires) + 
"\r\n";
}
uac_req_send();
```

and this:

```
# Log replies from uac_req_send()
event_route[uac:reply] {
xlog("L_NOTICE", "[UAC] - $uac_req(method) request from user 
$uac_req(auser) to $uac_req(ruri) completed with code: $uac_req(evcode)\n");
}
```

The result:

![image](https://user-images.githubusercontent.com/16212586/43027222-0a32bd48-8c2e-11e8-8038-16d0dba00dec.png)

```
Jul 20 16:49:42 sbc01 sbc[5236]: NOTICE: 

Re: [sr-dev] [kamailio/kamailio] coredumps possibly generated by DMQ in kamailio v5.1.4 (#1594)

[Joel Serrano]

@miconda: they are both (core1 and core2) from the same server, just later in 
time. So core1 was generated at say for example 1pm, then kamailio is restarted 
by watchdog, and at 3pm core2 is generated.

Regarding core-per-pid:

I have the following in `/etc/kamailio/kamailio.cfg`:

```
fork=yes
```

And in `/etc/sysctl.d/kamailio.conf`:

```
# Kamailio debugging
kernel.core_pattern = /var/tmp/core.%e.%p.%h.%t
kernel.core_uses_pid = 1
fs.suid_dumpable = 2
```

Just to verify:

```
root@sbc01:~# cat /proc/sys/kernel/core_uses_pid
1
root@sbc01:~#
```

Am I missing anything to get the core-per-pid ??


-- 
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/1594#issuecomment-406449916___
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] coredumps possibly generated by DMQ in kamailio v5.1.4 (#1594)

[Joel Serrano]

Hi Daniel:

```
(gdb) p process_no
$1 = 0
(gdb) p pt[process_no]
$2 = {pid = 777, unix_sock = -1, idx = -1, desc = "main process - attendant", 
'\000' }
(gdb)
```

-- 
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/1594#issuecomment-406209235___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Thanks! Let me know if you need any more info

-- 
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/1591#issuecomment-406000670___
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] coredumps possibly generated by DMQ in kamailio v5.1.4 (#1594)

[Joel Serrano]

@miconda: 

```
(gdb) frame 0
#0  0x7f4e12ce6c68 in get_dlg (callid=0x7ffdc5993850, ftag=0x7ffdc5993860, 
ttag=0x7ffdc5993870, dir=0x7ffdc5993840) at dlg_hash.c:797
797 in dlg_hash.c
(gdb) p *callid
$1 = {s = 0x7f4dec572b2e "72a1671957944647-777@138.99.136.21\r\nContent-Length: 
70\r\nMax-Forwards: 1\r\nContent-Type: 
text/plain\r\n\r\nsip:10.2.1.24:5080;status=active\r\nsip:10.2.1.23:5080;status=disabled\r\n",
 len = 34}
(gdb) p *ftag
$2 = {
  s = 0x7f4dec572aef "053226fbdabb3180cd6e80991bee5f34-940d\r\nCSeq: 10 
KDMQ\r\nCall-ID: 72a1671957944647-777@138.99.136.21\r\nContent-Length: 
70\r\nMax-Forwards: 1\r\nContent-Type: 
text/plain\r\n\r\nsip:10.2.1.24:5080;status=active\r\nsi"..., len = 37}
(gdb) p *ttag
$3 = {s = 0x0, len = 0}
(gdb) p *dir
$4 = 0
(gdb) p d_table
$5 = (dlg_table_t *) 0x0
(gdb) p *d_table
Cannot access memory at address 0x0
(gdb)
```

-- 
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/1594#issuecomment-405997714___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

I don't know if it helps, but I have one server constantly reporting 
incorrectly:

```
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551568",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551567",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551567",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551566",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551566",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551566",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551566",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551564",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551564",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551563",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551562",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551565",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551567",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551568",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551569",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551569",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551570",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551570",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551570",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551569",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551569",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551570",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551571",
root@kamailio1:~# kamctl rpc stats.get_statistics all | grep -e "dialog:active"
"dialog:active_dialogs = 18446744073709551572",
root@kamailio1:~#
``` 

-- 
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/1591#issuecomment-405637294___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] coredumps possibly generated by DMQ in kamailio v5.1.4 (#1594)

[Joel Serrano]

### Description

Not sure, found 2 cores generated today, only suggesting it's DMQ related by 
what I see in the backtrace. They could have been generated during a restart of 
kamailio, not 100% sure though.

### Troubleshooting

TBD

 Reproduction

TBD

 Debugging Data

Attaching *bt full*, *info locals* and *list* from:

```
-rw--- 1 root kamailio 549019648 Jul 13 16:29 
core.kamailio.22907.sbc01.1531517373
-rw--- 1 root kamailio 549019648 Jul 13 17:13 
core.kamailio.777.sbc01.1531520031
```

[core1__bt_full.txt](https://github.com/kamailio/kamailio/files/2194484/core1__bt_full.txt)
[core1__info_locals.txt](https://github.com/kamailio/kamailio/files/2194485/core1__info_locals.txt)
[core1__list.txt](https://github.com/kamailio/kamailio/files/2194486/core1__list.txt)
[core2__bt_full.txt](https://github.com/kamailio/kamailio/files/2194487/core2__bt_full.txt)
[core2__info_locals.txt](https://github.com/kamailio/kamailio/files/2194488/core2__info_locals.txt)
[core2__list.txt](https://github.com/kamailio/kamailio/files/2194489/core2__list.txt)


### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
root@sbc01:~# kamailio -V
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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 with gcc 6.3.0
root@sbc01:~#
```

* **Operating System**:

```
root@sbc01:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 9.4 (stretch)
Release:9.4
Codename:   stretch
root@sbc01:~#

root@sbc01:~# uname -a
Linux sbc01 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 
GNU/Linux
root@sbc01:~#
```


-- 
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/1594___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Hi Daniel, 

This is what I can get:

```
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.1334.13cn4.1531505030 > 
core.kamailio.1334.13cn4.1531505030-bt_full.txt
66  ../../core/parser/../mem/../atomic/atomic_common.h: No such file or 
directory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.1335.13cn4.1531505030 > 
core.kamailio.1335.13cn4.1531505030-bt_full.txt
66  ../../core/parser/../mem/../atomic/atomic_common.h: No such file or 
directory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.1336.13cn4.1531505030 > 
core.kamailio.1336.13cn4.1531505030-bt_full.txt
66  ../../core/parser/../mem/../atomic/atomic_common.h: No such file or 
directory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.1337.13cn4.1531505030 > 
core.kamailio.1337.13cn4.1531505030-bt_full.txt
66  ../../core/parser/../mem/../atomic/atomic_common.h: No such file or 
directory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.1338.13cn4.1531505030 > 
core.kamailio.1338.13cn4.1531505030-bt_full.txt
66  ../../core/parser/../mem/../atomic/atomic_common.h: No such file or 
directory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.1339.13cn4.1531505030 > 
core.kamailio.1339.13cn4.1531505030-bt_full.txt
66  ../../core/parser/../mem/../atomic/atomic_common.h: No such file or 
directory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.24376.13cn4.1531504766 > 
ocre.kamailio.24376.13cn4.1531504766-bt_full.txt
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.28420.13cn4.1531504860 > 
ocre.kamailio.28420.13cn4.1531504860-bt_full.txt
BFD: Warning: /var/tmp/core.kamailio.28420.13cn4.1531504860 is truncated: 
expected core file size >= 8607031296, found: 2081087488.
Cannot access memory at address 0x7fc79b2dc148
Cannot access memory at address 0x7fc79b2dc140
Failed to read a valid object file image from memory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.28421.13cn4.1531504860 > 
ocre.kamailio.28421.13cn4.1531504860-bt_full.txt
BFD: Warning: /var/tmp/core.kamailio.28421.13cn4.1531504860 is truncated: 
expected core file size >= 8607031296, found: 2136645632.
Cannot access memory at address 0x7fc79b2dc148
Cannot access memory at address 0x7fc79b2dc140
Failed to read a valid object file image from memory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.28422.13cn4.1531504860 > 
ocre.kamailio.28422.13cn4.1531504860-bt_full.txt
BFD: Warning: /var/tmp/core.kamailio.28422.13cn4.1531504860 is truncated: 
expected core file size >= 8607031296, found: 2128039936.
Cannot access memory at address 0x7fc79b2dc148
Cannot access memory at address 0x7fc79b2dc140
Failed to read a valid object file image from memory.
root@kamailio2:/var/tmp# gdb /usr/sbin/kamailio -ex "bt full" --batch 
core.kamailio.28423.13cn4.1531504860 > 
ocre.kamailio.28423.13cn4.1531504860-bt_full.txt
BFD: Warning: /var/tmp/core.kamailio.28423.13cn4.1531504860 is truncated: 
expected core file size >= 8607031296, found: 2174545920.
Cannot access memory at address 0x7fc79b2dc148
Cannot access memory at address 0x7fc79b2dc140
Failed to read a valid object file image from memory.
root@kamailio2:/var/tmp#
```

[core.kamailio.1334.13cn4.1531505030-bt_full.txt](https://github.com/kamailio/kamailio/files/2193740/core.kamailio.1334.13cn4.1531505030-bt_full.txt)
[core.kamailio.1335.13cn4.1531505030-bt_full.txt](https://github.com/kamailio/kamailio/files/2193741/core.kamailio.1335.13cn4.1531505030-bt_full.txt)
[core.kamailio.1336.13cn4.1531505030-bt_full.txt](https://github.com/kamailio/kamailio/files/2193742/core.kamailio.1336.13cn4.1531505030-bt_full.txt)
[core.kamailio.1337.13cn4.1531505030-bt_full.txt](https://github.com/kamailio/kamailio/files/2193743/core.kamailio.1337.13cn4.1531505030-bt_full.txt)
[core.kamailio.1338.13cn4.1531505030-bt_full.txt](https://github.com/kamailio/kamailio/files/2193744/core.kamailio.1338.13cn4.1531505030-bt_full.txt)
[core.kamailio.1339.13cn4.1531505030-bt_full.txt](https://github.com/kamailio/kamailio/files/2193745/core.kamailio.1339.13cn4.1531505030-bt_full.txt)
[ocre.kamailio.24376.13cn4.1531504766-bt_full.txt](https://github.com/kamailio/kamailio/files/2193746/ocre.kamailio.24376.13cn4.1531504766-bt_full.txt)
[ocre.kamailio.28420.13cn4.1531504860-bt_full.txt](https://github.com/kamailio/kamailio/files/2193747/ocre.kamailio.28420.13cn4.1531504860-bt_full.txt)
[ocre.kamailio.28421.13cn4.1531504860-bt_full.txt](https://github.com/kamailio/kamailio/files/2193748/ocre.kamailio.28421.13cn4.1531504860-bt_full.txt)
[ocre.kamailio.28422.13cn4.1531504860-bt_full.txt](https://github.com/kamailio/kamailio/files/219374

Re: [sr-dev] [kamailio/kamailio] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Hi Daniel, 

On my initial test in prod, I can see already discrepancies:

```
root@kamailio2:~# kamctl rpc dlg.stats_active
{
  "jsonrpc":  "2.0",
  "result": {
"starting": 4,
"connecting": 55,
"answering":  2,
"ongoing":  253,
"all":  314
  },
  "id": 23360
}
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 18446744073709551604",
"dialog:early_dialogs = 15",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 120",
"dialog:processed_dialogs = 340",
root@kamailio2:~#
```

Now we can go past 9223372036854776000 ??? I don't understand that.

That was right after restarting (green active dialogs, yellow early dialogs):

![image](https://user-images.githubusercontent.com/16212586/42706316-2926ed4e-868b-11e8-8f62-08bddc849d58.png)


Here is multiple runs of the stats.get_statistics:

```
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 18446744073709551614",
"dialog:early_dialogs = 8",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 315",
"dialog:processed_dialogs = 863",
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 18446744073709551614",
"dialog:early_dialogs = 8",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 315",
"dialog:processed_dialogs = 864",
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 18446744073709551614",
"dialog:early_dialogs = 8",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 315",
"dialog:processed_dialogs = 864",
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 18446744073709551613",
"dialog:early_dialogs = 10",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 320",
"dialog:processed_dialogs = 866",
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 0",
"dialog:early_dialogs = 8",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 322",
"dialog:processed_dialogs = 870",
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 1",
"dialog:early_dialogs = 9",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 323",
"dialog:processed_dialogs = 873",
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 18446744073709551615",
"dialog:early_dialogs = 9",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 324",
"dialog:processed_dialogs = 875",
root@kamailio2:~# kamctl rpc stats.get_statistics all | grep dialog
"dialog:active_dialogs = 18446744073709551615",
"dialog:early_dialogs = 10",
"dialog:expired_dialogs = 0",
"dialog:failed_dialogs = 325",
"dialog:processed_dialogs = 876",
root@kamailio2:~#
```

I tried to have a script gathering metrics:

```
root@kamailio2:~# cat dialogs.sh
#!/bin/bash

while true; do
DIALOGS=`kamctl rpc dlg.list | grep h_entry | sort  | wc -l`
METRICS=`kamctl rpc stats.get_statistics all | grep -e "dialog:active" -e 
"dialog:early" | tr -d " " | tr -d "\n"`
NEWMETRICS=`kamctl rpc dlg.stats_active | jq -c .result`
echo "`date +'%Y-%m-%d %H:%M:%S.%N'` - dlg.list:$DIALOGS - 
stats.get_statistics:$METRICS - dlg.stats_active:$NEWMETRICS"
sleep 1
done
root@kamailio2:~#
```

But, after a little kamailio "starts slowing down" until it dies (had to 
completely reboot the server).

```
root@kamailio2:~# ./dialogs.sh
2018-07-13 10:57:14.204158716 - dlg.list:419 - 
stats.get_statistics:"dialog:active_dialogs=13","dialog:early_dialogs=12", - 
dlg.stats_active:{"starting":5,"connecting":62,"answering":7,"ongoing":288,"all":362}
2018-07-13 10:57:15.437165579 - dlg.list:422 - 
stats.get_statistics:"dialog:active_dialogs=15","dialog:early_dialogs=11", - 
dlg.stats_active:{"starting":4,"connecting":59,"answering":10,"ongoing":289,"all":362}
2018-07-13 10:57:16.678432892 - dlg.list:423 - 
stats.get_statistics:"dialog:active_dialogs=14","dialog:early_dialogs=9", - 
dlg.stats_active:{"starting":2,"connecting":58,"answering":9,"ongoing":289,"all":358}
2018-07-13 10:57:17.915458776 - dlg.list:422 - 
stats.get_statistics:"dialog:active_dialogs=13","dialog:early_dialogs=9", - 
dlg.stats_active:{"starting":4,"connecting":60,"answering":7,"ongoing":289,"all":360}
2018-07-13 10:57:19.149467641 - dlg.list:420 - 
stats.get_statistics:"dialog:active_dialogs=13","dialog:early_dialogs=8", - 
dlg.stats_active:{"starting":3,"connecting":60,"answering":5,"ongoing":290,"all":358}
2018-07-13 10:57:20.386457513 - dlg.list:415 - 
stats.get_statistics:"dialog:active_dialogs=14","dialog:early_dialogs=7", - 
dlg.stats_active:{"starting":4,"connecting":59,"answering":5,"ongoing":290,"all":358}
2018-07-13 10:57:21.627241266 - dlg.list:412 - 
stats.get_statistics:"dialog:active_dialogs=15","dialog:early_dialogs=7", - 
d

Re: [sr-dev] [kamailio/kamailio] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

I'm building v5.1.4 packages with that commit cherry-picked. I will deploy as 
soon as I have run a few tests in lab. I have noticed that the issue happens 
only on low traffic, so it matches your theory of the value going "below 0"...

I was thinking if running a script every second gathering on both nodes:

```
kamctl rpc dlg.stats_active
kamctl rpc dlg.list | grep h_entry | sort  | wc -l
kamctl rpc stats.get_statistics all | grep -e "dialog:active" -e "dialog:early" 
| tr -d " " | tr -d "\n"
```

I will also enable debug logs on `kamailio2` node (has slightly less traffic 
than `kamailio1`) maybe that helps too.

Thank you! I'll report back results tomorrow.



-- 
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/1591#issuecomment-404894491___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

We have another cluster of two kamailio for internal traffic, those are also on 
v5.1.4 but don't have KDMQ enabled yet, and their graphs look perfect. So I'm 
really starting to think this can be DMQ related.


-- 
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/1591#issuecomment-404740630___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

Some screenshots to illustrate what I mean:

![image](https://user-images.githubusercontent.com/16212586/42674283-f2d6c2da-8623-11e8-8df4-cf5b9859efd6.png)

Same graph, with a Y-axe limited to 500:

![image](https://user-images.githubusercontent.com/16212586/42674318-112dc756-8624-11e8-8c06-c2fc345d08cf.png)

Same as above, but shortening the time frame and with Y-limit of 100:

![image](https://user-images.githubusercontent.com/16212586/42674387-586dfa28-8624-11e8-956d-f9b1805883da.png)

I see a type of pattern going further back in time is the following:

- all is working
- something happens (*see below note*)
- dialogs number reported goes to 0 or close to 0 for a bit
- dialogs report the 9223372036854776000
- things start working again?



And, looking in the logs, at the ~time the spikes happen, I can see this in the 
logs:

```
root@kamailio2:~# cat /var/log/kamailio/kamailio.log-20180712 | grep -v NOTICE 
| grep -v "core/tcp_"
...
Jul 12 02:54:24 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'orcr9cRwLT' and tags 'AV-f9MK~v' 
'tetjZeg24aZeS'
Jul 12 02:54:45 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'IRO6Y5Rw53' and tags 'cIaxfaScL' 
'9jBBFcc1NaUNQ'
Jul 12 02:54:48 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'fw3hjesWFN' and tags '-3xLiat-a' 
't1r1KrNrH0BcQ'
Jul 12 02:54:50 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'w1rHrdpK2f' and tags 'HoJgX22ya' 
'4XmtD99FgyyDa'
Jul 12 02:54:58 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'mrnlQ8OYuX' and tags 'yum6HTlKK' 
'766FZ05HaQXmj'
Jul 12 02:55:02 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'lrbwFVn7Q8' and tags 'xOubxsLmV' 
'77Q419N7eHy6N'
Jul 12 02:55:03 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID '14yaUN~xGG' and tags '6nSXFwBSb' 
'mp1U2N57Ncg3p'
Jul 12 02:55:05 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'hgI~lJdBJ3' and tags 'FzXjp4-YJ' 
'a2jt4Hrv1H0cN'
Jul 12 02:55:09 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'oBof16H0~A' and tags 'ZepyE21EK' 
'3ZXHF271aU7pH'
Jul 12 02:55:13 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'XIvos7QACD' and tags 'UPsNWynuM' 
'X3jF108jcX89N'
Jul 12 02:55:13 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'ygaFfVdLn0' and tags '3Qbx8dkvK' 
'0yUyZrX83aSpa'
Jul 12 02:55:18 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'm9G~N0LU9d' and tags 'wQ~cwqKHN' 
'cNp0aHaS0XD4F'
Jul 12 02:55:20 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'OUaCSKP2PZ' and tags 'W2-o~Knwc' 
'epjHQN6yQj91e'
Jul 12 02:55:22 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'wUtsFit9wE' and tags 'CmPHrLXm9' 
'KKpSm5Fv718mD'
Jul 12 02:55:24 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'i5FZlDb2Jt' and tags 'c7AO4enu~' 
'423vDyyBrU4cQ'
Jul 12 02:55:26 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'XLKRf6e5Xq' and tags 'rSTom2iS3' 
'020pQS21HyQUK'
Jul 12 02:55:29 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'nfBiavwuHu' and tags 'P3cHBXiea' 
'NQ2ZBN8BZNSBF'
Jul 12 02:55:31 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID '699iA2AdSO' and tags 'eZSvyxAYC' 
'tj76025mK04Qe'
Jul 12 02:55:31 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'XUuh-7CmGt' and tags 'GyhSzl-c7' 
'r0mNXc4DSerjQ'
Jul 12 02:55:33 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'oMau5CTVYF' and tags '42SPhgBwh' 
'XQeBjgrpNUFpp'
Jul 12 02:55:34 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'l0nKr0oj5c' and tags '2ZzNMM0b8' 
'B6p7a3U8H0c9j'
Jul 12 02:55:35 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'Kl49oLgGHV' and tags 'E5E5P9rFX' 
'NB9ZFyjFN2cvD'
Jul 12 02:55:35 kamailio2 sbc[27795]: WARNING: dialog [dlg_handlers.c:1596]: 
dlg_ontimeout(): timeout for dlg with CallID 'i2lEbuiAFm' and tags 'TDExnc7Bx' 
'Urv4SBvp5gyQQ'
Jul 12 02:55:39 kamailio2 sbc[27795]: WARNING

Re: [sr-dev] [kamailio/kamailio] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

@jchavanton: I will try to have a look 

@miconda: it reports 9223372036854776000  and after X time it goes back to good 
values. (where X can be sometimes on the very next request, sometimes after 
couple minutes, but haven't seen above that). But to your point: yes, it goes 
back to good values by itself.





-- 
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/1591#issuecomment-404660178___
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] RPC command stats.get_statistics randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

I updated the issue as I think this might not be related to KEX module and more 
with DIALOG module. As I'm not sure, I'm not specifying in the topic.

-- 
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/1591#issuecomment-404555603___
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] Problem with IPv6, TLS and advertise param (#1581)

[Joel Serrano]

Cherry-piked this commit into v5.1.4 and so far I can confirm it's working.

I have deployed the fix to prod, I'll report back in a new ticket if something 
fails.

-- 
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/1581#issuecomment-404327086___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] KEx module stats.get_statistics() randomly reporting 9223372036854776000 for current active/early dialogs (#1591)

[Joel Serrano]

### Description

Since we upgraded from v5.0.2 to v5.1.4 we are seeing spikes in our monitoring 
platform regarding current active and early dialogs.

Every 10s we gather metrics using Kamailio's HTTP server:

```
# Statistics endpoint
if ($hu =~ "^/statistics") {
jsonrpc_exec('{"jsonrpc": "2.0","method": 
"stats.get_statistics","params": ["all"],"id": 1}');
xhttp_reply("200", "OK", "application/json", "$jsonrpl(body)");
exit;
}
```

stats.get_statistics has lots of metrics, the problematic ones we have found 
are:

```
"dialog.active_dialogs":  "84",
"dialog.early_dialogs": "16",
```

The issue is that randomly, instead of reporting the real active/early dialogs, 
it will return **9223372036854776000**.

Example:

```
...
"dialog.active_dialogs":  "77",
"dialog.early_dialogs": "9223372036854776000",
...

...
"dialog.active_dialogs":  "9223372036854776000",
"dialog.early_dialogs": "20",
...

...
"dialog.active_dialogs":  "83",
"dialog.early_dialogs": "18",
...

```


### Troubleshooting

I added logging for kamailio to print the value for active-dialogs just to make 
sure it wasn't a problem further down in the pipeline, and I could see that 
same number, so it's definitely coming from Kamailio. Also, on version v5.0.2 
installed from deb repo this did not happen.


 Reproduction

I cannot reproduce on purpose, I see it happen several times a day though.

 Debugging

Please let me know what I can provide to troubleshoot this, I don't know where 
to start, I'm concerned of activating debug logs in prod and waiting for this 
to happen might overload the system, any alternatives? 


### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
# kamailio -v
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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 with gcc 6.3.0
```

* **Operating System**:

```
OS: Debian stretch 9.4

Kernel: Linux kamailio 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) 
x86_64 GNU/Linux
```



-- 
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/1591___
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] Problem with IPv6, TLS and advertise param (#1581)

[Joel Serrano]

Hi, 

I was testing using Linphone SIP library and this is what their logs say:

```
2018-07-03 16:40:59 [INFO] LinphoneCallStack.void linphone_log_handler():91 - 
[org.antlr.runtime.MismatchedTokenException]  reason [1876:1: hexpart : ( 
hexseq | hexseq COLON COLON ( hexseq )? | COLON COLON ( hexseq )? );]
2018-07-03 16:40:59 [INFO] LinphoneCallStack.void linphone_log_handler():91 - 
[org.antlr.runtime.MismatchedTokenException]  reason [1876:1: hexpart : ( 
hexseq | hexseq COLON COLON ( hexseq )? | COLON COLON ( hexseq )? );]
2018-07-03 16:40:59 [INFO] LinphoneCallStack.void linphone_log_handler():91 - 
header_record_route parser error for 
[Record-Route:]
```

Hope it helps.

-- 
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/1581#issuecomment-402324588___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Problem with IPv6, TLS and advertise param (#1581)

[Joel Serrano]

### Description

We want to be able to handle reINVITEs over TLS so calls can reconnect when 
they switch networks (for example from wifi to mobile data). 


We have the following config in kamailio.cfg:

```
listen=tls:1.1.1.1:443 advertise sbc01.domain.com:443
listen=tls:[:::::::]:443 advertise 
sbc01.domain.com:443
listen=udp:1.1.1.1:5060
```
In order to not break TLS validation (certs) we set the advertise to the FQDN 
so all headers are set with the FQDN and not the IP address, also notice no 
`[]` in the FQDN part of advertise IPv6 line. We do this, because we found that 
without the advertise, all headers have the IP address, which is also OK, but 
if the TCP connection breaks and the client reconnects, it will send the 
connection to the top request-route header, if it's an IP, the TLS validation 
will beak because the cn= doesn't match, having the FQDN there, the cn= will 
match and the request will continue.


Example scenario:

* IPv4 call:

Our public domain is `sip.domain.com` that has SRV records pointing to 
`sbc01.domain.com` and `sbc02.domain.com`. For this example let's stick to 
`sbc01.domain.com`.

Kamailio: 1.1.1.1 / sbc01.domain.com
Media server: 2.2.2.2

Client <---TLS 443---> Kamailio <---UDP 5060---> Media server

Example call:

![image](https://user-images.githubusercontent.com/16212586/42248688-cce7915c-7edb-11e8-84e8-f1917a6da7a4.png)


Let's focus on the INVITE that Kamailio sends to the media server (the *blue* 
INVITE in the screenshot)

The headers look like this:

```
INVITE sip:test@2.2.2.2:5060 SIP/2.0
Record-Route: 
Record-Route: 

...
```

Which is correct, if the client has to send a reINVITE, it will do a DNS 
request to sbc01.domain.com and depending if it has  and A records, and 
what the client's current transport is (ipv6/ipv4) it will select and use what 
it needs.

..Now let's say the same scenario, but origin transport is IPv6 this time..

* IPv6 call:

Same scenario as above, same invite, this time the headers look like this:

```
INVITE sip:test@2.2.2.2:5060 SIP/2.0
Record-Route: 
Record-Route: 

```
(notice the FQDN surrounded by `[]`)


 Reproduction

Add the `advertise` option on a `listen=` param with transport tls and using an 
IPv6.

Observe the format of the headers the `record_route()` function adds to the 
request.


### Possible Solutions

When setting a FQDN instead of an IP address (v4/v6) in the `advertise` option; 
never enclose it with `[]` ? It's a suggestion, maybe what I'm saying is 
completely nuts.


### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
# kamailio -v
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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 with gcc 6.3.0
```

* **Operating System**:

```
OS: Debian stretch 9.4

Kernel: Linux kamailio 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) 
x86_64 GNU/Linux
```



-- 
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/1581___
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] Enhancement on phonenum module: add CountryCode (string) (#1576)

[Joel Serrano]

Hi Daniel, 

Just wanted to let you know it works. I tested on master and cherry-picked your 
commit into 5.1 branch and tested there too (it's what we use in prod) and no 
issues so far :)

Thanks 👍 👍 

![image](https://user-images.githubusercontent.com/16212586/42243260-9aa0ede4-7ec5-11e8-90d9-5cd32f948cab.png)


-- 
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/1576#issuecomment-402284078___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Enhancement on phonenum module: add CountryCode (string) (#1576)

[Joel Serrano]

Currently you have the following information available when using 
`phonenum_match(num, pvc)` from the `phonenum` module:

* number - phone number that is matched
* valid - 1 if the matched number has a valid result; 0 otherwise
* normalized - normalized phone number
* cctel - country code for phone number
* ltype - local network type
* ndesc - phone number description
* error - error string if phone number matching fails.

It would be useful to have access also to the `cc` information.

Right now, `cctel` outputs the country code (digits) for the number.

Example: 

+34123456789 --> cctel = 34

The enhancement would be to add the country code (string) for the number (maybe 
in the `cc` position?):

+34123456789 --> cc = ES

Having a look at the phonenum module code (`cphonenumber.cpp`), I understand 
(with my very little idea of C) that country code (string) information is in 
fact used to get the country code (digits). So I think it would be only a 
matter of returning one more key:value:

https://github.com/kamailio/kamailio/blob/master/src/modules/phonenum/cphonenumber.cpp#L138

```
string regionCode;
_phoneUtil.GetRegionCodeForNumber(parsedNumber, ®ionCode);
res->cctel = _phoneUtil.GetCountryCodeForRegion(regionCode);
```

Something like (pseudocode, this obviously doesn't work but gives the idea):

```
string regionCode;
_phoneUtil.GetRegionCodeForNumber(parsedNumber, ®ionCode);
res->cctel = _phoneUtil.GetCountryCodeForRegion(regionCode);
res->cc = regionCode;
```

So then later in kamailio you can do for example:

```xlog("L_INFO", "Call from $phn(src=>cc) to $phn(dst=>cc)\n");```

I have also seen that a function to provide this info exists in the module 
level, but I haven't seen it used anywhere else but the declaration:

https://github.com/kamailio/kamailio/blob/master/src/modules/phonenum/cphonenumber.cpp#L94

This feels like a really easy change and I tried to do it myself, but I didn't 
manage to get through the complete path from "getting the info" to "making it 
available in the pvc" so here I am asking for help.

Thanks!


-- 
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/1576___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Will do Daniel. Thank you for the help.

-- 
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/1172#issuecomment-321552640___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi Daniel, just an update... So far, since we repackaged v5.0.2 compiling with 
libssl1.0 we haven't had a single problem... 

What should we try next to get this fixed with libssl1.1 ?



-- 
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/1172#issuecomment-319242183___
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] cores on stop if TLS is enabled using libssl1.1 ( Debian stretch ) (#1189)

[Joel Serrano]

Can the issue [1172](https://github.com/kamailio/kamailio/issues/1172) be 
related to this?

-- 
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/1189#issuecomment-319241950___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi Daniel, 

Just an update, we have just restarted the SBC with the new Kamailio build 
using OpenSSL v1.0:

```
Jul 25 00:59:09 voicesbc1 sbc[1112]: INFO: tls [tls_init.c:639]: init_tls_h(): 
tls: _init_tls_h:  compiled  with  openssl  version "OpenSSL 1.0.2l  25 May 
2017" (0x100020cf), kerberos support: off, compression: on
```

Now to wait and see if it reproduces. We have 2 SBCs, both 
Debian9+Kamailio5.0.2:

voicesbc1: Kamailio compiled with OpenSSL v1.0
voicesbc2: Kamailio compiled with OpenSSL v1.1

Until now, we have had to restart kamailio every time the issue appeared on 
any/both servers, let's see what happens in the next couple days.


-- 
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/1172#issuecomment-317664494___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi Daniel, just an update... I have done the following:

1 - Download src package for v5.0.2: `# apt-src install kamailio`.
2- Edit the control file: `./kamailio-5.0.2+stretch/debian/control`.
3- In the "Build-Depends" section, replace `libssl-dev` with `libssl1.0-dev`.
4- Build: `dpkg-buildpackage -b`

I checked the resulting TLS module package:

```
# dpkg -I kamailio-tls-modules_5.0.2+stretch_amd64.deb
 new debian package, version 2.0.
 size 362518 bytes: control archive=1025 bytes.
  22 bytes, 1 lines  conffiles
 757 bytes,18 lines  control
 842 bytes,10 lines  md5sums
 Package: kamailio-tls-modules
 Source: kamailio
 Version: 5.0.2+stretch
 Architecture: amd64
 Maintainer: Debian VoIP Team 
 Installed-Size: 995
 Depends: kamailio (= 5.0.2+stretch), libc6 (>= 2.14), libcurl3 (>= 7.16.2), 
libssl1.0.2 (>= 1.0.2d)
 Section: net
 Priority: optional
 Multi-Arch: same
 Homepage: http://www.kamailio.org/
 Description: TLS support for the Kamailio SIP server (authentication, 
transport)
  Kamailio is a very fast and flexible SIP (RFC3261)
  server. Written entirely in C, Kamailio can handle thousands calls
  per second even on low-budget hardware.
  .
  This package provides TLS support for encrypted and authenticated
  SIP connections as well as generic TLS support for many Kamailio modules.
root@debian9build:/opt/kamailio-5.0.2-deb#
```

So it seems it is correctly linked to libssl1.0.2.

I will install this version of Kamailio on one of the SBCs tonight and keep it 
in close observation. I will update here as soon as I have more info.

-- 
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/1172#issuecomment-317508340___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi Daniel, thanks for helping troubleshoot the issue.

I have Kamailio v4.4 with Debian 8 working with TLS on other servers and we 
have had 0 problems (OpenSSL v1.0)

If I install the kamailio 5 nightly deb build from tomorrow, would your latest 
patch be applied? Or should I manually compile from master branch?

Also, for some reason I had a feeling it could be OpenSSL 1.1, Debian 9 seems 
to have OpenSSL 1.0 also:

```
root:~# dpkg -l | grep libssl
ii  libssl1.0.2:amd641.0.2l-2   amd64   
 Secure Sockets Layer toolkit - shared libraries
ii  libssl1.1:amd64  1.1.0f-3   amd64   
 Secure Sockets Layer toolkit - shared libraries
root:~#
```

Can I build Kamailio deb package from the sources, compiling with the ssl v1.0 
version instead of v1.1, and then install that resulting deb package and wait 
and see if the problem reproduces?

Let me know what you think.



-- 
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/1172#issuecomment-312690313___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi, 

It happened again, I checked the captures and this is what is happening during 
the issue:

>From KamailioB to KamailioC/D

1. Kamailio B is sending OPTIONS to KamailioC/D.
2. KamailioC/D are replying 200.
3. Kamailio B is not acting to those 200 and has the nodes DOWN (probably 
because it is in that "hung" state).

At the same time:

>From KamailioC/D to KamailioB

1. KamailioC/D are sending OPTIONS to KamailioB.
2. KamailioB is NOT replying anything.

This time I had to restart Kamailio and it started working right away again.

[backtrace_20170701_2001.tar.gz](https://github.com/kamailio/kamailio/files/1117612/backtrace_20170701_2001.tar.gz)

Sorry for so many posts, but I update this as things happen.

-- 
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/1172#issuecomment-312470108___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi Daniel, 

More information. I'm attaching the log (with debug=2) between the dispatcher 
nodes down & up at the time of the problem.

[kamailio_sbc_2.log.txt](https://github.com/kamailio/kamailio/files/1117574/kamailio_sbc_2.log.txt)


Some extra stuff:

1. There is a gap a little bit after the dispatcher sets the nodes down, until 
a little before the dispatcher sets the nodes up, hope this helps.
2. We use VoIPmonitor and the sensor receives the traffic from a port mirror on 
the switch, in the timeframe of the issue, there is no traffic detected from 
the affected server.
3. We pull performance metrics from Kamailio every 10 seconds using xhttp and 
json-rpc modules, during the issue our tool can't pool metric either:

```
2017-07-01T22:02:15Z E! Error in plugin [inputs.httpjson]: Get 
http://127.0.0.1/statistics: net/http: timeout awaiting response headers 
(Client.Timeout exceeded while awaiting headers)
2017-07-01T22:02:25Z E! Error in plugin [inputs.httpjson]: Get 
http://127.0.0.1/statistics: net/http: request canceled (Client.Timeout 
exceeded while awaiting headers)
2017-07-01T22:02:35Z E! Error in plugin [inputs.httpjson]: Get 
http://127.0.0.1/statistics: net/http: request canceled (Client.Timeout 
exceeded while awaiting headers)
[...]
[...]
[...]
2017-07-01T22:39:25Z E! Error in plugin [inputs.httpjson]: Get 
http://127.0.0.1/statistics: net/http: request canceled (Client.Timeout 
exceeded while awaiting headers)
2017-07-01T22:39:35Z E! Error in plugin [inputs.httpjson]: Get 
http://127.0.0.1/statistics: net/http: request canceled (Client.Timeout 
exceeded while awaiting headers)
2017-07-01T22:39:45Z E! Error in plugin [inputs.httpjson]: Get 
http://127.0.0.1/statistics: net/http: request canceled (Client.Timeout 
exceeded while awaiting headers)
```

I will leave the tcpdumps enabled anyway in case next time it happens we can 
get more or better information.


Joel.




-- 
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/1172#issuecomment-312466536___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi again, unfortunately the tcpdump where only capturing the external side, I 
have restarted tcpdump now capturing internal too so we can see the OPTIONS 
between the servers.

-- 
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/1172#issuecomment-312462955___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi Daniel, 

Today it happened again. I have more information:

We have currently running 4x Debian 9 servers with Kamailio v5:

KamailioA & KamailioB
KamailioC & KamailioD

Servers A/B only take care of SSL offloading and loadbalance/failover between 
servers C/D. (using dispatcher with minimal config)

Flow would be:

User <-> KamailioA/B <-> KamailioC/D <-> ...

Today KamailioB stop replying... and I got the backtraces.

>From KamailioA: 0 problems
>From KamailioB: 

```
root:~/bt2# grep DISPATCHER /var/log/kamailio/kamailio.log
Jul  1 15:03:06 13cn4 sbc[14833]: WARNING: 

Re: [sr-dev] [kamailio/kamailio] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Hi Daniel, 

Here is the output:

```
root:~/bt# kamctl ps | grep -B1 "tcp receiver"
  "PID":  23610,
  "DSC":  "tcp receiver (generic) child=0"
--
  "PID":  23611,
  "DSC":  "tcp receiver (generic) child=1"
--
  "PID":  23612,
  "DSC":  "tcp receiver (generic) child=2"
--
  "PID":  23613,
  "DSC":  "tcp receiver (generic) child=3"
--
  "PID":  23614,
  "DSC":  "tcp receiver (generic) child=4"
--
  "PID":  23615,
  "DSC":  "tcp receiver (generic) child=5"
--
  "PID":  23616,
  "DSC":  "tcp receiver (generic) child=6"
--
  "PID":  23617,
  "DSC":  "tcp receiver (generic) child=7"
root:~/bt#

root:~/bt# gdb /usr/sbin/kamailio -ex "bt full" --batch 23610
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f73f4cbd0d3 in __epoll_wait_nocancel () at 
../sysdeps/unix/syscall-template.S:84
84  ../sysdeps/unix/syscall-template.S: No such file or directory.
#0  0x7f73f4cbd0d3 in __epoll_wait_nocancel () at 
../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x55a667819c13 in io_wait_loop_epoll (h=0x55a667cbee80 , t=2, 
repeat=0) at core/io_wait.h:1034
n = 2
r = 1
fm = 0x7ffddf805cf0
revents = 1734426560
__func__ = "io_wait_loop_epoll"
#2  0x55a66782afd3 in tcp_receive_loop (unix_sock=40) at 
core/tcp_read.c:1789
__func__ = "tcp_receive_loop"
#3  0x55a66770f088 in tcp_init_children () at core/tcp_main.c:4796
r = 0
i = 7
reader_fd_1 = 40
pid = 0
si_desc = "tcp receiver (generic)\000\000\360\\\200\337\375\177", 
'\000' , 
"\320X\200\337\375\177\000\000u\340tg\246U\000\000\201\016\234g\246U\000\000\001\000\000\000\000\000\000\000p\022\230g\000\000\000\000\070\352C\364s\177\000\000\300?ag\246U\000\000\f\372\000s\000\000\000\000\360X\200\337\375\177\000\000\f\372\000s\000\000\000"
si = 0x0
__func__ = "tcp_init_children"
#4  0x55a667620ff7 in main_loop () at main.c:1715
i = 8
pid = 23603
si = 0x0
si_desc = "udp receiver child=7 
sock=[2602:FF37:0:1:0:0:C601:3779]:5060\000\257$\366\200:z\360q\177\000\000\f\372\000s\000\000\000\000\300?ag\246U\000\000\360\\\200\337\375\177",
 '\000' , " Z\200\337\375\177\000\000a\262\200g\246U\000"
nrprocs = 8
woneinit = 1
__func__ = "main_loop"
#5  0x55a667627fb9 in main (argc=13, argv=0x7ffddf805cf8) at main.c:2646
cfg_stream = 0x55a668b42010
c = -1
r = 0
tmp = 0x7ffddf806eb5 ""
tmp_len = -178570608
port = 32627
proto = -545236016
options = 0x55a66796b0e8 
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
ret = -1
seed = 83065607
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0x0
p = 0x 
st = {st_dev = 19, st_ino = 15809, st_nlink = 2, st_mode = 16832, 
st_uid = 109, st_gid = 113, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 
4096, st_blocks = 0, st_atim = {tv_sec = 1498523393, tv_nsec = 31134570}, 
st_mtim = {tv_sec = 1498687722, tv_nsec = 986617235}, st_ctim = {tv_sec = 
1498687722, tv_nsec = 986617235}, __glibc_reserved = {0, 0, 0}}
__func__ = "main"
root:~/bt#

root:~/bt# kamctl ps | grep -B1 "udp receiver"
  "PID":  23586,
  "DSC":  "udp receiver child=0 sock=198.1.55.121:5060"
--
  "PID":  23587,
  "DSC":  "udp receiver child=1 sock=198.1.55.121:5060"
--
  "PID":  23588,
  "DSC":  "udp receiver child=2 sock=198.1.55.121:5060"
--
  "PID":  23589,
  "DSC":  "udp receiver child=3 sock=198.1.55.121:5060"
--
  "PID":  23590,
  "DSC":  "udp receiver child=4 sock=198.1.55.121:5060"
--
  "PID":  23591,
  "DSC":  "udp receiver child=5 sock=198.1.55.121:5060"
--
  "PID":  23592,
  "DSC":  "udp receiver child=6 sock=198.1.55.121:5060"
--
  "PID":  23593,
  "DSC":  "udp receiver child=7 sock=198.1.55.121:5060"
--
  "PID":  23594,
  "DSC":  "udp receiver child=0 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
--
  "PID":  23595,
  "DSC":  "udp receiver child=1 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
--
  "PID":  23596,
  "DSC":  "udp receiver child=2 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
--
  "PID":  23597,
  "DSC":  "udp receiver child=3 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
--
  "PID":  23598,
  "DSC":  "udp receiver child=4 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
--
  "PID":  23599,
  "DSC":  "udp receiver child=5 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
--
  "PID":  23600,
  "DSC":  "udp receiver child=6 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
--
  "PID":  23601,
  "DSC":  "udp receiver child=7 sock=[2602:FF37:0:1:0:0:C601:3779]:5060"
root:~/bt#

root:~/bt# gdb /usr/sbin/kamailio -ex "bt full" --batch 23586
[Thread debugging using libthread_db enabled]
Usi

Re: [sr-dev] [kamailio/kamailio] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

Ok! I'll wait until it happens again. 

Some extra info:

1- Pike is enabled, but we have logging when it blocks something (and no logs 
appeared).
2- CPU is always < 1% usage.
3- I have enabled kernel.core_uses_pid=1. 
4- Our traffic is:

[clients]--> IPv4/IPv6 tls_443 [Kamailio] IPv4 udp_5060 --> IPv4 udp_5060 
[dispatcher setid 4].

If I run the bt full right now to a worker process, should we get random stuff?

Becase right now I'm getting mostly the same on each process:

```
root:~# for i in `kamctl ps | grep PID | awk '{print $2}' | tr -d ","`; do gdb 
/usr/sbin/kamailio -ex "bt full" --batch $i >> $i.txt 2>&1; done
root:~# 

root:~# ls -l
total 140
-rw-r--r-- 1 root root 1769 Jun 29 01:04 23585.txt
-rw-r--r-- 1 root root 3300 Jun 29 01:04 23586.txt
-rw-r--r-- 1 root root 3300 Jun 29 01:04 23587.txt
-rw-r--r-- 1 root root 3301 Jun 29 01:04 23588.txt
-rw-r--r-- 1 root root 3300 Jun 29 01:04 23589.txt
-rw-r--r-- 1 root root 3301 Jun 29 01:04 23590.txt
-rw-r--r-- 1 root root 3300 Jun 29 01:04 23591.txt
-rw-r--r-- 1 root root 3301 Jun 29 01:04 23592.txt
-rw-r--r-- 1 root root 3301 Jun 29 01:04 23593.txt
-rw-r--r-- 1 root root 3432 Jun 29 01:04 23594.txt
-rw-r--r-- 1 root root 3432 Jun 29 01:04 23595.txt
-rw-r--r-- 1 root root 3431 Jun 29 01:04 23596.txt
-rw-r--r-- 1 root root 3432 Jun 29 01:04 23597.txt
-rw-r--r-- 1 root root 3432 Jun 29 01:04 23598.txt
-rw-r--r-- 1 root root 3432 Jun 29 01:04 23599.txt
-rw-r--r-- 1 root root 3432 Jun 29 01:04 23600.txt
-rw-r--r-- 1 root root 3432 Jun 29 01:04 23601.txt
-rw-r--r-- 1 root root 2388 Jun 29 01:04 23602.txt
-rw-r--r-- 1 root root 1836 Jun 29 01:04 23603.txt
-rw-r--r-- 1 root root 2245 Jun 29 01:04 23604.txt
-rw-r--r-- 1 root root 4023 Jun 29 01:04 23605.txt
-rw-r--r-- 1 root root 2950 Jun 29 01:04 23606.txt
-rw-r--r-- 1 root root 2837 Jun 29 01:04 23607.txt
-rw-r--r-- 1 root root 4691 Jun 29 01:04 23608.txt
-rw-r--r-- 1 root root 2740 Jun 29 01:04 23609.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23610.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23611.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23612.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23613.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23614.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23615.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23616.txt
-rw-r--r-- 1 root root 2691 Jun 29 01:04 23617.txt
-rw-r--r-- 1 root root 2151 Jun 29 01:04 23618.txt
root:~#

root:~# grep -n  *
23585.txt:31:p = 0x 
23586.txt:39:p = 0x 
23587.txt:39:p = 0x 
23588.txt:39:p = 0x 
23589.txt:39:p = 0x 
23590.txt:39:p = 0x 
23591.txt:39:p = 0x 
23592.txt:39:p = 0x 
23593.txt:39:p = 0x 
23594.txt:39:p = 0x 
23595.txt:39:p = 0x 
23596.txt:39:p = 0x 
23597.txt:39:p = 0x 
23598.txt:39:p = 0x 
23599.txt:39:p = 0x 
23600.txt:39:p = 0x 
23601.txt:39:p = 0x 
23602.txt:40:p = 0x 
23603.txt:33:p = 0x 
23604.txt:39:p = 0x 
23605.txt:75:p = 0x 
23606.txt:51:p = 0x 
23607.txt:49:p = 0x 
23608.txt:75:p = 0x 
23609.txt:50:p = 0x 
23610.txt:47:p = 0x 
23611.txt:47:p = 0x 
23612.txt:47:p = 0x 
23613.txt:47:p = 0x 
23614.txt:47:p = 0x 
23615.txt:47:p = 0x 
23616.txt:47:p = 0x 
23617.txt:47:p = 0x 
23618.txt:41:p = 0x 
root:~#
```

Am I missing something or am I doing anything wrong 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/1172#issuecomment-311893980___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

In the capture at some point Kamailio stops responding to any request. We have 
Nagios sending OPTIONS requests, when we get the CRITICAL because Kamailio 
doesn't reply, then we manually restart it (so the signal 15 TERM is caused in 
the restart).

We have a dispatcher group with 2 nodes, if both are down, Kamailio should 
reply with a 503.

I can send you the pcap in private, I would have to hide a lot of data to make 
post it here.

Also, I'm pretty sure the problem will reproduce, when it is happening how can 
I get some traces or something useful to send to you before we restart it?



-- 
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/1172#issuecomment-311886954___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

The same problem occurred on the second SBC, I have the packet capture from 
that moment. Please let me know what information you need. 

-- 
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/1172#issuecomment-311835421___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

I'm wondering, is this a kamailio issue or a debian stretch libssl1.1 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/1172#issuecomment-311788848___
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] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

I'm now capturing traffic in case it happens again.

-- 
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/1172#issuecomment-311779093___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Kamailio 5.0.2 suddenly stops processing traffic, then generates a core when restarting. (#1172)

[Joel Serrano]

### Description

Kamailio suddenly stops working (this is a production server so debug logging 
is disabled), when we restart it a core is generated and a segfault is logged.

### Troubleshooting

The only thing I have seen is some reference to IPv6 in the backtrace. But no 
idea where to start looking. I'm pretty sure we will need more information, but 
I don't know how to read or understand backtraces, please let me know what you 
see in it so I can dig deeper into this problem.

 Reproduction

I don't know how to reproduce yet, first I have to understand the cause.

 Debugging Data

Backtrace:
```
[New LWP 12052]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f 
/etc/kamailio/sbc.cfg -'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7efcf3b5df69 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#0  0x7efcf3b5df69 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#1  0x7efcf3b5e234 in OPENSSL_cleanup () from 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#2  0x7efcf7721910 in __run_exit_handlers (status=0, listp=0x7efcf7a855d8 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:83
atfct = 
onfct = 
cxafct = 
f = 
#3  0x7efcf772196a in __GI_exit (status=) at exit.c:105
No locals.
#4  0x55f0a9483d54 in handle_sigs () at main.c:699
chld = 845005216
chld_status = 845005248
any_chld_stopped = 32766
memlog = 0
__func__ = "handle_sigs"
#5  0x55f0a948ea43 in main_loop () at main.c:1758
i = 8
pid = 12091
si = 0x0
si_desc = "udp receiver child=7 
sock=[2602:FF37:0:1:0:0:C601:377A]:5060\000\367v\215\200\262+\363\372~\000\000\025\067\236\003\000\000\000\000\300\017H\251\360U\000\000\340\305]2\376\177",
 '\000' , "\020\303]2\376\177\000\000a\202g\251\360U\000"
nrprocs = 8
woneinit = 1
__func__ = "main_loop"
#6  0x55f0a9494fb9 in main (argc=13, argv=0x7ffe325dc5e8) at main.c:2646
cfg_stream = 0x55f0aa7fb010
c = -1
r = 0
tmp = 0x7ffe325dceb6 ""
tmp_len = -133383536
port = 32508
proto = 845006016
options = 0x55f0a97d80e8 
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
ret = -1
seed = 3679304743
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0x0
p = 0x 
st = {st_dev = 19, st_ino = 14769, st_nlink = 2, st_mode = 16832, 
st_uid = 109, st_gid = 113, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 
4096, st_blocks = 0, st_atim = {tv_sec = 1498523393, tv_nsec = 731915583}, 
st_mtim = {tv_sec = 1498533865, tv_nsec = 274210743}, st_ctim = {tv_sec = 
1498533865, tv_nsec = 274210743}, __glibc_reserved = {0, 0, 0}}
__func__ = "main"
```

Info locals:
```
[New LWP 12052]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f 
/etc/kamailio/sbc.cfg -'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7efcf3b5df69 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
```

List:
```
[New LWP 12052]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f 
/etc/kamailio/sbc.cfg -'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7efcf3b5df69 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
```

 Log Messages

We have regular logging with no issues, then suddenly we get:

```
Jun 28 01:57:51 kam-1 sbc[12075]: WARNING: