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/li
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
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
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/listinf
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
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/c
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 PUBLI
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
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
---
Reply to t
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 proble
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
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___
It can happen that a counter value is queried before it has been set. In
that case, we should assume a default value of 0.
A typical use case is the dialog module where we could call
get_dialog_profile for a specific key before set_dialog_profile has been
called for that key. There should be no er
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
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:
http
open
sip:{{ $extension }}@{{ $realm }}
{{ $extended_status|escape }}
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_s
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
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 Sand
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 t
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 thi
@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
@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.
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
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.o
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_
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://li
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 r
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 correc
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
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,
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/
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
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
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___
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/lis
Vlad,
Could you reproduce it ?
It is 100% repeatable here. Make a call (we have 2 legs, so it means 2 calls),
then kill opensips, and restart it.
Something different between your test and mine is that we are using profiles
(set_dlg_profile).
That might be the culprit. I seem to remember a few
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
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.ope
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 mailin
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 diffe
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,
The leak was fixed in my local branch, and I apparently forgot to push it.
Apologies.
About the bound checking error, the code was cut&pasted from another place in
the same file where the same error is still present:
Line 165:
/* create the new NOTIFY body */
if ( (pres_user->l
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
@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.opensip
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
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
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 a
It triggers the generation of many "confirmed" state PUBLISH requests
(for each response within request), which is incorrect. "confirmed"
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 b
48 matches
Mail list logo
