Re: [OpenSIPS-Users] dispatcher problem
Hi Matt, If you want good distribution, why don't you use instead the round-robin or the random dispatcher algorithms? [1] http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id293072 Regards, -- Vlad Paiu OpenSIPS Developer http://opensips-solutions.org/ Pe 2/3/2012 2:59 AM, Matt Hamilton a scris: Hi Ra(zvan, I don't assign any weights, and I use the dispatcher.list file: 1 sip:x.x.x.11:5060 1 sip:x.x.x.12:5060 1 sip:x.x.x.13:5060 When there are only 2 servers in that file, I always get: DBG:dispatcher:ds_select_dst: alg hash [1], id [1] and dispatcher selects the 2nd entry. When there are 3 servers - when the dispatcher distributes to all 3 servers, I get DBG:dispatcher:ds_select_dst: alg hash [0], id [0] before it dispatches to server1 (x.x.x.11) DBG:dispatcher:ds_select_dst: alg hash [1], id [1] for x.x.x.12 DBG:dispatcher:ds_select_dst: alg hash [2], id [2] for x.x.x.13 Anyway I did some more tests, and it turns out that the hash algorithm is very sensitive to the PV. 1. when the input hash_pvar is from this set (my original set that gave me problems): 061002 061003 061005 061006 61007 061008 Dispatcher splits them: Server1: 0 server2: 6 2. if I add a 1 in front of my hash PV - so that the new values are 1061002, etc. (indentation mark is part of the string) Server1: 2 Server2: 4 3. If I add another character, so that PVs look like x1061002 Server1: 3 Server2: 3 3-3 or 2-4 split is OK of course, but the 0-6 split threw me off. Is there a safe PV (integers, certain combinations, etc.) that I can use that will give me the best distribution? I can use a lookup table (like dialplan) to get those. Thanks, Matt Date: Fri, 3 Feb 2012 00:36:37 +0200 From: razvancrai...@opensips.org To: users@lists.opensips.org Subject: Re: [OpenSIPS-Users] dispatcher problem Hi, Matt! So for different hashed strings like: DBG:dispatcher:ds_hash_pvar: Hashing 061002! you always get the same output: DBG:dispatcher:ds_select_dst: alg hash [1], id [1] Also, are you assigning different weights for any of the Asterisk? Regards, -- Ra(zvan Crainea OpenSIPS Developer http://opensips-solutions.org/ On 02/03/2012 12:16 AM, Matt Hamilton wrote: Hi Ra(zvan, Yes, I'm using the same hashing values - the values I assign to the PV are also passed to the ds_select_dst correctly as far as I can see. Here is a typical debug output: DBG:dispatcher:ds_hash_pvar: Hashing 061002! DBG:dispatcher:ds_select_dst: alg hash [1], id [1] DBG:dispatcher:ds_select_dst: selected [7-1/1]sip:x.x.x.13:5060 DBG:dispatcher:ds_select_dst: using entry [1/0] I ran some test with 3 Asterisk servers with interesting results: With 3 Asterisk servers specified in dispatcher.list, here is the distribution: Server1: 061003 Server2: 061002, 061007, 061008 Server3: 061005, 061006 With only Server1 and Server2 specified in dispatcher.list: Server1: Server2: 061002, 061003, 061005, 061006, 61007, 061008 Likewise, with Server1 and Server3, Server3 gets everything. with Server2 and Server3, Server3 gets everything. Is there anything I can do to fix this (somehow trick the function assuming the way I do is the correct way)? Thanks, Matt Date: Thu, 2 Feb 2012 22:51:46 +0200 From: razvancrai...@opensips.org mailto:razvancrai...@opensips.org To: users@lists.opensips.org mailto:users@lists.opensips.org Subject: Re: [OpenSIPS-Users] dispatcher problem Hi, Matt! Are you sure you are not using the same hashing value all the time? If yes, can you increase your debugging level to 6 and provide more information? I would be looking in the opensips log for lines that contain the following strings: ds_hash_pvar: Hashing and ds_select_dst: alg hash . Regards, -- Ra(zvan Crainea OpenSIPS Developer http://opensips-solutions.org/ On 02/02/2012 10:15 PM, Matt Hamilton wrote: Hi, I'm using Opensips to dispatch to 2 servers - serverA, serverB. When one of the servers is down, Opensips is dispatching to the active one correctly. However, when both of them are Active, it's picking only one of them and ignoring the other; e.g., when serverB is down, dispatches to serverA when serverA is down, dispatches to serverB when both up, dispatches to serverB while dispatching to serverA when serverB is down, if I activate serverB, all requests dispatched to serverB Here is my code: modparam(dispatcher, hash_pvar, $avp(75)) in the script, I'm setting $avp(75) to one of the following 061002, 061003, 061004, 061005, 061006 just before calling ds_select_dst.
[OpenSIPS-Users] Query on external source ( execel or DB )
Hi folk, I need to know if with OpenSIPS i am able to have the following scenario: INITIAL SCENARIO: Incoming external call goes into SIP PBX , this one routes call toward another SIP PBX. WANTED SCENARIO: Incoming external call goes into SIP PBX,this one routes call toward OpeSIPS ( OpenSIPS have to check into outside source, for example a execl file or access file if calling number is present. If true It has to modify TO: header in a certain manner; if false, it has to modify TO Header with another way ). After modification, OpenSIPS routes call into final SIP PBX. Is that passible? I know OpenSIPS can easly modify Sip headers but what I don't know is if OpenSIPS can use a execl or acces external file as source to get the condition ( true or false ). Thanks -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Query-on-external-source-execel-or-DB-tp7250453p7250453.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Query on external source ( execel or DB )
Hello, Can't you use a regular database, instead of an excel or acces file ? If not, you can use the exec [1] module to execute an external script that processes info from your files, or even write a perl app that you can call via the perl [2] module. [1] http://www.opensips.org/html/docs/modules/devel/exec.html [2] http://www.opensips.org/html/docs/modules/devel/perl.html Regards, -- Vlad Paiu OpenSIPS Developer http://opensips-solutions.org/ Pe 2/3/2012 1:28 PM, spady a scris: Hi folk, I need to know if with OpenSIPS i am able to have the following scenario: INITIAL SCENARIO: Incoming external call goes into SIP PBX , this one routes call toward another SIP PBX. WANTED SCENARIO: Incoming external call goes into SIP PBX,this one routes call toward OpeSIPS ( OpenSIPS have to check into outside source, for example a execl file or access file if calling number is present. If true It has to modify TO: header in a certain manner; if false, it has to modify TO Header with another way ). After modification, OpenSIPS routes call into final SIP PBX. Is that passible? I know OpenSIPS can easly modify Sip headers but what I don't know is if OpenSIPS can use a execl or acces external file as source to get the condition ( true or false ). Thanks -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Query-on-external-source-execel-or-DB-tp7250453p7250453.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Query on external source ( execel or DB )
Thanks Vlad for your reply. Query has to be done into AS400's db. I think is not a standard db. So I thought about excel or access file ( I can export data from AS400 ). If there is not another solution, I will have a try as you suggested me. Thnaks a lot. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Query-on-external-source-execel-or-DB-tp7250453p7250764.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dispatcher problem
Hi Vlad, We have many locations with 5-10 phones each. We use applications that require us to keep track of device states continuously for each location. We would prefer to have each location handled by the same Asterisk server both for incoming and outbound calls including registrations and subscriptions. It's more scalable and cleaner this way. If that server goes down, the whole location traffic as a whole moves to the next available server. That's why I need more control over dispatching. Anyway, instead of using 061002, 061003, 061005, 061006, 061007, 061008, if I use 1, 2, 3, 4, 5, 6, I get a much reasonable distribution (at least for 6 locations I use for testing). For 50+ locations, the results might be different of course. Thanks, Matt Date: Fri, 3 Feb 2012 12:50:25 +0200 From: vladp...@opensips.org To: users@lists.opensips.org Subject: Re: [OpenSIPS-Users] dispatcher problem Hi Matt, If you want good distribution, why don't you use instead the round-robin or the random dispatcher algorithms? [1] http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id293072 Regards, -- Vlad Paiu OpenSIPS Developer http://opensips-solutions.org/ Pe 2/3/2012 2:59 AM, Matt Hamilton a scris: Hi Răzvan, I don't assign any weights, and I use the dispatcher.list file: 1 sip:x.x.x.11:5060 1 sip:x.x.x.12:5060 1 sip:x.x.x.13:5060 When there are only 2 servers in that file, I always get: DBG:dispatcher:ds_select_dst: alg hash [1], id [1] and dispatcher selects the 2nd entry. When there are 3 servers - when the dispatcher distributes to all 3 servers, I get DBG:dispatcher:ds_select_dst: alg hash [0], id [0] before it dispatches to server1 (x.x.x.11) DBG:dispatcher:ds_select_dst: alg hash [1], id [1] for x.x.x.12 DBG:dispatcher:ds_select_dst: alg hash [2], id [2] for x.x.x.13 Anyway I did some more tests, and it turns out that the hash algorithm is very sensitive to the PV. 1. when the input hash_pvar is from this set (my original set that gave me problems): 061002 061003 061005 061006 61007 061008 Dispatcher splits them: Server1: 0 server2: 6 2. if I add a 1 in front of my hash PV - so that the new values are 1061002, etc. (indentation mark is part of the string) Server1: 2 Server2: 4 3. If I add another character, so that PVs look like x1061002 Server1: 3 Server2: 3 3-3 or 2-4 split is OK of course, but the 0-6 split threw me off. Is there a safe PV (integers, certain combinations, etc.) that I can use that will give me the best distribution? I can use a lookup table (like dialplan) to get those. Thanks, Matt Date: Fri, 3 Feb 2012 00:36:37 +0200 From: razvancrai...@opensips.org To: users@lists.opensips.org Subject: Re: [OpenSIPS-Users] dispatcher problem Hi, Matt! So for different hashed strings like: DBG:dispatcher:ds_hash_pvar: Hashing 061002! you always get the same output: DBG:dispatcher:ds_select_dst: alg hash [1], id [1] Also, are you assigning different weights for any of the Asterisk? Regards, -- Răzvan Crainea OpenSIPS Developer http://opensips-solutions.org/ On 02/03/2012 12:16 AM, Matt Hamilton wrote: Hi Răzvan, Yes, I'm using the same hashing values - the values I assign to the PV are also passed to the ds_select_dst correctly as far as I can see. Here is a typical debug output: DBG:dispatcher:ds_hash_pvar: Hashing 061002! DBG:dispatcher:ds_select_dst: alg hash [1], id [1] DBG:dispatcher:ds_select_dst: selected [7-1/1] sip:x.x.x.13:5060 DBG:dispatcher:ds_select_dst: using entry [1/0] I ran some test with 3 Asterisk servers with interesting results: With 3 Asterisk servers specified in dispatcher.list, here is the distribution: Server1: 061003 Server2: 061002, 061007, 061008 Server3: 061005, 061006 With only Server1 and Server2 specified in dispatcher.list: Server1: Server2: 061002, 061003, 061005, 061006, 61007, 061008 Likewise, with Server1 and Server3, Server3 gets everything. with Server2 and Server3, Server3 gets everything. Is there anything I can do to fix this (somehow trick the function assuming the way I do is the correct
[OpenSIPS-Users] Problems compiling OpenSIPS 1.7 on OpenBSD 5.0 (error: expected specifier-qualifier-list, etc)
Hi Folks, I am trying to compile OpenSIPS 1.7(latest svn src) on OpenBSD 5.0, but I stumble fairly quickly on the below errors. Anyone who can explain what simple things I've messed up? Any help appreciated! Regards Taisto Qvist IP-Solutions.se *[root@sip] /usr/source/opensips_1_7 # gmake* Compiling evi/evi_core.c In file included from evi/evi_transport.h:30, from evi/event_interface.h:29, from evi/evi_modules.h:30, from evi/evi_core.c:26: /usr/include/sys/socket.h:166: error: expected specifier-qualifier-list before 'u_int8_t' /usr/include/sys/socket.h:184: error: expected specifier-qualifier-list before 'u_int8_t' /usr/include/sys/socket.h:254: error: expected specifier-qualifier-list before 'uid_t' /usr/include/sys/socket.h:400: error: expected specifier-qualifier-list before 'socklen_t' /usr/include/sys/socket.h:426: error: expected specifier-qualifier-list before 'socklen_t' /usr/include/sys/socket.h:482: error: expected specifier-qualifier-list before 'caddr_t' In file included from evi/evi_transport.h:30, from evi/event_interface.h:29, from evi/evi_modules.h:30, from evi/evi_core.c:26: /usr/include/sys/socket.h:497: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:498: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:499: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:500: error: expected declaration specifiers or '...' before 'uid_t' /usr/include/sys/socket.h:500: error: expected declaration specifiers or '...' before 'gid_t' /usr/include/sys/socket.h:501: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:502: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:503: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:505: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recv' /usr/include/sys/socket.h:506: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recvfrom' /usr/include/sys/socket.h:507: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recvmsg' /usr/include/sys/socket.h:508: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'send' /usr/include/sys/socket.h:509: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sendto' /usr/include/sys/socket.h:511: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sendmsg' /usr/include/sys/socket.h:512: error: expected declaration specifiers or '...' before 'socklen_t' In file included from evi/evi_transport.h:33, from evi/event_interface.h:29, from evi/evi_modules.h:30, from evi/evi_core.c:26: evi/../ip_addr.h: In function 'sockaddr2ip_addr': evi/../ip_addr.h:220: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su_cmp': evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:251: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su_getport': evi/../ip_addr.h:275: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su_setport': evi/../ip_addr.h:291: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su2ip_addr': evi/../ip_addr.h:308: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'init_su': evi/../ip_addr.h:338: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'hostent2su': evi/../ip_addr.h:375: error: 'struct sockaddr' has no member named 'sa_family' In file included from evi/../fastlock.h:54, from evi/../lock_ops.h:70, from evi/../locking.h:67, from evi/event_interface.h:31, from evi/evi_modules.h:30, from evi/evi_core.c:26:
Re: [OpenSIPS-Users] Problems compiling OpenSIPS 1.7 on OpenBSD 5.0 (error: expected specifier-qualifier-list, etc)
Hi, Taisto! It is a fix that was not ported to 1.7 until now. I have just backported it. Please update your svn sources and let me know if this doens't solve your problem. Regards, -- Răzvan Crainea OpenSIPS Developer http://opensips-solutions.org/ On 02/03/2012 05:24 PM, Taisto Qvist wrote: Hi Folks, I am trying to compile OpenSIPS 1.7(latest svn src) on OpenBSD 5.0, but I stumble fairly quickly on the below errors. Anyone who can explain what simple things I've messed up? Any help appreciated! Regards Taisto Qvist IP-Solutions.se *[root@sip] /usr/source/opensips_1_7 # gmake* Compiling evi/evi_core.c In file included from evi/evi_transport.h:30, from evi/event_interface.h:29, from evi/evi_modules.h:30, from evi/evi_core.c:26: /usr/include/sys/socket.h:166: error: expected specifier-qualifier-list before 'u_int8_t' /usr/include/sys/socket.h:184: error: expected specifier-qualifier-list before 'u_int8_t' /usr/include/sys/socket.h:254: error: expected specifier-qualifier-list before 'uid_t' /usr/include/sys/socket.h:400: error: expected specifier-qualifier-list before 'socklen_t' /usr/include/sys/socket.h:426: error: expected specifier-qualifier-list before 'socklen_t' /usr/include/sys/socket.h:482: error: expected specifier-qualifier-list before 'caddr_t' In file included from evi/evi_transport.h:30, from evi/event_interface.h:29, from evi/evi_modules.h:30, from evi/evi_core.c:26: /usr/include/sys/socket.h:497: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:498: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:499: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:500: error: expected declaration specifiers or '...' before 'uid_t' /usr/include/sys/socket.h:500: error: expected declaration specifiers or '...' before 'gid_t' /usr/include/sys/socket.h:501: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:502: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:503: error: expected declaration specifiers or '...' before 'socklen_t' /usr/include/sys/socket.h:505: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recv' /usr/include/sys/socket.h:506: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recvfrom' /usr/include/sys/socket.h:507: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'recvmsg' /usr/include/sys/socket.h:508: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'send' /usr/include/sys/socket.h:509: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sendto' /usr/include/sys/socket.h:511: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sendmsg' /usr/include/sys/socket.h:512: error: expected declaration specifiers or '...' before 'socklen_t' In file included from evi/evi_transport.h:33, from evi/event_interface.h:29, from evi/evi_modules.h:30, from evi/evi_core.c:26: evi/../ip_addr.h: In function 'sockaddr2ip_addr': evi/../ip_addr.h:220: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su_cmp': evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:251: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su_getport': evi/../ip_addr.h:275: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su_setport': evi/../ip_addr.h:291: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'su2ip_addr': evi/../ip_addr.h:308: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'init_su': evi/../ip_addr.h:338: error: 'struct sockaddr' has no member named 'sa_family' evi/../ip_addr.h: In function 'hostent2su': evi/../ip_addr.h:375: error: 'struct sockaddr' has no member named 'sa_family' In file included from evi/../fastlock.h:54, from evi/../lock_ops.h:70, from evi/../locking.h:67, from
Re: [OpenSIPS-Users] check_source_address not working with upgrade
Răzvan has fixed this issue with the latest trunk. I have tested and all is good now. Thanks Razvan and Ovidiu. On Thu, Feb 2, 2012 at 1:03 PM, duane.lar...@gmail.com wrote: I talked a little with Ovidiu offline so I went ahead and opened a bug ticket. Ticket is 3483337 check_source_address broken in latest trunk Open 2012-02-02 nobody duanelarson123 None 5 Thanks for the help Ovidiu. On , Duane Larson duane.lar...@gmail.com wrote: Yeah. It is the first one in the list (Number 15 in the dump). Like I said this worked before I upgraded. On Thu, Feb 2, 2012 at 10:56 AM, Ovidiu Sas o...@voipembedded.com wrote: The subnet is empty because you don't have any subnets (the mask is set to 32 and therefore you have full IP matching). Is the message source IP in the address_dump? Regards, Ovidiu Sas -- VoIP Embedded, Inc. http://www.voipembedded.com On Thu, Feb 2, 2012 at 11:52 AM, Duane Larson duane.lar...@gmail.com wrote: This is what I see Proxy01:/var/log# opensipsctl fifo address_dump 15 20 34 50 63 85 Proxy01:/var/log# Proxy01:/var/log# Proxy01:/var/log# Proxy01:/var/log# Proxy01:/var/log# opensipsctl fifo subnet_dump So the subnet_dump is empty. On Thu, Feb 2, 2012 at 10:48 AM, Ovidiu Sas o...@voipembedded.com wrote: Check the in memory cache: http://www.opensips.org/html/docs/modules/devel/permissions.html#id293903 See address_dump and subnet_dump. At start up, opensips will cache everything in memory. Regards, Ovidiu Sas -- VoIP Embedded, Inc. http://www.voipembedded.com On Thu, Feb 2, 2012 at 11:38 AM, duane.lar...@gmail.com wrote: I just upgraded my b2bua opensips server to the latest trunk version and now my if statements using check_source_address from the permissions module isn't working. I have the following set up loadmodule permissions.so modparam(permissions,db_url,mysql://adfasdf:dfasdf...@108.xxx.xxx.xxx /opensips) if (check_source_address(2) || check_source_address(3) || check_source_address(4)) { The INVITE comes from my SIP Proxy and worked before the upgrade without issue Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:check_src_addr_3: Looking for : 5060, 1 in tables Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:hash_match: specified group does not exist in hash table Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:match_subnet_table: subnet table is empty Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:check_src_addr_3: Looking for : 5060, 1 in tables Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:hash_match: specified group does not exist in hash table Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:match_subnet_table: subnet table is empty Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:check_src_addr_3: Looking for : 5060, 1 in tables Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:hash_match: specified group does not exist in hash table Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]: DBG:permissions:match_subnet_table: subnet table is empty This is what I have in the database Proxy01:/var/log# opensipsctl db show address +-+-++--+--+---+-+--+ | id | grp | ip | mask | port | proto | pattern | context_info | +-+-++--+--+---+-+--+ | 3 | 2 | 216.XXX.XXX.202 | 32 | 5060 | any | NULL | NULL | | 258 | 4 | 64.XXX.XXX.15 | 32 | 5060 | any | NULL | NULL | | 1 | 10 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL | | 2 | 10 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL | | 257 | 3 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL | | 4 | 2 | 216.XXX.XXX.202 | 32 | 5060 | any | NULL | NULL | +-+-++--+--+---+-+--+ I am not sure if OpenSIPS is really querying the mysql database because I don't really see any connections from the server when a call is made. How could this be possible? When I start OpenSIPS I see that it talks to the database. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] route all parking related calls to one FS server
Hi, I have opensips running nicely, followed this tutorial: http://wiki.freeswitch.org/wiki/OpenSIPS_configuration_for_2_or_more_FreeSWITCH_installs Problems happen when using call parking. Because a call can be parked on any FS server, you can't know where to pick up the parked call. A simple solution would be to direct all parking related calls to a single FS server. I've been able to direct parking calls to single FS server by matching $ru to parking extension and then setting $rd to the single FS server but it does not work when you transfer a call to that FS server. Could anyone tell me how to REFER calls to the correct parking server? I'd be happy to provide SIP traces if needed, thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIP Authentication Attacks
Hi, I know the phones are not on public IPs. Here is a opensips log of an attacker successfully registering (hashes have been scrubbed) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_newtran: transaction on entrance=(nil) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags= Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags=78 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: no transaction found Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id 0 entered Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_nonce: comparing [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728) MC=0x7ee3b0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254; is_null=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_str2val: converting STRING [] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: our result = 7f340e' Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: their response = '.7f340e, algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires: Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: authorization is OK Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:post_auth: nonce index= 3171 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_columns: freeing result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing 1 rows Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_row: freeing row values at 0x7fa090 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing rows at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_result: freeing result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: Auth attempt for xx...@yy.yy.yy.11 from 74.204.92.217 on port 5060 ret 1 -- James On Thu, Feb 2, 2012 at 12:08 AM, Dovid Bender os-l...@dovid.net wrote: James, We have found with out users that some of them put the phones on public IP’s. If the default password is not changed, no matter how hard the password is they will get in. Also try using characters like “@:^#” in your passwords. Regards, Dovid From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of aws j Sent: Thursday, February 02, 2012 06:08 To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] SIP Authentication Attacks Dear Mr James Can you attached to me your suspect file to make VoIP forensic on it . thanks Aws Msc VoIP security 2012/2/1 James Lamanna jlama...@gmail.com Hi, I've noticed lately that a server of mine is getting repeatedly hit by an attacker trying
Re: [OpenSIPS-Users] SIP Authentication Attacks
What does your whole REGISTER route look like? Maybe you are missing something in there and it is allowing someone to register even thought the password is wrong. On , James Lamanna jlama...@gmail.com wrote: Hi, I know the phones are not on public IPs. Here is a opensips log of an attacker successfully registering (hashes have been scrubbed) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_newtran: transaction on entrance=(nil) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags= Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags=78 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: no transaction found Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id 0 entered Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_nonce: comparing [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728) MC=0x7ee3b0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254; is_null=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_str2val: converting STRING [] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: our result = 7f340e' Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: their response = '.7f340e, algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires: Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: authorization is OK Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:post_auth: nonce index= 3171 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_columns: freeing result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing 1 rows Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_row: freeing row values at 0x7fa090 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing rows at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_result: freeing result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: Auth attempt for xx...@yy.yy.yy.11 from 74.204.92.217 on port 5060 ret 1 -- James On Thu, Feb 2, 2012 at 12:08 AM, Dovid Bender os-l...@dovid.net wrote: James, We have found with out users that some of them put the phones on public IP's. If the default password is not changed, no matter how hard the password is they will get in. Also try using characters like “@:^#” in your passwords. Regards, Dovid From:
Re: [OpenSIPS-Users] Trying to get Snom Contact List to work with OpenSIPS RLS
My main.c file has the following at the top /* * $Id: main.c 8506 2011-10-21 10:21:10Z vladut-paiu $ So do you think there is any point to installing the latest trunk version and seeing if it works or do you think the bug will still be in the latest version? Should I open a ticket on sourceforge? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Trying-to-get-Snom-Contact-List-to-work-with-OpenSIPS-RLS-tp7228906p7252536.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIP Authentication Attacks
On 3 February 2012 22:41, duane.lar...@gmail.com wrote: What does your whole REGISTER route look like? Maybe you are missing something in there and it is allowing someone to register even thought the password is wrong. Definitely an issue with your script. Somewhere in there you are rejecting credentials but carrying on anyway... On , James Lamanna jlama...@gmail.com wrote: Hi, I know the phones are not on public IPs. Here is a opensips log of an attacker successfully registering (hashes have been scrubbed) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_newtran: transaction on entrance=(nil) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags= Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags=78 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: no transaction found Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id 0 entered Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_nonce: comparing [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728) MC=0x7ee3b0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254; is_null=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_str2val: converting STRING [] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: our result = 7f340e' Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: their response = '.7f340e, algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires: Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: authorization is OK Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:post_auth: nonce index= 3171 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_columns: freeing result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing 1 rows Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_row: freeing row values at 0x7fa090 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing rows at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_result: freeing result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: Auth attempt for xx...@yy.yy.yy.11 from 74.204.92.217 on port 5060 ret 1 -- James On Thu, Feb 2, 2012 at 12:08 AM, Dovid Bender os-l...@dovid.net wrote: James, We have found with out users that some of
Re: [OpenSIPS-Users] SIP Authentication Attacks
Why do you say the credentials are wrong? I guess I'm missing something from the log...? www_authorize is returning 1 Here's the register handling: if (!t_newtran()) { xlog(L_ERR, Could not make new transation REGISTER - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n); sl_reply_error(); exit; } $var(auth_code) = www_authorize(asterisk, subscriber); xlog(L_INFO,Auth attempt for $fU@$fd from $si on port $Rp ret $var(auth_code)); if ( $var(auth_code) == -1 || $var(auth_code) == -2 ) { xlog(L_INFO,Auth error for $fU@$fd from $si cause $var(auth_code)); } if ( $var(auth_code) 0 ) { www_challenge(asterisk, 0); exit; } -- James On Fri, Feb 3, 2012 at 3:23 PM, dotnetdub dotnet...@gmail.com wrote: On 3 February 2012 22:41, duane.lar...@gmail.com wrote: What does your whole REGISTER route look like? Maybe you are missing something in there and it is allowing someone to register even thought the password is wrong. Definitely an issue with your script. Somewhere in there you are rejecting credentials but carrying on anyway... On , James Lamanna jlama...@gmail.com wrote: Hi, I know the phones are not on public IPs. Here is a opensips log of an attacker successfully registering (hashes have been scrubbed) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_newtran: transaction on entrance=(nil) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags= Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags=78 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: no transaction found Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id 0 entered Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_nonce: comparing [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728) MC=0x7ee3b0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254; is_null=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_str2val: converting STRING [] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: our result = 7f340e' Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: their response = '.7f340e, algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires: Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: authorization is OK Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:post_auth: nonce index= 3171 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_columns: freeing result