Hi,
Don't know how much it is important but it's worth looking at it.
Regarding the following block (modparam.c around line 88):
```
if (param->type&USE_FUNC_PARAM) {
n = ((param_func_t)(param->param_pointer))(type, val );
if (n<0)
return -4;
} else {
swit
@bogdan-iancu Yes, this is what I meant. Also, if restart_fr_on_each_reply is
disabled, why the timer should be restarted if a 183 is received after a 100?
Once we received the 100 reply, we assume the next hop will attempt to reach
the called party (or fail to) and therefore the timer should no
Hi,
We just set the restart_fr_on_each_reply parameter to 0 so that fr_inv_timer is
not restarted when provisional replies are received but we got the following
issue.
The SIP flow was:
```
10:56:37.203070 |---INVITE sip:+27137445208@196.25.241.86
SIP/2.0--->|
10:56:37.43
Hi,
I just found it was caused by an error while importing public changes.
The DLG_FLAG_NEW dialog flag was saved in the database. Therefore, it was
fetched during dialogs loading and the timer process tried to insert it again
in the database and because the dlg_id column was not set as the pri
Closed #311.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/311#event-162398896___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Hi,
We recently encountered a weird issue that corrupted the dialog table of our
servers after an instance had no more shared memory.
The different memory errors that appeared in the logs:
```
xxx[6439]: WARNING:core:fm_malloc: Not enough free memory, will attempt
defragmentation.
xxx[
Hi Liviu,
I think your argumentation is right, we will think about using one dialog table
per instance so that we never encounter this issue.
Regards,
Mickael
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/306#issuecomment-53040535
Closed #306.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/306#event-155986444___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Hi Liviu,
This is the architecture we use for a long time.
We have N OpenSIPS instances that share the same dialog table. Traffic is load
balanced over the instances. I agree that dialogs are exclusive to each
instance (a dialog that doesn't belong to an instance would be ignored by this
insta
Hi,
In function update_dialog_dbinfo (see dlg_db_handler.c), the dlg_id is not set
before issuing the UPDATE statement. The type is set to DB_BIGINT using the
VAL_TYPE macro, but the value is not set.
} else if (cell->flags & DLG_FLAG_VP_CHANGED) {
VAL_TYPE(values) = DB_BIGINT;
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/307___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Hi,
After the dialog table schema has been changed to replace the hash_entry and
hash_id columns by the new dlg_id column, the dlg_id column is now the primary
key of the table (while only an index - non UNIQUE - was defined before for the
(hash_entry,hash_id) columns).
With a configuration wh
Hi,
In the load_dialog_info_from_db function (dlg_db_handler.c), the following
block may be problematic:
dlg->h_id = hash_id;
next_id = d_table->entries[dlg->h_entry].next_id;
d_table->entries[dlg->h_entry].next_id = (next_id < dlg->h_id) ? (dlg->h_id +
1) : next_id;
At startup, assume d_table
13 matches
Mail list logo
