Re: [OpenSIPS-Users] SIPTRACE sequence issue

[MohammedShehzad]

Hi Bogdan,

Thanks for your prompt response. I was hacking into the code of
siptrace module but no success yet. Anyway something is better than
nothing.

Regards,
MohammedShehzad


> Hi Mohammed,
>
> This is more or less a limitation ; as opensips is doing parallel
> processing , you may have concurrent DB access (like inserting the
> siptrace record for 200OK and the one for ACK)...Also the DB ops
> (requiring locks) may change the sequence of the ops ( the order of the
> queries and the order of the actual db ops).
>
> There is no way to guarantee the order of the package in DB.
>
> Regards,
> Bogdan
>
> MohammedShehzad wrote:
> > Hello everybody,
> >
> > I am facing an issue in sip message sequence while I log the siptrace
> > using siptrace module.
> > The issue is random, means, generally it is fine, but sometimes the
> > SIP messages are out of sequence i.e. ACK get logged before 200OK,
> > even sometimes INVITE comes after 100 Trying or 180 ringing.
> >
> > I found that, when CDRTool list siptrace of call, the SIP messages are
> > ordered by ID, which is auto increment field. So it seems that the
> > siptraces are not being inserted properly in sequence from siptrace
> > module itself.
> > My Opensips Version : opensips-1.5.3-notls
> > MySQL database is used, and is on remote system.
> >
> > Is there anything I should try to resolve this issue? Or is this
> > bug/limitation of siptrace module itself?
> > Regards,
> > MohammedShehzad

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

[OpenSIPS-Users] need help on CDRTool

[ha do]

hi 

i try to learn CDRTool, 

i config the global.inc  with 
# Normalize engine settings
$CDRTool['normalize']['defaultCountryCode']  = "84";

the cdr_generic.php 
class CDRS {

var $CDR_class   = 'CDR';
var $intAccessCode   = '00';
var $natAccessCode   = '0';
var $maxrowsperpage  = 15;
var $status  = array();
var $normalizedField = 'Normalized';
var $DestinationIdField  = 'DestinationId';
var $BillingIdField  = 'UserName';

i config  in web

the destination
Ops,Reseller,Trusted 
peer,Domain,Subscriber,Destination,Region,Description,Incr,Min Dur,Max Dur,Max 
Price
2,084,,vietnam,6,6,0,

rate
Ops,Reseller,Rate,Destination,App,Connect,Duration,Conn In,Duration In
2,0,84,84,audio,0,998,,

profile
Ops,Reseller,Profile,Rate 1,00-H1,Rate 2,H1-H2,Rate 3,H2-H3,Rate 4,H3-24
2,0,84,84,24,0,0,,0,,0


when i make call and get the syslog of cdrtool
Nov 11 06:20:57 opensips cdrtool[2312]: MaxSessionTime Duration=36000 
callid=1289440810-2424-hiep...@192.168.1.36 From=sip:843...@192.168.1.41 
Gateway=192.168.1.36 To=sip:00842...@192.168.1.41
Nov 11 06:20:57 opensips cdrtool[2312]: MaxSessionTime=unlimited Type=postpaid 
callid=1289440810-2424-hiep...@192.168.1.36 billingparty=843...@192.168.1.41

get the log from callcontrol
Call id 1289440810-2424-hiep...@192.168.1.36 of 843...@192.168.1.41 to 
sip:00842...@192.168.1.41 is postpaid not limited


what do i miss thing to make CDRTool rating a call, please help

Thank you
Ha`



  

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

Re: [OpenSIPS-Users] OpenSIPS core dumps

[thrillerbee]

My other proxy crashed as well with these ERRORs in the syslog:

Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]:
ERROR:db_flatstore:get_name: pkg memory allocation failure
Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]:
ERROR:db_flatstore:flat_reopen_connection: failed to get_name
Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]:
ERROR:db_flatstore:flat_db_insert: uninitialized connection
Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]:
ERROR:db_flatstore:flat_db_insert: uninitialized connection
...
Nov 10 22:01:21 core2 /usr/local/sbin/opensips[22959]:
ERROR:db_flatstore:flat_db_insert: uninitialized connection
Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]:
ERROR:db_flatstore:flat_db_insert: uninitialized connection
Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]:
ERROR:db_flatstore:new_flat_id: no pkg memory left
Nov 10 22:01:22 core2 kernel: [4297088.404734] opensips[22959]: segfault at
10 ip 7f3db577e21f sp 7fffa260d640 error 4 in
db_flatstore.so[7f3db577b000+5000]

On Wed, Nov 10, 2010 at 10:19 AM, thrillerbee  wrote:

> Bogdan,
>
> Well, I spoke too soon - it's not just an issue with the opensipsctl fifo
> calls - looks more like a memory leak.  It crashed again today, but I did
> get some errors in the syslog this time right before the crash:
>  Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]:
> ERROR:db_flatstore:new_flat_id: no pkg memory left
> Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at
> 10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in
> db_flatstore.so[7fa7ff749000+5000]
> To be thorough, I've attached the backtrace & output from print commands
> (although they're the same as before).
>
> To answer your question, yes - I do use the flat_rotate MI command.
>
> Thanks again.
>
> On Wed, Nov 10, 2010 at 4:04 AM, Bogdan-Andrei Iancu <
> bog...@voice-system.ro> wrote:
>
>> Hi,
>>
>> opensipsctl takes care that each command takes a separate fifo reply, so
>> here it should be no problem. But the problem may be when comes with sending
>> multiple commands (via FIFO) in the same time - this translates into
>> parallel writes to the same file and depends on the atomicity of the write
>> op.
>>
>> But in the worst case, a mixture at the FIFO level may lead to bogus
>> command and not in any kind of crashDo you use the "flat_rotate" MI
>> command ?
>>
>> Regards,
>> Bogdan
>>
>> thrillerbee wrote:
>>
>>> Bogdan,
>>>
>>> It seems the issue is with 'opensipsctl fifo' - it's very sensitive to
>>> simultaneous calls.  Basically, I've combined all my scripts to prevent
>>> 'opensipsctl fifo' from being called too frequently and that seems (so far)
>>> to have mitigated the issue.  Is there anything one should know about how
>>> (not) to use /opensipsctl/?
>>>
>>> Thanks.
>>>
>>> On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu <
>>> bog...@voice-system.ro > wrote:
>>>
>>>Hi,
>>>
>>>strange if you do not have any errors :(
>>>
>>>I just made a fix on both trunk and 1.6 to extend some checks in
>>>flatstore and prevent crashing (even if the DB op will not be
>>>executed).
>>>
>>>Could you update from SVN and see if stops crashing ?
>>>
>>>Regards,
>>>Bogdan
>>>
>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Register attack!

[Adrian Georgescu]

This could be improved by profiling the traffic per customer and pike it 
accordingly.

Adrian

On Nov 3, 2010, at 6:23 PM, Flavio Goncalves wrote:

> Hi Saul,
> 
> I did like your solution. My only concern about Pike was to block
> legitimate traffic. A SIP dialer can easily get to the pike threshold,
> but doing pike_check_req() just for register, options and bye requests
> seems to avoid this.
> 
> The only "but" is,  the attack can also be done using INVITE and using
> Pike with INVITE can make you drop legitimate traffic, my initial
> concern. I think, that detecting authentication requests with wrong
> passwords or inexistent users is still the most generic solution. Just
> an opinion.
> 
> Best regards,
> 
> Flavio E. Goncalves
> CEO - V.Office
> OpenSIPS Bootcamp (New Jersey, NY  Nov. 15-19)
> 
> 
> 
> 
> 2010/11/3 Saúl Ibarra Corretgé :
>> On 11/03/2010 04:00 PM, Hung Nguyen wrote:
>>> Hi all, thanks for reply.
>>> 
>>> I have tested with pike module. It is very simple.
>>> 
>>> --
>>> modparam("pike", "sampling_time_unit", 3)
>>> modparam("pike", "reqs_density_per_unit", 20)
>>> 
>>> if (method = 'REGISTER | OPTION | BYE') {
>>>if (!pike_check_req()) {
>>>#TODO: do anything if you want
>>>drop();
>>>exit;
>>>}
>>> }
>>> --
>>> 
>>> I tested with sipvicious, about 5 second pike detect flood =>  drop
>>> packet or send 200 OK for register (svcrash.py will stop).
>>> You can be blook flooding with any method.
>>> 
>> 
>> Take into account that with pike module you are dropping the packets at
>> the application level, but they still enter the system. As the pike
>> module also generates syslog messages, you may want to use them in
>> combination with some other tool in order to block the traffic with
>> iptables, for example.
>> 
>> 
>> Regards,
>> 
>> --
>> Saúl Ibarra Corretgé
>> AG Projects
>> 
>> ___
>> 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
> 


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

[OpenSIPS-Users] how to add new domain in CDRTool

[ha do]

hi all

how can i add new domain in CDRTool on Rating menu
because when i add new domain the CDRTool always said error

Error: value '192.168.1.41' for field 'Domain' must be of format 'example.com' 


Thank you



  

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

Re: [OpenSIPS-Users] loose_route()

[Victor Gamov]

On 10.11.2010 13:13, Bogdan-Andrei Iancu wrote:

Hi Victor,

That is strict routing - in SIP you have 2 types of routing - Strict
Routing (old one) and Loose Routing (new one).


I see about strict and loose routing :-)

I can not understand how loose_route() process requests :-(


But in your case, the previous hop is strict route (this is why you have
opensips IP in RURI)


hmmm


and next hop (next Route) is a Loose Route (see the
lr param). So OpenSIPS is doing a Strict to Loose Routing conversion..

Lost you? :D


:-)

No problems!

I hope that loose_route() will process Route headers not RURI.

RFC-3261 16.4 says that
"The proxy MUST inspect the Request-URI of the request.  If the
   Request-URI of the request contains a value this proxy previously
   placed into a Record-Route header field (see Section 16.6 item 4),
   the proxy MUST replace the Request-URI in the request with the last
   value from the Route header field, and remove that value from the
   Route header field.  The proxy MUST then proceed as if it received
   this modified request."

So loose_route() inspect R-URI.   But R-URI
sip:74951000...@x.x.x.x:5060
is not the same as inserted into Route
(sip:X.X.X.X;lr=on;ftag=2204003977).

So Route header
Route: 
removed, R-URI untouched, next Route processed and $du is 
sip:X.X.X.X:50080 now.


As my script does not decide to call lookup() but t_relay(), then 
request forwarded to $du.


This was my (incorrect) logic...

--
CU,
Victor Gamov
<>___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

The b2b_logic module will not compile:

make[1]: Entering directory `/usr/local/src/opensips_1_6/modules/b2b_logic'
Compiling b2b_logic.c
gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall
-minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott
-Wold-style-definition -Wmissing-field-initializers -Wredundant-decls
-DMOD_NAME='"b2b_logic"'-DNAME='"opensips"' -DVERSION='"1.6.3-notls"'
-DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386
-D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local/etc/opensips/"' -DPKG_MALLOC
-DSHM_MEM  -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE
-DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC
 -DSVNREVISION='"2:7361"'  -DFAST_LOCK -DADAPTIVE_WAIT
-DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN
-DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL
-DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT
-I/usr/include/libxml2 -I/usr/local/include/libxml2 -I/usr/local/include -c
b2b_logic.c -o b2b_logic.o
Compiling logic.c
gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall
-minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott
-Wold-style-definition -Wmissing-field-initializers -Wredundant-decls
-DMOD_NAME='"b2b_logic"'-DNAME='"opensips"' -DVERSION='"1.6.3-notls"'
-DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386
-D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local/etc/opensips/"' -DPKG_MALLOC
-DSHM_MEM  -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE
-DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC
 -DSVNREVISION='"2:7361"'  -DFAST_LOCK -DADAPTIVE_WAIT
-DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN
-DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL
-DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT
-I/usr/include/libxml2 -I/usr/local/include/libxml2 -I/usr/local/include -c
logic.c -o logic.o
logic.c: In function ‘process_bridge_bye’:
logic.c:352: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:352: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:352: error: too few arguments to function ‘b2b_api.send_reply’
logic.c: In function ‘b2b_logic_notify’:
logic.c:780: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:780: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:780: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:848: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:848: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:848: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:851: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:851: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:851: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:857: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:857: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:857: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:1052: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:1052: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:1052: error: too few arguments to function ‘b2b_api.send_reply’
make[1]: *** [logic.o] Error 1
make[1]: Leaving directory `/usr/local/src/opensips_1_6/modules/b2b_logic'
make: *** [modules] Error 2

Regards.

On Wed, Nov 10, 2010 at 6:10 AM, Anca Vamanu  wrote:

>  Hi,
>
> I have found the cause of the crash and fixed it. Please update your code.
>
> Thanks and regards,
>
>
> --
> Anca Vamanuwww.voice-system.ro
>
>
>
> On 11/09/2010 06:40 PM, thrillerbee wrote:
>
> Anca,
>
>  I am seeing a crash about every 13-14 days.  I've attached the backtrace
> from this morning.
> The other problem is that OpenSIPS immediately crashes when monit tries to
> restart it. I have to manually truncate the b2b_entities & b2b_logic tables
> to get it to start w/o crashing.  I'm attaching this backtrace as well
> (called *restart*).
>
>  Thanks.
>
> On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee wrote:
>
>> Anca,
>>
>> I had not altered the code.  It core dumped pretty quickly so I was force
>> to revert to revision 7317.
>> I will try to schedule some time to retest the newest revision and see if
>> it core dumps again.
>>
>> Thanks again.
>>
>> On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu  wrote:
>>
>>>  Hi,
>>>
>>> The lines in your gdb backtrace don't match at all. Have you altered the
>>> code or is the core corrupted?
>>>
>>>
>>> R

Re: [OpenSIPS-Users] OpenSIPS core dumps

[thrillerbee]

Bogdan,

Well, I spoke too soon - it's not just an issue with the opensipsctl fifo
calls - looks more like a memory leak.  It crashed again today, but I did
get some errors in the syslog this time right before the crash:
Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]:
ERROR:db_flatstore:new_flat_id: no pkg memory left
Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at
10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in
db_flatstore.so[7fa7ff749000+5000]
To be thorough, I've attached the backtrace & output from print commands
(although they're the same as before).

To answer your question, yes - I do use the flat_rotate MI command.

Thanks again.

On Wed, Nov 10, 2010 at 4:04 AM, Bogdan-Andrei Iancu  wrote:

> Hi,
>
> opensipsctl takes care that each command takes a separate fifo reply, so
> here it should be no problem. But the problem may be when comes with sending
> multiple commands (via FIFO) in the same time - this translates into
> parallel writes to the same file and depends on the atomicity of the write
> op.
>
> But in the worst case, a mixture at the FIFO level may lead to bogus
> command and not in any kind of crashDo you use the "flat_rotate" MI
> command ?
>
> Regards,
> Bogdan
>
> thrillerbee wrote:
>
>> Bogdan,
>>
>> It seems the issue is with 'opensipsctl fifo' - it's very sensitive to
>> simultaneous calls.  Basically, I've combined all my scripts to prevent
>> 'opensipsctl fifo' from being called too frequently and that seems (so far)
>> to have mitigated the issue.  Is there anything one should know about how
>> (not) to use /opensipsctl/?
>>
>> Thanks.
>>
>> On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu <
>> bog...@voice-system.ro > wrote:
>>
>>Hi,
>>
>>strange if you do not have any errors :(
>>
>>I just made a fix on both trunk and 1.6 to extend some checks in
>>flatstore and prevent crashing (even if the DB op will not be
>>executed).
>>
>>Could you update from SVN and see if stops crashing ?
>>
>>Regards,
>>Bogdan
>>
>
Core was generated by `/usr/local/sbin/opensips -P 
/var/run/opensips/opensips.pid -m 512 -u root -g ro'.
Program terminated with signal 11, Segmentation fault.
[New process 27044]
#0  0x7fa7ff74c21f in flat_db_insert (h=0x7efb38, k=0x7fa7fe48ca60, 
v=0x7fa7fe48cd20, n=19) at flatstore.c:165
165 f = CON_FILE(h);
(gdb) bt full
#0  0x7fa7ff74c21f in flat_db_insert (h=0x7efb38, k=0x7fa7fe48ca60, 
v=0x7fa7fe48cd20, n=19) at flatstore.c:165
f = 
i = 
l = 
p = 
__FUNCTION__ = "flat_db_insert"
#1  0x7fa7fe2737ef in acc_db_request (rq=0x7fa7de27a978, rpl=) at acc.c:364
m = 19
n = 
i = 
my_ps = (db_ps_t) 0x0
__FUNCTION__ = "acc_db_request"
#2  0x7fa7fe27869e in tmcb_func (t=, type=, ps=) at acc_logic.c:386
No locals.
#3  0x7fa7ff1014a2 in run_trans_callbacks (type=256, trans=0x7fa7df8a6e00, 
req=0x7fa7de27a978, rpl=0x7efef0, code=200) at t_hooks.c:208
cbp = (struct tm_callback *) 0x7fa7dc84f6f0
backup = (struct usr_avp **) 0x771f48
trans_backup = (struct cell *) 0x7fa7df8a6e00
__FUNCTION__ = "run_trans_callbacks"
#4  0x7fa7ff1015c7 in run_trans_callbacks_locked (type=256, 
trans=0x7fa7df8a6e00, req=0x7fa7de27a978, rpl=0x7efef0, code=200) at 
t_hooks.c:254
No locals.
#5  0x7fa7ff11ea38 in relay_reply (t=0x7fa7df8a6e00, p_msg=, branch=1, msg_status=200, cancel_bitmap=0x7fffdc101ad8) at t_reply.c:1257
relay = 1
save_clone = 0
buf = 0x1184390 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKadcb.35a7dc2.0\r\nVia: SIP/2.0/UDP 
184.106.205.223;branch=z9hG4bKadcb.be5e7083.0\r\nVia: SIP/2.0/UDP 
216.18.222.3;branch=z9hG4bKadcb.18d6b484.0\r"...
res_len = 1391
relayed_code = 200
relayed_msg = (struct sip_msg *) 0x7efef0
bm = {to_tag_val = {s = 0x1 , len = 8322800}}
totag_retr = 
reply_status = RPS_COMPLETED
cb_s = {
  s = 0x1184390 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKadcb.35a7dc2.0\r\nVia: SIP/2.0/UDP 
184.106.205.223;branch=z9hG4bKadcb.be5e7083.0\r\nVia: SIP/2.0/UDP 
216.18.222.3;branch=z9hG4bKadcb.18d6b484.0\r"..., len = 1391}
text = {s = 0x18f , len = 1452}
__FUNCTION__ = "relay_reply"
#6  0x7fa7ff11f548 in reply_received (p_msg=0x7efef0) at t_reply.c:1502
last_uac_status = 
branch = 1
reply_status = 
timer = 
cancel_bitmap = 0
t = (struct cell *) 0x7fa7df8a6e00
backup_list = 
has_reply_route = 3692375232
__FUNCTION__ = "reply_received"
#7  0x0042519d in forward_reply (msg=0x7efef0) at forward.c:559
new_buf = 
to = 
new_len = 
mod = (struct sr_module *) 0x78dfe0
proto = 
id = 
send_sock = 
len = 
__FUNCTION__ = "forward_reply"
#8  0x004

Re: [OpenSIPS-Users] Dispatcher radius messages are not valid

[Maciej Bylica]

Hi Bogdan,

>From my point of view it is not so clear, because opensips and
dispatcher use the same secret (the same radiusclient.conf file) and
are located on the same server.
There are only one entry provided in radius server clients file
describing ip address (the same for opensips and dispatcher) and
secret (the same for opensips and dispatcher).
So if opensips had permission to sent messages then in the same way
dispatcher should be able to massage radius server.

Thx,
Maciej

> Hi Maciej,
>
> Sounds quite clear (from the err message) that the secrets on radius server
> and radius client are not the sameIt is not an opensips issue, it is a
> matter of configuring the radius server and radius client library.
>
> Regards,
> Bogdan
>
> Maciej Bylica wrote:
>>
>> Hello,
>>
>> I am working on opensips 1.6.3 $Revision: 4448 together with
>> media-dispatcher 2.4.3, media-relay 2.4.3, python 2.5.2-3, freeradius
>> 2.1.8, radiusclient-ng 0.5.6
>> Freeradius should gather radius messages directly from opensips and
>> dispatcher. Both are installed on the same server and use the same
>> radiusclient.conf file.
>>
>> The problem is that radius messages generated from dispatcher are not
>> taken into account while i have no problem with opensips radius
>> messages (secred for dispatcher and opensips is the same)
>> Here is an output from radius server
>>
>> Waking up in 0.10 seconds.
>> Thread 9 got semaphore
>> Thread 9 handling request 121, (13 handled so far)
>> [] Received Accounting-Request packet from client 10.1.1.229
>> with invalid signature!  (Shared secret is incorrect.) Dropping packet
>> without response.
>>
>> I've already tested freeradius-xs from debian pkg with same effect.
>> I am running 32bit os linux debian lenny.
>>
>> Has anybody similiar problem. Could you guys pls point me what should i
>> check?
>>
>> Thx in advance,
>> Maciej
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Bootcamp
> 15 - 19 November 2010, Edison, New Jersey, USA
> www.voice-system.ro
>
>
> ___
> 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] Simple ACC test with MySQL

[David Santiago]

This is the part where the ACC module is setup:

...
# - acc params -
/* what sepcial events should be accounted ? */
modparam("acc", "early_media", 1)
modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
/* by default ww do not adjust the direct of the sequential requests.
   if you enable this parameter, be sure the enable "append_fromtag"
   in "rr" module */
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "log_flag", 1)
modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_url", "mysql://opensips:opensip...@localhost/opensips")
#Pointer to the DB
modparam("acc", "db_extra", "caller_id=$fu; callee_id=$tu")
...


and this is the part where the INVITE for an initial request is handled...

...
# record routing
if (!is_method("REGISTER|MESSAGE"))
record_route();
*
# account only INVITEs
xlog("mozaa - about to check if it's an INVITE...");
if (is_method("INVITE")) {
xlog("mozaa - yes, it is. Setting flag");
setflag(1); # do accounting
}
xlog("mozaa - INVITE check done");*

if (!uri==myself)
## replace with following line if multi-domain support is used
##if (!is_uri_host_local())
{
append_hf("P-hint: outbound\r\n");
...

...and these are the traces being written to the log:

...
Nov 10 16:18:04 s18 /opt/opensipsnotls/sbin/opensips[8997]: mozaa - about to
check if it's an INVITE...
Nov 10 16:18:04 s18 /opt/opensipsnotls/sbin/opensips[8997]:
DBG:core:pv_printf: final buffer length 32
Nov 10 16:18:04 s18 /opt/opensipsnotls/sbin/opensips[8997]: mozaa - yes, it
is. Setting flag
Nov 10 16:18:04 s18 /opt/opensipsnotls/sbin/opensips[8997]:
DBG:core:pv_printf: final buffer length 25
Nov 10 16:18:04 s18 /opt/opensipsnotls/sbin/opensips[8997]: mozaa - INVITE
check done
...

On Wed, Nov 10, 2010 at 4:02 PM, Brett Nemeroff  wrote:

> On Wed, Nov 10, 2010 at 5:16 AM, David Santiago <
> david.santi...@almiralabs.com> wrote:
>
>> Modified... and still no records in the ACC table nor errors in the syslog
>> (although I have set the debug level to 9).
>>
>>
> Are you sure you are looking at the right logs? Put some xlogs into your
> code and be sure they show up as well.
>
> If you have acc loaded up, the db params set **and the db flag set during
> the INVITE**, you should either get an acc record or an error while debug is
> up.
>
> I've seen cases where depending on configuration and linux distro that it's
> tricky to tell which logfile is being written to. Or rather, perhaps it's
> not being written to the log you're expecting.
>
> -Brett
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Simple ACC test with MySQL

[Brett Nemeroff]

On Wed, Nov 10, 2010 at 5:16 AM, David Santiago <
david.santi...@almiralabs.com> wrote:

> Modified... and still no records in the ACC table nor errors in the syslog
> (although I have set the debug level to 9).
>
>
Are you sure you are looking at the right logs? Put some xlogs into your
code and be sure they show up as well.

If you have acc loaded up, the db params set **and the db flag set during
the INVITE**, you should either get an acc record or an error while debug is
up.

I've seen cases where depending on configuration and linux distro that it's
tricky to tell which logfile is being written to. Or rather, perhaps it's
not being written to the log you're expecting.

-Brett
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Load balancer probing from incorrect interface

[Bill W]

Hey Bogdan,

Yes, I have 3 listen= lines; two with public IPs and one with a private IP.

When I remove the mhomed=1 then things work as intended except for the 
probing.  I can proxy traffic correctly on all interfaces.


When I enable mhomed=1, then I get the errors below.

Thanks,
Bill


On 11/10/2010 5:38 AM, Bogdan-Andrei Iancu wrote:

Hi Bill,

is your opensips actually listening (configured as listener in .cfg) on
a interface in the private network (where the probing needs to be done) ??

Regards,
Bogdan

Bill W wrote:

Hey Bogdan,

I enabled the mhomed=1 parameter, and now I'm getting a bunch of
errors in the logs.

ERROR:tm:t_uac: no socket found
ERROR:load_balancer:lb_do_probing: probing failed
ERROR:core:get_out_socket: no socket found
ERROR:tm:uri2sock: no corresponding socket for af 2

Thoughts?

Bill


On 11/8/2010 6:05 AM, Bogdan-Andrei Iancu wrote:

Hi Bill,

as you have a multi interface system, have you tried to enable the
"mhomed" global parameter?
http://www.opensips.org/Resources/DocsCoreFcn16#toc60

Regards,
Bogdan

Bill W. wrote:

As an update, the load balancer probe appears to use the ip address
specified by the first listen= directive.

If I list the public IP first, then the probe tries to talk to the
internal IP from the external interface IP.


On 11/7/10 6:18 PM, Bill W. wrote:


Hello everyone,

I've got an opensips-1.6.3-tls installation using multiple interfaces
and load balancing.

My internal interface is rfc1918 space and my external interface has
public IPs.
listen=udp:10.0.10.3:5060
listen=udp:66.180.205.3:5060


I have the following load_balancer configuration:
id | group_id | dst_uri | probe_mode
+--+---+
1 | 1 | sip:66.180.205.11 | 2
2 | 1 | sip:66.180.205.12 | 2
3 | 2 | sip:10.0.10.1 | 2
4 | 2 | sip:10.0.10.2 | 2


What's happening is that the load balancer is trying to probe the
public
IPs from the private interface IP (and failing of course).

tcpdump output on internal interface:
18:13:26.471734 IP 10.0.10.3.5060> 66.180.205.11.5060: SIP, length:
18:13:28.473802 IP 10.0.10.3.5060> 66.180.205.11.5060: SIP, length:


Thoughts?

Thanks,
Bill

___
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




___
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] Register attack!

[Saúl Ibarra Corretgé]

Hi Flavio,

On 11/03/2010 06:23 PM, Flavio Goncalves wrote:

Hi Saul,

I did like your solution. My only concern about Pike was to block
legitimate traffic. A SIP dialer can easily get to the pike threshold,
but doing pike_check_req() just for register, options and bye requests
seems to avoid this.

The only "but" is,  the attack can also be done using INVITE and using
Pike with INVITE can make you drop legitimate traffic, my initial
concern. I think, that detecting authentication requests with wrong
passwords or inexistent users is still the most generic solution. Just
an opinion.



Of course, pike is not a solution alone. I've also seen pik ekick in if 
you have too many MESSAGEs stored on msilo for example. Different 
techniques need to be used in order to cover most of the cases, as you 
pointed out.



Regards,

--
Saúl Ibarra Corretgé
AG Projects

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

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

Hi,

I have found the cause of the crash and fixed it. Please update your code.

Thanks and regards,

--
Anca Vamanu
www.voice-system.ro



On 11/09/2010 06:40 PM, thrillerbee wrote:

Anca,

I am seeing a crash about every 13-14 days.  I've attached the 
backtrace from this morning.
The other problem is that OpenSIPS immediately crashes when monit 
tries to restart it. I have to manually truncate the b2b_entities & 
b2b_logic tables to get it to start w/o crashing.  I'm attaching this 
backtrace as well (called /restart/).


Thanks.

On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee > wrote:


Anca,

I had not altered the code.  It core dumped pretty quickly so I
was force to revert to revision 7317.
I will try to schedule some time to retest the newest revision and
see if it core dumps again.

Thanks again.

On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu mailto:a...@opensips.org>> wrote:

Hi,

The lines in your gdb backtrace don't match at all. Have you
altered the code or is the core corrupted?


Regards,

-- 
Anca Vamanu

www.voice-system.ro  



On 11/01/2010 04:35 PM, thrillerbee wrote:

Anca,

I am still seeing core dumps.  bt attached.

Thanks .

On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee
mailto:thriller...@gmail.com>> wrote:

Anca,

Thanks for the info.  I'll let you know if I have issues
after the upgrade.

Thanks.


On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu
mailto:a...@opensips.org>> wrote:

Hi,

At startup, the b2b_tables are copied into memory and
are truncated,
then the data is updated in the database at an
interval controlled by
the update_period parameter ( by default 100 seconds).

As for the core dump, if you are using trunk, can you
please update your
code? I just committed a lot of changes in those modules.

Regards,

--
Anca Vamanu
www.voice-system.ro 




On 10/26/2010 06:58 AM, thrillerbee wrote:
> I'm waiting for my b2bua box to core dump again so
I can get the
> backtrace, but is it expected behavior that
OpenSIPS cannot restart
> w/o first truncating the b2b_entities & b2b_logic
tables?  That makes
> for a messy recovery...
>
> Thanks.

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

Re: [OpenSIPS-Users] loose_route()

[Bogdan-Andrei Iancu]

Hi Victor,

That is strict routing - in SIP you have 2 types of routing - Strict 
Routing (old one) and Loose Routing (new one).


Previous described is Loose Route. What you have here is Strict Routing 
and it is a different algorithm.


In Strict Routing, RURI points to the next hop and all the hops 
(including the end point) are added as Route. Each hop (when finding 
itself in RURI) takes the next Route and moves it in RURI (that is 
standard Strict to Strict Routing- previous and next hop are both strict 
routers)


But in your case, the previous hop is strict route (this is why you have 
opensips IP in RURI) and next hop (next Route) is a Loose Route (see the 
lr param). So OpenSIPS is doing a Strict to  Loose Routing conversion..


Lost you? :D

Regards,
Bogdan

Victor Gamov wrote:

Thanks Bogdan!

Now I have one more rr-question.

ACK request received by opensips listen on X.X.X.X at port 5060

ACK sip:74951000...@x.x.x.x:5060 SIP/2.0.
Max-Forwards: 10.
Record-Route: 
Via: SIP/2.0/UDP Y.Y.Y.Y;branch=z9hG4bK9a79.79e07dd4.2
Via: SIP/2.0/UDP 
Z.Z.Z.Z:50072;rport=50072;branch=z9hG4bKc740505a77ff27fd47aeaded4f9c9287e3e68c732824a333ac632064bb1cc6d7 


Call-id: 3749305...@192_168_100_114
Cseq: 1 ACK
From: ;tag=2204003977
To: ;tag=bd829e82ae5c473bdc4d5e71154c80a7
Route: 
Route: 
Content-length: 0

loose_route() called and return true.
I expect then topmost Route-header
Route: 

will be removed, then next (last) Route header will be inspected and 
packet will be forwarded to X.X.X.X port 50080.


But R-URI rewrited to
sip:X.X.X.X:50080;lr=on

and request forwarded to X.X.X.X port 5060

log says:

DBG:core:parse_headers: flags=200
DBG:rr:is_preloaded: is_preloaded: No
DBG:core:grep_sock_info: checking if host==us: 12==12 &&  [X.X.X.X] == 
[X.X.X.X]

DBG:core:grep_sock_info: checking if port 5060 matches port 50080
DBG:core:grep_sock_info: checking if host==us: 12==12 &&  [X.X.X.X] == 
[X.X.X.X]

DBG:core:grep_sock_info: checking if port 5060 matches port 50080
DBG:core:grep_sock_info: no match for: [X.X.X.X:50080]
DBG:core:grep_aliases: no match for: [0:X.X.X.X:50080]
DBG:core:check_self: host != me
DBG:core:grep_sock_info: checking if host==us: 12==12 &&  [X.X.X.X] == 
[X.X.X.X]

DBG:core:grep_sock_info: checking if port 5060 matches port 5060
DBG:core:grep_sock_info: match found for: [X.X.X.X:5060]
DBG:core:check_self: host == me
DBG:rr:after_loose: Topmost route URI: 
'sip:X.X.X.X;lr=on;ftag=2350422187' is me

DBG:rr:after_loose: URI to be processed: 'sip:X.X.X.X:50080;lr=on'
DBG:rr:after_loose: Next URI is a loose router

before t_relay():
METHOD=ACK;
R-URI=sip:X.X.X.X:50080;lr=on;
du=sip:X.X.X.X;lr=on;ftag=2204003977;
dp=5060;


Where I'm wrong?


On 23.10.2010 16:07, Bogdan-Andrei Iancu wrote:

Victor Gamov wrote:

Sorry for my mistake. Original packet is:

---
ACK sip:5700...@x.x.x.x SIP/2.0.
Route:
To:;tag=4ded008d6ca9692485d1918f60c7da12
---

In this case the Route hdr is removed (as consumed) and the
loose_route() function true (Route driven). $du will not be set as the
only routing info in the request is the RURI, which is the default SIP
routing.


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



--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro


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

[OpenSIPS-Users] modparam?

[Anton Zagorskiy]

Hello.

Can I change module's parameter in the route block? I want to change db_url
parameter.






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




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

Re: [OpenSIPS-Users] modparam?

[Bogdan-Andrei Iancu]

Hi Anton,

no, you cannotwhat module are looking at ?

Regards,
Bogdan

Anton Zagorskiy wrote:

Hello.

Can I change module's parameter in the route block? I want to change db_url
parameter.






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




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

  



--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro


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

Re: [OpenSIPS-Users] Register attack!

[Bogdan-Andrei Iancu]

Hi Flavio,

of course you can  skip from pike check different known traffic sources 
(like diallers, gateways, etc) and also you can do pike check only for 
certain messages (like auth failed because of no user)


Regards,
Bogdan

Flavio Goncalves wrote:

Hi Saul,

I did like your solution. My only concern about Pike was to block
legitimate traffic. A SIP dialer can easily get to the pike threshold,
but doing pike_check_req() just for register, options and bye requests
seems to avoid this.

The only "but" is,  the attack can also be done using INVITE and using
Pike with INVITE can make you drop legitimate traffic, my initial
concern. I think, that detecting authentication requests with wrong
passwords or inexistent users is still the most generic solution. Just
an opinion.

Best regards,

Flavio E. Goncalves
CEO - V.Office
OpenSIPS Bootcamp (New Jersey, NY  Nov. 15-19)




2010/11/3 Saúl Ibarra Corretgé :
  

On 11/03/2010 04:00 PM, Hung Nguyen wrote:


Hi all, thanks for reply.

I have tested with pike module. It is very simple.

--
modparam("pike", "sampling_time_unit", 3)
modparam("pike", "reqs_density_per_unit", 20)

if (method = 'REGISTER | OPTION | BYE') {
   if (!pike_check_req()) {
   #TODO: do anything if you want
   drop();
   exit;
   }
}
--

I tested with sipvicious, about 5 second pike detect flood =>  drop
packet or send 200 OK for register (svcrash.py will stop).
You can be blook flooding with any method.

  

Take into account that with pike module you are dropping the packets at
the application level, but they still enter the system. As the pike
module also generates syslog messages, you may want to use them in
combination with some other tool in order to block the traffic with
iptables, for example.


Regards,

--
Saúl Ibarra Corretgé
AG Projects

___
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

  



--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro


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

Re: [OpenSIPS-Users] Registrations, Retransmissions and Nonces

[Bogdan-Andrei Iancu]

Hi Saul,

sure, go ahead.

Regards,
Bogdan

Saúl Ibarra Corretgé wrote:

Hi Bogdan,



yes, it does affect those versions too. But versions prior to 1.6 are
not officially maintained any more, so backporting fixes is not a must.
But if want, feel free to do the backports.



AFAIS the change is only a single line. Shall I commit the backport to 
branches 1.4 and 1.5?



Thanks and regards,




--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro


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