### Description
No matter what I set the dialog timeout to, the time between INVITE/ACK and timout and the timeout in the dialog db changed at random. It seems to be between 1 and 3 minutes.
94 seconds between the INVITE/ACK and dialog timeout in this case
Jul 7 21:09:28 dev-dallas-sip2-int /usr/sbin/kamailio[30347]: INFO: <script>: RELAYING INVITE to 999999@207.91.156.195:5060 (999999e100a1 -> 102)
Jul 7 21:11:02 dev-dallas-sip2-int /usr/sbin/kamailio[30353]: WARNING: dialog [dlg_handlers.c:1577]: dlg_ontimeout(): timeout for dlg with CallID '0_373726168(a)192.168.1.60' and tags '3498684614' '983bb3d4-38fe-4d47-8d73-c57b85e757d3'
In the database for this dialog, this looks very strange.
start_time 1499461769
timeout 1409235713
### Troubleshooting
I tried to use keep alive in the dialog with ka_timer and ka_interval, I do see the OPTIONS and 200 OK flowing between the two devices and kamailio. This does not prevent the dialog from timing out though.
#### Reproduction
I am just setting the dialog flag on the initial INVITE and let Kamailio do it's thing with the dialog.
modparam("dialog", "db_mode", 1)
modparam("dialog", "default_timeout", 43200) # this should be the default as per kamailio documentation
### Additional Information
* **Kamailio Version**:
```
version: kamailio 5.0.2 (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 on 14:05:03 Jun 14 2017 with gcc 4.8.5
```
* **Operating System**:
```
3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 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/1182
Recently playing with jsonrpcs I found an issue with core.sockets_list and core.aliases_list commands called via jsonrpc_dispatch.
The problem for the first is that the socket's list is that the JSON produced is like
{
"jsonrpc": "2.0",
"result": {
"socket": {
"proto": "udp",
"address": "XX.XX.XX.XX",
"ipaddress": "XX.XX.XX.XX",
"port": "5060",
"mcast": "no",
"mhomed": "no"
},
"socket": {
"proto": "udp",
"address": "XX.XX.XX.XX",
"ipaddress": "XX.XX.XX.XX",
"port": "5060",
"mcast": "no",
"mhomed": "no"
},
....
},
"id": 1
}
While this is a valid JSON document, the fact that the "socket" key is defined several time in the same object makes many parsers not to properly parse it and only keep the last value.
Solution for this is to set the RET_ARRAY flag for the rpc command core.sockets_list reply so that the jsonrpcs module will create an array for the sockets instead on an object.
Similar issue for the aliases list returned by the core.aliases_list command: in this case the proposed solution is to add an "aliases" array to the rpc reply.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1185
-- Commit Summary --
* core: set RET_ARRAY flag for core.sockets_list command
* core: return aliases list as an array in core.aliases_list
-- File Changes --
M src/core/core_cmd.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1185.patchhttps://github.com/kamailio/kamailio/pull/1185.diff
--
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/pull/1185