[OpenSIPS-Users] Is there new information about "WARNING ...tm-utimer...delay in execution" nowadays ?

2017-03-20 Thread Rodrigo Pimenta Carvalho 

Hi.


I have seen again that behavior from OpenSIPS that generates lots of warnings, 
like below:


Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan  1 06:19:08 [1792] 
WARNING:core:utimer_ticker: utimer task  already scheduled for 
21873780 ms (now 21873970 ms), it may overlap..
Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan  1 06:19:08 [1792] 
WARNING:core:utimer_ticker: utimer task  already scheduled for 
21873990 ms (now 21873990 ms), it may overlap..
Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan  1 06:19:08 [1793] 
WARNING:core:handle_timer_job: utimer job  has a 19 us delay in 
execution
Jan 01 06:19:26 colibri-imx6 opensips[1785]: Jan  1 06:19:26 [1792] 
WARNING:core:utimer_ticker: utimer task  already scheduled for 0 ms 
(now 21891940 ms), it may overlap..
Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan  1 06:19:43 [1792] 
WARNING:core:utimer_ticker: utimer task  already scheduled for 
21908780 ms (now 21909000 ms), it may overlap..
Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan  1 06:19:43 [1792] 
WARNING:core:utimer_ticker: utimer task  already scheduled for 
21909010 ms (now 21909010 ms), it may overlap..
Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan  1 06:19:43 [1794] 
WARNING:core:handle_timer_job: utimer job  has a 22 us delay in 
execution
Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan  1 06:19:43 [1797] 
WARNING:core:handle_timer_job: timer job  has a 22 us delay in 
execution
Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan  1 06:19:43 [1795] 
WARNING:core:handle_timer_job: timer job  has a 22 us delay in 
execution
Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan  1 06:19:43 [1793] 
WARNING:core:handle_timer_job: timer job  has a 23 us delay 
in execution
Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan  1 06:19:49 [1798] 
WARNING:core:handle_timer_job: utimer job  has a 37 us delay in 
execution
Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan  1 06:19:49 [1792] 
WARNING:core:utimer_ticker: utimer task  already scheduled for 
21914930 ms (now 21915300 ms), it may overlap..
Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan  1 06:19:49 [1792] 
WARNING:core:utimer_ticker: utimer task  already scheduled for 
21915320 ms (now 21915320 ms), it may overlap..
Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan  1 06:19:49 [1794] 
WARNING:core:handle_timer_job: utimer job  has a 3 us delay in 
execution
Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan  1 06:19:49 [1795] 
WARNING:core:handle_timer_job: utimer job  has a 3 us delay in 
execution

When it happens, I can see that OpenSIPS is using the CPU almost 100% of the 
time. And such behavior prevents others softwares in my system to work without 
problems. I see 6 process with 'OpenSIPS name and each one using 11% of CPU, 
for example. Now, the unique solution is to reboot the system.  Otherwise, the 
system remains instable and OpenSIPS continues using the CPU much more than 
usual.

Is there some new information about such issue that I should to know nowadays?
Is my hardware under minimals requirements to run OpenSIPS?
Is my script opensips.cfg wrong?

My system has the following characteristics:

CPU clock = 996000
CPU model name= ARMv7 Processor rev 10 (v7l)
 Hardware=  Freescale i.MX6 Quad/DualLite (Device Tree)

   total   used  free sharedbuffers 
cached
Mem:251140 157208  93932  0196  26304



In my script opensips.cfg I have:
---
tcp_children=4
tcp_keepalive = 1
children=4
#fork=no
auto_aliases=no

 Transaction Module
loadmodule "tm.so"
modparam("tm", "fr_timeout", 90)
modparam("tm", "fr_inv_timeout", 120)
modparam("tm", "T1_timer", 3000)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "onreply_avp_mode", 1)

Any hint will be very helpful!

Best regards.





RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] WARNING: rr: after_strict: no socket found for match second RR

2017-03-20 Thread Pat Burke 
Hello, 


I was wondering if there was a resolution to this.  I am running into the same 
thing.  It seem to be very dependent on the SIP Client that I use and how they 
interact with each other.


Thanks,
Pat Burke


HI Michele,

Could you provide (off list) a pcap for the scenario, pointing also the which 
SIP msg is generating the log you mentioned ?

Regards,

Bogdan-Andrei Iancu OpenSIPS Founder and 
Developerhttp://www.opensips-solutions.com
On 02/08/2017 11:38 AM, Michele Pinassi wrote:


Hi all,

i'm going crazy with an issue with WiFi VoIP users. Our VoIP server, Opensips 
1.11.9, was inside DMZ with public IP address 193.x.x.110 and WiFi network is 
10.x.x.x. VoIP fixed phone are inside a separated network 172.20.x.x and 
firewall allowed traffic in both directions between those nets.

When i call from a fixed phone (172.20.1.90, as example) to a client connected 
to WiFi network (ex. 10.101.8.71) it works perfectly. But, on other side, SIP 
signalling fail on a PRACK sent to 193.x.x.110 instead of 10.101.8.71, printing 
out "WARNING:rr:after_strict:no socket found for match second RR" error.

5004 was the CALLED user, 5009 the calling one, on WiFi network (10.10.1.22):

/usr/sbin/opensips[29845]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route RELAY 
INVITE To: 5004, From: 5009, RURI: sip:5004@172.20.1.33:45802
/usr/sbin/opensips[29845]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route NEW BRANCH 
To: 5004, From: 5009, RURI: sip:5004@172.20.1.33:45802
/usr/sbin/opensips[29844]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route RELAY PRACK 
To: 5004, From: 5009, RURI: sip:193.x.x.110;lr;
/usr/sbin/opensips[29849]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route MISSED CALL 
INVITE To: 5004, From: 5009, RURI: sip:5004@172.20.1.33:45802
/usr/sbin/opensips[29845]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route RELAY ACK 
To: 5004, From: 5009, RURI: sip:voip..it;transport=udp;lr



Oh the 5009 phone i did a tcpdump where i saw:

SIP/2.0 489 Bad Event

v: SIP/2.0/UDP 
10.0.8.1:34209;rport=53951;received=10.101.8.71;branch=z9hG4bKPjDD2mDOwI11dIEIX-FY-72lpXL2jS9Qvz

Record-Route: x.x.110;lr;ftag=V41fxeL-v5HuRwE4rUnVN-XRVBTsVal3>

i: 6znDCyifz4jVTBUDMGe07e2UQrdr2qCl

f: xxx.it>;tag=V41fxeL-v5HuRwE4rUnVN-XRVBTsVal3

t: xxx.it>;tag=1eC1ckc8ts5OH4mJhMwZ-RgHxEFUgMJw

CSeq: 27800 SUBSCRIBE

l: Â 0


PRACK sip:5004@193.x.x.110:26892 SIP/2.0

v: SIP/2.0/UDP 
10.0.8.1:34209;rport;branch=z9hG4bKPjghFr0FmAkMHZhWMcfUtl1mUxj-IdkyQg

Max-Forwards: 70

f: xxx.it>;tag=KgJWD-2L-MlmTD0FyxgXhlnUeIIOhYbM

t: xxx.it>;tag=aewrc0nu91

i: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub

CSeq: 13112 PRACK

Route: x.x.110;lr;ftag=KgJWD-2L-MlmTD0FyxgXhlnUeIIOhYbM;did=b8.6fcc5694>

RAck: 1 13111 INVITE

l: Â 0


SIP/2.0 404 Not here

v: SIP/2.0/UDP 
10.0.8.1:34209;received=10.101.8.71;rport=53951;branch=z9hG4bKPjghFr0FmAkMHZhWMcfUtl1mUxj-IdkyQg

f: xxx.it>;tag=KgJWD-2L-MlmTD0FyxgXhlnUeIIOhYbM

t: xxx.it>;tag=aewrc0nu91

i: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub

CSeq: 13112 PRACK

Server: VoIP

Content-Length: 0

Any hints how to solve this issue ?

Thanks, Michele

--



___ Users mailing 
listUsers@lists.opensips.orghttp://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] Help with B2B marketing scenario - receiving 491 Request Pending from GW

2017-03-20 Thread Bogdan-Andrei Iancu 

Hi Andy,

Could you post a pcap showing the whole flow from the B2B perspective - 
it will simpler to understand the problem.


Regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/14/2017 02:51 PM, Andreas Bøckmann wrote:

Hello

I am trying to use the B2B marketing scenario example as shown here 
 with 
the exception that I have another OpenSIPS instance running between 
B2B and other parties except MediaServer.


opensipsctl fifo b2b_trigger_scenario marketing 
sip:+4712...@my.domain.com  
sip:+4723456@1.2.3.4  
sip:+4723...@my.domain.com 


This executes as something like:

a)  B2B sends INVITE to Proxy (my.domain.com ) 
towards 4712345.

b)  Proxy sends this call to PSTN-GW and it works
c)  B2B sends INVITE to MediaServer (1.2.3.4) and RTP flows correctly.
d)  B2B received BYE from MediaServer

e)  B2B sends INVITE to Proxy (my.domain.com ) 
towards 4723456

f)   Proxy sends this call to PSTN-GW
g)  PSTN-GW responds 491 Request Pending for this call

My B2B is running the script found here 
 and the Proxy is running the script 
found here 


RFC 3261, 14.1 UAC Behavior States:
UAC MUST NOT initiate a new INVITE transaction within a dialog while 
another INVITE transaction is in progress in either direction. If 
there is an ongoing INVITE client transaction, the TU MUST wait until 
the transaction reaches the completed or terminated state before 
initiating the new INVITE.


Can anybody help me spot where my error is?


Thank you!

Kind regards,
Andy




___
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] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash...

2017-03-20 Thread Bogdan-Andrei Iancu 

Michele,

I don;t think that the failed reconnect events are related to the OOM 
issue - to get some disconnection is normal if you have DB cons which 
are idle for longer period of time (hours). OpenSIPS will automatically 
attempt to re-connect / connect . Do you get these reconnect errors on 
daily bases ?


Regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/16/2017 04:00 PM, Michele Pinassi wrote:


More on this issue:

/usr/sbin/opensips[1050]: 313438393637323537333232383031-kto38ogzez62 
- Failure route 0  
/usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c8ec) 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1049]: ERROR:presence:update_presentity: No E_Tag 
match [a.1489656643.1049.47170.35]
/usr/sbin/opensips[1047]: ERROR:presence:update_presentity: No E_Tag 
match [a.1489656643.1047.47360.76]
/usr/sbin/opensips[1048]: ERROR:presence:update_presentity: No E_Tag 
match [a.1489656643.1047.47329.35]
/usr/sbin/opensips[1050]: ERROR:presence:update_presentity: No E_Tag 
match [a.1489656643.1047.47330.35]
/usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c8ec) 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1052]: CRITICAL:db_mysql:db_mysql_submit_query: too 
many mysql server reconnection failures
/usr/sbin/opensips[1052]: ERROR:core:db_do_query: error while 
submitting query - [select username,domain,etag,event from presentity 
where expires<1489672563 order by username]
/usr/sbin/opensips[1052]: ERROR:presence:msg_presentity_clean: 
querying database for expired messages
/usr/sbin/opensips[1052]: CRITICAL:core:timer_ticker: timer handler 
 lasted (394 us) for more than timer tick 
(100 us) -> potential timer shifting
/usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1047]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1047]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c8ec) 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1047]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1049]: CRITICAL:db_mysql:db_mysql_submit_query: too 
many mysql server reconnection failures
/usr/sbin/opensips[1049]: ERROR:core:db_do_update: error while 
submitting query
/usr/sbin/opensips[1049]: ERROR:presence:update_presentity: updating 
published info in database
/usr/sbin/opensips[1049]: ERROR:presence:handle_publish: when updating 
presentity
/usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected: 
disconnect event for 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting 
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0xb7292054
/usr/sbin/opensips[1050]: CRITICAL:db_mysql:db_mysql_submit_query: too 
many mysql server reconnection failures
/usr/sbin/opensips[1050]: ERROR:core:db_do_update: error while 
submitting query
/usr/sbin/opensips[1050]: ERROR:presence:update_presentity: updating 
published info in database
/usr/sbin/opensips[1050]: ERROR:presence:handle_publish: when up

Re: [OpenSIPS-Users] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash...

2017-03-20 Thread Bogdan-Andrei Iancu 

Hello Michele,

Not sure if there is any relation between the 2 events (the E-tag and 
OOM). Do troubleshoot the OOM issue, see 
http://www.opensips.org/Documentation/TroubleShooting-OutOfMem - you 
will have to compile in the memory debugger, so , when an OOM event 
occurs, you can get a memory dump to check if it is a leak or a simple 
overloading of memory (simply not enough mem for your load).


Best regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/16/2017 10:05 AM, Michele Pinassi wrote:

Opensips 1.11.9-notls on a Debian 8.7 x64, with more that 700 phones
registered.

Sometimes, almost twice a week, i got a lot of:

/usr/sbin/opensips[1585]: ERROR:presence:update_presentity: No E_Tag
match [a.1489409482.1585.24993.147]
/usr/sbin/opensips[1586]: ERROR:presence:update_presentity: No E_Tag
match [a.1489409482.1584.24871.146]
/usr/sbin/opensips[1584]: ERROR:presence:update_presentity: No E_Tag
match [a.1489409482.1586.24799.146]

that, after few hours, results in a:

/usr/sbin/opensips[1585]: ERROR:tm:new_t: out of mem
/usr/sbin/opensips[1584]: WARNING:core:fm_malloc: Not enough free
memory, will attempt defragmentation
/usr/sbin/opensips[1585]: ERROR:tm:t_newtran: new_t failed
/usr/sbin/opensips[1584]: ERROR:tm:new_t: out of mem

of course, users were not happy :-) so i need suggestions how to solve
the problem or how to avoid that error cause opensips to eat all the
memory available...

Thanks, Michele



___
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] Updating from OpenSIPS 2.2.2 to 2.2.3.

2017-03-20 Thread Bogdan-Andrei Iancu 

Hi Rodrigo,

2.2.3 and 2.2.2 are minor releases on the 2.2 branch, so they differ 
only in bug fixes - there are the same in behavior, in scripting and DB 
schema.


Best regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/20/2017 02:47 PM, Rodrigo Pimenta Carvalho wrote:


Dear OpenSIPS-users;



We are finishing a project to create a product (Intercom) that uses 
OpenSIPS 2.2.2.


Things are going well with OpenSIPS.


I saw that OpenSIPS 2.2.3 fixed lots of bugs. In this case I could be 
interested in updating my OpenSIPS 2.2.2 to 2.2.3.


However, before doing that, I would like to visualize whether such 
update will need any fix in my code (opensips.cfg file).



1 - Was there some modification in some function signature (name or 
parameters) from some module?


2 - Was there some modification in the opensips database schema?



Any hint will be very helpful!

Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979


___
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] Which internal module did the hangup?

2017-03-20 Thread Bogdan-Andrei Iancu 

Hi Daniel,

That's a tricky one - mediaproxy is also using the dialog module (via 
internal API) to terminate the call. So, in both cases, the dialog 
module is doing the hangup. I guess you can spot the difference from the 
logs only :(.


Having a Reason header will make sense here.

Regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/20/2017 03:26 PM, Daniel Zanutti wrote:

I have 2 modules that may hangup the call:
 - Dialog - duration timeout or sip ping with sip options
 - Mediaproxy - RTP timeout

On local_route, is there any way to know which module did the hangup?

Thanks




___
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] Opensips drouting probing

2017-03-20 Thread Bogdan-Andrei Iancu 
Failure route does not help you if your routing does not start at all - 
if do_routing() returns negative. Again, in request route, test the 
return code for do_routing() - it will return a negative code if no 
destination is available for routing.


Regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/20/2017 02:28 PM, Denis wrote:

Hello, Bogdan!
Yes, i know about that.
In failure_route i have
if (($DLG_status == 1) && t_check_status("408"))
action. And it works if i have multiple direction (using alternative 
mode) for the prefix.
But when i use only one direction for the prefix i have the problem 
described below.

Thank you.
--
С уважением, Денис.
Best regards, Denis
20.03.2017, 15:24, "Bogdan-Andrei Iancu" :

Hi Denis,

I suspect a scripting error on your side. If all the destinations are 
disabled, the do_routing() returns a negative code into the script - 
you need to handle this case and send back whatever negative reply 
you want. The Drouting modules does not do any SIP signalling for you.


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

OpenSIPS Summit May 2017 Amsterdam
   http://www.opensips.org/events/Summit-2017Amsterdam.html
On 03/17/2017 07:50 AM, Denis via Users wrote:

Hello!
According to drouting module documentation i am trying to introduce 
a probing feature to control destination SIP UA access.

Almost everything works correct, besides one thing.
If i have only one destination, which became inaccessible, Opensips 
"freezes" a call, i.e. it sends 100 trying (script logging) and 
after does not sent any code (i expected, that Opensips will sent 
408 code in such situation after fr_timeout triggering).
Inaccessible destination has "probing" status and i see OPTIONS sent 
by Opensis to destination.

Server:: OpenSIPS (2.2.3 (x86_64/linux))
Thank you for any help.
--
С уважением, Денис.
Best regards, Denis
___
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] Which internal module did the hangup?

2017-03-20 Thread Daniel Zanutti 
I have 2 modules that may hangup the call:
 - Dialog - duration timeout or sip ping with sip options
 - Mediaproxy - RTP timeout

On local_route, is there any way to know which module did the hangup?

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

Re: [OpenSIPS-Users] Monitoring Mediaproxy

2017-03-20 Thread Daniel Zanutti 
Just counting how many is probably a good solution and very very simple.

Thanks =)

On Mon, Mar 20, 2017 at 7:00 AM, Carlos Oliva 
wrote:

> Hi Daniel!
>
> I made a little php script for Nagios some years ago that may help you.
>
> It is intented to use on opensips machine (where media dispatcher is
> running)
>
> You pass as argument the number of mediaproxy relay machines you expected
> to have and it returnks Ok and the list of your relays or error if the
> number of relays is not what you expect.
>
> It's very simple but works well, we've been using it for years. This is
> the script:
>
>
> #!/usr/bin/php
>  $errno="";
> $errstr="";
> $fp=fsockopen('127.0.0.1','25061',$errno,$errstr,'2');
> fputs($fp, "summary\r\n");
> $line  = fgets($fp);
> fclose($fp);
> $decoded=json_decode($line);
> $num_relays=0;
> $str_salida="";
> foreach($decoded as $relay)
> {
> if($relay->status=="active")
> {
> $num_relays++;
> $str_salida.=" ".$relay->ip;
> }
> }
> if($num_relays==$argv[1])
> {
> echo "OK IPs de Relays RTP: ".$str_salida."\n";
> exit(0);
> }
> else
> {
> echo "ERROR faltan Relays. IPs de Relays RTP: ".$str_salida."\n";
> exit(2);
> }
>
> ?>
>
> Best regards,
>
> Carlos Oliva
>
>
>
>
>
>
>
>
>
> 2017-03-17 18:57 GMT+01:00 Daniel Zanutti :
>
>> Understood.
>>
>> Thanks for explanation.
>>
>> Regards
>>
>> On Fri, Mar 17, 2017 at 2:47 PM, Dan Pascu  wrote:
>>
>>>
>>> On 16 Mar 2017, at 15:58, Daniel Zanutti wrote:
>>>
>>> > Hi Dan
>>> >
>>> > This is exactly how I'm monitoring but looking to the dispatcher it's
>>> kind hard on a Nagios like system, because I'm monitoring Relay A, B and C,
>>> but the status will be on dispatcher machine D. But ok, if it's the only
>>> way.
>>>
>>> The relay doesn't listen for network connections, you cannot connect
>>> directly to a relay. A relay will only connect to all configured
>>> dispatchers. The dispatcher on the other hand has a control port where you
>>> can connect and give commands, including fetching statistics from relays
>>> over the connections the relay already established with the dispatcher.
>>>
>>> --
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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

[OpenSIPS-Users] Updating from OpenSIPS 2.2.2 to 2.2.3.

2017-03-20 Thread Rodrigo Pimenta Carvalho 
Dear OpenSIPS-users;



We are finishing a project to create a product (Intercom) that uses OpenSIPS 
2.2.2.

Things are going well with OpenSIPS.


I saw that OpenSIPS 2.2.3 fixed lots of bugs. In this case I could be 
interested in updating my OpenSIPS 2.2.2 to 2.2.3.

However, before doing that, I would like to visualize whether such update will 
need any fix in my code (opensips.cfg file).


1 - Was there some modification in some function signature (name or parameters) 
from some module?

2 - Was there some modification in the opensips database schema?



Any hint will be very helpful!

Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensips drouting probing

2017-03-20 Thread Denis via Users 
Hello, Bogdan! Yes, i know about that.In failure_route i haveif (($DLG_status == 1) && t_check_status("408"))action. And it works if i have multiple direction (using alternative mode) for the prefix.But when i use only one direction for the prefix i have the problem described below. Thank you. -- С уважением, Денис.Best regards, Denis   20.03.2017, 15:24, "Bogdan-Andrei Iancu" :Hi Denis,I suspect a scripting error on your side. If all the destinations are disabled, the do_routing() returns a negative code into the script - you need to handle this case and send back whatever negative reply you want. The Drouting modules does not do any SIP signalling for you.Best regards,Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html
On 03/17/2017 07:50 AM, Denis via Users wrote:Hello! According to drouting module documentation i am trying to introduce a probing feature to control destination SIP UA access.Almost everything works correct, besides one thing.If i have only one destination, which became inaccessible, Opensips "freezes" a call, i.e. it sends 100 trying (script logging) and after does not sent any code (i expected, that Opensips will sent 408 code in such situation after fr_timeout triggering).Inaccessible destination has "probing" status and i see OPTIONS sent by Opensis to destination. Server:: OpenSIPS (2.2.3 (x86_64/linux)) Thank you for any help. -- С уважением, Денис.Best regards, Denis___
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] Detecting zombie registrations

2017-03-20 Thread Bogdan-Andrei Iancu 

Hi John,

See the remove_on_timeout_bflag parameter in nathelper module:
http://www.opensips.org/html/docs/modules/2.2.x/nathelper.html#id293676

If a contact is marked with that branch flag during registration (before 
save()), the contact will be periodically pinged and on failure it will 
removed from registration table.


Best regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/15/2017 11:39 PM, John Quick wrote:

At the last OpenSIPS Summit, I thought they announced in the keynote speech
that a mechanism was being introduced in v2.2 to detect and discard zombie
registrations.
I cannot find anything about this in the documentation (or in documentation
for v2.3).
Did this happen?  Is there a description somewhere please?

John Quick
Smartvox Limited


___
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] Opensips drouting probing

2017-03-20 Thread Bogdan-Andrei Iancu 

Hi Denis,

I suspect a scripting error on your side. If all the destinations are 
disabled, the do_routing() returns a negative code into the script - you 
need to handle this case and send back whatever negative reply you want. 
The Drouting modules does not do any SIP signalling for you.


Best regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/17/2017 07:50 AM, Denis via Users wrote:

Hello!
According to drouting module documentation i am trying to introduce a 
probing feature to control destination SIP UA access.

Almost everything works correct, besides one thing.
If i have only one destination, which became inaccessible, Opensips 
"freezes" a call, i.e. it sends 100 trying (script logging) and after 
does not sent any code (i expected, that Opensips will sent 408 code 
in such situation after fr_timeout triggering).
Inaccessible destination has "probing" status and i see OPTIONS sent 
by Opensis to destination.

Server:: OpenSIPS (2.2.3 (x86_64/linux))
Thank you for any help.
--
С уважением, Денис.
Best regards, Denis


___
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] [Release] OpenSIPS 2.3.0 major release, beta version

2017-03-20 Thread Bogdan-Andrei Iancu 

Hi Richard,

Yes, that is the correct migration.

Best regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/17/2017 01:28 PM, Richard Robson wrote:

Hi Team,

Firstly Congrats on a  job well done on getting the new Version out.

Now a qick question on the acc changes.

I inject several parmeter using the db_extra modparam. This looks to 
have changes significantly.



if I to the following in 2.2 for example:

modparam("acc", "db_extra", "caller_id=$fU;
callee_id=$tU;
caller_domain=$fd;
callee_domain=$td)

is this correct for 2.3

modparam("acc", "extra_fields", "db: caller_id->caller_id; callee_id -> 
callee_id,caller_domain -> caller_domain;callee_domain -> callee_domain")

and set these in the script at the appropriate places?

$acc_extra(caller_id) = $fU;
$acc_extra(callee_id) = $tU;
$acc_extra(caller_domain) = $fd;
$acc_extra(callee_domain) = $td;

R




On 16/03/2017 19:59, Ramachandran, Agalya (Contractor) wrote:

Congrats team for the next mile stone achievement!!!

Regards,
Agalya

-Original Message-
From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of 
Bogdan-Andrei Iancu
Sent: Thursday, March 16, 2017 3:03 PM
To:users@lists.opensips.org; 
developensips;n...@lists.opensips.org;busin...@lists.opensips.org
Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version

Hi All !!

Almost 2 months ago I was posting [1] :  “A new year has arrived, so it is the 
time for a new OpenSIPS major release – for OpenSIPS version 2.3 “.

Well, this just happened !!

I’m happy to announce the beta version of the OpenSIPS 2.3.0 major release. 
Curios to find out more about this release ?
See the philosophy behind this release by reading the overview of OpenSIPS 
2.3.o, code name *integration* :

  http://www.opensips.org/About/Version-Overview-2-3-0

Enjoy it !!!


[1]https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/

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

OpenSIPS Summit May 2017 Amsterdam
http://www.opensips.org/events/Summit-2017Amsterdam.html


___
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



--
Richard Robson
Greenlight Support
01382 843843
supp...@greenlightcrm.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] Siptrace crash

2017-03-20 Thread Ionut Ionita 

Hello Schneur,

I'm sorry but I can't figure out where the problem is from unless 
you'll give me more details ( a stack trace, or some details about the 
scenario).


Ionut Ionita
OpenSIPS Developer

On 03/19/2017 12:52 PM, Schneur Rosenberg wrote:

Would this help? I dont have a memory dump

Mar 17 19:27:01 sip10 kernel: [115810.179291] opensips[1297]: segfault
at 18 ip 7f3e0ddf1592 sp 7ffeda1c2fe0 error 4 in
siptrace.so[7f3e0dde5000+22000]
Mar 17 19:27:01 sip10 /sbin/opensips[1601]: CRITICAL:core:receive_fd: EOF on 33

___
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] Monitoring Mediaproxy

2017-03-20 Thread Carlos Oliva 
Hi Daniel!

I made a little php script for Nagios some years ago that may help you.

It is intented to use on opensips machine (where media dispatcher is
running)

You pass as argument the number of mediaproxy relay machines you expected
to have and it returnks Ok and the list of your relays or error if the
number of relays is not what you expect.

It's very simple but works well, we've been using it for years. This is the
script:


#!/usr/bin/php
status=="active")
{
$num_relays++;
$str_salida.=" ".$relay->ip;
}
}
if($num_relays==$argv[1])
{
echo "OK IPs de Relays RTP: ".$str_salida."\n";
exit(0);
}
else
{
echo "ERROR faltan Relays. IPs de Relays RTP: ".$str_salida."\n";
exit(2);
}

?>

Best regards,

Carlos Oliva








2017-03-17 18:57 GMT+01:00 Daniel Zanutti :

> Understood.
>
> Thanks for explanation.
>
> Regards
>
> On Fri, Mar 17, 2017 at 2:47 PM, Dan Pascu  wrote:
>
>>
>> On 16 Mar 2017, at 15:58, Daniel Zanutti wrote:
>>
>> > Hi Dan
>> >
>> > This is exactly how I'm monitoring but looking to the dispatcher it's
>> kind hard on a Nagios like system, because I'm monitoring Relay A, B and C,
>> but the status will be on dispatcher machine D. But ok, if it's the only
>> way.
>>
>> The relay doesn't listen for network connections, you cannot connect
>> directly to a relay. A relay will only connect to all configured
>> dispatchers. The dispatcher on the other hand has a control port where you
>> can connect and give commands, including fetching statistics from relays
>> over the connections the relay already established with the dispatcher.
>>
>> --
>> Dan
>>
>>
>>
>>
>>
>> ___
>> 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] OpenSIPS debug logging SIP packets it deems non-local

2017-03-20 Thread Răzvan Crainea 

Hi, Jock!

If you are not seeing anything in the logs, it means that OpenSIPS 
doesn't even receive the message.
I would first try to make a ngrep trace and see if the reply message 
gets on the machine. Next, I would double check the firewall rules of 
the machine, perhaps disabling the completely.


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/15/2017 11:16 PM, Jock McKechnie wrote:

We have an existing call flow layout that effectively runs:
"SBC" -> "OpenSIPS LB" -> "FreeSWITCH"

and have recently added a middleman for completely abstract reasons so
it now goes:
"SBC" -> "OpenSIPS A" -> "OpenSIPS LB" -> "FreeSWITCH"

And all of a sudden the LB OpenSIPS is unable to see replies from the
FreeSWITCH. My thinking at this time is that the LB has decided the
200 OKs coming back from FreeSWITCH are not actually destined for it,
so it's ignoring them, as if were a stray packet on a different
dialogue that it's not able to understand mid-stream and dumps.

The LB OpenSIPS is running a reasonably old version of OpenSIPS at
present, pending a mass corporate upgrade - 1.8.5.

I have the 'debug' level set to '9' and I'm not seeing any hints that
OpenSIPS is seeing the discarded/ignored SIP packets in the log at
all. Is this action _not_ logged, or am I barking up the wrong tree
and OpenSIPS isn't even seeing this packet at all?

Apologies for long-winded lead up to a simple question, but I wanted
to be thorough.

As always, many thanks;

  - Jock

___
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