Re: [OpenSIPS-Users] unsubscribe or 481 not working

[Aron Podrigal]

are the notifies you see after unsubscribing for new dialogs or for dialogs
created while the UA was still subscribed?

when a UA unsubscribes I think the presence server is stll suppose to
continue notifying the ua for any remaining active dialogs. correct me if
I'm wrong.

On Wed, Jan 25, 2017, 6:34 PM Tito Cumpen  wrote:

> the previously subscribed address. The UA will respond will respond with a
> 481 but opensips just continues to send the notifies although they are no
> longer subscribed. Is there any reason for this behavior?I am seeing
> this from opensips logs WARNING:presence:p_tm_callback: completed with
> status [481] and to_tag [688612044cccea408f6da88d48100390-629d], cseq
> [CSeq: 1] Does anyone have any idea why ?
>
> On Wed, Jan 25, 2017 at 6:30 PM, Tito Cumpen  wrote:
>
> Group,
>
> I am having issues handling the removal of subscriptions in presence. I am
> using opensips 2.2.2 git revision b0fbe60. My UA is sending subscription
> with an expire 0 and opensips responds with 200 ok like this
> SIP/2.0 200 OK
> Via: SIP/2.0/WSS
> 192.0.2.67;received=xx.xx.xxx.xx;rport=49679;branch=z9hG4bK4495443
> To: ;tag=688612044cccea408f6da88d48100390-629d
> From: "Dave Drummond, MD" ;tag=j58ltmkvo3
> Call-ID: 2oc1fhb8h11j4qupkd4n
> CSeq: 4305 SUBSCRIBE
> Expires: 0
> Contact: 
> Server: domain.org
> Content-Length: 0
>
> opensips continues to send notifies on reference to address th
>
>
> ___
> 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] send_reply from branch_route

[Pat Burke]

Hello,

I have an opensips server that I use for routing.  I receive a call and will 
attempt multiple carriers to complete the call.  My understanding is that in 
2.2 I had to use branch_route to be able to make multiple attempts.  What I am 
running into now is that when I get a SIP response that indicates that I don't 
want to try another carrier, or I have tried as many as I want to try, then I 
want to send a SIP response (ether the response from the last carrier or a 
response of my own) and end the call.  When I t_reply I get the following error 
            "CRITICAL:tm:w_t_reply: unsupported route_type (8)".


In a nutshell, the flow is


1)  Call flow leads to RELAY_TO_EGRESS to make the first call.
2)  RELAY_TO_EGRESS sets up the call information by calling OUTBOUND_SETUP 
(which will attempt to terminate the call if there are errors or no more 
carriers) and then creates a branch to handle the attempt (BRANCH_TO_EGRESS)
3)  BRANCH_TO_EGRESS does some final setup (setting up headers, etc) and sets 
the t_on_failure to "egress_failed"
4)  If the call attempt fails, "egress_failed" is called which may want to 
terminate the call (send_reply...) or attempt again by calling 
TRY_CARRIER_FAILOVER
5) TRY_CARRIER_FAILOVER will start the process again by calling RELAY_TO_EGRESS 
(which usually ends in the call to OUTBOUND_SETUP because that is where it 
determines when no more attempts are going to be made).


In 1.11 without branching this worked fine.


What is the correct way to architect the code.  Here is the general structure I 
have now.


...


route[RELAY_TO_EGRESS] {
    route(OUTBOUND_SETUP);
    t_on_branch("BRANCH_TO_EGRESS");


    if (!t_relay("0x01")) {
        send_reply("500","Internal Error");
        exit;
    }
}


route[OUTBOUND_SETUP] {
...
                if ($avp(current_carrier_idx) == $avp(out_routes_no)) {
                    route(NO_ROUTES_AVAILABLE, "No more routes available.");
                }
...
    if (!route(VALIDATE_CARRIER)) {
        route(TRY_CARRIER_FAILOVER, "503", "In supplemental exclusion.");
        return(1);
    }
}


branch_route[BRANCH_TO_EGRESS] {
...
    t_on_failure("egress_failed");
...
}


route[NO_ROUTES_AVAILABLE] {
    xlog("L_WARN", "$rU SCRIPT:EGRESS:WARN: No carriers to route to.  Ending 
the call \n");
    $avp(error_reason) := $avp(error_reason) + $param(1);
    t_reply("503","Service not available.");
    exit;
}


failure_route[egress_failed] {
...
    if (t_was_cancelled()) {
        route(ADD_STATUS_ERROR_REASON_TO_HISTORY, $(rs), $(rr));
        xlog("L_WARN", "$rU SCRIPT:RADVANCE:WARN: Do not route advance replying 
with $(rs) - $(rr) \n");
        $avp(error_reason) := $avp(error_reason) + "Call Terminated with " + 
$(rs) + ".";
        t_reply("487","Request cancelled");
        exit;
    }


    if ($(rs) != null) {
        route(TRY_CARRIER_FAILOVER, $(rs), $(rr));
    } else {
        $avp(error_reason) := $avp(error_reason) + "Server Error V2 - empty 
response (rs).";
        route(TRY_CARRIER_FAILOVER, "503", "Server Error");
    }


    exit;
}


route[TRY_CARRIER_FAILOVER] {

   route(RELAY_TO_EGRESS);
}
}


Thanks,
Pat Burke




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

Re: [OpenSIPS-Users] unsubscribe or 481 not working

[Tito Cumpen]

the previously subscribed address. The UA will respond will respond with a
481 but opensips just continues to send the notifies although they are no
longer subscribed. Is there any reason for this behavior?I am seeing
this from opensips logs WARNING:presence:p_tm_callback: completed with
status [481] and to_tag [688612044cccea408f6da88d48100390-629d], cseq
[CSeq: 1] Does anyone have any idea why ?

On Wed, Jan 25, 2017 at 6:30 PM, Tito Cumpen  wrote:

> Group,
>
> I am having issues handling the removal of subscriptions in presence. I am
> using opensips 2.2.2 git revision b0fbe60. My UA is sending subscription
> with an expire 0 and opensips responds with 200 ok like this
> SIP/2.0 200 OK
> Via: SIP/2.0/WSS 192.0.2.67;received=xx.xx.xxx.xx;rport=49679;branch=
> z9hG4bK4495443
> To: ;tag=688612044cccea408f6da88d48100390-629d
> From: "Dave Drummond, MD" ;tag=j58ltmkvo3
> Call-ID: 2oc1fhb8h11j4qupkd4n
> CSeq: 4305 SUBSCRIBE
> Expires: 0
> Contact: 
> Server: domain.org
> Content-Length: 0
>
> opensips continues to send notifies on reference to address th
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] unsubscribe or 481 not working

[Tito Cumpen]

Group,

I am having issues handling the removal of subscriptions in presence. I am
using opensips 2.2.2 git revision b0fbe60. My UA is sending subscription
with an expire 0 and opensips responds with 200 ok like this
SIP/2.0 200 OK
Via: SIP/2.0/WSS
192.0.2.67;received=xx.xx.xxx.xx;rport=49679;branch=z9hG4bK4495443
To: ;tag=688612044cccea408f6da88d48100390-629d
From: "Dave Drummond, MD" ;tag=j58ltmkvo3
Call-ID: 2oc1fhb8h11j4qupkd4n
CSeq: 4305 SUBSCRIBE
Expires: 0
Contact: 
Server: domain.org
Content-Length: 0

opensips continues to send notifies on reference to address th
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] scheduled concurrent call reporting

[Abdul Basit]

Khalil,

Why don't you consider snmpstat module for stats collection from opensips?


On 25 Jan 2017 17:12, "Khalil Khamlichi"  wrote:

> Liviu, you just saved my day. my plan is to push information to redis
> every 10s maybe 5s if need there is, when dashboard is complete I might
> consider saving the stream of data for plotting and further analysis.
>
>
> On Wed, Jan 25, 2017 at 11:45 AM, Liviu Chircu  wrote:
>
>> I do not see any problems with calling "get_profile_size()" from timer
>> routes, event routes, etc. As such, you can safely bypass the block
>> restriction using the following example:
>>
>> route [get_prof_sz_inboundCalls] {
>> get_profile_size("inboundCalls",,"$var(size)");
>> }
>>
>> route [get_prof_sz_outboundCalls] {
>> get_profile_size("outboundCalls",,"$var(size)");
>> }
>>
>> timer_route [mytimer, 1]
>> {
>> route(get_prof_sz_inboundCalls);
>> xlog("inboundCalls: $var(size)\n");
>>
>> route(get_prof_sz_outboundCalls);
>> xlog("outboundCalls: $var(size)\n");
>> }
>>
>> Regards,
>>
>> Liviu Chircu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 24.01.2017 01:05, Khalil Khamlichi wrote:
>>
>> the idea is that I don't need to get the number of calls 30 times per
>> second which would happens if I save to redis on each invite. scheduling
>> the saving to redis every 10 seconds serves  well my purpose but the
>> timer_route doesn't seem to accept get_profile_size()
>>
>> any hints would be appreciated.
>>
>> On Mon, Jan 23, 2017 at 10:39 PM, Khalil Khamlichi <
>> khamlichi.kha...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am trying to get call load information out of opensips at regular
>>> intervals to get some sort of realtime view of the load on the server.
>>>
>>> After applying profiles on the the INVITEs, I have tried to call
>>> get_profile_size from a timer_route.
>>> I am getting error :
>>>
>>> CRITICAL:core:yyerror: parse error in config file
>>> /usr/local//etc/opensips/opensips.cfg, line 483, column 38-39: Command
>>> cannot be used in the block
>>>
>>> Any alternative solutions ?
>>>
>>> Thanks in advance.
>>>
>>> kkh
>>>
>>
>>
>>
>> ___
>> 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
>>
>>
>
> ___
> 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] [BLOG] Real-time billing using OpenSIPS 2.3 and CGRateS

[Răzvan Crainea]

Hello all!

The upcoming OpenSIPS 2.3 will have built-in integration with the 
CGRateS engine, providing a simple way to do real-time billing/charging. 
Check out more information on our blog:


https://blog.opensips.org/2017/01/25/real-time-billing-using-cgrates

Best regards,

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


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

Re: [OpenSIPS-Users] calling create_dialog() on failover

[Richard Robson]

I may be answering my own question here, But I going to say Thay I 
should be using match_dialog to see if there is an existing dialog and 
only create one if there is not one already/


R

On 25/01/2017 16:42, Richard Robson wrote:
I'm wanting to check rate limits and channel limits for calls over 
several gateways. this I have working, but we are getting instances of 
failures on upstream carriers. this is due to one carrier in paricular 
not liking the CLIs our customers are calling from. In this case the 
call comes back as a 403, which I want to failover from the  
t_on_failure route to the next gateway. If I reuse my relay route it 
it will have a subsequent create_dialog() it also does the topology 
hiding and accounting in. Am I OK to recall the create dialog and 
reuse the relay route or am i better to do a second route to relay the 
call to the next gateway assuming that this will be the same dialog 
from the original call.



Regards,





--
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

[OpenSIPS-Users] calling create_dialog() on failover

[Richard Robson]

I'm wanting to check rate limits and channel limits for calls over 
several gateways. this I have working, but we are getting instances of 
failures on upstream carriers. this is due to one carrier in paricular 
not liking the CLIs our customers are calling from. In this case the 
call comes back as a 403, which I want to failover from the  
t_on_failure route to the next gateway. If I reuse my relay route it it 
will have a subsequent create_dialog() it also does the topology hiding 
and accounting in. Am I OK to recall the create dialog and reuse the 
relay route or am i better to do a second route to relay the call to the 
next gateway assuming that this will be the same dialog from the 
original call.



Regards,


--

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

Re: [OpenSIPS-Users] FW: OpenSIPs 2.2.2 warnings during start service

[Ramachandran, Agalya (Contractor)]

Hi Bogdan,

Yes, am having tar ball of the 2.2 source code released in Oct 2016.
On top of it, I have added the fix in timer.c . That’s all I have.

https://github.com/OpenSIPS/opensips/commit/68d4240698e639490ab7dfa187b1458f00146fb3

I am running OpenSIPS in VM.

Regards,
Agaya

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Wednesday, January 25, 2017 4:23 AM
To: Ramachandran, Agalya (Contractor) ; 
OpenSIPS users mailling list 
Subject: Re: FW: [OpenSIPS-Users] OpenSIPs 2.2.2 warnings during start service

Hi Agalya,

That is really weird - I suppose you are using the latest 2.2, right ?

Are you using a VM or container to run OpenSIPS ?

Regards,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 01/24/2017 06:42 PM, Ramachandran, Agalya (Contractor) wrote:


From: Ramachandran, Agalya (Contractor)
Sent: Tuesday, January 24, 2017 11:42 AM
To: 'Bogdan-Andrei Iancu' 
Subject: RE: [OpenSIPS-Users] OpenSIPs 2.2.2 warnings during start service

Hi Bogdan,


1)  do you get warning only for the tm-utimer job ? or do you see other too 
?
I rarely see from blcore-expire job too.
  2)do you have some load on the server (in terms of traffic) ? or is 
it idle/almost-idle ?
Mostly its idle, May be it will process 5 to 10 calls in an hour. That is the 
load it is been handling right now.

Giving the Process id and its same logs.

Process::  ID=0 PID=11744 Type=attendant
Process::  ID=1 PID=11745 Type=MI FIFO
Process::  ID=2 PID=11746 Type=time_keeper
Process::  ID=3 PID=11747 Type=timer
Process::  ID=4 PID=11748 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=5 PID=11749 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=6 PID=11750 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=7 PID=11751 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=8 PID=11752 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=9 PID=11753 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=10 PID=11754 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=11 PID=11755 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=12 PID=11756 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=13 PID=11757 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=14 PID=11758 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=15 PID=11759 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=16 PID=11760 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=17 PID=11761 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=18 PID=11762 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=19 PID=11763 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=20 PID=11764 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=21 PID=11765 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=22 PID=11766 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=23 PID=11767 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=24 PID=11768 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=25 PID=11769 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=26 PID=11770 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=27 PID=11771 Type=SIP receiver udp:10.0.0.1:5060
Process::  ID=28 PID=11772 Type=Timer handler

Jan 23 22:36:29 /usr/local/sbin/opensips[11771]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 22:49:42 /usr/local/sbin/opensips[11767]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 22:53:15 /usr/local/sbin/opensips[11771]: WARNING:core:handle_timer_job: 
timer job  has a 8 us delay in execution
Jan 23 22:53:15 /usr/local/sbin/opensips[11753]: WARNING:core:handle_timer_job: 
timer job  has a 8 us delay in execution
Jan 23 22:55:06 /usr/local/sbin/opensips[11771]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 22:59:37 /usr/local/sbin/opensips[11767]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 23:07:20 /usr/local/sbin/opensips[11771]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 23:29:51 /usr/local/sbin/opensips[11771]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 23:30:11 /usr/local/sbin/opensips[11771]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 23:30:26 /usr/local/sbin/opensips[11772]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution
Jan 23 23:35:55 /usr/local/sbin/opensips[11758]: WARNING:core:handle_timer_job: 
utimer job  has a 3 us delay in execution
Jan 23 23:35:55 /usr/local/sbin/opensips[11771]: WARNING:core:handle_timer_job: 
utimer job  has a 2 us delay in execution

Regards,
Agalya

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Tuesday, January 24, 2017 11:09 AM
To: Ramachandran, Agalya (Contractor) 
>; 
OpenSIPS users 

Re: [OpenSIPS-Users] OpenSIPs 2.2.2 warnings during start service

[Bogdan-Andrei Iancu]

Hi,

That explains - during the execution of the startup route the rest of 
worker-like processes are not yet created (we wait to have the startup 
route finished), while the timer is already fires. So it triggers some 
timer jobs but there is no proc available to handle them.


This is a corner case, still I'm thinking of a solution on how to go 
around it. Still, at the end, there is nothing wrong (the timer jobs 
will still be handled, but later, after startup route is done), but you 
get those warnings.


Regards,

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

On 01/24/2017 11:28 PM, Ahmed Munir wrote:
Yes, this works not to do DB op during route startup script and 
eliminate the warnings.



I would like to know, what method will you recommend for route startup 
DB op in opensips 2.2?


On Tue, Jan 24, 2017 at 9:12 AM, Bogdan-Andrei Iancu 
> wrote:


The versions before 2.1 had a completely different approach on hoe
the timer jobs were handled - different code, so no such warnings.
The 2.1 introduces the a more flexible and scalable processing for
the timer jobs.

Could you confirm that removing the DB op from the startup route
eliminates the warnings ?

Thanks,

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

On 01/24/2017 03:49 PM, Ahmed Munir wrote:

Yes, using startup route in my routing script and running DB
query. This kind of warning I didn't face using 1.6 and 1.8
opensips versions but 2.2.2.
Will you recommend async statement for my current routing (see
below) for the startup? startup_route { $var(res) = 1;
$avp(tmp) = "1";# $var(x) = 0; while($var(res) > 0) {

$var(res) = avp_db_query("SELECT Distinct One800, dnis
FROM DNIS_Mapping where One800 > $avp(tmp) order by One800;",
"$avp(One800), $avp(dnis)"); if($var(res) >= 0) {
$var(i) = 0;
while($(avp(One800)[$var(i)]) != "NULL") {

cache_store("local",
"DNIS_$(avp(dnis)[$var(i)])", "$(avp(One800)[$var(i)])");
$avp(tmp) = $(avp(One800)[$var(i)]);
 #   $var(x) = $var(x) + 1;
$(avp(One800)[$var(i)]) = "NULL";
$var(i) = $var(i) + 1;
#   xlog("$var(x) : $(avp(s:dnis)[$var(i)])");

} } } }
On Tue, Jan 24, 2017 at 6:38 AM, Bogdan-Andrei Iancu
> wrote:

Hi Ahmed, So, the warnings pop up ONLY during startup
sequence.  Do you use startup route or any module performing
mem caching of some DB table (drouting, permission, etc) ?
Usually, the first UDP child is doing some heavy lifting
during startup.Regards,

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


On 01/19/2017 06:01 PM, Ahmed Munir wrote:

Hi Razvan,
During starting up the opensips service, I see the first
opensips child process (pid"11172) consumes CPU process to
70-80% and later drop downs to 0.3 - 0.0 % CPU per core. See
below; [root@qorblpsisprxyd1 ~]# top -c -u opensips top -
10:49:54 up 76 days, 23:31,  5 users,  load average: 0.00,
0.00, 0.00 Tasks: 229 total,   1 running, 228 sleeping,   0
stopped,   0 zombie Cpu(s):  0.0%us,  0.1%sy,  0.0%ni,
99.9%id,  0.0%wa,  0.0%hi, 0.0%si,  0.0%st Mem:  65964364k
total,  2568124k used, 63396240k free,   180220k buffers
Swap:  1023996k total,0k used,  1023996k free, 
1226104k cached   PID USER  PR  NI  VIRT  RES  SHR S

%CPU %MEMTIME+ COMMAND 11177 opensips  20   0  165m 5696
4528 S  0.3  0.0   0:00.23 /usr/sbin/opensips -P
/var/run/opensips.pid -m 64 -u opensips -g opensips 11187
opensips  20   0  165m 5628 4460 S  0.3  0.0   0:00.41
/usr/sbin/opensips -P /var/run/opensips.pid -m 64 -u
opensips -g opensips 11166 opensips  20   0  165m 6892 5752
S  0.0  0.0   0:00.23 /usr/sbin/opensips -P
/var/run/opensips.pid -m 64 -u opensips -g opensips 11168
opensips  20   0  165m 1980  840 S  0.0  0.0   0:00.00
/usr/sbin/opensips -P /var/run/opensips.pid -m 64 -u
opensips -g opensips 11169 opensips  20   0  165m 1464  328
S  0.0  0.0   0:00.53 /usr/sbin/opensips -P
/var/run/opensips.pid -m 64 -u opensips -g opensips 11171
opensips  20   0  165m 1640  504 S  0.0  0.0   0:00.15
/usr/sbin/opensips -P /var/run/opensips.pid -m 64 -u
opensips -g opensips 11172 opensips  20   0  166m  40m  38m

Re: [OpenSIPS-Users] how to catch hangup event inside opensips

[Liviu Chircu]

There are several ways of doing this, to name a few:

- catch CDR events (E_ACC_CDR) [1] in the event_route, and go from 
there. This is the most straight-forward solution, giving you lots of 
information to work with. However, you must be using the "acc" module in 
order for it to work.


- catch dialog state change events (E_DLG_STATE_CHANGED) [2] in the 
event_route, go from there. The idea is to detect when a dialog goes 
from state 4 (confirmed) -> 5 (deleted). A problem with this approach 
might be the limited amount of information available in the event route.


- simply catch all BYE requests in your OpenSIPS script, and go from 
there. The tricky part with this approach is to not forget about the 
auto-generated BYEs (calls cut by OpenSIPS), by also doing some handling 
inside the "local route".


[1]: http://www.opensips.org/html/docs/modules/2.3.x/acc#id295391
[2]: http://www.opensips.org/html/docs/modules/2.3.x/dialog.html#id297615

Regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 25.01.2017 14:52, Khalil Khamlichi wrote:
sorry the expression "run a route" was misleading, actually we are 
working on a dashboard, we need to catch events happening inside 
opensips to feed our counters, we hope to be able to catch hangup 
event and probably the sip_code so that we can have counters for every 
sip code specific to every gateway. the other way around this is to 
catch the cdr insert and feed counters.


On Wed, Jan 25, 2017 at 12:32 PM, Stefano Pisani 
> wrote:


please explain better

Il 25 Gennaio 2017 13:24:57 CET, Khalil Khamlichi
>
ha scritto:

there is one more question we still struggling with, how to
run a route at each hangup, we never found any way to do it
inside opensips. right now we catching the event upon cdr
insert in db.


-- Inviato dal mio cellulare Android con K-9 Mail.
___
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] how to catch hangup event inside opensips

[Khalil Khamlichi]

sorry the expression "run a route" was misleading, actually we are working
on a dashboard, we need to catch events happening inside opensips to feed
our counters, we hope to be able to catch hangup event and probably the
sip_code so that we can have counters for every sip code specific to every
gateway. the other way around this is to catch the cdr insert and feed
counters.

On Wed, Jan 25, 2017 at 12:32 PM, Stefano Pisani  wrote:

> please explain better
>
> Il 25 Gennaio 2017 13:24:57 CET, Khalil Khamlichi <
> khamlichi.kha...@gmail.com> ha scritto:
>>
>> there is one more question we still struggling with, how to run a route
>> at each hangup, we never found any way to do it inside opensips. right now
>> we catching the event upon cdr insert in db.
>>
>
> -- Inviato dal mio cellulare Android con K-9 Mail.
> ___
> 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] how to catch hangup event inside opensips

[Stefano Pisani]

please explain better

Il 25 Gennaio 2017 13:24:57 CET, Khalil Khamlichi  
ha scritto:
>there is one more question we still struggling with, how to run a route
>at
>each hangup, we never found any way to do it inside opensips. right now
>we
>catching the event upon cdr insert in db.

-- Inviato dal mio cellulare Android con K-9 Mail.___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] how to catch hangup event inside opensips

[Khalil Khamlichi]

there is one more question we still struggling with, how to run a route at
each hangup, we never found any way to do it inside opensips. right now we
catching the event upon cdr insert in db.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] scheduled concurrent call reporting

[Khalil Khamlichi]

Liviu, you just saved my day. my plan is to push information to redis every
10s maybe 5s if need there is, when dashboard is complete I might consider
saving the stream of data for plotting and further analysis.


On Wed, Jan 25, 2017 at 11:45 AM, Liviu Chircu  wrote:

> I do not see any problems with calling "get_profile_size()" from timer
> routes, event routes, etc. As such, you can safely bypass the block
> restriction using the following example:
>
> route [get_prof_sz_inboundCalls] {
> get_profile_size("inboundCalls",,"$var(size)");
> }
>
> route [get_prof_sz_outboundCalls] {
> get_profile_size("outboundCalls",,"$var(size)");
> }
>
> timer_route [mytimer, 1]
> {
> route(get_prof_sz_inboundCalls);
> xlog("inboundCalls: $var(size)\n");
>
> route(get_prof_sz_outboundCalls);
> xlog("outboundCalls: $var(size)\n");
> }
>
> Regards,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 24.01.2017 01:05, Khalil Khamlichi wrote:
>
> the idea is that I don't need to get the number of calls 30 times per
> second which would happens if I save to redis on each invite. scheduling
> the saving to redis every 10 seconds serves  well my purpose but the
> timer_route doesn't seem to accept get_profile_size()
>
> any hints would be appreciated.
>
> On Mon, Jan 23, 2017 at 10:39 PM, Khalil Khamlichi <
> khamlichi.kha...@gmail.com> wrote:
>
>> Hi,
>>
>> I am trying to get call load information out of opensips at regular
>> intervals to get some sort of realtime view of the load on the server.
>>
>> After applying profiles on the the INVITEs, I have tried to call
>> get_profile_size from a timer_route.
>> I am getting error :
>>
>> CRITICAL:core:yyerror: parse error in config file
>> /usr/local//etc/opensips/opensips.cfg, line 483, column 38-39: Command
>> cannot be used in the block
>>
>> Any alternative solutions ?
>>
>> Thanks in advance.
>>
>> kkh
>>
>
>
>
> ___
> 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
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] scheduled concurrent call reporting

[Liviu Chircu]

I do not see any problems with calling "get_profile_size()" from timer 
routes, event routes, etc. As such, you can safely bypass the block 
restriction using the following example:


route [get_prof_sz_inboundCalls] {
get_profile_size("inboundCalls",,"$var(size)");
}

route [get_prof_sz_outboundCalls] {
get_profile_size("outboundCalls",,"$var(size)");
}

timer_route [mytimer, 1]
{
route(get_prof_sz_inboundCalls);
xlog("inboundCalls: $var(size)\n");

route(get_prof_sz_outboundCalls);
xlog("outboundCalls: $var(size)\n");
}

Regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 24.01.2017 01:05, Khalil Khamlichi wrote:
the idea is that I don't need to get the number of calls 30 times per 
second which would happens if I save to redis on each invite. 
scheduling the saving to redis every 10 seconds serves  well my 
purpose but the timer_route doesn't seem to accept get_profile_size()


any hints would be appreciated.

On Mon, Jan 23, 2017 at 10:39 PM, Khalil Khamlichi 
> wrote:


Hi,

I am trying to get call load information out of opensips at
regular intervals to get some sort of realtime view of the load on
the server.

After applying profiles on the the INVITEs, I have tried to call
get_profile_size from a timer_route.
I am getting error :

CRITICAL:core:yyerror: parse error in config file
/usr/local//etc/opensips/opensips.cfg, line 483, column 38-39:
Command cannot be used in the block

Any alternative solutions ?

Thanks in advance.

kkh




___
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] FW: OpenSIPs 2.2.2 warnings during start service

[Bogdan-Andrei Iancu]

Hi Agalya,

That is really weird - I suppose you are using the latest 2.2, right ?

Are you using a VM or container to run OpenSIPS ?

Regards,

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

On 01/24/2017 06:42 PM, Ramachandran, Agalya (Contractor) wrote:


*From:*Ramachandran, Agalya (Contractor)
*Sent:* Tuesday, January 24, 2017 11:42 AM
*To:* 'Bogdan-Andrei Iancu' 
*Subject:* RE: [OpenSIPS-Users] OpenSIPs 2.2.2 warnings during start 
service


Hi Bogdan,

1)do you get warning only for the tm-utimer job ? or do you see other 
too ?


I rarely see from blcore-expire job too.

  2)do you have some load on the server (in terms of traffic) 
? or is it idle/almost-idle ?


Mostly its idle, May be it will process 5 to 10 calls in an hour. That 
is the load it is been handling right now.


Giving the Process id and its same logs.

Process:: ID=0 PID=11744 Type=attendant

Process:: ID=1 PID=11745 Type=MI FIFO

Process:: ID=2 PID=11746 Type=time_keeper

Process:: ID=3 PID=11747 Type=timer

Process:: ID=4 PID=11748 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=5 PID=11749 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=6 PID=11750 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=7 PID=11751 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=8 PID=11752 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=9 PID=11753 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=10 PID=11754 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=11 PID=11755 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=12 PID=11756 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=13 PID=11757 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=14 PID=11758 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=15 PID=11759 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=16 PID=11760 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=17 PID=11761 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=18 PID=11762 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=19 PID=11763 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=20 PID=11764 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=21 PID=11765 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=22 PID=11766 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=23 PID=11767 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=24 PID=11768 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=25 PID=11769 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=26 PID=11770 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=27 PID=11771 Type=SIP receiver udp:10.0.0.1:5060

Process:: ID=28 PID=11772 Type=Timer handler

Jan 23 22:36:29 /usr/local/sbin/opensips[11771]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 22:49:42 /usr/local/sbin/opensips[11767]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 22:53:15 /usr/local/sbin/opensips[11771]: 
WARNING:core:handle_timer_job: timer job  has a 8 us 
delay in execution


Jan 23 22:53:15 /usr/local/sbin/opensips[11753]: 
WARNING:core:handle_timer_job: timer job  has a 8 
us delay in execution


Jan 23 22:55:06 /usr/local/sbin/opensips[11771]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 22:59:37 /usr/local/sbin/opensips[11767]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 23:07:20 /usr/local/sbin/opensips[11771]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 23:29:51 /usr/local/sbin/opensips[11771]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 23:30:11 /usr/local/sbin/opensips[11771]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 23:30:26 /usr/local/sbin/opensips[11772]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Jan 23 23:35:55 /usr/local/sbin/opensips[11758]: 
WARNING:core:handle_timer_job: utimer job  has a 3 us 
delay in execution


Jan 23 23:35:55 /usr/local/sbin/opensips[11771]: 
WARNING:core:handle_timer_job: utimer job  has a 2 us 
delay in execution


Regards,
Agalya

*From:*Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
*Sent:* Tuesday, January 24, 2017 11:09 AM
*To:* Ramachandran, Agalya (Contractor) 
>; OpenSIPS users mailling 
list >
*Subject:* Re: [OpenSIPS-Users] OpenSIPs 2.2.2 warnings during start 
service


Hi Agalya,

1) do you get warning only for the tm-utimer job ? or do you see other 
too ?


2) do you have some load on the server (in terms of traffic) ? or is 
it idle/almost-idle ?


3) the "ps" and the logs are not from the same run (the pid's do not 
match) - can you get the data from same run please ?


Best regards,

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