[OpenSIPS-Users] sip options pings are empty

[Tito Cumpen]

Hello,


I am using opensips 2.3 git rev. 3a66b9c and I am noticing that sip options
pings to wss clients are sent with no body at all. I am using SIP.js/0.7.
and see that the options sent when using :


 modparam("nathelper", "natping_interval", 10)
modparam("nathelper", "natping_tcp", 1)
modparam("nathelper", "sipping_from", "sip:pin...@mydomain.net")
modparam("nathelper", "remove_on_timeout_bflag", "RM_ONTO_FLAG")
modparam("nathelper", "sipping_bflag", "NAT_SIP_PINGS")

are empty and therefore the these clients cannot be monitored because sipjs
dismisses the empty messages
Thu Apr 12 2018 18:27:14 GMT-0400 (EDT) | sip.parser | no CRLF found, not a
SIP message, discarded
sip-0.7.7.min.js:36 Thu Apr 12 2018 18:27:23 GMT-0400 (EDT) | sip.transport
| received WebSocket text message:


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

[OpenSIPS-Users] Fwd: [SR-Users] MSILO: SIP stored offline MESSAGE repetitive delivery

[Abdul Basit]

Hi Opensips team,

I faced instant message timeout issues with MSILO module while setting SIP
IM server using kamailio.
It turned out that fr_timer values was too low to wait for MESSAGE delivery
to the destination (online/offline both cases) that server was replying
with 408.
Which result in message sending failed on sending side where as IM was
reaching to the destination.

The same issue is true for msilo sample configuration
 for
opensips.
Kindly update it at your end as well. This will save lot of time for the
ones who want to use opensips as IM server.

--
regards,

abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445

-- Forwarded message --
From: Abdul Basit 
Date: 13 April 2018 at 02:28
Subject: Re: [SR-Users] MSILO: SIP stored offline MESSAGE repetitive
delivery
To: Henning Westerholt 


Thanks Henning.

Good move. You removed the timers so that they use their default values :)

Same need to be done in sample msilo script
https://kamailio.org/docs/modules/5.1.x/modules/msilo.html#idp45433660

Who will be doing that?


--
regards,

abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445

On 13 April 2018 at 00:37, Henning Westerholt  wrote:

> On Thursday, 12 April 2018 10:15:19 CEST Abdul Basit wrote:
> > My issue for IM handling has been resolved.
> >
> > @MS helped to look into the matter. From to the example
> > [..]
> >
> > I replaced it as below
> >
> > # -- tm params --
> >
> > modparam("tm", "fr_timer", 1 )
> > modparam("tm", "fr_inv_timer", 15 )
> > modparam("tm", "wt_timer", 10 )
> >
> >
> > Lower fr_timer was initiating 408 without waiting for 200 OK from
> > destination because 10ms is too low. This was confusing msilo module and
> > the sender device that MESSAGE sent was failed.
> > Increasing the fr_timer value resolved the issue.
> > This also resolved a ripple effect. i.e, kamailio delivery of offline
> > messages from DB store to the destination party.
> > Since kamailio was get message delivery error, it was
> > executing failure_route[1] that was storing the message again in DB store
> > as offline message and so on.
> >
> > lower fr_timer values are also exits in 3.x, 4.x, 5x and dev branches
> > documentation.
> > [..]
>
> Hello Abdul,
>
> great that you found the issue. I have fixed this issue in git master and
> also
> 5.1 and 5.0 branch.
>
> Best regards,
>
> Henning
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 1XX, 2XX not relayed to caller

[SamyGo]

Hi,
So CSEQ is 2 but the caller sends another INVITE with CSEQ 3 which isn't
relayed and that doesnt happen 100% of time, so CSEQ was my first suspect.
VIA headers have some difference matching with a working call and I wonder
why. The same devices are known to be working just as good on production
multi-hop scenarios. I'm going to flush all my work and resort to the
sample config file and figure this out.

What confuses me is the enable_double_rr is turned ON as well..same flow of
call works for UDP-UDP, So, while there is an extra Record-Route in
there..why is it treated differently.

Let me share a trace shortly.

Regards,
Sammy

On Thu, Apr 12, 2018 at 4:16 PM, Bogdan-Andrei Iancu 
wrote:

> Hi,
>
> The 100 is never relayed, it is a hop by hop reply. So that is ok. On the
> 180, indeed, the TM/transaction module fails to match the reply to any
> transaction - have you actually inspected the VIA/Cseq/Callid to see if the
> do match ? Maybe the incoming 180 is indeed broken.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>   http://www.opensips.org/events/Summit-2018Amsterdam
>
> On 04/12/2018 08:21 PM, SamyGo wrote:
>
> Hi,
> Seems like I'm stuck with a very basic situation. I've 2 OpenSIPS boxes
> and 2 Users registered on each Proxy. Caller is on UDP, Destination is on
> TCP. Call made from A to B will not have its 1XX and 2XX relayed back to
> the originating Proxy: see this sngrep flow.
>
>
>
> So, naturally OpenSIPS-B triggers 408 Timeout.
>
> So iptables is off and I can see 180 Ringing and subsequent replies
> showing up in OpenSIPS logs like this:
> 
>
>  DBG:core:tcp_read_req: tcp_read_req end
>  DBG:core:tcp_read_req: Using the global ( per process ) buff
>  DBG:core:tcp_handle_req: content-length= 0
>  DBG:core:tcp_handle_req: Nothing more to read on TCP conn 0x7f93987cc9b8,
> currently in state 0
>  DBG:core:parse_msg: SIP Reply  (status):
>  DBG:core:parse_msg:  version: 
>  DBG:core:parse_msg:  status:  <180>
>  DBG:core:parse_msg:  reason:  
>  DBG:core:parse_headers: flags=2
>  DBG:core:get_hdr_field: cseq : <2> 
>  DBG:core:parse_via_param: found param type 234,  =
> <18.11.20.74>; state=6
>  DBG:core:parse_via_param: found param type 232,  =
> ; state=6
>  DBG:core:parse_via_param: found param type 235,  = <5060>; state=16
>  DBG:core:parse_via: end of header reached, state=5
>  DBG:core:parse_headers: via found, flags=2
>  DBG:core:parse_headers: this is the first via
>  DBG:core:receive_msg: After parse_msg...
>  DBG:core:forward_reply: found module nathelper, passing reply to it
>  DBG:core:parse_headers: flags=4
>  DBG:core:parse_to_param: tag=40adb5b3-e13c-e811-86eb-c4544411cd9b
>  DBG:core:_parse_to: end of header reached, state=29
>  DBG:core:_parse_to: display={}, ruri={sip:5...@myvoiptest.net}
>  DBG:core:get_hdr_field:  [70]; uri=[sip:5...@myvoiptest.net ]
>  DBG:core:get_hdr_field: to body []
>  DBG:core:get_hdr_field: content_length=0
>  DBG:core:get_hdr_field: found end of header
>  DBG:core:forward_reply: found module tm, passing reply to it
>  DBG:tm:t_check: start=0x
>  DBG:core:parse_headers: flags=22
>  DBG:core:parse_headers: flags=8
>  DBG:tm:t_reply_matching: failure to match a transaction
>  DBG:tm:t_check: end=(nil)
>  DBG:core:destroy_avp_list: destroying list (nil)
>
>
>
> For successful relaying the last few lines show a matched transaction. I
> suspected CSEQ and Via headers and going through the traces+logs meanwhile
> looking for some guidance as what params to look for.
>
>
> OpenSIPS is latest devel:
> version: opensips 2.4.0-dev (x86_64/linux)
> flags: STATS: On, SHM_EXTRA_STATS, DISABLE_NAGLE, USE_MCAST, SHM_MMAP,
> PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535
> poll method support: poll, epoll, sigio_rt, select.
> git revision: 0ff609d
> main.c compiled on 19:11:13 Apr 11 2018 with gcc 5.4.0
>
> P.S: Same config works for other calls as well.
>
> Regards,
> Sammy
>
>
> ___
> 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] 1XX, 2XX not relayed to caller

[Bogdan-Andrei Iancu]

Hi,

The 100 is never relayed, it is a hop by hop reply. So that is ok. On 
the 180, indeed, the TM/transaction module fails to match the reply to 
any transaction - have you actually inspected the VIA/Cseq/Callid to see 
if the do match ? Maybe the incoming 180 is indeed broken.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 04/12/2018 08:21 PM, SamyGo wrote:

Hi,
Seems like I'm stuck with a very basic situation. I've 2 OpenSIPS 
boxes and 2 Users registered on each Proxy. Caller is on UDP, 
Destination is on TCP. Call made from A to B will not have its 1XX and 
2XX relayed back to the originating Proxy: see this sngrep flow.




So, naturally OpenSIPS-B triggers 408 Timeout.

So iptables is off and I can see 180 Ringing and subsequent replies 
showing up in OpenSIPS logs like this:



 DBG:core:tcp_read_req: tcp_read_req end
 DBG:core:tcp_read_req: Using the global ( per process ) buff
 DBG:core:tcp_handle_req: content-length= 0
 DBG:core:tcp_handle_req: Nothing more to read on TCP conn 
0x7f93987cc9b8, currently in state 0

 DBG:core:parse_msg: SIP Reply  (status):
 DBG:core:parse_msg:  version: 
 DBG:core:parse_msg:  status:  <180>
 DBG:core:parse_msg:  reason:  
 DBG:core:parse_headers: flags=2
 DBG:core:get_hdr_field: cseq : <2> 
 DBG:core:parse_via_param: found param type 234,  = 
<18.11.20.74>; state=6
 DBG:core:parse_via_param: found param type 232,  = 
; state=6
 DBG:core:parse_via_param: found param type 235,  = <5060>; 
state=16

 DBG:core:parse_via: end of header reached, state=5
 DBG:core:parse_headers: via found, flags=2
 DBG:core:parse_headers: this is the first via
 DBG:core:receive_msg: After parse_msg...
 DBG:core:forward_reply: found module nathelper, passing reply to it
 DBG:core:parse_headers: flags=4
 DBG:core:parse_to_param: tag=40adb5b3-e13c-e811-86eb-c4544411cd9b
 DBG:core:_parse_to: end of header reached, state=29
 DBG:core:_parse_to: display={}, ruri={sip:5...@myvoiptest.net 
}
 DBG:core:get_hdr_field:  [70]; uri=[sip:5...@myvoiptest.net 
 ]
 DBG:core:get_hdr_field: to body [ >]

 DBG:core:get_hdr_field: content_length=0
 DBG:core:get_hdr_field: found end of header
 DBG:core:forward_reply: found module tm, passing reply to it
 DBG:tm:t_check: start=0x
 DBG:core:parse_headers: flags=22
 DBG:core:parse_headers: flags=8
 DBG:tm:t_reply_matching: failure to match a transaction
 DBG:tm:t_check: end=(nil)
 DBG:core:destroy_avp_list: destroying list (nil)



For successful relaying the last few lines show a matched transaction. 
I suspected CSEQ and Via headers and going through the traces+logs 
meanwhile looking for some guidance as what params to look for.



OpenSIPS is latest devel:
version: opensips 2.4.0-dev (x86_64/linux)
flags: STATS: On, SHM_EXTRA_STATS, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, 
PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535

poll method support: poll, epoll, sigio_rt, select.
git revision: 0ff609d
main.c compiled on 19:11:13 Apr 11 2018 with gcc 5.4.0

P.S: Same config works for other calls as well.

Regards,
Sammy


___
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] switch / case behaviour

[Bogdan-Andrei Iancu]

+1

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 04/12/2018 02:00 PM, Liviu Chircu wrote:


Hi Richard,

IMO, that looks like a slip-up which has been probably lurking in 
there since the very beginnings. I suggest we should fix it to match 
the expected behavior of switch/case/default for most (all?) 
programming languages which are out there. It would be interesting to 
hear other opinions as well before we act, though.


Cheers,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 09.04.2018 16:38, Richard Revels wrote:
I am unsure of the expected behaviour in the config switch / case 
block when the break is not defined between a defined case and the 
default case but what I'm seeing right now is not what I expect.  
Wanted to get some input before opening a bug tracker on it.


--code--
route[testswitch]
{
switch( $avp(testvalue) )
{
case "defined break":
xlog("L_INFO", "log only this line \n");
break;

case "non defined break":
xlog("L_INFO", "log this line and fall through to also 
and then to default \n");


case "also non defined":
xlog("L_INFO", "log this line and fall through to default 
\n");


default:
xlog("L_ERR", "log default line \n");
}
xlog("L_ERR", "at end of switch block with $avp(testvalue) \n");
}

...

$avp(testvalue) := "defined break";
route(testswitch);
$avp(testvalue) := "non defined break";
route(testswitch);
$avp(testvalue) := "also non defined";
route(testswitch);
$avp(testvalue) := "non defined value";
route(testswitch);

--end code--

--log--

2018-04-09T13:13:28.092141+00:00 pidflo-01 /sbin/opensips[25651]: log 
only this line
2018-04-09T13:13:28.092150+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with defined break
2018-04-09T13:13:28.092158+00:00 pidflo-01 /sbin/opensips[25651]: log 
this line and fall through to also and then to default
2018-04-09T13:13:28.092161+00:00 pidflo-01 /sbin/opensips[25651]: log 
this line and fall through to default
2018-04-09T13:13:28.092164+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with non defined break
2018-04-09T13:13:28.092168+00:00 pidflo-01 /sbin/opensips[25651]: log 
this line and fall through to default
2018-04-09T13:13:28.092171+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with also non defined
2018-04-09T13:13:28.092176+00:00 pidflo-01 /sbin/opensips[25651]: log 
default line
2018-04-09T13:13:28.092179+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with non defined value


--end log--




___
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] codec stripping with rtpengine

[Bogdan-Andrei Iancu]

Hi Ryan,

yeah, this happens because OpenSIPS applies all the changes at the end, 
when the message is about to be sent out. As a side effect, when sending 
the SDP to rtpengine, opensips does not see its own previous changes 
over the body (changes are still pending).
Usually there are easy workarounds for this, but in this case it looks 
like bug to me. Could you please open a bug report the the github tracker.


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 04/09/2018 05:22 PM, Esty, Ryan wrote:


Hi opensips list,

First some background I’m trying to use opensips as a webrtc proxy. I 
found out that the packets for the invite going to my sip server are 
too big for my sip server. It doesn’t like packets to be over 4000 
bytes. I’m trying to take what I can out of the sip packets like codes 
I know the other side can’t do. First codec stripping works but only 
with the audio codecs. If I try to strip a video codec the packet gets 
mangled. This is probably a bug in rtpengine and not opensips. I was 
hoping if anyone has any idea how I might get my invite packets 
smaller? The webrtc side is generating ssrc lines in my sdp. I’m 
trying to strip them out but I’m not sure if rtpengine is putting them 
back in or not. Before my rtpengine_offer I do a 
replace_body_all(“a=ssrc.*\r\n,” “”) but the invite still has all the 
ssrc lines in it.


Ryan



___
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] 1XX, 2XX not relayed to caller

[SamyGo]

Hi,
Seems like I'm stuck with a very basic situation. I've 2 OpenSIPS boxes and
2 Users registered on each Proxy. Caller is on UDP, Destination is on TCP.
Call made from A to B will not have its 1XX and 2XX relayed back to the
originating Proxy: see this sngrep flow.



So, naturally OpenSIPS-B triggers 408 Timeout.

So iptables is off and I can see 180 Ringing and subsequent replies showing
up in OpenSIPS logs like this:


 DBG:core:tcp_read_req: tcp_read_req end
 DBG:core:tcp_read_req: Using the global ( per process ) buff
 DBG:core:tcp_handle_req: content-length= 0
 DBG:core:tcp_handle_req: Nothing more to read on TCP conn 0x7f93987cc9b8,
currently in state 0
 DBG:core:parse_msg: SIP Reply  (status):
 DBG:core:parse_msg:  version: 
 DBG:core:parse_msg:  status:  <180>
 DBG:core:parse_msg:  reason:  
 DBG:core:parse_headers: flags=2
 DBG:core:get_hdr_field: cseq : <2> 
 DBG:core:parse_via_param: found param type 234,  =
<18.11.20.74>; state=6
 DBG:core:parse_via_param: found param type 232,  =
; state=6
 DBG:core:parse_via_param: found param type 235,  = <5060>; state=16
 DBG:core:parse_via: end of header reached, state=5
 DBG:core:parse_headers: via found, flags=2
 DBG:core:parse_headers: this is the first via
 DBG:core:receive_msg: After parse_msg...
 DBG:core:forward_reply: found module nathelper, passing reply to it
 DBG:core:parse_headers: flags=4
 DBG:core:parse_to_param: tag=40adb5b3-e13c-e811-86eb-c4544411cd9b
 DBG:core:_parse_to: end of header reached, state=29
 DBG:core:_parse_to: display={}, ruri={sip:5...@myvoiptest.net}
 DBG:core:get_hdr_field:  [70]; uri=[sip:5...@myvoiptest.net ]
 DBG:core:get_hdr_field: to body []
 DBG:core:get_hdr_field: content_length=0
 DBG:core:get_hdr_field: found end of header
 DBG:core:forward_reply: found module tm, passing reply to it
 DBG:tm:t_check: start=0x
 DBG:core:parse_headers: flags=22
 DBG:core:parse_headers: flags=8
 DBG:tm:t_reply_matching: failure to match a transaction
 DBG:tm:t_check: end=(nil)
 DBG:core:destroy_avp_list: destroying list (nil)



For successful relaying the last few lines show a matched transaction. I
suspected CSEQ and Via headers and going through the traces+logs meanwhile
looking for some guidance as what params to look for.


OpenSIPS is latest devel:
version: opensips 2.4.0-dev (x86_64/linux)
flags: STATS: On, SHM_EXTRA_STATS, DISABLE_NAGLE, USE_MCAST, SHM_MMAP,
PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 0ff609d
main.c compiled on 19:11:13 Apr 11 2018 with gcc 5.4.0

P.S: Same config works for other calls as well.

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

Re: [OpenSIPS-Users] drouting: need more information about a feature

[Bogdan-Andrei Iancu]

Hi,

This module was never completed and never pushed to the public tree. 
Maybe in the future :)


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 04/09/2018 11:53 AM, Abdoul Osséni wrote:

Hello Dear list,

According to this email 
https://opensips.org/pipermail/users/2014-September/029817.html, 
drouting can reorder the gateways according PDD, ASR and ACD stats.


Can you explain me how it works and how can I enable this feature?

Thank you for your works.

Abdoul.


___
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] opensipsctl fifo dr_number_routing command and partitions

[Bogdan-Andrei Iancu]

Indeed, the dr_number_routing MI command does not accept wildcards in 
the partition definition, as the docs state.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 04/06/2018 01:36 PM, Pasan Meemaduma via Users wrote:
I don't think it accept wildcard match via fifo command, doc indicates 
partition name is required only group id can be omitted. May be a dev 
can help ?



On Friday, April 6, 2018, 3:56:04 PM GMT+5:30, Kirill Galinurov 
 wrote:



Yes of course.
opensipsctl fifo dr_number_routing mts 1 91956858923 where mts is 
partition name -


Matched Prefix:: 91956
   CARRIER:: D4701
withouth partition name

opensipsctl fifo dr_number_routing  1 91956858923
 400 Bad parameter

And with * as partition name

opensipsctl fifo dr_number_routing * 1 91956858923
400 Bad parameter




2018-04-06 13:01 GMT+03:00 Pasan Meemaduma >:


Hi Kirill,

did you try opensipsctl fifo dr_number_routing 


In my setup

Ex: opensipsctl fifo dr_number_routing 1 0412345678

Matched Prefix:: 04
CARRIER:: xx
CARRIER:: xx






On Friday, April 6, 2018, 3:18:03 PM GMT+5:30, Kirill Galinurov
> wrote:


Hi all. How to use fifo command dr_number_routing to search all
partitions for matching?
Like do_routing("*:1") in script.

__ _
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] do_routing causes invalid avp id error

[Bogdan-Andrei Iancu]

Hi John,

Yes, found the issue - it was introduced by this commit:
https://github.com/OpenSIPS/opensips/commit/7844aaba9400e6480d341c18ac41dcc17b403070
but the carrier ID AVP is by default not set, so the delete op generate 
the harmless error


It  should be fixed now on all maintained versions.

Thanks and regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 04/05/2018 01:32 PM, John Quick wrote:

I'm testing with v2.4 beta. Using the DROUTING module.
When I call the function do_routing("2") it always generates the following
error:
ERROR:core:search_first_avp: invalid avp id -1

I've used this module and this function before in earlier versions of
OpenSIPS and I cannot recall seeing this error message before.

I tried various remedies such as adding/removing this line:
modparam("drouting", "ruri_avp", '$avp(dr_ruri)')

..also I have tried both of the following as a way of calling the function:
 if
(do_routing("2",,,"$var(ruleattrs)","$var(gwattrs)","$var(carrattrs)")) {
 if (do_routing("2")) {

but every time I see the same error reported.

By the way, the function operates as expected and selects the correct
gateway. The error message seems to be irrelevant.

John Quick
Smartvox Limited
Web: www.smartvox.co.uk



___
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 2.5 and fraud module

[Liviu Chircu]

Use $Ts [1] to get the current UNIX timestamp in seconds.

[1]: http://www.opensips.org/Documentation/Script-CoreVar-2-4#toc91

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

On 12.04.2018 14:08, Denis via Users wrote:
Liviu, is there any way to find out current time from Opensips during 
call processing (some functions, variables etc which i can use in 
opensips.cfg)?

Thank you
--
С уважением, Денис.
Best regards, Denis
12.04.2018, 13:50, "Liviu Chircu" :


Hi Denis,

The fraud detection module has no such mechanism, currently. We could 
invent some variables such as $frd_last_warn, $frd_last_crit, 
$frd_first_warn, $frd_first_crit. They would output a UNIX timestamp. 
If there were no warnings during the current interval, the timestamp 
value would be 0. Can't think of anything better now - you can polish 
this idea and open up a pull request if you want.


How many users do you have? The "cachedb_local" offers a fast and 
configurable hash implementation. Why wouldn't it be a good solution 
in order to store/fetch the above-mentioned timestamps for each of 
your users?


Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com 
On 10.04.2018 13:11, Denis via Users wrote:

Hello, Liviu!
"So you want to check the time of the last fraud detection attempt 
for a user?"

Yes, but not for store this time to anywhere.
I want to detect the time of the first fraud call, and if this time, 
for example, between 19:00 and 09:00, make some actions.

Can i do it with Opensips?
Thank you.
--
С уважением, Денис.
Best regards, Denis
10.04.2018, 12:28, "Liviu Chircu"  
:


Hi Denis,

Yes, the "sequential calls" holds the size of the last batch of calls
sent to the same number. For example, if a user were to dial 44 and 45
prefixes in a round-robin manner, his "sequential calls" value would
never exceed 1.

So you want to check the time of the last fraud detection attempt for a
user? You can use "cachedb_local", for example, and hold the last fraud
detection timestamp for each user. Also, note that check_fraud() 
[1] has

some useful return codes (-1 and -2), in case you don't want to use the
E_FRD_ events.

Cheers,

[1]:
http://www.opensips.org/html/docs/modules/2.4.x/fraud_detection.html#func_check_fraud

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

On 09.04.2018 09:12, Denis via Users wrote:

 Hello, Liviu!
 Thank you very much!
 I will try your fix.
 And, What does "Sequential calls" mean? These are calls to one
number?
 So, if we have situation dealing with reset counters, i want
to make
 one thing.
 I want to check the time when fraud has been detected and if this
 time, say, after 19:00 make some actions. How can i check time
of the
 call processing?
 Thank you.



___
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


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

Re: [OpenSIPS-Users] ASR & ACR per country/destination

[DanB]

Hi Abdoul,

You should start with the components part of the integration: sessions,
cdrs and stats.

I would suggest that we move discussion on CGRateS group so we don't
create much noise here with CGRateS related questions.

Thanks,
DanB



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

Re: [OpenSIPS-Users] Opensips 2.5 and fraud module

[Denis via Users]

Liviu, is there any way to find out current time from Opensips during call processing (some functions, variables etc which i can use in opensips.cfg)? Thank you -- С уважением, Денис.Best regards, Denis 12.04.2018, 13:50, "Liviu Chircu" :Hi Denis,The fraud detection module has no such mechanism, currently. We could invent some variables such as $frd_last_warn, $frd_last_crit, $frd_first_warn, $frd_first_crit. They would output a UNIX timestamp. If there were no warnings during the current interval, the timestamp value would be 0. Can't think of anything better now - you can polish this idea and open up a pull request if you want.How many users do you have? The "cachedb_local" offers a fast and configurable hash implementation. Why wouldn't it be a good solution in order to store/fetch the above-mentioned timestamps for each of your users?Best regards,Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.comOn 10.04.2018 13:11, Denis via Users wrote:Hello, Liviu! "So you want to check the time of the last fraud detection attempt for a user?" Yes, but not for store this time to anywhere.I want to detect the time of the first fraud call, and if this time, for example, between 19:00 and 09:00, make some actions. Can i do it with Opensips? Thank you. -- С уважением, Денис.Best regards, Denis 10.04.2018, 12:28, "Liviu Chircu" :Hi Denis,Yes, the "sequential calls" holds the size of the last batch of callssent to the same number. For example, if a user were to dial 44 and 45prefixes in a round-robin manner, his "sequential calls" value wouldnever exceed 1.So you want to check the time of the last fraud detection attempt for auser? You can use "cachedb_local", for example, and hold the last frauddetection timestamp for each user. Also, note that check_fraud() [1] hassome useful return codes (-1 and -2), in case you don't want to use theE_FRD_ events.Cheers,[1]:http://www.opensips.org/html/docs/modules/2.4.x/fraud_detection.html#func_check_fraudLiviu ChircuOpenSIPS Developerhttp://www.opensips-solutions.comOn 09.04.2018 09:12, Denis via Users wrote: Hello, Liviu! Thank you very much! I will try your fix. And, What does "Sequential calls" mean? These are calls to one number? So, if we have situation dealing with reset counters, i want to make one thing. I want to check the time when fraud has been detected and if this time, say, after 19:00 make some actions. How can i check time of the call processing? Thank you.___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 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] switch / case behaviour

[Liviu Chircu]

Hi Richard,

IMO, that looks like a slip-up which has been probably lurking in there 
since the very beginnings. I suggest we should fix it to match the 
expected behavior of switch/case/default for most (all?) programming 
languages which are out there. It would be interesting to hear other 
opinions as well before we act, though.


Cheers,

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

On 09.04.2018 16:38, Richard Revels wrote:
I am unsure of the expected behaviour in the config switch / case 
block when the break is not defined between a defined case and the 
default case but what I'm seeing right now is not what I expect.  
Wanted to get some input before opening a bug tracker on it.


--code--
route[testswitch]
{
switch( $avp(testvalue) )
        {
  case "defined break":
          xlog("L_INFO", "log only this line \n");
  break;

  case "non defined break":
          xlog("L_INFO", "log this line and fall through to also and 
then to default \n");


  case "also non defined":
          xlog("L_INFO", "log this line and fall through to default \n");

  default:
          xlog("L_ERR", "log default line \n");
        }
xlog("L_ERR", "at end of switch block with $avp(testvalue) \n");
}

...

        $avp(testvalue) := "defined break";
        route(testswitch);
        $avp(testvalue) := "non defined break";
        route(testswitch);
        $avp(testvalue) := "also non defined";
        route(testswitch);
        $avp(testvalue) := "non defined value";
        route(testswitch);

--end code--

--log--

2018-04-09T13:13:28.092141+00:00 pidflo-01 /sbin/opensips[25651]: log 
only this line
2018-04-09T13:13:28.092150+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with defined break
2018-04-09T13:13:28.092158+00:00 pidflo-01 /sbin/opensips[25651]: log 
this line and fall through to also and then to default
2018-04-09T13:13:28.092161+00:00 pidflo-01 /sbin/opensips[25651]: log 
this line and fall through to default
2018-04-09T13:13:28.092164+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with non defined break
2018-04-09T13:13:28.092168+00:00 pidflo-01 /sbin/opensips[25651]: log 
this line and fall through to default
2018-04-09T13:13:28.092171+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with also non defined
2018-04-09T13:13:28.092176+00:00 pidflo-01 /sbin/opensips[25651]: log 
default line
2018-04-09T13:13:28.092179+00:00 pidflo-01 /sbin/opensips[25651]: at 
end of switch block with non defined value


--end log--




___
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] ASR & ACR per country/destination

[Abdoul Osséni]

Hi Dan,

Thank you for your feedback.

If I understood, I must:
- Install cdrstats?
- use cgrates module with the function cgrates_acc?

How can I install only cdrstats?

Thank you.

Abdoul OSSENI
Ingénieur DevOps chez Néo-Soft


Le mar. 3 avr. 2018 à 20:55, Dan-Cristian Bogos  a
écrit :

> Hi Abdoul,
>
> If no other/simpler way to do it, you can use StatS subsystem in CGRateS
> on top of CDRs coming from OpenSIPS to aggregate stats on the filter you
> need. On top of that you have another subsystem, ThresholdS, which can
> notify you when your supplier starts misbehaving.
>
> DanB
>
> Message: 1
>> Date: Fri, 30 Mar 2018 17:06:23 +
>> From: Abdoul Osséni 
>> To: OpenSIPS users mailling list 
>> Subject: [OpenSIPS-Users] ASR & ACR per country/destination
>> Message-ID:
>> > w...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello dear list,
>>
>> I am looking for a tool that will provide me call statistics (ASR and ACD)
>> by destination/country with alerting by emails.
>> I try to detect when a sip provider does not work well in order to route
>> the traffic to another sip provider.
>>
>> Thank you.
>>
>> Abdoul OSSENI
>> AfriCallShop
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.opensips.org/pipermail/users/attachments/20180330/a966401d/attachment-0001.html
>> >
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> --
>>
>> End of Users Digest, Vol 116, Issue 68
>> **
>>
> ___
> 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