Re: [OpenSIPS-Users] Mediaproxy speed calculations

2017-03-28 Thread Daniel Zanutti
Hi Dan

Ok about not being able to force calculation, it's done periodically. But
for some reason, it's not calculating =(

You misunderstood me about the machine. On this scenario, I have complete
control of the machines, all physical machines are ours. When I said the
system is not overloaded during the night, I mean that both physical and
virtual machines are not being used at all (load 0%).

I just checked that at least one of these machines are physical and not
virtual, this is the config:
CPU0: Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz (fam: 06, model: 1a,
stepping: 05)
smpboot: Total of 8 processors activated (44687.68 BogoMIPS)

Based on your explanation, my physical machine with 2.8GHz is computing at
5MHz, which is surely wrong.

I have a similar scenario deployed on more than 50 machine and almost every
time Mediaproxy is started at linux boot, it doesn't calculate and show
speed. After restarting the process, speed is calculated fine.

Could you please consider that the software may have a bug? Are you
interested on fixing it? Can I help?

Thanks


On Tue, Mar 28, 2017 at 5:32 PM, Dan Pascu  wrote:

>
> On 28 Mar 2017, at 20:55, Daniel Zanutti wrote:
>
> > Hi Dan
> >
> > Thanks for answering.
> >
> > The machine is not overloaded, actually i have the same problem with 10
> calls or 1000 calls.
> >
> > Syslog:
> > Mar 28 14:51:45 MP-104 media-relay[782]: warning: Aggregate speed
> calculation time exceeded 10ms: 15214 us for 418 sessions
> >
> >
> > TOP:
> > load average: 0.56, 0.61, 0.63
>
> You misunderstood me. I was not talking about your virtual machine, I was
> talking about the real hardware being overloaded, probably running too many
> virtual machines.
>
> From inside the virtual machine you cannot assess how loaded the real
> hardware is. You can have 0% CPU load inside your virtual machine, that
> doesn't mean things are OK. The fact that inside your virtual machine an
> operation takes 600 times longer than on 5 years old real hardware, means
> that your system is unable to perform as it should. If the real hardware
> CPU runs at let's say 3GHz, this is equivalent to saying that your virtual
> machine has a CPU running at 3000MHz/600 = 5MHz. You try to run a media
> relay that has to react in real time inside a virtual machine that behaves
> as if it has a 5MHz CPU!
>
> You may prefer to run things on virtual machines for reasons related to
> costs, but at the end of the day one thing is clear: a media relay requires
> a RTOS. Linux running on real hardware is not an RTOS, but if the machine
> doesn't run other things that can influence the resource allocation, it can
> approximate one pretty well. A virtual machine running 600 times slower
> than real hardware, with resources shared between multiple virtual
> machines, is as far removed from the idea of a RTOS as it can possibly be.
>
> > You are right about being virtual, but I'm sure the server is not
> overloaded because I have the same problem during the night, with almost no
> traffic. During the day, it MAY be overloaded but surely not during the
> night and this information never shows up on these relays.
> >
> > Is there any way to force it? Could you give some directions?
>
> Force what? As I said the traffic calculations are done periodically at an
> interval specified in the configuration, with the default being 15 seconds.
> You can disable them by setting the sampling interval to 0. The warning
> doesn't mean they are skipped, it only means the relay took too long to
> compute them and was unresponsive for other requests during that time.
>
> >
> > Thanks
> >
> >
> > On Tue, Mar 28, 2017 at 2:27 PM, Dan Pascu  wrote:
> >
> > On 24 Mar 2017, at 19:51, Daniel Zanutti wrote:
> >
> > > Hi
> > >
> > > Looks like i'm diving deep on mediaproxy.
> > >
> > > Some of our relays are not calculating the speed on the network. If I
> restart a couple times it starts calculating fine.
> > >
> > > I found this log:
> > > media-relay[4100]: warning: Aggregate speed calculation time exceeded
> 10ms: 11644 us for 222 sessions
> > >
> > > Is there any solution to always calculate?
> >
> > The relay always calculates. That is just a warning when it takes too
> long, but the calculation still took place.
> >
> > The reasons why you might not see traffic:
> >
> > 1. There is no actual traffic, despite having sessions setup, the
> devices do not send media
> > 2. There is traffic but for some reason reading the traffic information
> from the kernel fails (I have no idea why that could happen, except maybe a
> severely overloaded virtual machine - see below)
> >
> > I noticed something very wrong with that warning. On a machine running
> on a Core I7 from 2012 (Sandy Bridge architecture, so not the latest
> hardware, but something from 5 years ago), the calculation for 222
> sessions, takes 20 us (that is micro seconds). You got 11644 us, which is
> approximately 600 times slower. Which means 

Re: [OpenSIPS-Users] Mediaproxy speed calculations

2017-03-28 Thread Dan Pascu

On 28 Mar 2017, at 20:55, Daniel Zanutti wrote:

> Hi Dan
> 
> Thanks for answering.
> 
> The machine is not overloaded, actually i have the same problem with 10 calls 
> or 1000 calls.
> 
> Syslog:
> Mar 28 14:51:45 MP-104 media-relay[782]: warning: Aggregate speed calculation 
> time exceeded 10ms: 15214 us for 418 sessions
> 
> 
> TOP:
> load average: 0.56, 0.61, 0.63

You misunderstood me. I was not talking about your virtual machine, I was 
talking about the real hardware being overloaded, probably running too many 
virtual machines.

From inside the virtual machine you cannot assess how loaded the real hardware 
is. You can have 0% CPU load inside your virtual machine, that doesn't mean 
things are OK. The fact that inside your virtual machine an operation takes 600 
times longer than on 5 years old real hardware, means that your system is 
unable to perform as it should. If the real hardware CPU runs at let's say 
3GHz, this is equivalent to saying that your virtual machine has a CPU running 
at 3000MHz/600 = 5MHz. You try to run a media relay that has to react in real 
time inside a virtual machine that behaves as if it has a 5MHz CPU!

You may prefer to run things on virtual machines for reasons related to costs, 
but at the end of the day one thing is clear: a media relay requires a RTOS. 
Linux running on real hardware is not an RTOS, but if the machine doesn't run 
other things that can influence the resource allocation, it can approximate one 
pretty well. A virtual machine running 600 times slower than real hardware, 
with resources shared between multiple virtual machines, is as far removed from 
the idea of a RTOS as it can possibly be.

> You are right about being virtual, but I'm sure the server is not overloaded 
> because I have the same problem during the night, with almost no traffic. 
> During the day, it MAY be overloaded but surely not during the night and this 
> information never shows up on these relays.
> 
> Is there any way to force it? Could you give some directions?

Force what? As I said the traffic calculations are done periodically at an 
interval specified in the configuration, with the default being 15 seconds. You 
can disable them by setting the sampling interval to 0. The warning doesn't 
mean they are skipped, it only means the relay took too long to compute them 
and was unresponsive for other requests during that time.

> 
> Thanks
> 
> 
> On Tue, Mar 28, 2017 at 2:27 PM, Dan Pascu  wrote:
> 
> On 24 Mar 2017, at 19:51, Daniel Zanutti wrote:
> 
> > Hi
> >
> > Looks like i'm diving deep on mediaproxy.
> >
> > Some of our relays are not calculating the speed on the network. If I 
> > restart a couple times it starts calculating fine.
> >
> > I found this log:
> > media-relay[4100]: warning: Aggregate speed calculation time exceeded 10ms: 
> > 11644 us for 222 sessions
> >
> > Is there any solution to always calculate?
> 
> The relay always calculates. That is just a warning when it takes too long, 
> but the calculation still took place.
> 
> The reasons why you might not see traffic:
> 
> 1. There is no actual traffic, despite having sessions setup, the devices do 
> not send media
> 2. There is traffic but for some reason reading the traffic information from 
> the kernel fails (I have no idea why that could happen, except maybe a 
> severely overloaded virtual machine - see below)
> 
> I noticed something very wrong with that warning. On a machine running on a 
> Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware, but 
> something from 5 years ago), the calculation for 222 sessions, takes 20 us 
> (that is micro seconds). You got 11644 us, which is approximately 600 times 
> slower. Which means your virtual machine is severely overloaded, or the 
> amount of resources it has allocated from the real hardware is abysmal.
> 
> On the same machine I mentioned before, having 2000 active sessions results 
> in the speed calculations taking 170 us, which is well below the warning 
> limit of 10 ms. Which means, the relay can drive thousands of sessions and 
> you'll never see the warning.
> 
> In conclusion, unless you run on a severely overloaded system, or a very 
> underpowered virtual machine, you should never see that warning and seeing 
> the warning doesn't mean that calculations didn't take place.
> 
> --
> 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


--
Dan





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


Re: [OpenSIPS-Users] Mediaproxy speed calculations

2017-03-28 Thread Daniel Zanutti
Hi Dan

Thanks for answering.

The machine is not overloaded, actually i have the same problem with 10
calls or 1000 calls. I can confirm there is a lot of traffic on it, for
instance:

1 1.1.1.1 2.6.1 108h09'30" 6.71Mbps 413 audio 413 Active
2 2.2.2.2 2.6.5 95h50'12" 0bps 435 audio 435 Active
3 3.3.3.3 2.6.5 95h50'16" 0bps 382 audio 382 Active
4 4.4.4.4 2.6.5 108h08'38" 7.29Mbps 402 audio 402 Active
5 5.5.5.5 2.6.5 107h59'38" 6.41Mbps 375 audio 375 Active
(fake IPs)

IPTRAF:
eth0  304104304104 00  20903.40 kbits/sec


Syslog:
Mar 28 14:51:45 MP-104 media-relay[782]: warning: Aggregate speed
calculation time exceeded 10ms: 15214 us for 418 sessions


TOP:
load average: 0.56, 0.61, 0.63


Kernel:
Linux MP-104 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07)
x86_64 GNU/Linux


You are right about being virtual, but I'm sure the server is not
overloaded because I have the same problem during the night, with almost no
traffic. During the day, it MAY be overloaded but surely not during the
night and this information never shows up on these relays.

Is there any way to force it? Could you give some directions?

Thanks


On Tue, Mar 28, 2017 at 2:27 PM, Dan Pascu  wrote:

>
> On 24 Mar 2017, at 19:51, Daniel Zanutti wrote:
>
> > Hi
> >
> > Looks like i'm diving deep on mediaproxy.
> >
> > Some of our relays are not calculating the speed on the network. If I
> restart a couple times it starts calculating fine.
> >
> > I found this log:
> > media-relay[4100]: warning: Aggregate speed calculation time exceeded
> 10ms: 11644 us for 222 sessions
> >
> > Is there any solution to always calculate?
>
> The relay always calculates. That is just a warning when it takes too
> long, but the calculation still took place.
>
> The reasons why you might not see traffic:
>
> 1. There is no actual traffic, despite having sessions setup, the devices
> do not send media
> 2. There is traffic but for some reason reading the traffic information
> from the kernel fails (I have no idea why that could happen, except maybe a
> severely overloaded virtual machine - see below)
>
> I noticed something very wrong with that warning. On a machine running on
> a Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware,
> but something from 5 years ago), the calculation for 222 sessions, takes 20
> us (that is micro seconds). You got 11644 us, which is approximately 600
> times slower. Which means your virtual machine is severely overloaded, or
> the amount of resources it has allocated from the real hardware is abysmal.
>
> On the same machine I mentioned before, having 2000 active sessions
> results in the speed calculations taking 170 us, which is well below the
> warning limit of 10 ms. Which means, the relay can drive thousands of
> sessions and you'll never see the warning.
>
> In conclusion, unless you run on a severely overloaded system, or a very
> underpowered virtual machine, you should never see that warning and seeing
> the warning doesn't mean that calculations didn't take place.
>
> --
> 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


Re: [OpenSIPS-Users] Mediaproxy speed calculations

2017-03-28 Thread Dan Pascu

On 24 Mar 2017, at 19:51, Daniel Zanutti wrote:

> Hi
> 
> Looks like i'm diving deep on mediaproxy.
> 
> Some of our relays are not calculating the speed on the network. If I restart 
> a couple times it starts calculating fine.
> 
> I found this log:
> media-relay[4100]: warning: Aggregate speed calculation time exceeded 10ms: 
> 11644 us for 222 sessions
> 
> Is there any solution to always calculate?

The relay always calculates. That is just a warning when it takes too long, but 
the calculation still took place.

The reasons why you might not see traffic:

1. There is no actual traffic, despite having sessions setup, the devices do 
not send media
2. There is traffic but for some reason reading the traffic information from 
the kernel fails (I have no idea why that could happen, except maybe a severely 
overloaded virtual machine - see below)

I noticed something very wrong with that warning. On a machine running on a 
Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware, but 
something from 5 years ago), the calculation for 222 sessions, takes 20 us 
(that is micro seconds). You got 11644 us, which is approximately 600 times 
slower. Which means your virtual machine is severely overloaded, or the amount 
of resources it has allocated from the real hardware is abysmal.

On the same machine I mentioned before, having 2000 active sessions results in 
the speed calculations taking 170 us, which is well below the warning limit of 
10 ms. Which means, the relay can drive thousands of sessions and you'll never 
see the warning.

In conclusion, unless you run on a severely overloaded system, or a very 
underpowered virtual machine, you should never see that warning and seeing the 
warning doesn't mean that calculations didn't take place.

--
Dan





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


[OpenSIPS-Users] AVP + rest_post with utf-8 values

2017-03-28 Thread SamyGo
Hi,

I've a specific problem with avps containing values in language other than
English. For example an avp(test) holding a Chinese character gets
converted to ? while passing to some rest_post URL.

*code:*

$avp(test) = $fn;
xlog("L_INFO","Got Display Name: $avp(test) \n");
rest_post("$avp(url)","$avp(test)" );


The output in x-log line stays correct but the webserver gets the value of
$avp(test) converted in "...??.."

I've tried to add the charset=utf-8 in the content-type header but it
doesn't help.

Looking forward to get some hints/help on this.

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


Re: [OpenSIPS-Users] ACC Db Duration

2017-03-28 Thread qasimak...@gmail.com
Thanks Daniel :)... You saved the day!

Regards,
Qasim

On Tue, Mar 28, 2017 at 6:36 PM, Daniel Zanutti 
wrote:

> Hi
>
> Did you check "cdr_flag" on Acc module?
>
> Otherwise it will generate 2 registers, 1 for INVITE and 1 for BYE.
>
> Regards
>
> On Tue, Mar 28, 2017 at 10:29 AM, qasimak...@gmail.com <
> qasimak...@gmail.com> wrote:
>
>> Hi,
>>
>> Sorry for the spam last email i miss-clicked on send amidst writing the
>> email.
>>
>> Anyways the problem i am facing is that my ACC module is configured with
>> MySQL DB backend and the CDR's are being written. However the problem i am
>> facing is that it is not logging duration into DB or syslog. Here are debug
>> logs where query is being prepared and inserted
>>
>>
>>- db_mysql_do_prepared_query: new query=|insert into acc(
>>
>> *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance*
>>) values (?,?,?,?,?,?,?,?,?,?,?,?,?)|
>>- DBG:db_mysql:re_init_statement:  query  is >
>> *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance*
>>) values(?,?,?,?,?,?,?,?,?,?,?,?,?)>, ptr=(nil)
>>
>> The problem is that i dont see duration in this query. Am i missing some
>> flag or something that needs to be set for duration to be logged in DB?
>>
>> *P.S. I am using opensips 1.11*
>>
>> Regards,
>>
>> Qasim
>>
>> ___
>> 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] ACC Db Duration

2017-03-28 Thread Daniel Zanutti
Hi

Did you check "cdr_flag" on Acc module?

Otherwise it will generate 2 registers, 1 for INVITE and 1 for BYE.

Regards

On Tue, Mar 28, 2017 at 10:29 AM, qasimak...@gmail.com  wrote:

> Hi,
>
> Sorry for the spam last email i miss-clicked on send amidst writing the
> email.
>
> Anyways the problem i am facing is that my ACC module is configured with
> MySQL DB backend and the CDR's are being written. However the problem i am
> facing is that it is not logging duration into DB or syslog. Here are debug
> logs where query is being prepared and inserted
>
>
>- db_mysql_do_prepared_query: new query=|insert into acc(
>
> *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance*
>) values (?,?,?,?,?,?,?,?,?,?,?,?,?)|
>- DBG:db_mysql:re_init_statement:  query  is 
> *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance*
>) values(?,?,?,?,?,?,?,?,?,?,?,?,?)>, ptr=(nil)
>
> The problem is that i dont see duration in this query. Am i missing some
> flag or something that needs to be set for duration to be logged in DB?
>
> *P.S. I am using opensips 1.11*
>
> Regards,
>
> Qasim
>
> ___
> 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] ACC db duration

2017-03-28 Thread Daniel Zanutti
Hi

Did you check "cdr_flag" on Acc module?

Otherwise it will generate 2 registers, 1 for INVITE and 1 for BYE.

Regards


On Tue, Mar 28, 2017 at 10:09 AM, qasimak...@gmail.com  wrote:

> Hi,
>
> I have enabled acc module in my opensips installation with db, My CDR's
> are being written in MySQL backend but for every call the duration remains
> 0, I have checked but according to documentation duration is automatically
> logged in ACC module. PLease note following debug filtered where query is
> made and executed
>
> ___
> 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] ACC Db Duration

2017-03-28 Thread qasimak...@gmail.com
Hi,

Sorry for the spam last email i miss-clicked on send amidst writing the
email.

Anyways the problem i am facing is that my ACC module is configured with
MySQL DB backend and the CDR's are being written. However the problem i am
facing is that it is not logging duration into DB or syslog. Here are debug
logs where query is being prepared and inserted


   - db_mysql_do_prepared_query: new query=|insert into acc(
   
*method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance*
   ) values (?,?,?,?,?,?,?,?,?,?,?,?,?)|
   - DBG:db_mysql:re_init_statement:  query  is , ptr=(nil)

The problem is that i dont see duration in this query. Am i missing some
flag or something that needs to be set for duration to be logged in DB?

*P.S. I am using opensips 1.11*

Regards,

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


Re: [OpenSIPS-Users] new CDRTool release 9.5.0

2017-03-28 Thread Bogdan-Andrei Iancu

Congratulation Adrian !!

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/28/2017 03:58 PM, Adrian Georgescu wrote:

Hello,

The software includes bug fixes, better SIP tracing and compatibility with latest 
PHP version(s) >= 5.4.

Debian packages are available for Debian Jessie, Wheezy and Unstable.

The software can be downloaded from:

http://cdrtool.ag-projects.com

Changelog

cdrtool (9.5.0) unstable; urgency=medium

   * Added mysqli database backend
   * Reworked Debian packaging
   * Switched to Net/URL2
   * Update PEAR to use new syntax (prevents warnings)
   * Fixed most PHP warning messages
   * Cleaned code
   * Formatted code
   * Added systemd service

   [ Web Interface ]

   * Fixed search in logging screen
   * Fixed updating subscriber ACLs
   * Updated trace links in sip settings to use a new window for each trace
   * Updated title in sip settings page
   * Updated DNS error messages
   * Added SQL debug printer
   * Updated SIP Trace to look better

Regards,
Adrian


___
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] ACC db duration

2017-03-28 Thread qasimak...@gmail.com
Hi,

I have enabled acc module in my opensips installation with db, My CDR's are
being written in MySQL backend but for every call the duration remains 0, I
have checked but according to documentation duration is automatically
logged in ACC module. PLease note following debug filtered where query is
made and executed
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] new CDRTool release 9.5.0

2017-03-28 Thread Adrian Georgescu
Hello,

The software includes bug fixes, better SIP tracing and compatibility with 
latest PHP version(s) >= 5.4.

Debian packages are available for Debian Jessie, Wheezy and Unstable.

The software can be downloaded from:

http://cdrtool.ag-projects.com

Changelog

cdrtool (9.5.0) unstable; urgency=medium

  * Added mysqli database backend
  * Reworked Debian packaging
  * Switched to Net/URL2
  * Update PEAR to use new syntax (prevents warnings)
  * Fixed most PHP warning messages
  * Cleaned code
  * Formatted code
  * Added systemd service

  [ Web Interface ]

  * Fixed search in logging screen
  * Fixed updating subscriber ACLs
  * Updated trace links in sip settings to use a new window for each trace
  * Updated title in sip settings page
  * Updated DNS error messages
  * Added SQL debug printer
  * Updated SIP Trace to look better

Regards,
Adrian


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


Re: [OpenSIPS-Users] Opensips drouting probing

2017-03-28 Thread Denis via Users
Hello, Bogdan! Is there any idea about problem? Thank you. -- С уважением, Денис.Best regards, Denis 24.03.2017, 07:52, "Denis" :Hello! It does not work.Opensips "freezes" a call. In syslog i see "INFO:drouting:do_routing: All the gateways are disabled" -- С уважением, Денис.Best regards, Denis   23.03.2017, 18:42, "Bogdan-Andrei Iancu" :Hi,You should do :    if (!do_routing(...) ) {        send_reply("404","No Route");        exit;    }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/23/2017 04:21 PM, Denis wrote:Hello, Bogdan! "test the return code for do_routing()".How can i do that? I triedif (!do_routing("$avp(5)","W",,"$avp(300)","$avp(3)",)) {
 xlog ("Route4: Reason = $rc");
}but can see in log only "INFO:drouting:do_routing: All the gateways are disabled". Thank you. -- С уважением, Денис.Best regards, Denis   20.03.2017, 17:20, "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 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] Possible Drouting bug

2017-03-28 Thread Bogdan-Andrei Iancu

Hello John,

Do you use partitions ? Is the use_partition enabled ? If not, the 
use_next_gw() should be used like:

use_next_gw( "$avp(rules_attributes)","$avp(gw_attributes)")

(the first param, the partition, is not to be provided)

Could you check if this solves the problem ?

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/23/2017 09:19 AM, John Nash wrote:
I am using drouting and recently tried to use gateway attribute. I 
call ...


do_routing("$avp(int_grp_id)","WF","$avp(gw_whitelist)" , 
"$avp(rules_attributes)","$avp(gw_attributes)"))


After this call I can see $avp(gw_attributes) is populated frp, attr 
column of dr_gateways table.


but when i call following ...
use_next_gw(,"$avp(rules_attributes)","$avp(gw_attributes)")

$avp(gw_attributes) becomes empty


If i call next_routing() instead of use_next_gw then 
$avp(gw_attributes) retains old value but does not populate new value







___
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] SIP default port routing issue

2017-03-28 Thread Satish Patel
Thanks you,

I think i missed your email, but you said interface in my case its
PORT.  we have multiple port listening for SIP request and we have
notice INVITE comes on 5062 but when server send 200 OK it use 5060
instead of 5062 where it received invite.

On Mon, Mar 27, 2017 at 3:29 AM, Răzvan Crainea  wrote:
> Please register on the mailing list, I have already replied to this
> thread[1], but I guess you didin't get the reply.
>
> [1] http://lists.opensips.org/pipermail/users/2017-March/036849.html
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com
>
>
> On 03/26/2017 08:16 PM, Satish Patel wrote:
>>
>> any suggestion?
>>
>> On Tue, Mar 21, 2017 at 6:48 PM, Satish Patel 
>> wrote:
>>>
>>> This is little tricky question, we are developing softphone and we put
>>> logic in phone it will try to connect 5060 if it's blocked by some
>>> country then it will try 5061 if that is block then try 5062
>>>
>>> Now on OpenSIPS we are listening on all 3 ports 5060, 5061 and 5062.
>>> Now problem is here INVITE goes on correct port but when server send
>>> 200 OK mesg it will always pick first port in listen: directive, how
>>> do i synchronize communication to specific port where INVITE comes
>>> from?
>>
>> ___
>> 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