Re: [OpenSIPS-Devel] [opensips] SNMP Tables not populated (#669)
The problem is the same with V1.8.5. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/669#issuecomment-151554500___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_json timeout on answer to pua_publish (#657)
Hi, Here is a php code snippet that reproduces the problem very quickly: http://www.ekiga.net/misc/dirty_test.php.txt --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/657#issuecomment-149203151___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_json timeout on answer to pua_publish (#657)
After a while, opensips needs to be restarted, all mi_json operations are concluded by a timeout. Result is: root@golgoth05:~# php dirty_test.php 0: Published OK with etag a.1445258272.3016.1.0 1: Failure (curl): Operation timed out after 2000 milliseconds with 0 bytes received closed --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/657#issuecomment-149222105___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] SNMP Tables not populated (#669)
We have working SNMP support in 2.1: root@golgoth05:~/beip-bx# snmpwalk -v 2c -c beip localhost openserSIPEntityType.0 OPENSER-SIP-COMMON-MIB::openserSIPEntityType.0 = BITS: 38 proxyServer(2) redirectServer(3) registrarServer(4) However, tables remain desperately empty: root@golgoth05:~/beip-bx# snmptable -Ci -v 2c -c beip localhost openserSIPStatusCodesTable OPENSER-SIP-COMMON-MIB::openserSIPStatusCodesTable: No entries root@golgoth05:~/beip-bx# snmptable -Ci -v 2c -c beip localhost openserSIPContactTable SNMP table: OPENSER-SIP-SERVER-MIB::openserSIPContactTable index openserSIPContactDisplayName openserSIPContactURI openserSIPContactLastUpdated openserSIPContactExpiry openserSIPContactPreference 1.1 DefaultUser DefaultUser 0-0-0,0:0:0.0 0-0-0,0:0:0.0 -0.01 root@golgoth05:~/beip-bx# snmptable -Ci -v 2c -c beip localhost openserSIPRegUserTable SNMP table: OPENSER-SIP-SERVER-MIB::openserSIPRegUserTable index openserSIPUserUri openserSIPUserAuthenticationFailures 1 DefaultUser0 --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/669___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] SNMP Tables not populated (#669)
This was tested against V2.1.1. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/669#issuecomment-146564714___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] mi_json timeout on answer to pua_publish (#657)
Hi, Issue #552 was recently fixed, but I fear not all problems are gone. We are experiencing several cases where the json call over http times out with no answer being given after a few seconds. The easiest way to reproduce it is to trigger a PUBLISH to publish some state, then to send a PUBLISH with expires=0. I can reproduce the problem 100% of the time doing so. Looking at the attached opensips.log, you will see that the PUBLISH with expires=0 works, but that there is no answer from mi_json: Sep 28 14:16:48 golgoth05 opensips[3980]: DBG:mi_json:mi_json_run_mi_cmd: got mi_rpl=[0x] Sep 28 14:16:48 golgoth05 opensips[3980]: DBG:mi_json:mi_json_answer_to_connection: got an async reply Then nothing more. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/657___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_json timeout on answer to pua_publish (#657)
Log is here: http://www.ekiga.net/misc/callserver.txt --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/657#issuecomment-143729400___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Fixed counter value when the key is not found. (#562)
This is indeed a far better fix. Thanks ! --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/562#issuecomment-137728743___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_xmlrpc_ng mi_json answer bug with pua_publish (#552)
Hi Bogdan, I see the changes are only done in mi_xmlrpc_ng code files. Does that mean that the equivalent bug in mi_json is still present or does mi_json use the same code ? Thanks, Le mardi 18 août 2015 à 03:47 -0700, Bogdan Andrei IANCU a écrit : Hi @dsandras , Hi @mqandeel - I found the problem and fixed it. The fixes are available not on GIT for all maintained versions. Thank you a lot for your report and support ! — Reply to this email directly or view it on GitHub. -- Damien Sandras dsand...@seconix.com --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/552#issuecomment-132299628___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_xmlrpc_ng mi_json answer bug with pua_publish (#552)
Oh great! Thanks for the clarification! Le mardi 18 août 2015 à 12:30 -0700, Bogdan Andrei IANCU a écrit : @dsandras , both modules were fixed. There is a set of commits for each module. Regards, Bogdan — Reply to this email directly or view it on GitHub. -- Damien Sandras dsand...@seconix.com --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/552#issuecomment-132333489___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_xmlrpc_ng mi_json answer bug with pua_publish (#552)
Hi Bogdan, following @mqandeel, xmlrpc-ng would suffer of the same bug. From my point of view, things could be done in SYNC mode... Thanks for having a look ! --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/552#issuecomment-127944394___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_xmlrpc_ng mi_json answer bug with pua_publish (#552)
Indeed. But I am not sure if it is a bug in mi_json or in the sublayer shared by all mi modules actually. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/552#issuecomment-127948815___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] CacheDB_SQL: Removed harmless ERROR log. (#561)
It is possible that set_dlg_profile has not been called yet when get_dlg_profile is called for a specific key. In that case, the counter value should be set to 0 and we should not report an error because it is perfectly valid. You can view, comment on, or merge this pull request online at: https://github.com/OpenSIPS/opensips/pull/561 -- Commit Summary -- * CacheDB_SQL: Removed harmless ERROR log. -- File Changes -- M modules/cachedb_sql/cachedb_sql.c (6) -- Patch Links -- https://github.com/OpenSIPS/opensips/pull/561.patch https://github.com/OpenSIPS/opensips/pull/561.diff --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/561 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] CacheDB_SQL: Removed harmless ERROR log. (#561)
Closed #561. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/561#event-33178___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] mi_xmlrpc_ng mi_json answer bug with pua_publish (#552)
?php
$extension = 754;
$realm = ds.local.beip.be;
$enable_tcp = true;
$uri = sip:$extension@$realm;
if ($enable_tcp)
$uri .= ';transport=tcp';
$etag = '.';
$id = 754-web;
$status = away;
$extended_status = Belgian Beer Rocks;
$ttl = 3600;
$xml = ?xml version='1.0' encoding='UTF-8'?
presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'
xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'
entity='pres:{{ $extension }}@{{ $realm }}'
tuple{{ if $id }} id='{{ $id }}'{{ /if }}
statusbasicopen/basic/status
contact priority='1'sip:{{ $extension }}@{{ $realm }}/contact
note{{ $extended_status|escape }}/note
/tuple
dm:person id='{{ $id }}-pid'
rpid:activitiesrpid:{{ $status }}//rpid:activi;
$args = array ($uri, $ttl, 'presence', 'application/pidf+xml', $etag, '.',
$xml);
$path = implode ($args, ',');
$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL,
http://127.0.0.1:8011/json/pua_publish?params=; . urlencode
($path));
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_HTTP_VERSION, 1.1);
curl_setopt($ch, CURLOPT_HTTPHEADER, array (Accept: application/json));
curl_setopt($ch, CURLOPT_TIMEOUT, 2);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$s = curl_exec ($ch);
echo $s . ici \n;
curl_close ($ch);
?
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/552#issuecomment-58777___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] mi_xmlrpc_ng mi_json answer bug with pua_publish (#552)
It seems mi_xmlrpc_ng mi_json can not build the XMLRPC or JSON answer when the modules are used together with pua_publish. Jun 11 15:55:45 golgoth05 opensips[31577]: DBG:mi_json:mi_json_answer_to_connection: got an async reply Jun 11 15:55:45 golgoth05 opensips[31577]: DBG:httpd:answer_to_connection: MHD_create_response_from_callback Jun 11 15:55:45 golgoth05 opensips[31577]: ERROR:mi_json:mi_json_flush_data: Unexpected NULL mi handler! This Unexpected NULL mi handler when building the module response to the query happens with both modules. Attached is a script that reproduces the error. The system should probably return a 500 Internal Server error. Please note that when I submit a wrong XML document using mi_json through a command-line telnet, it seems to work. But both XMLRPC and mi_json trigger the bug when being invoked from a PHP script. Perhaps there is a timing issue or something similar. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/552___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] dialog: Update dlg lifetime whe re-evaluating the AVP after the callback... (#431)
No problem... What about 1.11 and master? (I did not check them) Le lundi 20 avril 2015 à 02:23 -0700, Bogdan Andrei IANCU a écrit : Thank you @dsandras , I also updated 1.10 - it suffers from the same problem. — Reply to this email directly or view it on GitHub. -- Damien Sandras dsand...@seconix.com --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/431#issuecomment-94405255___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] Registrar: Add contact-based aliasing when the remote UA supports it. (#446)
If an endpoint supporting TCP connection reuse registers to OpenSIPS, we now create TCP connections aliases for all IP/ports announced by the UA. From my point of view, it is more a fix than a new feature. Without this patch, OpenSIPS will only reuse connections targetted at the IP / ports in the Via, which correspond to the actual currently active connection. But most of the time, the proxy will not use those IP/ports when communicating with the UA. It will instead use the registered IP/ports. We should automatically reuse the active connection for all communications with those IP/ports instead of creating new connections, especially in 1.8 where it is a blocking operation. If the connection can not be reused, then OpenSIPS will create a new one. You can view, comment on, or merge this pull request online at: https://github.com/OpenSIPS/opensips/pull/446 -- Commit Summary -- * Registrar: Add contact-based aliasing when the remote UA supports it. -- File Changes -- M modules/registrar/save.c (13) -- Patch Links -- https://github.com/OpenSIPS/opensips/pull/446.patch https://github.com/OpenSIPS/opensips/pull/446.diff --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/446 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] dialog: Update dlg lifetime whe re-evaluating the AVP after the callback... (#431)
This completes the previous commit. Without this fix, when the SST module is activated and the routines are activated with the appropriate setflag, the calls will be interrupted after the sst timeout even when there is no sst support at all from both peers. You can view, comment on, or merge this pull request online at: https://github.com/OpenSIPS/opensips/pull/431 -- Commit Summary -- * dialog: Update dlg lifetime whe re-evaluating the AVP after the callbacks. -- File Changes -- M modules/dialog/dlg_handlers.c (1) -- Patch Links -- https://github.com/OpenSIPS/opensips/pull/431.patch https://github.com/OpenSIPS/opensips/pull/431.diff --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/431 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Fixed presentity naming. (#20)
@bogdan-iancu, no, it is simply a note. You can put whatever you want over there. This code simply publishes a presence notification when the dialog state changes. Calling is misleading because it is also notified when you receive an incoming call. But basically, you can put everything there. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/20#issuecomment-68342017___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Session Timers reINVITE do not refresh the dialog timeout (#267)
@bogdan-iancu , yes, I confirm it is the right fix! Thanks a lot :) --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/267#issuecomment-49171534___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Session Timers reINVITE do not refresh the dialog timeout (#267)
Closed #267. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/267#event-142183800___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] Session Timers reINVITE do not refresh the dialog timeout (#267)
Reverting this commit fixes the issue: fa0ff03b2e1f6c080119cb82303239336131e9ac With that commit, the reINVITE do not reset the counter. OpenSIPS cuts the call with hint Session Expired. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/267___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Set the dialog lifetime before running the callbacks. (fa0ff03)
Unfortunately, see issue #267 --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/commit/fa0ff03b2e1f6c080119cb82303239336131e9ac#commitcomment-6976033___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
Hi, What is weird is that you commented out instructions that were not present in the original cachedb_sql implementation we provided to you. In other words, the 1.8 backtrace I sent you corresponds to a crash without cdb_dbf.close(cdb_db_handle); cdb_db_handle = 0; Are you sure the correct bug is fixed ? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-42183088___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
And what I do not understand either is that Bogdan closed my pull request that was moving the cdb_db_handle = cdb_dbf.init(db_url) from child_init to mod_init telling that it was not correct because we are using a global connection in that case, but your fix does the same except it does not remove the initialisation from child_init. That means that we start the module with a global connection, then move to a per process connection as soon as possible ? Is that intended ? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-42183648___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
Hi, Understood. I hope it is a safe fix :) It seems to work here too... --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-42187540___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Fixes bug where the pua db elements were deleted too early. (#130)
Thanks ! :) --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/130#issuecomment-41131912___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
Hi Vlad, Do you have a patch to test ? Indeed, my workaround is unsafe. Thank you, Le 16/04/14 11:54, vladpaiu a écrit : Hello, After further talks on IRC, the crash is related to using dialog profiles with cachedb_* persistency. Bug confirmed, working on a fix. Best Regards, Vlad — Reply to this email directly or view it on GitHub https://github.com/OpenSIPS/opensips/issues/197#issuecomment-40581904. Damien SANDRAS *Ekiga Project* http://www.ekiga.org --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-41011397___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
As discussed on IRC, and for the record, the crash is the following: Program terminated with signal 11, Segmentation fault. #0 0x7f1fb645ed41 in db_mysql_raw_query (_h=0x0, _s=0x7f1fb55356c0, _r=0x7fff6994c760) at dbase.c:1004 1004dbase.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x7f1fb645ed41 in db_mysql_raw_query (_h=0x0, _s=0x7f1fb55356c0, _r=0x7fff6994c760) at dbase.c:1004 #1 0x7f1fb53331e0 in dbcache_add (con=0x7f1fb66f20a0, attr=0x7f1fb1d37140, val=1, expires=1397723480, new_val=0x0) at cachedb_db.c:327 #2 0x7f1fb1b19db5 in link_dlg_profile (linker=0x7f1fa096a188, dlg=0x7f1fa09692a8) at dlg_profile.c:692 #3 0x7f1fb1b1a194 in set_dlg_profile (msg=0x0, value=0x7fff6994c890, profile=0x7f1fa09470f8) at dlg_profile.c:751 #4 0x7f1fb1afbcd9 in read_dialog_profiles (b=0x16b2aa6 calls/s#1,751|, l=14, dlg=0x7f1fa09692a8, double_check=0) at dlg_db_handler.c:444 #5 0x7f1fb1afca86 in load_dialog_info_from_db (dlg_hash_size=4096) at dlg_db_handler.c:581 #6 0x7f1fb1afabf6 in init_dlg_db (db_url=0x7f1fb1d36ef0, dlg_hash_size=4096, db_update_period=60) at dlg_db_handler.c:192 #7 0x7f1fb1af6d2f in mod_init () at dialog.c:765 #8 0x00475986 in init_mod (m=0x7f1fb6682d20) at sr_module.c:458 #9 0x004758c2 in init_mod (m=0x7f1fb66830c8) at sr_module.c:453 #10 0x004758c2 in init_mod (m=0x7f1fb6683198) at sr_module.c:453 #11 0x004758c2 in init_mod (m=0x7f1fb6683268) at sr_module.c:453 #12 0x004758c2 in init_mod (m=0x7f1fb6683338) at sr_module.c:453 #13 0x004758c2 in init_mod (m=0x7f1fb6683408) at sr_module.c:453 #14 0x004758c2 in init_mod (m=0x7f1fb66834d8) at sr_module.c:453 #15 0x004758c2 in init_mod (m=0x7f1fb66835a8) at sr_module.c:453 #16 0x00475cb0 in init_modules () at sr_module.c:498 #17 0x0042e522 in main (argc=11, argv=0x7fff6994ce68) at main.c:1503 --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-40582662___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] OpenSIPS: Fixed possible crash in cachedb module. (#206)
This is due to the dialog module mod_init method using the cachedb module methods before child_init has been called. In that case, the SQL handled is still set to NULL. Fixes issue #197. You can merge this Pull Request by running: git pull https://github.com/dsandras/opensips ds-fix-cachedbsql-crash Or you can view, comment on it, or merge it online at: https://github.com/OpenSIPS/opensips/pull/206 -- Commit Summary -- * OpenSIPS: Fixed possible crash in cachedb module. -- File Changes -- M modules/cachedb_sql/cachedb_sql.c (9) -- Patch Links -- https://github.com/OpenSIPS/opensips/pull/206.patch https://github.com/OpenSIPS/opensips/pull/206.diff --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/206 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
Vlad, I have pushed a pull request for master. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-40583570___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
Hi, Would an OpenVPN access be ok ? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-40464426___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
Btw, it is 1.8.4 from the tarball. We have a few patches (which are all available as pull requests), but located in the presence modules. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-40464789___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
This did not happen with 1.8.3. Reproducing the bug is easy: 1) Start a call 2) killall -9 opensips 3) start opensips: it never starts --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
I'll have a look right now for the logs. But: modparam(dialog, db_mode, 1) # REALTIME --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-40074926___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS 1.8.4 can not be started when there are dialogs in the dialogs table (#197)
You can find the log here: http://ekiga.net/misc/callserver.log Not much interesting to see over there. I'm surprised you can not reproduce it because it is 100% reproducable here. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/197#issuecomment-40076122___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Fixes bug where the pua db elements were deleted too early. (#130)
I think this is not the same bug unfortunately. The patch you are refering to is dealing with active_watchers being deleted erroneously from the database. The patch of this pull request is dealing with pua entries being deleted too early from the database. That is the same bug, but with 2 different fixes in 2 different modules. I think my pull request is still valid. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/130#issuecomment-39844969___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] presence_dialoginfo: Fix memory leak in dlginfo_agg_nbody. (#174)
Hi, Yes. However, it seems to me that the probability for those leaks to appear was very weak (only in case of error). The leak was on pres_user not always being freed, which is not possible anymore as it is not dynamically allocated anymore. Le 12/03/14 21:59, Bogdan Andrei IANCU a écrit : Hi @dsandras https://github.com/dsandras , could you also confirm that the applied patch fixes the mem leaks you are aware about ? Thanks and regards, Bogdan — Reply to this email directly or view it on GitHub https://github.com/OpenSIPS/opensips/pull/174#issuecomment-37464157. Damien SANDRAS *Ekiga Project* http://www.ekiga.org --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/174#issuecomment-37644817___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] presence_dialoginfo: Fix memory leak in dlginfo_agg_nbody. (#174)
Hi,
The leak was fixed in my local branch, and I apparently forgot to push it.
Apologies.
About the bound checking error, the code was cutpasted from another place in
the same file where the same error is still present:
Line 165:
/* create the new NOTIFY body */
if ( (pres_user-len + pres_domain-len + 1) MAX_URI_SIZE) {
LM_ERR(entity URI too long, maximum=%d\n, MAX_URI_SIZE);
return NULL;
}
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/174#issuecomment-37311079___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] pua_dialoginfo: failed calls triggers sending PUBLISH errors (#142)
Thanks for fixing this ! --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/142#issuecomment-33565812___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] pua_dialoginfo: failed calls triggers sending PUBLISH errors (#142)
Hi Bogdan, 1) I think it is wise. Actually, the early state of the dialog is notified (180 Ringing, or even, I think 100 Trying). The only state that is not notified is the trying state. This trying state does not correspond to a specific SIP Message or dialog state, but to the fact that pua_dialoginfo_set has been called from the routing script. I think it is preferable in most cases to notify only when there is some kind of SIP message transiting over the network. 2) OK --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/142#issuecomment-30745381___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] pua_dialoginfo: failed calls triggers sending PUBLISH errors (#142)
@ovidiusas : Yes, I meant a response from the remote peer transiting over the network. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/142#issuecomment-30756247___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] pua_dialoginfo: failed calls triggers sending PUBLISH errors (#142)
Hi Bogdan, The main reason why I added that setting in the first place was to workaround the SIP PUBLISH problem in OpenSIPS. We wanted to minimize the number of PUBLISH being sent. For example, when you call a device that is BUSY, you will be notified through a PUBLISH that there was a call attempt, then that the call was finished, instantly. With the unordered PUBLISH problems, the BLF was most of the time stuck in a wrong state. In general, even if that specific problem has been fixed, I think that it is preferable to minimize state changes on servers with many users, and many BLFs, It is probably best to be notified as soon as the call is ringing state, but not before to prevent such rapid state changes. I would keep the option, but I would apply Ovidiu's suggesting : when the publish_on_trying parameter is disabled, we should not try publishing the terminated state. Moreover, the RFC 4235 states: 3.10. Rate of Notifications For reasons of congestion control, it is important that the rate of notifications not be excessive. It is RECOMMENDED that the server not generate notifications for a single subscriber faster than once every 1 second. So I think that trying - terminated instant transitions should be prevented, and that is what the publish_on-trying option is trying to do. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/142#issuecomment-30655605___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] pua_dialoginfo: failed calls triggers sending PUBLISH errors (#142)
Hi Ovidiu, I can change the default value, and adapt the documentation. Please note that the trying state corresponds to dialoginfo_set being called in the dialplan. Not to the remote peer answering with a 100 Trying. However, fixing the bogus error probe seems difficult. I can't see a way in pua_dialoginfo to prevent publishing the terminated state if there was no previous publication (ie if we did not reach the trying state when publish_on_trying is set to 0). There is actually no way to determine the state before the callback is triggered. Do you, or Bogdan, have an implementation suggestion ? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/142#issuecomment-30681836___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] Fixed DLGCB_RESPONSE_WITHIN cb triggering useless confirmed state. (#149)
It triggers the generation of many quot;confirmedquot; state PUBLISH requests (for each response within request), which is incorrect. quot;confirmedquot; state publication should be limited to reINVITE when the nopublish flag is not set and not for everything (like REFER, ...). You can merge this Pull Request by running: git pull https://github.com/dsandras/opensips ds-fix-unneeded-publish Or you can view, comment on it, or merge it online at: https://github.com/OpenSIPS/opensips/pull/149 -- Commit Summary -- * Fixed DLGCB_RESPONSE_WITHIN cb triggering useless quot;confirmedquot; state. -- File Changes -- M modules/pua_dialoginfo/pua_dialoginfo.c (4) -- Patch Links -- https://github.com/OpenSIPS/opensips/pull/149.patch https://github.com/OpenSIPS/opensips/pull/149.diff ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
