date:20160111

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

2016-01-11 Thread Bogdan Andrei IANCU

> @@ -1365,7 +1377,7 @@ static struct mi_root* ds_mi_list(struct mi_root* 
> cmd_tree, void* param)
>   9, part_it->name.s, part_it->name.len);
>  
>   if (part_node == NULL
> - || ds_print_mi_list(part_node, part_it) < 0) {
> + || ds_print_mi_list(part_node, part_it, explicit) < 0) {

as third param of ds_print_mi_list() is a bitmask, use here the predefined 
flags as macro (see the other comment). Maybe "explicit" is not the best name - 
better use a "flag" variable to collect through the code all the flags you want 
to pass to ds_print_mi_list(). 

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/748/files#r49302430___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

2016-01-11 Thread Bogdan Andrei IANCU

> @@ -2110,6 +2123,27 @@ int ds_print_mi_list(struct mi_node* rpl, 
> ds_partition_t *partition)
>   if(node1 == NULL)
>   goto error;
>   }
> +
> + if (flags & 1) {

Please define the flag "1" as a macro with the meaning of "full listing"

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/748/files#r49302225___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

2016-01-11 Thread Liviu Chircu

`-DDBG_QM_MALLOC` was restructured (see 
https://github.com/OpenSIPS/opensips/pull/736), so it does not have any impact 
anymore on master.

In short, each of the 3 current stable allocators now has its debugging 
version, available through `-DDBG_MALLOC`. Readability of the entire fragment 
dump was improved as well.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/743#issuecomment-170502718___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] No 100 Trying reply generated by the t_relay() for INVITE after t_newrean() [was: "Early cancel" issue..]

2016-01-11 Thread Maxim Sobolev

Hi Bogdan, please drop me a note if possible when you merge that patch
into public branch[es], I'll adjust my test case to verify that
accordingly.

On the second issue, it basically about handling of INVITE
transactions in the tm module. The issue is that given unique, new
INVITE transaction those two pieces of routing code would behave
differently as viewed by the remote UAC:

[---routing 1---]
## shield us against retransmits
if (!t_newtran()) {
sl_reply_error();
exit;
};

t_relay("udp:X.Y.Z.W:5060");
[---end routing 1---]

[---routing 2---]
t_relay("udp:X.Y.Z.W:5060");
[---end routing 2---]

The first one won't generate "100 Trying", while the second would. I
don't think the "udp:X.Y.Z.W:5060" is of any importantce, it would
probably be the same with just bare t_relay(), but that's what I've
been testing with. I had to add the following workaround to get it
working properly:

  if (!t_newtran()) {
  sl_reply_error();
  exit;
  };
 + if (method == "INVITE") {
 +   t_reply("100", "Trying");
 + };

I don't think this is intended behavior. The easy fix would be to
patch the t_relay(), but in fact I think 100 Trying should be
generated by the t_newtran() in that case. This would cause UAC to
stop retransmits and let opensips to work on the reply in peace.

On Mon, Jan 11, 2016 at 3:27 AM, Bogdan-Andrei Iancu
 wrote:
> Hi Maxim,
>
> A Happy New Year to you too ! Sorry for the slow reply, many things to catch
> up with.
>
> So, I understand the original problem (retransmissions and cancelling for
> slowly answered invites) is solved by the patch I sent you. Hoping the are
> no side effects on this change, I can start scheduling it to be pushed to
> the public repo as fix to the maintained opensips versions.
>
> On the second issue (with the 100 Trying), I'm not sure I understand the
> problem : there is a mentioning of a bogus 100 Trying and also a work around
> of forcing the 100 Trying from script.
> Could you please detail a bit the actual bug ?
>
> Thanks and regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 29.12.2015 08:01, Maxim Sobolev wrote:
>>
>> Hi Bogdan, happy holidays for you and OpenSIPS team! So, what's the
>> next step to get those early CANCEL changes merged? Basic testing
>> seems to be confirming its functionality. I'd also like to get your
>> opinion on the 100 Trying generation when t_newtran() is used. Thanks!
>>
>> On Wed, Dec 23, 2015 at 7:07 AM, Maxim Sobolev 
>> wrote:
>>>
>>> OK, further investigation revealed that the lack of the provisional
>>> reply is caused by the usage of the t_newtran() in our routing script,
>>> which then causes different code path in the t_relay(), i.e.
>>> t_forward_nonack() function is used instead of t_relay_to(). Which
>>> appears to be triggering a separate bug in the OpenSIPS that affects
>>> all releases out there. We use t_newtran() to  make sure each request
>>> is processed only once, otherwise each re transmit would cause
>>> separate request to the rtpproxy to be generated. I think the fix
>>> would be to extend t_forward_nonack() to properly generate 100 Trying.
>>>
>>> Just in case, our routing script looks like the following:
>>>
>>> ==
>>>  ## shield us against retransmits
>>>  if (!t_newtran()) {
>>>  sl_reply_error();
>>>  exit;
>>>  };
>>>
>>>  if (method == "INVITE") {
>>>  if (rtpproxy_offer("r")) {
>>>  t_on_reply("1");
>>>  t_on_failure("1");
>>>  };
>>>  };
>>>
>>>  if (method == "BYE") {
>>>  unforce_rtp_proxy();
>>>  };
>>>
>>>  record_route();
>>>
>>>  if (loose_route()) {
>>>  t_relay();
>>>  exit;
>>>  };
>>>
>>>  if (src_ip == "127.0.0.1" && src_port == 5061) {
>>>  t_relay("udp:127.0.0.1:5062");
>>>  } else {
>>>  t_relay("udp:127.0.0.1:5061");
>>>  };
>>> ==
>>>
>>> Please note that Kamailio does not have neither issue with early
>>> CANCEL + lost 100, nor this issue. For now I've resolved it by adding
>>> explicit t_reply("100", "Trying").
>>>
>>> On the positive note, you patch seems to be working, thanks. Let me
>>> know if you want me to open issue wrt that t_newtran's 100 Trying
>>> problem.
>>>
>>>
>>> https://github.com/sippy/voiptests/commit/11a6bc6bee1ddfc83eb4acf784ce7aebf8e6815b
>>>
>>> On Wed, Dec 23, 2015 at 5:05 AM, Maxim Sobolev 
>>> wrote:

 Sorry, Bogdan, please disregard my previous message. After closer look
 at the log it seems that my initial diagnosis was not quite correct.
 The problem appears that provisional response generation is broken
 somehow, so that the originating UA keeps sending INVITEs over and
 over again and could not initiate outbound CANCEL at all until 180
 comes in.

[OpenSIPS-Devel] YUM repository downtime

2016-01-11 Thread Nick Altmann

Hello everyone!

Jan 12-13, the YUM repository (yum.opensips.org) will be down due to
maintenance.

--
Nick
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2016-01-11 Thread Bogdan-Andrei Iancu


Hi Maxim,

A Happy New Year to you too ! Sorry for the slow reply, many things to 
catch up with.


So, I understand the original problem (retransmissions and cancelling 
for slowly answered invites) is solved by the patch I sent you. Hoping 
the are no side effects on this change, I can start scheduling it to be 
pushed to the public repo as fix to the maintained opensips versions.


On the second issue (with the 100 Trying), I'm not sure I understand the 
problem : there is a mentioning of a bogus 100 Trying and also a work 
around of forcing the 100 Trying from script.

Could you please detail a bit the actual bug ?

Thanks and regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 29.12.2015 08:01, Maxim Sobolev wrote:

Hi Bogdan, happy holidays for you and OpenSIPS team! So, what's the
next step to get those early CANCEL changes merged? Basic testing
seems to be confirming its functionality. I'd also like to get your
opinion on the 100 Trying generation when t_newtran() is used. Thanks!

On Wed, Dec 23, 2015 at 7:07 AM, Maxim Sobolev  wrote:

OK, further investigation revealed that the lack of the provisional
reply is caused by the usage of the t_newtran() in our routing script,
which then causes different code path in the t_relay(), i.e.
t_forward_nonack() function is used instead of t_relay_to(). Which
appears to be triggering a separate bug in the OpenSIPS that affects
all releases out there. We use t_newtran() to  make sure each request
is processed only once, otherwise each re transmit would cause
separate request to the rtpproxy to be generated. I think the fix
would be to extend t_forward_nonack() to properly generate 100 Trying.

Just in case, our routing script looks like the following:

==
 ## shield us against retransmits
 if (!t_newtran()) {
 sl_reply_error();
 exit;
 };

 if (method == "INVITE") {
 if (rtpproxy_offer("r")) {
 t_on_reply("1");
 t_on_failure("1");
 };
 };

 if (method == "BYE") {
 unforce_rtp_proxy();
 };

 record_route();

 if (loose_route()) {
 t_relay();
 exit;
 };

 if (src_ip == "127.0.0.1" && src_port == 5061) {
 t_relay("udp:127.0.0.1:5062");
 } else {
 t_relay("udp:127.0.0.1:5061");
 };
==

Please note that Kamailio does not have neither issue with early
CANCEL + lost 100, nor this issue. For now I've resolved it by adding
explicit t_reply("100", "Trying").

On the positive note, you patch seems to be working, thanks. Let me
know if you want me to open issue wrt that t_newtran's 100 Trying
problem.

https://github.com/sippy/voiptests/commit/11a6bc6bee1ddfc83eb4acf784ce7aebf8e6815b

On Wed, Dec 23, 2015 at 5:05 AM, Maxim Sobolev  wrote:

Sorry, Bogdan, please disregard my previous message. After closer look
at the log it seems that my initial diagnosis was not quite correct.
The problem appears that provisional response generation is broken
somehow, so that the originating UA keeps sending INVITEs over and
over again and could not initiate outbound CANCEL at all until 180
comes in.

00:00:07.297/GLOBAL/alice_ua: RECEIVED message from 127.0.0.1:5060:
SIP/2.0 180 Ringing

I am investigating as to what could be a problem, looks like this
condition might have been hidden and just exposed now. It seems that
it has nothing to do with the change in question.

On Wed, Dec 23, 2015 at 4:20 AM, Maxim Sobolev  wrote:

Hi Bogdan, that patch is not fully functional. Yes, it did restore
INVITE re-transmits, so that the second 100 Trying is stimulated
properly, but the CANCEL to the egress call leg is not generated until
180 Ringing response comes in. You can see full log here:

https://s3.amazonaws.com/archive.travis-ci.org/jobs/98496601/log.txt

See Call-ID: a0f27d0745c1a6b52348900c67362be8@172.17.0.79 for an example:


On Mon, Dec 14, 2015 at 5:31 PM, Bogdan-Andrei Iancu
 wrote:

Maxim,

Please check the attached patch for 1.11

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 14.12.2015 22:46, Maxim Sobolev wrote:

Thanks Bogdan, I will be working on test case this week. I'll drop you
a note when it's ready.

On Fri, Dec 11, 2015 at 8:42 AM, Bogdan-Andrei Iancu
 wrote:

Roger that, thanks for the detailed explanations - let's be consistent in
handling the INVITE cancelling, in terms of letting all the time the
final
UAS to generate the final reply (if still alive).

Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com





--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com

[OpenSIPS-Devel] [opensips] opensips crashes (#749)

2016-01-11 Thread Artem Chalkov

Hello!
I use opensips 211:

version: opensips 211 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, 
FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select
git revision: 1535a27
mainc compiled on 19:34:45 Nov 27 2015 with gcc 482

opensips sometimes crashes
Output of core's bt full:

#0  0x7f1868f545d7 in raise () from /lib64/libcso6
No symbol table info available
#1  0x7f1868f55cc8 in abort () from /lib64/libcso6
No symbol table info available
#2  0x0048cf2d in sig_alarm_abort (signo=) at mainc:395
__FUNCTION__ = "sig_alarm_abort"
#3  
No symbol table info available
#4  0x7f1868ffa4f7 in sched_yield () from /lib64/libcso6
No symbol table info available
#5  0x7f184f9dad19 in get_lock (lock=) at //fastlockh:180
i = 0
#6  _lock (s=) at lockh:100
No locals
#7  set_timer (new_tl=new_tl@entry=0x7f17d43ca128, 
list_id=list_id@entry=RT_T1_TO_1, ext_timeout=ext_timeout@entry=0x0) at 
timerc:899
timeout = 50
list = 0x7f17cee3d510
ext_timeout = 0x0
list_id = RT_T1_TO_1
new_tl = 0x7f17d43ca128
#8  0x7f184f9af7db in _set_fr_retr (retr=, 
rb=0x7f17d43ca0e0) at t_funcsh:137
timer = 4935813
#9  start_retr (rb=0x7f17d43ca0e0) at t_funcsh:151
No locals
#10 t_uac (method=method@entry=0x7fffa9e2e6e0, 
headers=headers@entry=0x7f1859d1eb68, body=body@entry=0x7f1859d1f680, 
dialog=, cb=cb@entry=0x0, cbp=cbp@entry=0x6e, 
release_func=release_func@entry=0x0) at uacc:480
to_su = {s = {sa_family = 2, sa_data = 
"\023\304QXV\v\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 
50195, sin_addr = {s_addr = 190208081}, sin_zero = 
"\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2,
sin6_port = 50195, sin6_flowinfo = 190208081, sin6_addr = {__in6_u 
= {__u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 
0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}
new_to_su = {s = {sa_family = 21168, sa_data = 
",Q\030\177\000\000\000\232\253\023PuR\f"}, sin = {sin_family = 21168, sin_port 
= 20780, sin_addr = {s_addr = 32536}, sin_zero = "\000\232\253\023PuR\f"}, sin6 
= {
sin6_family = 21168, sin6_port = 20780, sin6_flowinfo = 32536, 
sin6_addr = {__in6_u = {__u6_addr8 = 
"\000\232\253\023PuR\f\320R,Q\030\177\000", __u6_addr16 = {39424, 5035, 30032, 
3154, 21200, 20780, 32536, 0},
__u6_addr32 = {330013184, 206730576, 1361859280, 32536}}}, 
sin6_scope_id = 2850219744}}
new_cell = 0x7f17d43c9f08
backup_cell = 
request = 0x7f17d43ca0e0
req = 0x7f184fc00f40 
backup = 
buf = 
buf1 = 
buf_len = 997
buf_len1 = 997
ret = -1
flags = 
sflag_bk = 
backup_route_type = 
sip_msg_len = 6008
new_send_sock = 
h_to = {
  s = 0x7f17d4101be1 "To: sip:call3@mleasingmangosipru\r\nFrom: 
;tag=1ed2349c918d0a9e231a1e5e84c35f23-388e\r\nCSeq:
 10 PUBLISH\r\nCall-ID: 44bbb9067500408c-7331@1921683059\r\nMax-Forwards: 
70\r\n", len = 36}
h_from = {
  s = 0x7f17d4101c05 "From: 
;tag=1ed2349c918d0a9e231a1e5e84c35f23-388e\r\nCSeq:
 10 PUBLISH\r\nCall-ID: 44bbb9067500408c-7331@1921683059\r\nMax-Forwards: 
70\r\nContent-Length: 526\r\nUser-Agent: Man", len = 82}
h_cseq = {
  s = 0x7f17d4101c57 "CSeq: 10 PUBLISH\r\nCall-ID: 
44bbb9067500408c-7331@1921683059\r\nMax-Forwards: 70\r\nContent-Length: 
526\r\nUser-Agent: Mango SIP\r\nEvent: dialog\r\nExpires: 0\r\nSIP-If-Match: 
a145247400474364347671\r\nConte", len = 8}
h_callid = {
  s = 0x7f17d4101c69 "Call-ID: 
44bbb9067500408c-7331@1921683059\r\nMax-Forwards: 70\r\nContent-Length: 
526\r\nUser-Agent: Mango SIP\r\nEvent: dialog\r\nExpires: 0\r\nSIP-If-Match: 
a145247400474364347671\r\nContent-Type: applicati", len = 46}
proxy = 0x7f1859af01d8
new_proxy = 
dst_changed = 
__FUNCTION__ = "t_uac"
#11 0x7f184f9b0dc1 in request (m=0x7fffa9e2e6e0, ruri=0x7fffa9e2ebf8, 
to=0x7fffa9e2ebf8, from=0x7fffa9e2ebf8, h=0x7f1859d1eb68, b=0x7f1859d1f680, 
oburi=0x7fffa9e2eaf0, cb=0x0, cbp=0x6e, release_func=0x0) at uacc:584



---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/749___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [OpenSIPS/opensips] b32a14: [proto_hep]correctly calculate length when sending

2016-01-11 Thread ionutrazvanionita

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b32a14e6536e4a651eb9fcc0d26dcf034a8b8cda
  
https://github.com/OpenSIPS/opensips/commit/b32a14e6536e4a651eb9fcc0d26dcf034a8b8cda
  Author: ionutrazvanionita 
  Date:   2016-01-11 (Mon, 11 Jan 2016)

  Changed paths:
M modules/proto_hep/hep.c

  Log Message:
  ---
  [proto_hep]correctly calculate length when sending


___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

2016-01-11 Thread Eric Tamme

Hey Raz,

I repeated my previous test: open few tabs, close them, repeat. but I dumped 
the statistics, and did a list_tcp_conns between each test.  All the tcp conns 
seem to tear down properly, but pkg memory use does grow over time.  As you can 
see by the connection number in my gist, I had to open 144 connections to get 
it to fail this time, but i could see the pkg mem increasing across several 
processes each time i did a fifo getstatists.

Here is the gist: https://gist.github.com/etamme/f2a1c3da0706e1d4ee8c

I had a single tab open with a single wss registration, I dumped the stats and 
did a list_tcp_cons, then I opened a new tab which failed to handshake because 
the pid ran out of memory.



---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/743#issuecomment-170620431___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] Proposed fix for erratic nat_traversal keepalives (#751)

2016-01-11 Thread aerringer

Earlier, one process handled nat_traversal timeouts, so static
iteration counter correctly distributed keepalives across timeout
interval.

Now timeouts are sent to various processes, each of which had its own
counter, resulting in erratic keepalive delivery.

Fix moves the iteration counter into shared memory.

LMK if there is a more preferred way to contribute changes.
You can view, comment on, or merge this pull request online at:

  https://github.com/OpenSIPS/opensips/pull/751

-- Commit Summary --

  * Create shm based iteration counter
  * Merge remote-tracking branch 'OpenSIPS/master'

-- File Changes --

M modules/nat_traversal/nat_traversal.c (59)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/751.patch
https://github.com/OpenSIPS/opensips/pull/751.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/751
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

2016-01-11 Thread Răzvan Crainea

Hi, Eric!

I see a lot of memory used by the structures that store the connections. Could 
you try to list all connections just before running out of memory and let me 
know how many active connections you have? You can use `opensipsctl fifo 
list_tcp_conns`.

 Also, how many children are you using?

Thanks,
Răzvan

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/743#issuecomment-170602049___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

2016-01-11 Thread Eric Tamme

I am only using 2 children.  

I will try to get it to run out of memory again and see how many active 
connections there are.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/743#issuecomment-170602506___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [OpenSIPS/opensips] f47178: dispatcher: add ds_list full mi command, update do...

2016-01-11 Thread Bogdan Andrei IANCU

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: f471785b3e75925d78b6bda63c1ee1d704fc93c7
  
https://github.com/OpenSIPS/opensips/commit/f471785b3e75925d78b6bda63c1ee1d704fc93c7
  Author: Cerghit Ionel 
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
M modules/dispatcher/README
M modules/dispatcher/dispatch.c
M modules/dispatcher/dispatch.h
M modules/dispatcher/dispatcher.c
M modules/dispatcher/doc/dispatcher_admin.xml
M modules/dispatcher/doc/dispatcher_faq.xml

  Log Message:
  ---
  dispatcher: add ds_list full mi command, update documentation

optional parameter 'full' added for ds_list full, which will display
the weight, priority and description of a destination
role of weight and priority briefly explained in documentation, FAQ section


  Commit: 829bd4774edac33cba5f0fb06271f3a51ffa10b8
  
https://github.com/OpenSIPS/opensips/commit/829bd4774edac33cba5f0fb06271f3a51ffa10b8
  Author: Cerghit Ionel 
  Date:   2016-01-11 (Mon, 11 Jan 2016)

  Changed paths:
M modules/dispatcher/dispatch.c
M modules/dispatcher/dispatch.h
M modules/dispatcher/dispatcher.c

  Log Message:
  ---
  dispatcher: reworked ds_print_mi_list flags parameter


  Commit: 48023d74020c9f28722c363b197b6e92bbf7c691
  
https://github.com/OpenSIPS/opensips/commit/48023d74020c9f28722c363b197b6e92bbf7c691
  Author: Bogdan Andrei IANCU 
  Date:   2016-01-11 (Mon, 11 Jan 2016)

  Changed paths:
M modules/dispatcher/README
M modules/dispatcher/dispatch.c
M modules/dispatcher/dispatch.h
M modules/dispatcher/dispatcher.c
M modules/dispatcher/doc/dispatcher_admin.xml
M modules/dispatcher/doc/dispatcher_faq.xml

  Log Message:
  ---
  Merge pull request #748 from ionel-cerghit/ds_list_explicit

dispatcher: add ds_list full mi command, update documentation


Compare: 
https://github.com/OpenSIPS/opensips/compare/2e5160e5e1d8...48023d74020c___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

2016-01-11 Thread Bogdan Andrei IANCU

Merged #748.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/748#event-511290683___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

2016-01-11 Thread ionel-cerghit

Thank you for the comments Bogdan! I made the changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/748#issuecomment-170584084___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] Implement RTPProxy statistics fetching (#750)

2016-01-11 Thread vladpaiu

RTPProxy has the Q command ( both in 12 and 20 releases ) which allows for 
fetching statistics on a per call basis
Implement a mechanism ( function or pvar ) for fetching them -  eg fetching the 
call stats at BYE time, for storing them in CDRs or for attaching them to a BYE 
header ( similar to P-RTP-Stat )

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/750___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

2016-01-11 Thread Eric Tamme

I recompiled with -DBG_MALLOC as suggested by liviu.

I started the proxy, opened a few tabs to register webrtc clients over wss, 
closed the tabs and repeated the process till the proxy ran out of memory.  I 
then sent sigusr1 signals to all the pids and got the following log output.

https://gist.github.com/etamme/d1d96c08ea68f9873e40

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/743#issuecomment-170595551___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

[OpenSIPS-Devel] No 100 Trying reply generated by the t_relay() for INVITE after t_newrean() [was: "Early cancel" issue..]

[OpenSIPS-Devel] YUM repository downtime

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

[OpenSIPS-Devel] [opensips] opensips crashes (#749)

[OpenSIPS-Devel] [OpenSIPS/opensips] b32a14: [proto_hep]correctly calculate length when sending

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

[OpenSIPS-Devel] [opensips] Proposed fix for erratic nat_traversal keepalives (#751)

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

[OpenSIPS-Devel] [OpenSIPS/opensips] f47178: dispatcher: add ds_list full mi command, update do...

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

Re: [OpenSIPS-Devel] [opensips] dispatcher: add ds_list full mi command, update documentation (#748)

[OpenSIPS-Devel] [opensips] Implement RTPProxy statistics fetching (#750)

Re: [OpenSIPS-Devel] [opensips] Memory leak/out of memory when using proto_wss (#743)

17 matches

Site Navigation

Mail list logo

Footer information