Using OpenSIPS as a proxy with TLS/SRTP support

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Using OpenSIPS as a proxy with TLS/SRTP support

Serge Berney

Hello everybody,

 

I’m new user of OpenSIPS and desire to make this kind of configuration :

 

IPPhone ß SIP TLS & SRTP à OpenSIPS ß SIP & RTP à Asterisk

 

(Asterisk is working well and have CDR/User AUTH & Dialplan)

OpenSIPS is well compiled and seems to work J

 

But now, which module must I enable on OpenSIPS to enable TLS, SRTP and to redirect traffic to Asterisk ?

Could you help me in configuration ?

 

Thanks in advance !

 

Serge BERNEY
Kin SA
Knowledge Integrated Networks
Rue du Bois-du-Lan 8
Case Postale 221
1217 Meyrin 1
Tél: +41 22 989 0 999
Fax: +41 22 989 0 998
[hidden email]
www.kinonline.net

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Using OpenSIPS as a proxy with TLS/SRTP support

Iñaki Baz Castillo
2009/3/27 Serge Berney <[hidden email]>:

> I’m new user of OpenSIPS and desire to make this kind of configuration :
>
>
>
> IPPhone ß SIP TLS & SRTP à OpenSIPS ß SIP & RTP à Asterisk
>
>
>
> (Asterisk is working well and have CDR/User AUTH & Dialplan)
>
> OpenSIPS is well compiled and seems to work J
>
>
>
> But now, which module must I enable on OpenSIPS to enable TLS,

Please look at OpenSIPS wiki for TLS tutorial.


> SRTP and to redirect traffic to Asterisk ?

OpenSIPS is a SIP proxy, it doesn't handle media.




> Could you help me in configuration ?

Your question is too wide. Please, read the entire documentation of
OpenSIPS core and modules. OpenSIPS is powerful but it's not
user-friendly as Asterisk can be.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Opensips fifo - dp_reload hangs

DanB-2
Hey Guys,

something I noticed after upgrading from 1.4.x to 1.5.0 was that when
executing the dp_reload via opensipsctl the tool hangs (not able to
execute anything after, so I need to restart manually the opensips
server).
The command was working fine before upgrade.
Can anyone confirm me that the command works after the upgrade. Maybe
it's something specific to my upgrade process.

Ta,
DanB


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Using OpenSIPS as a proxy with TLS/SRTP support

Bogdan-Andrei Iancu
In reply to this post by Iñaki Baz Castillo
Hi there,

as a completion - as OpenSIPs does not directly do media, it cannot
convert SRTP <-> RTP. Also, AFAIK, there are no decent tools (I mean
only RTP tools that can be driven by OpenSIPS) to do this kind of
translation. But never now what may come up in the future ;)

Regards,
Bogdan

Iñaki Baz Castillo wrote:

> 2009/3/27 Serge Berney <[hidden email]>:
>
>  
>> I’m new user of OpenSIPS and desire to make this kind of configuration :
>>
>>
>>
>> IPPhone ß SIP TLS & SRTP à OpenSIPS ß SIP & RTP à Asterisk
>>
>>
>>
>> (Asterisk is working well and have CDR/User AUTH & Dialplan)
>>
>> OpenSIPS is well compiled and seems to work J
>>
>>
>>
>> But now, which module must I enable on OpenSIPS to enable TLS,
>>    
>
> Please look at OpenSIPS wiki for TLS tutorial.
>
>
>  
>> SRTP and to redirect traffic to Asterisk ?
>>    
>
> OpenSIPS is a SIP proxy, it doesn't handle media.
>  

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

Bogdan-Andrei Iancu
In reply to this post by DanB-2
Hi Dan,

Do you get some error during the dp_reload on the opensips side ? have
you checked the CPU usage (maybe something hangs) ?

AFAIR, nothing was change on this part between 1.4 and 1.5.

Regards,
Bogdan

Dan-Cristian Bogos wrote:

> Hey Guys,
>
> something I noticed after upgrading from 1.4.x to 1.5.0 was that when
> executing the dp_reload via opensipsctl the tool hangs (not able to
> execute anything after, so I need to restart manually the opensips
> server).
> The command was working fine before upgrade.
> Can anyone confirm me that the command works after the upgrade. Maybe
> it's something specific to my upgrade process.
>
> Ta,
> DanB
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

DanB-2
Hi Bogdan,

there are no errors in the debug (ran with level 4). Bellow you can find
some of the debug I see (ignoring the values load).
I should mention that I have not so much rules in, about 140.

Let me know if you need further info.

*************************************************************************

Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:mi_fifo:mi_fifo_server: entered consume
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:mi_fifo:mi_fifo_server: **** done consume
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:dialplan:dp_load_db:
init
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_do_query:
SYNC-DBG - SELECT successfully executed!
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_new_result:
allocate 48 bytes for result set at 0x74a908
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:core:db_allocate_columns: allocate 224 bytes for result columns at
0x74a948
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a988)[0]=[dpid]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a998)[1]=[pr]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9a8)[2]=[match_op]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9b8)[3]=[match_exp]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9c8)[4]=[match_len]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9d8)[5]=[subst_exp]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9e8)[6]=[repl_exp]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9f8)[7]=[attrs]
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_fetch_result: converting row 0 of 142 count 142
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:core:db_allocate_rows: allocate 38624 bytes for result rows and
values at 0x7556b0
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:db_mysql:db_mysql_str2val: converting INT [112]


.......

Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile:
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [00]    OP_EXPR
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left 01 right 00 next -1
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [01]          3
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left -1 right -1 next 02
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [02]          1
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left -1 right -1 next 03
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [03]          3
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left -1 right -1 next 04
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [04]          2
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left -1 right -1 next 05
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [05]          0
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left -1 right -1 next 07
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [06]     OP_DOT
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left -1 right -1 next -1
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: [07]  OP_GREEDY
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile: left 06 right 131071 next -1
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
DBG:dialplan:trex_compile:
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:dialplan:build_rule:
build_rule
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:dialplan:build_rule:
attrs are

......

Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_rows:
freeing 142 rows
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
freeing row values at 0x755f90
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
freeing row values at 0x756090
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
freeing row values at 0x756190
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
freeing row values at 0x756290

.......

Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
freeing row values at 0x75eb90
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
freeing row values at 0x75ec90
Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_rows:
freeing rows at 0x7556b0

Nothing after ...

Ta,
DanB


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

DanB-2
In reply to this post by Bogdan-Andrei Iancu
Hi Bogdan,

I have managed to make some more tests for the "dp_reload" issue, and came out the following:

* The issue is not server dependent. I have installed an opensips server on a completely different machine with different architecture, and same issue came up again.
* The issue is not data dependent. On the test machine I have emptied completely the dialplan table and issued a dp_reload command, same thing happened, fifo was destroyed and the command hanged (tried other commands later and no response).
* "dp_translate" command works fine.

Bellow you can find the debug for the "dp_reload" with empty dialplan table in the database.

Can u try my scenario in your labs? I am not doing anything specific, so if this is a bug, it can be common one.

Ta,
DanB

wtdev1:/etc/opensips# opensipsctl fifo dp_reload
Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: **** done consume
Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully executed!
Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8174dc8
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for result columns at 0x8174e60
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e80)[0]=[dpid]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e88)[1]=[pr]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e90)[2]=[match_op]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e98)[3]=[match_exp]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea0)[4]=[match_len]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea8)[5]=[subst_exp]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb0)[6]=[repl_exp]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb8)[7]=[attrs]
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned from the query
Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

Bogdan-Andrei Iancu
In reply to this post by DanB-2
Hi Dan,

can you use gdb to attach to the fifo process (after freeze) to get the
backtrace and to see what it is doing?

Regards,
Bogdan

Dan-Cristian Bogos wrote:

> Hi Bogdan,
>
> there are no errors in the debug (ran with level 4). Bellow you can find
> some of the debug I see (ignoring the values load).
> I should mention that I have not so much rules in, about 140.
>
> Let me know if you need further info.
>
> *************************************************************************
>
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:mi_fifo:mi_fifo_server: entered consume
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:mi_fifo:mi_fifo_server: **** done consume
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:dialplan:dp_load_db:
> init
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_do_query:
> SYNC-DBG - SELECT successfully executed!
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_new_result:
> allocate 48 bytes for result set at 0x74a908
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:core:db_allocate_columns: allocate 224 bytes for result columns at
> 0x74a948
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a988)[0]=[dpid]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a998)[1]=[pr]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9a8)[2]=[match_op]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9b8)[3]=[match_exp]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9c8)[4]=[match_len]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9d8)[5]=[subst_exp]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9e8)[6]=[repl_exp]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x74a9f8)[7]=[attrs]
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_fetch_result: converting row 0 of 142 count 142
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:core:db_allocate_rows: allocate 38624 bytes for result rows and
> values at 0x7556b0
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:db_mysql:db_mysql_str2val: converting INT [112]
>
>
> .......
>
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile:
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [00]    OP_EXPR
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left 01 right 00 next -1
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [01]          3
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left -1 right -1 next 02
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [02]          1
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left -1 right -1 next 03
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [03]          3
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left -1 right -1 next 04
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [04]          2
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left -1 right -1 next 05
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [05]          0
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left -1 right -1 next 07
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [06]     OP_DOT
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left -1 right -1 next -1
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: [07]  OP_GREEDY
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile: left 06 right 131071 next -1
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]:
> DBG:dialplan:trex_compile:
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:dialplan:build_rule:
> build_rule
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:dialplan:build_rule:
> attrs are
>
> ......
>
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_rows:
> freeing 142 rows
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
> freeing row values at 0x755f90
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
> freeing row values at 0x756090
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
> freeing row values at 0x756190
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
> freeing row values at 0x756290
>
> .......
>
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
> freeing row values at 0x75eb90
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_row:
> freeing row values at 0x75ec90
> Apr  1 11:57:32 sip1 /usr/sbin/opensips[4800]: DBG:core:db_free_rows:
> freeing rows at 0x7556b0
>
> Nothing after ...
>
> Ta,
> DanB
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

Bogdan-Andrei Iancu
In reply to this post by DanB-2
Hi Dan,

I found the bug and fixed it - for the moment the fix is on trunk only
and if you could test it before backport to 1.5, it will be great.

Thanks and regards,
Bogdan

Dan-Cristian Bogos wrote:

> Hi Bogdan,
>
> I have managed to make some more tests for the "dp_reload" issue, and came out the following:
>
> * The issue is not server dependent. I have installed an opensips server on a completely different machine with different architecture, and same issue came up again.
> * The issue is not data dependent. On the test machine I have emptied completely the dialplan table and issued a dp_reload command, same thing happened, fifo was destroyed and the command hanged (tried other commands later and no response).
> * "dp_translate" command works fine.
>
> Bellow you can find the debug for the "dp_reload" with empty dialplan table in the database.
>
> Can u try my scenario in your labs? I am not doing anything specific, so if this is a bug, it can be common one.
>
> Ta,
> DanB
>
> wtdev1:/etc/opensips# opensipsctl fifo dp_reload
> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: **** done consume
> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
> Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
> Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully executed!
> Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8174dc8
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
> Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for result columns at 0x8174e60
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e80)[0]=[dpid]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e88)[1]=[pr]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e90)[2]=[match_op]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e98)[3]=[match_exp]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea0)[4]=[match_len]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea8)[5]=[subst_exp]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb0)[6]=[repl_exp]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb8)[7]=[attrs]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned from the query
> Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
>
>
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

DanB-2
Hi Bogdan,

I have updated to trunk and tested again. Here is what I found out:

* First "dp_reload" is successful.
* Second "dp_reload" hangs, even for empty dialplan table.

Let me know if you need any further tests.

Ta,
DanB


On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:

> Hi Dan,
>
> I found the bug and fixed it - for the moment the fix is on trunk only
> and if you could test it before backport to 1.5, it will be great.
>
> Thanks and regards,
> Bogdan
>
> Dan-Cristian Bogos wrote:
> > Hi Bogdan,
> >
> > I have managed to make some more tests for the "dp_reload" issue, and came out the following:
> >
> > * The issue is not server dependent. I have installed an opensips server on a completely different machine with different architecture, and same issue came up again.
> > * The issue is not data dependent. On the test machine I have emptied completely the dialplan table and issued a dp_reload command, same thing happened, fifo was destroyed and the command hanged (tried other commands later and no response).
> > * "dp_translate" command works fine.
> >
> > Bellow you can find the debug for the "dp_reload" with empty dialplan table in the database.
> >
> > Can u try my scenario in your labs? I am not doing anything specific, so if this is a bug, it can be common one.
> >
> > Ta,
> > DanB
> >
> > wtdev1:/etc/opensips# opensipsctl fifo dp_reload
> > Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
> > Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: **** done consume
> > Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
> > Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
> > Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully executed!
> > Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8174dc8
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
> > Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for result columns at 0x8174e60
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e80)[0]=[dpid]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e88)[1]=[pr]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e90)[2]=[match_op]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e98)[3]=[match_exp]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea0)[4]=[match_len]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea8)[5]=[subst_exp]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb0)[6]=[repl_exp]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb8)[7]=[attrs]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned from the query
> > Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
> >
> >
> >
> >
> >  
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

Bogdan-Andrei Iancu
Hi Dan,

As expected, the "debug" function strikes again (some unhandled  return
if data was null was causing a deadlock)..

Fixed, tested and backported to 1.5.

Thanks again for your help,

Regards,
Bogdan

Dan-Cristian Bogos wrote:

> Hi Bogdan,
>
> I have updated to trunk and tested again. Here is what I found out:
>
> * First "dp_reload" is successful.
> * Second "dp_reload" hangs, even for empty dialplan table.
>
> Let me know if you need any further tests.
>
> Ta,
> DanB
>
>
> On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:
>  
>> Hi Dan,
>>
>> I found the bug and fixed it - for the moment the fix is on trunk only
>> and if you could test it before backport to 1.5, it will be great.
>>
>> Thanks and regards,
>> Bogdan
>>
>> Dan-Cristian Bogos wrote:
>>    
>>> Hi Bogdan,
>>>
>>> I have managed to make some more tests for the "dp_reload" issue, and came out the following:
>>>
>>> * The issue is not server dependent. I have installed an opensips server on a completely different machine with different architecture, and same issue came up again.
>>> * The issue is not data dependent. On the test machine I have emptied completely the dialplan table and issued a dp_reload command, same thing happened, fifo was destroyed and the command hanged (tried other commands later and no response).
>>> * "dp_translate" command works fine.
>>>
>>> Bellow you can find the debug for the "dp_reload" with empty dialplan table in the database.
>>>
>>> Can u try my scenario in your labs? I am not doing anything specific, so if this is a bug, it can be common one.
>>>
>>> Ta,
>>> DanB
>>>
>>> wtdev1:/etc/opensips# opensipsctl fifo dp_reload
>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: **** done consume
>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
>>> Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
>>> Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully executed!
>>> Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8174dc8
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
>>> Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for result columns at 0x8174e60
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e80)[0]=[dpid]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e88)[1]=[pr]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e90)[2]=[match_op]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e98)[3]=[match_exp]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea0)[4]=[match_len]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea8)[5]=[subst_exp]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb0)[6]=[repl_exp]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb8)[7]=[attrs]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned from the query
>>> Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
>>>
>>>
>>>
>>>
>>>  
>>>      
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

DanB-2
Hi Bogdan,

Many thanks for solving it so fast.

I can confirm that all OK now.

Cheers,
DanB

On Tue, 2009-04-07 at 17:18 +0300, Bogdan-Andrei Iancu wrote:

> Hi Dan,
>
> As expected, the "debug" function strikes again (some unhandled  return
> if data was null was causing a deadlock)..
>
> Fixed, tested and backported to 1.5.
>
> Thanks again for your help,
>
> Regards,
> Bogdan
>
> Dan-Cristian Bogos wrote:
> > Hi Bogdan,
> >
> > I have updated to trunk and tested again. Here is what I found out:
> >
> > * First "dp_reload" is successful.
> > * Second "dp_reload" hangs, even for empty dialplan table.
> >
> > Let me know if you need any further tests.
> >
> > Ta,
> > DanB
> >
> >
> > On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:
> >  
> >> Hi Dan,
> >>
> >> I found the bug and fixed it - for the moment the fix is on trunk only
> >> and if you could test it before backport to 1.5, it will be great.
> >>
> >> Thanks and regards,
> >> Bogdan
> >>
> >> Dan-Cristian Bogos wrote:
> >>    
> >>> Hi Bogdan,
> >>>
> >>> I have managed to make some more tests for the "dp_reload" issue, and came out the following:
> >>>
> >>> * The issue is not server dependent. I have installed an opensips server on a completely different machine with different architecture, and same issue came up again.
> >>> * The issue is not data dependent. On the test machine I have emptied completely the dialplan table and issued a dp_reload command, same thing happened, fifo was destroyed and the command hanged (tried other commands later and no response).
> >>> * "dp_translate" command works fine.
> >>>
> >>> Bellow you can find the debug for the "dp_reload" with empty dialplan table in the database.
> >>>
> >>> Can u try my scenario in your labs? I am not doing anything specific, so if this is a bug, it can be common one.
> >>>
> >>> Ta,
> >>> DanB
> >>>
> >>> wtdev1:/etc/opensips# opensipsctl fifo dp_reload
> >>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
> >>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: **** done consume
> >>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
> >>> Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
> >>> Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully executed!
> >>> Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8174dc8
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
> >>> Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for result columns at 0x8174e60
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e80)[0]=[dpid]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e88)[1]=[pr]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e90)[2]=[match_op]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e98)[3]=[match_exp]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea0)[4]=[match_len]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea8)[5]=[subst_exp]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb0)[6]=[repl_exp]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb8)[7]=[attrs]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned from the query
> >>> Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>      
> >
> >
> >  
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Opensips fifo - dp_reload hangs

Bogdan-Andrei Iancu
Super :)

Thanks and regards,
Bogdan

Dan-Cristian Bogos wrote:

> Hi Bogdan,
>
> Many thanks for solving it so fast.
>
> I can confirm that all OK now.
>
> Cheers,
> DanB
>
> On Tue, 2009-04-07 at 17:18 +0300, Bogdan-Andrei Iancu wrote:
>  
>> Hi Dan,
>>
>> As expected, the "debug" function strikes again (some unhandled  return
>> if data was null was causing a deadlock)..
>>
>> Fixed, tested and backported to 1.5.
>>
>> Thanks again for your help,
>>
>> Regards,
>> Bogdan
>>
>> Dan-Cristian Bogos wrote:
>>    
>>> Hi Bogdan,
>>>
>>> I have updated to trunk and tested again. Here is what I found out:
>>>
>>> * First "dp_reload" is successful.
>>> * Second "dp_reload" hangs, even for empty dialplan table.
>>>
>>> Let me know if you need any further tests.
>>>
>>> Ta,
>>> DanB
>>>
>>>
>>> On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:
>>>  
>>>      
>>>> Hi Dan,
>>>>
>>>> I found the bug and fixed it - for the moment the fix is on trunk only
>>>> and if you could test it before backport to 1.5, it will be great.
>>>>
>>>> Thanks and regards,
>>>> Bogdan
>>>>
>>>> Dan-Cristian Bogos wrote:
>>>>    
>>>>        
>>>>> Hi Bogdan,
>>>>>
>>>>> I have managed to make some more tests for the "dp_reload" issue, and came out the following:
>>>>>
>>>>> * The issue is not server dependent. I have installed an opensips server on a completely different machine with different architecture, and same issue came up again.
>>>>> * The issue is not data dependent. On the test machine I have emptied completely the dialplan table and issued a dp_reload command, same thing happened, fifo was destroyed and the command hanged (tried other commands later and no response).
>>>>> * "dp_translate" command works fine.
>>>>>
>>>>> Bellow you can find the debug for the "dp_reload" with empty dialplan table in the database.
>>>>>
>>>>> Can u try my scenario in your labs? I am not doing anything specific, so if this is a bug, it can be common one.
>>>>>
>>>>> Ta,
>>>>> DanB
>>>>>
>>>>> wtdev1:/etc/opensips# opensipsctl fifo dp_reload
>>>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
>>>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: **** done consume
>>>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
>>>>> Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
>>>>> Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully executed!
>>>>> Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8174dc8
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
>>>>> Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for result columns at 0x8174e60
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e80)[0]=[dpid]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e88)[1]=[pr]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e90)[2]=[match_op]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174e98)[3]=[match_exp]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea0)[4]=[match_len]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174ea8)[5]=[subst_exp]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb0)[6]=[repl_exp]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8174eb8)[7]=[attrs]
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>>>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned from the query
>>>>> Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  
>>>>>      
>>>>>          
>>>  
>>>      
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users