[OpenSIPS-Devel] [ opensips-Bugs-3178242 ] Reuse Transport socket
Bugs item #3178242, was opened at 2011-02-11 12:24 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178242group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Reuse Transport socket Initial Comment: Hi, This is not really a bug report, but a thought: I'm reading the TM source code, and specifically the t_uac function. This function tries to find the right socket to send the request with the next hop URI. In my case, I created a dialog using TCP, the connection is up, Request is sent, but the peer replies with a Contact header URI that looks like: sip:user@ip. So every next request will be sent to this URI. But Transport argument is not set. In your source code, parse_uri (called in uri2sock) will set proto of this uri to PROTO_NONE. But sip_resolvehost function (called in urisock via mk_proxy) will set default protocol to UDP when URI is not SIPS type. So every next request will be sent on UDP. There are 2 ways to explain this bug: - the peer is wrong so it has to add transport argument to its Contact header; - You choose explicitly to use UDP by default, but RFC seems to recommend reuse of socket; RFC 3261 (18 Transport): It is RECOMMENDED that connections be kept open for some implementation-defined duration after the last message was sent or received over that connection. This duration SHOULD at least equal the longest amount of time the element would need in order to bring a transaction from instantiation to the terminated state. This is to make it likely that transactions are completed over the same connection on which they are initiated (for example, request, response, and in the case of INVITE, ACK for non-2xx responses). What is your point of view about this problem ? Thanks for your answer, Regards, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178242group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [ opensips-Bugs-3177286 ] Crash in drouting
I also had this crash and the solution is to have more than 1 rule in the
dr_rules table.
WBR, Anton Zagorskiy
VoIP Developer, Oyster Telecom
Phone.: +7 812 601-0666
Fax: +7 812 601-0593
a.zagors...@oyster-telecom.ru
www.oyster-telecom.ru
-Original Message-
From: devel-boun...@lists.opensips.org [mailto:devel-
boun...@lists.opensips.org] On Behalf Of SourceForge.net
Sent: Thursday, February 10, 2011 6:57 PM
To: nore...@sourceforge.net
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3177286 ] Crash in drouting
Bugs item #3177286, was opened at 2011-02-10 12:05
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3177286g
roup_id=232389
Please note that this message will contain a full copy of the comment
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Crash in drouting
Initial Comment:
I am trying implement the drouting... a have 3 gateway in dr_gateways
table... and only one rule... gw_list=3,2,1
In the third attempt, opensips crash follows the configuration and
mysql tables!
route{
...
#drouting
if(!do_routing(0)){
send_reply(503, No rules found matching the URI
prefix);
exit;
}
#flag 11 . flag the transaction to handle the failure route
setflag(11);
route(1);
...
}
route[1] {
# for INVITEs enable some additional helper routes
if (is_method(INVITE)) {
t_on_branch(2);
t_on_reply(2);
t_on_failure(1);
}
if (!t_relay()) {
sl_reply_error();
};
exit;
}
failure_route[1] {
xlog(FAILURE_ROUTE[1]: M=$rm RURI=$ru F=$fu T=$tu IP=$si
STS=$rs RZ=$rr\n);
if (t_was_cancelled()) {
exit;
}
#drouting
if(isflagset(11)){
if (use_next_gw()) {
#xlog (next gateway $ru \n);
t_on_failure(1);
t_relay();
exit;
} else {
t_reply(503, Service not available, no more
gateways);
exit;
}
}
}
Feb 10 09:29:58 tesla /sbin/opensips[16358]: ONREPLY_ROUTE[2]:
M=INVITE RURI=null F=sip:3534716644@200.251.137.109
T=sip:%23553588023317@200.251.137.110:5060 IP
Feb 10 09:29:58 tesla /sbin/opensips[16358]:
DBG:tm:t_should_relay_response: T_code=183, new_code=486
Feb 10 09:29:58 tesla /sbin/opensips[16358]: DBG:tm:t_pick_branch:
picked branch 1, code 486 (prio=686)
Feb 10 09:29:58 tesla /sbin/opensips[16358]: DBG:tm:is_3263_failure:
dns-failover test: branch=1, last_recv=486, flags=2
Feb 10 09:29:58 tesla /sbin/opensips[16358]:
DBG:tm:run_trans_callbacks: trans=0xb59803bc, callback type 64, id 1
entered
Feb 10 09:29:58 tesla /sbin/opensips[16358]: FAILURE_ROUTE[1]:
M=INVITE RURI=sip:553588023317@200.182.99.124
F=sip:3534716644@200.251.137.109 T=sip:#553588023317@
Feb 10 09:29:58 tesla /sbin/opensips[16358]: DBG:drouting:use_next_gw:
new RURI set to sip:0023#553588023317@200.155.77.57
Feb 10 09:29:58 tesla /sbin/opensips[16358]: DBG:core:_shm_resize:
resize(0) called
Feb 10 09:29:58 tesla /sbin/opensips[16350]: INFO:core:handle_sigs:
child process 16358 exited by a signal 11
Feb 10 09:29:58 tesla /sbin/opensips[16350]: INFO:core:handle_sigs:
core was generated
Feb 10 09:29:58 tesla /sbin/opensips[16350]: INFO:core:handle_sigs:
terminating due to SIGCHLD
Feb 10 09:29:58 tesla /sbin/opensips[16370]: INFO:core:sig_usr: signal
15 received
Feb 10 09:29:58 tesla /sbin/opensips[16372]: INFO:core:sig_usr: signal
15 received
Feb 10 09:29:58 tesla /sbin/opensips[16373]: INFO:core:sig_usr: signal
15 received
mysql select * from dr_gateways;
+--+--++---++---+--
--+--+
| gwid | type | address| strip | pri_prefix | attrs |
probe_mode | description |
+--+--++---++---+--
--+--+
|1 |0 | 200.155.77.57 | 0 | 0023# | |
0 | |
|2 |0 | 200.182.99.124 | 0 || |
0 | |
|3 |0 | 72.85.25.12| 0 | 5580# | |
0 | CLI |
+--+--++---++---+--
--+--+
mysql select * from dr_rules;
++-++-+--+-++--
-+-+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist |
attrs |
[OpenSIPS-Devel] [ opensips-Bugs-3178281 ] Srand in b2b_entities
Bugs item #3178281, was opened at 2011-02-11 13:21 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178281group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Srand in b2b_entities Initial Comment: Hi, The use of srand is wrong in generation of random value in the second part of callid. srand have to be called one time for init, after call rand to get a random value. Regards, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178281group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [ opensips-Bugs-3178281 ] Srand in b2b_entities
Here is my patch. Why: srand has to be initiate with a different value by process. In the previous version, srand called get_uticks with concurrency access, and rand value will be the same. On Fri, Feb 11, 2011 at 2:21 PM, SourceForge.net nore...@sourceforge.net wrote: Bugs item #3178281, was opened at 2011-02-11 13:21 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178281group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Srand in b2b_entities Initial Comment: Hi, The use of srand is wrong in generation of random value in the second part of callid. srand have to be called one time for init, after call rand to get a random value. Regards, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178281group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- Olivier Détour srand.patch Description: Binary data ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[7710] trunk/modules/b2b_logic/logic.c
Hi Ovidiu, A quick question, what is DLG_CONFIRMED state? Is that when the call has been answered and a 200OK/ACK exchanged? We've seen an issue with the B2BUA module where in the middle of a re-invite a bridging attempt will cause the the B2BUA to send a Cancel to the caller, and send another re-invite which leads to unpredictable consequences on the the UAC. Thanks, Leah S. On Mon, Feb 7, 2011 at 11:41 PM, Ovidiu Sas o...@voipembedded.com wrote: Revision: 7710 http://opensips.svn.sourceforge.net/opensips/?rev=7710view=rev Author: osas Date: 2011-02-08 04:41:09 + (Tue, 08 Feb 2011) Log Message: --- b2b_logic: bridging is permited only in DLG_CONFIRMED state Modified Paths: -- trunk/modules/b2b_logic/logic.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7732] trunk
Revision: 7732 http://opensips.svn.sourceforge.net/opensips/?rev=7732view=rev Author: anca_vamanu Date: 2011-02-11 14:22:41 + (Fri, 11 Feb 2011) Log Message: --- - fixed wrong NOT NULL constraints in some column definitions for b2b_logic table (reported by Kamen Petrov) Modified Paths: -- trunk/db/schema/b2b_logic.xml trunk/scripts/dbtext/opensips/b2b_logic trunk/scripts/mysql/b2b-create.sql trunk/scripts/postgres/b2b-create.sql This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[7710] trunk/modules/b2b_logic/logic.c
On Tue, Feb 8, 2011 at 9:08 AM, Leah Shad l...@sipcnam.com wrote: Hi Ovidiu, A quick question, what is DLG_CONFIRMED state? Is that when the call has been answered and a 200OK/ACK exchanged? Yes. We've seen an issue with the B2BUA module where in the middle of a re-invite a bridging attempt will cause the the B2BUA to send a Cancel to the caller, and send another re-invite which leads to unpredictable consequences on the the UAC. Can you get a SIP trace for that, along with debug logs? Please open a separate thread for this questions, following up a commit log is not the best way to discuss issues. Regards, Ovidiu Sas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [ opensips-Bugs-3178281 ] Srand in b2b_entities
Hi Olivier, You are right, srandom is not used right there. However, we want to take out that part from there, not use srand anymore and extend another mechanism for getting unique values that is now used for top hiding, to other scenarios also. Now for top hiding the from_tag is computed from 4 values taken from the message - callid, fromtag, ruri and via branch. I will implement this and take out the random from there next week. Thanks and regards, -- Anca Vamanu OpenSIPS Developer On 02/11/2011 03:55 PM, Olivier Détour wrote: Here is my patch. Why: srand has to be initiate with a different value by process. In the previous version, srand called get_uticks with concurrency access, and rand value will be the same. On Fri, Feb 11, 2011 at 2:21 PM, SourceForge.net nore...@sourceforge.net wrote: Bugs item #3178281, was opened at 2011-02-11 13:21 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178281group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Srand in b2b_entities Initial Comment: Hi, The use of srand is wrong in generation of random value in the second part of callid. srand have to be called one time for init, after call rand to get a random value. Regards, ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3172168 ] Call-Info header parser
Patches item #3172168, was opened at 2011-02-04 02:27 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3172168group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Call-Info header parser Initial Comment: Attached is a patch for parsing the content of a Call-Info header. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2011-02-11 19:07 Message: Hi Ovidiu, Patch was uploaded - thanks a lot! Best regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3172168group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3171014 ] can't do 'svn co' under windows
Bugs item #3171014, was opened at 2011-02-03 01:38 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3171014group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: trunk Status: Open Resolution: None Priority: 1 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't do 'svn co' under windows Initial Comment: many time, i can't do 'svn co' opensips and openser to, under windows the log from TourtoiseSVN under windows ... Added: F:\work\svn\voip\opensips_trunk\modules\db_unixodbc Added: F:\work\svn\voip\opensips_trunk\modules\db_unixodbc\res.h Added: F:\work\svn\voip\opensips_trunk\modules\db_unixodbc\row.c Added: F:\work\svn\voip\opensips_trunk\modules\db_unixodbc\list.c Added: F:\work\svn\voip\opensips_trunk\modules\db_unixodbc\README Added: F:\work\svn\voip\opensips_trunk\modules\db_unixodbc\row.h Added: F:\work\svn\voip\opensips_trunk\modules\db_unixodbc\dbase.c Error: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again Error: Can't open file Error: 'F:\work\svn\voip\opensips_trunk\modules\db_unixodbc\.svn\tmp\text-base\con.c.svn-base': Error: File not found! Finished!: that is problem under windows becouse windows can't create file 'con.c' 'con.h' and any file that have name as 'con', becouse CON reserved for windows IO the solution a rename filenames opensips_trunk/modules/db_unixodbc/con.c and opensips_trunk/modules/db_unixodbc/con.h to another name as example like that 'conn.*' opensips_trunk/modules/db_unixodbc/conn.c opensips_trunk/modules/db_unixodbc/conn.h -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2011-02-11 19:11 Message: Hi, maybe a stupid question, but why do you want to co on windows? anyhow the code does not compile under windows :D . Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3171014group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7735] trunk/modules/tm/t_reply.c
Revision: 7735 http://opensips.svn.sourceforge.net/opensips/?rev=7735view=rev Author: bogdan_iancu Date: 2011-02-11 17:30:55 + (Fri, 11 Feb 2011) Log Message: --- - fixed mem leak in SDP Credits go to Ovidiu Sas Modified Paths: -- trunk/modules/tm/t_reply.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7733] trunk/parser/msg_parser.c
Revision: 7733 http://opensips.svn.sourceforge.net/opensips/?rev=7733view=rev Author: bogdan_iancu Date: 2011-02-11 16:59:01 + (Fri, 11 Feb 2011) Log Message: --- - when allocating a NEW URI (in SI requests first line) alloc an extra 1 byte as some regexp/dns related functions expect one byte end padding to make the domain part of RURI null terminated Modified Paths: -- trunk/parser/msg_parser.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7734] trunk/parser
Revision: 7734 http://opensips.svn.sourceforge.net/opensips/?rev=7734view=rev Author: bogdan_iancu Date: 2011-02-11 17:07:19 + (Fri, 11 Feb 2011) Log Message: --- applied patch #3172168 - a parser the content of a Call-Info header. Credits go to Ovidiu Sas. Modified Paths: -- trunk/parser/hf.c trunk/parser/hf.h Added Paths: --- trunk/parser/parse_call_info.c trunk/parser/parse_call_info.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7736] branches/1.6
Revision: 7736 http://opensips.svn.sourceforge.net/opensips/?rev=7736view=rev Author: bogdan_iancu Date: 2011-02-11 17:33:55 + (Fri, 11 Feb 2011) Log Message: --- backport from trunk (rev #7735): - fixed mem leak in SDP Credits go to Ovidiu Sas Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=7735view=rev Modified Paths: -- branches/1.6/modules/tm/t_reply.c branches/1.6/parser/msg_parser.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7737] trunk/modules/tm/t_reply.c
Revision: 7737 http://opensips.svn.sourceforge.net/opensips/?rev=7737view=rev Author: osas Date: 2011-02-11 17:48:01 + (Fri, 11 Feb 2011) Log Message: --- tm: fix copy/paste error on previous commit Modified Paths: -- trunk/modules/tm/t_reply.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7738] branches/1.6/modules/tm/t_reply.c
Revision: 7738 http://opensips.svn.sourceforge.net/opensips/?rev=7738view=rev Author: osas Date: 2011-02-11 17:51:33 + (Fri, 11 Feb 2011) Log Message: --- tm: fix copy/paste error on previous commit Modified Paths: -- branches/1.6/modules/tm/t_reply.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3173636 ] mem core dump
Bugs item #3173636, was opened at 2011-02-05 12:28 Message generated for change (Comment added) made by revels You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3173636group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan (revels) Assigned to: Anca Vamanu (anca_vamanu) Summary: mem core dump Initial Comment: This is on 1.6.4 backtrace here: http://pastebin.com/SF1S0GDb -- Comment By: Ryan (revels) Date: 2011-02-11 17:24 Message: loadmodule cfgutils.so loadmodule uac.so loadmodule db_postgres.so loadmodule signaling.so loadmodule sl.so loadmodule tm.so loadmodule rr.so loadmodule maxfwd.so loadmodule textops.so loadmodule mi_fifo.so loadmodule uri.so loadmodule acc.so loadmodule dialog.so loadmodule avpops.so loadmodule drouting.so loadmodule permissions.so loadmodule dispatcher.so -- Comment By: Anca Vamanu (anca_vamanu) Date: 2011-02-10 08:08 Message: Hi, It looks like a memory corruption to me. What module have you loaded in your configuration? Regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3173636group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3178730 ] dialog core dump
Bugs item #3178730, was opened at 2011-02-11 17:35 Message generated for change (Tracker Item Submitted) made by revels You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178730group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan (revels) Assigned to: Nobody/Anonymous (nobody) Summary: dialog core dump Initial Comment: I use an origination opensips proxy to dispatch to these 2 core proxies. Both generated a core dump within 2 minutes of each other: core_proxy1: http://pastebin.com/56vi8K2P core_proxy2: http://pastebin.com/V5bjx8fj Both are running 1.6.4-2 release code They had both been running for about a week when this happened. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3178730group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
