[OpenSIPS-Users] codec stripping with rtpengine

2018-04-09 Thread Esty, Ryan
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


[OpenSIPS-Users] switch / case behaviour

2018-04-09 Thread Richard Revels
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


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

2018-04-09 Thread Abdoul Osséni
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


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

2018-04-09 Thread Denis via Users
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. -- С уважением, Денис.Best regards, Denis 05.04.2018, 14:54, "Liviu Chircu" :Hi Denis,I have fixed the sequential calls to also reset on interval / day change, as well as adding a new param on the 2.3 and 2.2 branches, named "use_local_time" [1], so as not to break the default behavior.The default behavior will change in 2.4+, so it will use the local time, as it's more intuitive. This can be disabled with "use_utc_time" [2], of course.Cheers,[1]: http://www.opensips.org/html/docs/modules/2.2.x/fraud_detection.html#param_use_local_time[2]: http://www.opensips.org/html/docs/modules/2.4.x/fraud_detection.html#param_use_utc_timeLiviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.comOn 04.04.2018 16:54, Denis via Users wrote:Ok, i will check it. And what about "sequential call"? Should i make TT? P.S. I will ask you about one thing yet.Can i detect current 'time' using Opensips script? And compare it someway? Thank you. -- С уважением, Денис.Best regards, Denis 04.04.2018, 15:13, "Liviu Chircu" :Did OpenSIPS crash or restart between 0:25 - 3:20? I double checked, and"total_calls" cannot be reset in another way.Another possibility is that the code sees GMT time. Since Москва is onGMT+3, this may well explain the situation: first calls were placedaround 21:25 GMT, then the "total calls" limit was hit. At 0:00, thecounters were reset, so another 29 calls successfully passed throughstarting with 0:20.Let's keep an eye out for the "total calls" metric during normal hours,for a couple of days, so we confirm the above hypothesis (or not).Best regards,Liviu ChircuOpenSIPS Developerhttp://www.opensips-solutions.com___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