8 Jul
2017
8 Jul
'17
12:40 a.m.
### 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
10 Jul
10 Jul
8:27 p.m.
New subject: [kamailio/kamailio] 5.0.* dialogs expiring early (#1182)
Do you use $dlg_ctx(...) or $dlg(...) variables? What other dialog parameters have you set
in config?
--
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#issuecomment-314176681
9:03 p.m.
New subject: [kamailio/kamailio] 5.0.* dialogs expiring early (#1182)
I am not setting any dlg variables in my config, I am only the dialog module to pull
dialog information from the SQL database to figure out which contact to send ACKs and BYEs
to. The only dialog related function I use in my config is to set the dlg flag on the
initial INVITE.
From what I have seen, the timeouts and timestamps in
memory are correct but the ones in the database are very wrong. Kamailio is loading the
timeout from the database in it's timer handlers so it is using the incorrect values.
I am now trying to read contacts from $dlg() variables in place of the SQL database now,
in hopes that disabling the database for dialogs will force Kamailio to use the timeout in
memory rather than the database.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1182#issuecomment-314186526
9:39 p.m.
New subject: [kamailio/kamailio] 5.0.* dialogs expiring early (#1182)
I am now using the $dlg variables without the any database modparams and the
dlg_ontimeout() still occurs at around 95 seconds.
This is the only modparam I have set for dialogs now:
modparam("dialog", "dlg_flag", 1)
Which I call on an INVITE with dlg_setflag(1);
I have tried setting the default_timeout to the default timeout and it changes nothing.
modparam("dialog", "default_timeout", 43200)
--
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#issuecomment-314196856
11 Jul
11 Jul
12:48 p.m.
New subject: [kamailio/kamailio] 5.0.* dialogs expiring early (#1182)
Reading again properly, I noticed now that the state is 3, as you questioned.
In this state, the lifetime of dialog is not yet in effect. If the ACK doesn't come in
60sec from the 200ok, then the lifetime is set to 10sec. Depending on the timer step, the
actual duration can vary a bit, because all these checks are done on timer.
In a similar situation, if the dialog is not answered in 300sec from initiation, it is
destroyed.
The dialog timeout (lifetime) as configured via mod param is used after the ACK is
routed.
Maybe these values should be make params, in this way people will become more aware of
them.
Now, back to your need -- why do you need dialog to route ACK and BYE, aren't the
Contact and Record-Route headers enough? Or they are messed up by some nodes in the path
(e.g., sbc, alg)?
--
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#issuecomment-314393002
6:06 p.m.
New subject: [kamailio/kamailio] 5.0.* dialogs expiring early (#1182)
Using dlg_manage() on my ACK caused the dialog state to be updated to 4, and my dialogs
are no longer timing out early!
The timeout column in my SQL database now contains the correct unix epoch as well, is it
intended to be much less than the start_time when the dialog state is 3? I guess it
isn't really used if the ACK has not arrived.
---------------------
I am not using record-route headers; I think I had some trouble with the PBX preferring
them over the contact header which resulted in lost packets. I will look at them again in
the next stage of development, now that everything is working well enough as is.
My architecture relies heavily on an identifier in the URIs and contacts, this identifier
is used to forward SIP to registered contacts associated with many PBXs contained behind
NAT on physical hosts.
It just so happens that for in-dialog SIP like ACK/PRACK/UPDATE/BYE there are no headers
which contain this identifier when sent from the user's device. So for those I have to
resort to using the contact stored in the dialog variables.
--
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#issuecomment-314474454
12 Jul
12 Jul
2:49 p.m.
New subject: [kamailio/kamailio] 5.0.* dialogs expiring early (#1182)
Closed #1182.
--
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#event-1160569580
2:49 p.m.
New subject: [kamailio/kamailio] 5.0.* dialogs expiring early (#1182)
If you want to do your own management for routing of requests within dialog, then up to
you. Check also the htable module, could be an alternative for storing data based on
Call-ID, but dialog should be fine.
I am closing this item, as dialog relies on SIP specs for internal states. I will have in
mind to add those timeouts for no-ACK and early dialogs as mod parameters.
--
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#issuecomment-314745581
2694
days inactive
2699
days old
7 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Jared Hull