From cc3283 at att.com  Tue Jun  2 01:53:45 2020
From: cc3283 at att.com (CARTWRIGHT, CORY C)
Date: Tue, 2 Jun 2020 01:53:45 +0000
Subject: [OpenSIPS-Users] Question on inuse_transactions vs Calls in
	progress and CPS
Message-ID: <8e66a6c3af0d42f3a62a9ea08e1bbc7c@att.com>

Hello,

We use opensips in sort of a load balancer configuration, not using the load balancer mod.   We handle brokering of SUBSCRIBE / NOTIFY messages for caller name lookups.
When looking at the tm stats I see the inuse_transactions about 10x to 20x the amount of SUB queries I receive.  For example if I'm sending in 3 cps  tm stat shows tm:inuse_transactions:: 66

@300cps ~ tm:inuse_transactions:: 6016

I'm trying to understand why this is, each query averages around 250ms from SUB to NOT.  Dialog consists of  SUB, 200, NOT, 200

I'm hoping for some advice on investigating this, or if I'm just not understanding something some pointers on where to look in the documentation.

Thanks,
C


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/b19970c6/attachment.html>

From williamj at exetel.com.au  Tue Jun  2 04:07:14 2020
From: williamj at exetel.com.au (William Jin)
Date: Tue, 2 Jun 2020 04:07:14 +0000
Subject: [OpenSIPS-Users] Question about IP Transit
Message-ID: <SG2PR06MB2409F18924BA3B0C2BCC04E49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>

Hi

We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian
opensips -V
version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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.
main.c compiled on  with gcc 6.3.0

The situation is:
Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6
A(v4) <=> opensips(v4<=>v6) <=> B(v6)

We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue.

A(v4) => opensips(v4/v6) => B(v6)          -     working
A(v4) => opensips(v4/v6) => B(v6) => C(v4)   - not working
A(v4) => opensips(v4/v6) => B(v4) => C(v4)   - working

Could you please shed some light on it?

--
Regards,
William Jin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/97f3b7eb/attachment.html>

From williamj at exetel.com.au  Tue Jun  2 04:48:53 2020
From: williamj at exetel.com.au (William Jin)
Date: Tue, 2 Jun 2020 04:48:53 +0000
Subject: [OpenSIPS-Users] Question about IP Transit
In-Reply-To: <SG2PR06MB2409F18924BA3B0C2BCC04E49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>
References: <SG2PR06MB2409F18924BA3B0C2BCC04E49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>
Message-ID: <SG2PR06MB2409884F3EA53CAA7154FBF49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>

Just additional info:
A(v4) => opensips(v4/v6) => B(v6) => C(v6)   - also working
Does that mean if the B number is V6, I need to send the invite to the v6 IP of the opensips? Then the server should handle the ip transit from v6 to v4 again?



--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au>
Sent: Tuesday, 2 June 2020 2:07 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] Question about IP Transit

Hi

We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian
opensips -V
version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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.
main.c compiled on  with gcc 6.3.0

The situation is:
Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6
A(v4) <=> opensips(v4<=>v6) <=> B(v6)

We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue.

A(v4) => opensips(v4/v6) => B(v6)          -     working
A(v4) => opensips(v4/v6) => B(v6) => C(v4)   - not working
A(v4) => opensips(v4/v6) => B(v4) => C(v4)   - working

Could you please shed some light on it?

--
Regards,
William Jin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/a3d022c6/attachment-0001.html>

From spanda at 3clogic.com  Tue Jun  2 07:32:53 2020
From: spanda at 3clogic.com (Sasmita Panda)
Date: Tue, 2 Jun 2020 13:02:53 +0530
Subject: [OpenSIPS-Users] Need help in memory caching in opensips 3.0 .
In-Reply-To: <CALf-Q46uqf1OUTjjoJMMMW3dkfyZFhmFoYZnwiaDY8j0s+OWcw@mail.gmail.com>
References: <CALf-Q46uqf1OUTjjoJMMMW3dkfyZFhmFoYZnwiaDY8j0s+OWcw@mail.gmail.com>
Message-ID: <CALf-Q46m7oSbWXfAJtUjjY-yPC7++WVpivu_Mq1a=wy0Vn-DsA@mail.gmail.com>

Can  anyone help me on the above issue please ? Still I am stuck on this .


*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


On Fri, May 29, 2020 at 6:05 PM Sasmita Panda <spanda at 3clogic.com> wrote:

> Hi ,
>
> I am trying to do memory caching for authentication .  Followed the below
> link.
> https://www.opensips.org/Documentation/Tutorials-MemoryCaching
>
> my DB looks like below .
> | id | username | domain               | password | email_address | ha1 |
> ha1b | rpid |
>
> +----+----------+--------------------------------------------+----------+---------------+-----+------+------+
> |  1 | 7878     | fs-reg.i3clogic.com | som123 |               |     |
>    | NULL |
>
> loadmodule "cachedb_local.so"
> #loading auth module
> loadmodule "auth.so"
> loadmodule "auth_db.so"
>
> modparam("auth_db", "db_url", "mysql://root:cccl0g1c at localhost/opensips")
> modparam("auth_db", "calculate_ha1", yes)
> modparam("auth_db", "user_column", "username")
> #modparam("auth_db", "use_domain", 1)
> modparam("auth_db", "domain_column", "domain")
> modparam("auth_db", "password_column", "password")
> modparam("auth_db", "load_credentials", "$avp(55)=password")
>
> modparam("auth","username_spec","$avp(54)")
> modparam("auth","password_spec","$avp(55)")
>
>  if(cache_fetch("local","passwd_$tu",$avp(55))) {
>                 $avp(54) = $tU;
>                 if (!pv_www_authorize("")) {
>                         # authentication failed -> do challenge
>                         www_challenge("", "1");
>                         exit;
>                 };
>         } else {
>                 if (!www_authorize("", "subscriber")) {
>                         # authentication failed -> do challenge
>                         www_challenge("", "1");
>                         exit;
>                 };
>                 # after DB authentication, the password is available
>                 cache_store("local","passwd_$tu","$avp(55)",1200);
>         }
>
>
> This thing I have done . While doing DB authentication its working , but
> which doing through memory caching its giving error "Incorrect Password" .
> Whats wrong I  am doing . please help me .
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/3ea0dd91/attachment.html>

From burhankhan1 at gmail.com  Tue Jun  2 13:06:15 2020
From: burhankhan1 at gmail.com (Burhan Khan)
Date: Tue, 2 Jun 2020 15:06:15 +0200
Subject: [OpenSIPS-Users] Sip traces to remote Homer Server
Message-ID: <CAEHqF3Y_EhPZ31CnW6umoajxmPqg3n70UOdXn4Wm6kDKhQ9MLw@mail.gmail.com>

Hi

I am trying to send sip traces from opensips 3.0 to remote Homer server but
it is getting error. Following is my configuration


loadmodule "proto_hep.so"

loadmodule  "tracer.so"



listen=hep_udp:1.2.3.4:9060



modparam("tracer", "trace_on", 1)

modparam("proto_hep", "hep_id", "[homer] 1.2.3.4:9060;transport=udp")


modparam("tracer", "trace_id", "[tid]uri=hep:homer")


In route section


        $var(trace_id) = "tid";

        trace($var(trace_id),  , "sip", );

 Error is :::

*ERROR:core:udp_init_listener: bind(27, 0x7ff5729214c4, 16) on *1.2.3.4*:
Cannot assign requested address*
*ERROR:core:trans_init_all_listeners: failed to init listener [*1.2.3.4*],
proto hep_udp*
*ERROR:core:main: failed to init all SIP listeners, aborting*



*Regards*
*Burhan Khan*

*+46769568906*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/eab97199/attachment.html>

From sobomax at sippysoft.com  Tue Jun  2 13:55:09 2020
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Tue, 2 Jun 2020 06:55:09 -0700
Subject: [OpenSIPS-Users] Sip traces to remote Homer Server
In-Reply-To: <CAEHqF3Y_EhPZ31CnW6umoajxmPqg3n70UOdXn4Wm6kDKhQ9MLw@mail.gmail.com>
References: <CAEHqF3Y_EhPZ31CnW6umoajxmPqg3n70UOdXn4Wm6kDKhQ9MLw@mail.gmail.com>
Message-ID: <CAH7qZfsJQC0_4FMhy6KHQ=6gnSM0htV6ki67rEZ1L9QpV2o=mg@mail.gmail.com>

Well, apparently there is no  1.2.3.4 IP configured on your machine, you
need to replace it with an actual IP address, or possibly 0.0.0.0 if a
particular source address does not matter.

-Max

-Max

On Tue, Jun 2, 2020 at 6:07 AM Burhan Khan <burhankhan1 at gmail.com> wrote:

> Hi
>
> I am trying to send sip traces from opensips 3.0 to remote Homer server
> but it is getting error. Following is my configuration
>
>
> loadmodule "proto_hep.so"
>
> loadmodule  "tracer.so"
>
>
>
> listen=hep_udp:1.2.3.4:9060
>
>
>
> modparam("tracer", "trace_on", 1)
>
> modparam("proto_hep", "hep_id", "[homer] 1.2.3.4:9060;transport=udp")
>
>
> modparam("tracer", "trace_id", "[tid]uri=hep:homer")
>
>
> In route section
>
>
>         $var(trace_id) = "tid";
>
>         trace($var(trace_id),  , "sip", );
>
>  Error is :::
>
> *ERROR:core:udp_init_listener: bind(27, 0x7ff5729214c4, 16) on *1.2.3.4*:
> Cannot assign requested address*
> *ERROR:core:trans_init_all_listeners: failed to init listener [*1.2.3.4*],
> proto hep_udp*
> *ERROR:core:main: failed to init all SIP listeners, aborting*
>
>
>
> *Regards*
> *Burhan Khan*
>
> *+46769568906*
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/703f5b35/attachment-0001.html>

From burhankhan1 at gmail.com  Tue Jun  2 14:05:40 2020
From: burhankhan1 at gmail.com (Burhan Khan)
Date: Tue, 2 Jun 2020 16:05:40 +0200
Subject: [OpenSIPS-Users] Sip traces to remote Homer Server
In-Reply-To: <CAH7qZfsJQC0_4FMhy6KHQ=6gnSM0htV6ki67rEZ1L9QpV2o=mg@mail.gmail.com>
References: <CAEHqF3Y_EhPZ31CnW6umoajxmPqg3n70UOdXn4Wm6kDKhQ9MLw@mail.gmail.com>
 <CAH7qZfsJQC0_4FMhy6KHQ=6gnSM0htV6ki67rEZ1L9QpV2o=mg@mail.gmail.com>
Message-ID: <CAEHqF3Y2cjkiZ70cuvPQT25gJhFH-+5PjPU5ghpKQP3VoObpqg@mail.gmail.com>

There is some real IP instead of 1.2.3.4. It is pingable and it's port 9060
is accessible from opensips machine.

On Tue, Jun 2, 2020 at 3:57 PM Maxim Sobolev <sobomax at sippysoft.com> wrote:

> Well, apparently there is no  1.2.3.4 IP configured on your machine, you
> need to replace it with an actual IP address, or possibly 0.0.0.0 if a
> particular source address does not matter.
>
> -Max
>
> -Max
>
> On Tue, Jun 2, 2020 at 6:07 AM Burhan Khan <burhankhan1 at gmail.com> wrote:
>
>> Hi
>>
>> I am trying to send sip traces from opensips 3.0 to remote Homer server
>> but it is getting error. Following is my configuration
>>
>>
>> loadmodule "proto_hep.so"
>>
>> loadmodule  "tracer.so"
>>
>>
>>
>> listen=hep_udp:1.2.3.4:9060
>>
>>
>>
>> modparam("tracer", "trace_on", 1)
>>
>> modparam("proto_hep", "hep_id", "[homer] 1.2.3.4:9060;transport=udp")
>>
>>
>> modparam("tracer", "trace_id", "[tid]uri=hep:homer")
>>
>>
>> In route section
>>
>>
>>         $var(trace_id) = "tid";
>>
>>         trace($var(trace_id),  , "sip", );
>>
>>  Error is :::
>>
>> *ERROR:core:udp_init_listener: bind(27, 0x7ff5729214c4, 16) on *1.2.3.4*:
>> Cannot assign requested address*
>> *ERROR:core:trans_init_all_listeners: failed to init listener [*1.2.3.4*],
>> proto hep_udp*
>> *ERROR:core:main: failed to init all SIP listeners, aborting*
>>
>>
>>
>> *Regards*
>> *Burhan Khan*
>>
>> *+46769568906*
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales at sippysoft.com
> Skype: SippySoft
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

*Regards*
*Burhan Khan*

*+46769568906*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/873d6be1/attachment.html>

From sobomax at sippysoft.com  Tue Jun  2 16:41:08 2020
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Tue, 2 Jun 2020 09:41:08 -0700
Subject: [OpenSIPS-Users] Sip traces to remote Homer Server
In-Reply-To: <CAEHqF3Y2cjkiZ70cuvPQT25gJhFH-+5PjPU5ghpKQP3VoObpqg@mail.gmail.com>
References: <CAEHqF3Y_EhPZ31CnW6umoajxmPqg3n70UOdXn4Wm6kDKhQ9MLw@mail.gmail.com>
 <CAH7qZfsJQC0_4FMhy6KHQ=6gnSM0htV6ki67rEZ1L9QpV2o=mg@mail.gmail.com>
 <CAEHqF3Y2cjkiZ70cuvPQT25gJhFH-+5PjPU5ghpKQP3VoObpqg@mail.gmail.com>
Message-ID: <CAH7qZfs8dAwo3BoAehzRD85zajSvMrub8N9MGk58F0ryS7Ws-g@mail.gmail.com>

That IP address in the listen directive should be the *address of the
OpenSIPS machine itself*, since it's going to be the address where the HEP
client socket binds. The destination address is specified in the
modparam( "proto_hep",
"hep_id",  ...).

The only scenario when both addresses are the same is when both OpenSIPS
and Homer are running on the same box, which I suppose is not the case.

-Max

On Tue, Jun 2, 2020 at 7:07 AM Burhan Khan <burhankhan1 at gmail.com> wrote:

> There is some real IP instead of 1.2.3.4. It is pingable and it's port
> 9060 is accessible from opensips machine.
>
> On Tue, Jun 2, 2020 at 3:57 PM Maxim Sobolev <sobomax at sippysoft.com>
> wrote:
>
>> Well, apparently there is no  1.2.3.4 IP configured on your machine, you
>> need to replace it with an actual IP address, or possibly 0.0.0.0 if a
>> particular source address does not matter.
>>
>> -Max
>>
>> -Max
>>
>> On Tue, Jun 2, 2020 at 6:07 AM Burhan Khan <burhankhan1 at gmail.com> wrote:
>>
>>> Hi
>>>
>>> I am trying to send sip traces from opensips 3.0 to remote Homer server
>>> but it is getting error. Following is my configuration
>>>
>>>
>>> loadmodule "proto_hep.so"
>>>
>>> loadmodule  "tracer.so"
>>>
>>>
>>>
>>> listen=hep_udp:1.2.3.4:9060
>>>
>>>
>>>
>>> modparam("tracer", "trace_on", 1)
>>>
>>> modparam("proto_hep", "hep_id", "[homer] 1.2.3.4:9060;transport=udp")
>>>
>>>
>>> modparam("tracer", "trace_id", "[tid]uri=hep:homer")
>>>
>>>
>>> In route section
>>>
>>>
>>>         $var(trace_id) = "tid";
>>>
>>>         trace($var(trace_id),  , "sip", );
>>>
>>>  Error is :::
>>>
>>> *ERROR:core:udp_init_listener: bind(27, 0x7ff5729214c4, 16) on *1.2.3.4*:
>>> Cannot assign requested address*
>>> *ERROR:core:trans_init_all_listeners: failed to init listener [*1.2.3.4*],
>>> proto hep_udp*
>>> *ERROR:core:main: failed to init all SIP listeners, aborting*
>>>
>>>
>>>
>>> *Regards*
>>> *Burhan Khan*
>>>
>>> *+46769568906*
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>> Maksym Sobolyev
>> Sippy Software, Inc.
>> Internet Telephony (VoIP) Experts
>> Tel (Canada): +1-778-783-0474
>> Tel (Toll-Free): +1-855-747-7779
>> Fax: +1-866-857-6942
>> Web: http://www.sippysoft.com
>> MSN: sales at sippysoft.com
>> Skype: SippySoft
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
>
> *Regards*
> *Burhan Khan*
>
> *+46769568906*
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/b31ab78d/attachment-0001.html>

From tito at xsvoce.com  Tue Jun  2 18:52:59 2020
From: tito at xsvoce.com (Tito Cumpen)
Date: Tue, 2 Jun 2020 11:52:59 -0700
Subject: [OpenSIPS-Users] Need help in memory caching in opensips 3.0 .
In-Reply-To: <CALf-Q46m7oSbWXfAJtUjjY-yPC7++WVpivu_Mq1a=wy0Vn-DsA@mail.gmail.com>
References: <CALf-Q46uqf1OUTjjoJMMMW3dkfyZFhmFoYZnwiaDY8j0s+OWcw@mail.gmail.com>
 <CALf-Q46m7oSbWXfAJtUjjY-yPC7++WVpivu_Mq1a=wy0Vn-DsA@mail.gmail.com>
Message-ID: <CANZPVB5EX22tq85_HafG-kc-6JUp_5+fdxm-s6u+xQfV-ncn8Q@mail.gmail.com>

Sasmita,


Try using


  proxy_challenge("", "1");


instead of
                        www_challenge("", "1");





On Tue, Jun 2, 2020 at 12:36 AM Sasmita Panda <spanda at 3clogic.com> wrote:

> Can  anyone help me on the above issue please ? Still I am stuck on this .
>
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Fri, May 29, 2020 at 6:05 PM Sasmita Panda <spanda at 3clogic.com> wrote:
>
>> Hi ,
>>
>> I am trying to do memory caching for authentication .  Followed the below
>> link.
>> https://www.opensips.org/Documentation/Tutorials-MemoryCaching
>>
>> my DB looks like below .
>> | id | username | domain               | password | email_address | ha1 |
>> ha1b | rpid |
>>
>> +----+----------+--------------------------------------------+----------+---------------+-----+------+------+
>> |  1 | 7878     | fs-reg.i3clogic.com | som123 |               |     |
>>    | NULL |
>>
>> loadmodule "cachedb_local.so"
>> #loading auth module
>> loadmodule "auth.so"
>> loadmodule "auth_db.so"
>>
>> modparam("auth_db", "db_url", "mysql://root:cccl0g1c at localhost/opensips")
>> modparam("auth_db", "calculate_ha1", yes)
>> modparam("auth_db", "user_column", "username")
>> #modparam("auth_db", "use_domain", 1)
>> modparam("auth_db", "domain_column", "domain")
>> modparam("auth_db", "password_column", "password")
>> modparam("auth_db", "load_credentials", "$avp(55)=password")
>>
>> modparam("auth","username_spec","$avp(54)")
>> modparam("auth","password_spec","$avp(55)")
>>
>>  if(cache_fetch("local","passwd_$tu",$avp(55))) {
>>                 $avp(54) = $tU;
>>                 if (!pv_www_authorize("")) {
>>                         # authentication failed -> do challenge
>>                         www_challenge("", "1");
>>                         exit;
>>                 };
>>         } else {
>>                 if (!www_authorize("", "subscriber")) {
>>                         # authentication failed -> do challenge
>>                         www_challenge("", "1");
>>                         exit;
>>                 };
>>                 # after DB authentication, the password is available
>>                 cache_store("local","passwd_$tu","$avp(55)",1200);
>>         }
>>
>>
>> This thing I have done . While doing DB authentication its working , but
>> which doing through memory caching its giving error "Incorrect Password" .
>> Whats wrong I  am doing . please help me .
>>
>> *Thanks & Regards*
>> *Sasmita Panda*
>> *Senior Network Testing and Software Engineer*
>> *3CLogic , ph:07827611765*
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200602/a8c54c44/attachment.html>

From spanda at 3clogic.com  Wed Jun  3 07:20:23 2020
From: spanda at 3clogic.com (Sasmita Panda)
Date: Wed, 3 Jun 2020 12:50:23 +0530
Subject: [OpenSIPS-Users] Need help in memory caching in opensips 3.0 .
In-Reply-To: <CANZPVB5EX22tq85_HafG-kc-6JUp_5+fdxm-s6u+xQfV-ncn8Q@mail.gmail.com>
References: <CALf-Q46uqf1OUTjjoJMMMW3dkfyZFhmFoYZnwiaDY8j0s+OWcw@mail.gmail.com>
 <CALf-Q46m7oSbWXfAJtUjjY-yPC7++WVpivu_Mq1a=wy0Vn-DsA@mail.gmail.com>
 <CANZPVB5EX22tq85_HafG-kc-6JUp_5+fdxm-s6u+xQfV-ncn8Q@mail.gmail.com>
Message-ID: <CALf-Q46jhLjU-njg1CN=-+SNqOCenhSkCQry=VewhNeazpkedw@mail.gmail.com>

I have changed my config like below .
        if(cache_fetch("local","passwd_$tu",$avp(password))) {
                $avp(username) = $tU;

                  xlog("SCRIPT: stored password is $avp(username)
 $avp(password)\n");
                if (!pv_proxy_authorize("")){
                        proxy_challenge("", "1");
                        exit;
                };

        } else {

                if (!proxy_authorize("", "subscriber")) {
                        # authentication failed -> do challenge
                        proxy_challenge("","1");
                        exit;
                };

                xlog("SCRIPT: storing password <$avp(password)>\n");

                cache_store("local","passwd_$tu","$avp(password)",1200);
        }

 Now its giving "Proxy authentication required" response .


*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


On Wed, Jun 3, 2020 at 12:24 AM Tito Cumpen <tito at xsvoce.com> wrote:

> Sasmita,
>
>
> Try using
>
>
>   proxy_challenge("", "1");
>
>
> instead of
>                         www_challenge("", "1");
>
>
>
>
>
> On Tue, Jun 2, 2020 at 12:36 AM Sasmita Panda <spanda at 3clogic.com> wrote:
>
>> Can  anyone help me on the above issue please ? Still I am stuck on this .
>>
>>
>> *Thanks & Regards*
>> *Sasmita Panda*
>> *Senior Network Testing and Software Engineer*
>> *3CLogic , ph:07827611765*
>>
>>
>> On Fri, May 29, 2020 at 6:05 PM Sasmita Panda <spanda at 3clogic.com> wrote:
>>
>>> Hi ,
>>>
>>> I am trying to do memory caching for authentication .  Followed the
>>> below link.
>>> https://www.opensips.org/Documentation/Tutorials-MemoryCaching
>>>
>>> my DB looks like below .
>>> | id | username | domain               | password | email_address | ha1
>>> | ha1b | rpid |
>>>
>>> +----+----------+--------------------------------------------+----------+---------------+-----+------+------+
>>> |  1 | 7878     | fs-reg.i3clogic.com | som123 |               |     |
>>>      | NULL |
>>>
>>> loadmodule "cachedb_local.so"
>>> #loading auth module
>>> loadmodule "auth.so"
>>> loadmodule "auth_db.so"
>>>
>>> modparam("auth_db", "db_url", "mysql://root:cccl0g1c at localhost
>>> /opensips")
>>> modparam("auth_db", "calculate_ha1", yes)
>>> modparam("auth_db", "user_column", "username")
>>> #modparam("auth_db", "use_domain", 1)
>>> modparam("auth_db", "domain_column", "domain")
>>> modparam("auth_db", "password_column", "password")
>>> modparam("auth_db", "load_credentials", "$avp(55)=password")
>>>
>>> modparam("auth","username_spec","$avp(54)")
>>> modparam("auth","password_spec","$avp(55)")
>>>
>>>  if(cache_fetch("local","passwd_$tu",$avp(55))) {
>>>                 $avp(54) = $tU;
>>>                 if (!pv_www_authorize("")) {
>>>                         # authentication failed -> do challenge
>>>                         www_challenge("", "1");
>>>                         exit;
>>>                 };
>>>         } else {
>>>                 if (!www_authorize("", "subscriber")) {
>>>                         # authentication failed -> do challenge
>>>                         www_challenge("", "1");
>>>                         exit;
>>>                 };
>>>                 # after DB authentication, the password is available
>>>                 cache_store("local","passwd_$tu","$avp(55)",1200);
>>>         }
>>>
>>>
>>> This thing I have done . While doing DB authentication its working , but
>>> which doing through memory caching its giving error "Incorrect Password" .
>>> Whats wrong I  am doing . please help me .
>>>
>>> *Thanks & Regards*
>>> *Sasmita Panda*
>>> *Senior Network Testing and Software Engineer*
>>> *3CLogic , ph:07827611765*
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200603/55d11ea8/attachment-0001.html>

From liviu at opensips.org  Wed Jun  3 14:09:38 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 3 Jun 2020 17:09:38 +0300
Subject: [OpenSIPS-Users] [BLOG] SIP Push Notification with OpenSIPS 3.1 LTS
 [RFC 8599 support][Part II]
Message-ID: <53867a7e-55ef-f968-87cf-b1af3109d947@opensips.org>

Hi, all!

It is my pleasure to announce the final post [1] in the SIP Push 
Notification with OpenSIPS 3.1 series, which will teach you how to 
enable the support within your "opensips.cfg" file, as well as how to 
make best use of it.

Enjoy!

[1]: 
https://blog.opensips.org/2020/06/03/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-ii/

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



From xuhua.lin at gmail.com  Thu Jun  4 00:44:03 2020
From: xuhua.lin at gmail.com (Howard Lin)
Date: Wed, 3 Jun 2020 20:44:03 -0400
Subject: [OpenSIPS-Users] Notification of line-seize event
Message-ID: <CAB2Ph7Fb5aDEvPG7fMoRirrSFsoR6MsZ8E7xTJht+Aykz9+LgQ@mail.gmail.com>

Hi just wonder if possible or how to send a SIP notify of line-seize event
of one AOR to another AOR?

Thanks,
Xuhua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200603/ac6e45e3/attachment.html>

From williamj at exetel.com.au  Thu Jun  4 03:35:07 2020
From: williamj at exetel.com.au (William Jin)
Date: Thu, 4 Jun 2020 03:35:07 +0000
Subject: [OpenSIPS-Users] Question about IP Transit
In-Reply-To: <SG2PR06MB2409884F3EA53CAA7154FBF49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>
References: <SG2PR06MB2409F18924BA3B0C2BCC04E49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>,
 <SG2PR06MB2409884F3EA53CAA7154FBF49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>
Message-ID: <SG2PR06MB2409E46CB9CB2C9618351D8F9B890@SG2PR06MB2409.apcprd06.prod.outlook.com>

Hi,

Does anyone have any idea?

I can send the sip trace if needed.

--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au>
Sent: Tuesday, 2 June 2020 2:48 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Question about IP Transit

Just additional info:
A(v4) => opensips(v4/v6) => B(v6) => C(v6)   - also working
Does that mean if the B number is V6, I need to send the invite to the v6 IP of the opensips? Then the server should handle the ip transit from v6 to v4 again?



--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au>
Sent: Tuesday, 2 June 2020 2:07 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] Question about IP Transit

Hi

We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian
opensips -V
version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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.
main.c compiled on  with gcc 6.3.0

The situation is:
Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6
A(v4) <=> opensips(v4<=>v6) <=> B(v6)

We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue.

A(v4) => opensips(v4/v6) => B(v6)          -     working
A(v4) => opensips(v4/v6) => B(v6) => C(v4)   - not working
A(v4) => opensips(v4/v6) => B(v4) => C(v4)   - working

Could you please shed some light on it?

--
Regards,
William Jin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/30101295/attachment.html>

From goup2010 at gmail.com  Thu Jun  4 09:17:06 2020
From: goup2010 at gmail.com (Dragomir Haralambiev)
Date: Thu, 4 Jun 2020 12:17:06 +0300
Subject: [OpenSIPS-Users] install RTPEngine on Centos 8
Message-ID: <CADzurOJNYvQ=A1KzLfNu2bU3M8k4VbiEzYKMAHhXRd_ea8xLig@mail.gmail.com>

Hello,

I need to  install RTPEngine on Centos 8?
Any help

Best regards,
Dragomir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/b5ab48ea/attachment.html>

From spanda at 3clogic.com  Thu Jun  4 12:28:49 2020
From: spanda at 3clogic.com (Sasmita Panda)
Date: Thu, 4 Jun 2020 17:58:49 +0530
Subject: [OpenSIPS-Users] Need help using cachedb_local .
Message-ID: <CALf-Q46H4DM3517M=5dhbWSG0Qg=9tY9ay7yOK3ZpvfgTY+1iw@mail.gmail.com>

Hi,

modparam("cachedb_local", "cachedb_url", "local:///collection1")


 While setting the above parameter in the cachedb_local module I am getting
below error .

ERROR:core:set_mod_param_regex: parameter <cachedb_url> not found in module
<cachedb_local>
Jun  4 12:24:15 ip-20-0-114-18 opensips: CRITICAL:core:yyerror: parse error
in config file /usr/etc/opensips/opensips_memorycache_registrar.cfg, line
148, column 20-21: Parameter <cachedb_url> not found in module
<cachedb_local> - can't set

Its saying the cachedb_url parameter is not found in the module . But the
mobile document says the parameter exists . Do suggest if I am doing
anything wrong .

*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/9599123f/attachment-0001.html>

From denys.pozniak at gmail.com  Thu Jun  4 12:32:41 2020
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Thu, 4 Jun 2020 15:32:41 +0300
Subject: [OpenSIPS-Users] install RTPEngine on Centos 8
In-Reply-To: <CADzurOJNYvQ=A1KzLfNu2bU3M8k4VbiEzYKMAHhXRd_ea8xLig@mail.gmail.com>
References: <CADzurOJNYvQ=A1KzLfNu2bU3M8k4VbiEzYKMAHhXRd_ea8xLig@mail.gmail.com>
Message-ID: <CA+x3AxoshYvGEigoVkcSDmkn_wj=LLGqXBaa_Nnnjosspy6v9g@mail.gmail.com>

Hello!
Try to use my build (not tested, as is):
https://copr.fedorainfracloud.org/coprs/denysp/rtpengine-centos8/


чт, 4 июн. 2020 г. в 12:20, Dragomir Haralambiev <goup2010 at gmail.com>:

> Hello,
>
> I need to  install RTPEngine on Centos 8?
> Any help
>
> Best regards,
> Dragomir
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

BR,
Denys Pozniak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/ef7b7baf/attachment.html>

From burhankhan1 at gmail.com  Thu Jun  4 12:38:41 2020
From: burhankhan1 at gmail.com (Burhan Khan)
Date: Thu, 4 Jun 2020 14:38:41 +0200
Subject: [OpenSIPS-Users] Sip traces to remote Homer Server
In-Reply-To: <CAH7qZfs8dAwo3BoAehzRD85zajSvMrub8N9MGk58F0ryS7Ws-g@mail.gmail.com>
References: <CAEHqF3Y_EhPZ31CnW6umoajxmPqg3n70UOdXn4Wm6kDKhQ9MLw@mail.gmail.com>
 <CAH7qZfsJQC0_4FMhy6KHQ=6gnSM0htV6ki67rEZ1L9QpV2o=mg@mail.gmail.com>
 <CAEHqF3Y2cjkiZ70cuvPQT25gJhFH-+5PjPU5ghpKQP3VoObpqg@mail.gmail.com>
 <CAH7qZfs8dAwo3BoAehzRD85zajSvMrub8N9MGk58F0ryS7Ws-g@mail.gmail.com>
Message-ID: <CAEHqF3Z0QBfCjU9HyyUvhpapdXzeV4veqT3SGdxDLryXBf4HsA@mail.gmail.com>

Thanks. It is working now

On Tue, Jun 2, 2020 at 6:44 PM Maxim Sobolev <sobomax at sippysoft.com> wrote:

> That IP address in the listen directive should be the *address of the
> OpenSIPS machine itself*, since it's going to be the address where the HEP
> client socket binds. The destination address is specified in the modparam( "proto_hep",
> "hep_id",  ...).
>
> The only scenario when both addresses are the same is when both OpenSIPS
> and Homer are running on the same box, which I suppose is not the case.
>
> -Max
>
> On Tue, Jun 2, 2020 at 7:07 AM Burhan Khan <burhankhan1 at gmail.com> wrote:
>
>> There is some real IP instead of 1.2.3.4. It is pingable and it's port
>> 9060 is accessible from opensips machine.
>>
>> On Tue, Jun 2, 2020 at 3:57 PM Maxim Sobolev <sobomax at sippysoft.com>
>> wrote:
>>
>>> Well, apparently there is no  1.2.3.4 IP configured on your machine, you
>>> need to replace it with an actual IP address, or possibly 0.0.0.0 if a
>>> particular source address does not matter.
>>>
>>> -Max
>>>
>>> -Max
>>>
>>> On Tue, Jun 2, 2020 at 6:07 AM Burhan Khan <burhankhan1 at gmail.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> I am trying to send sip traces from opensips 3.0 to remote Homer server
>>>> but it is getting error. Following is my configuration
>>>>
>>>>
>>>> loadmodule "proto_hep.so"
>>>>
>>>> loadmodule  "tracer.so"
>>>>
>>>>
>>>>
>>>> listen=hep_udp:1.2.3.4:9060
>>>>
>>>>
>>>>
>>>> modparam("tracer", "trace_on", 1)
>>>>
>>>> modparam("proto_hep", "hep_id", "[homer] 1.2.3.4:9060;transport=udp")
>>>>
>>>>
>>>> modparam("tracer", "trace_id", "[tid]uri=hep:homer")
>>>>
>>>>
>>>> In route section
>>>>
>>>>
>>>>         $var(trace_id) = "tid";
>>>>
>>>>         trace($var(trace_id),  , "sip", );
>>>>
>>>>  Error is :::
>>>>
>>>> *ERROR:core:udp_init_listener: bind(27, 0x7ff5729214c4, 16) on *1.2.3.4*:
>>>> Cannot assign requested address*
>>>> *ERROR:core:trans_init_all_listeners: failed to init listener [*1.2.3.4*],
>>>> proto hep_udp*
>>>> *ERROR:core:main: failed to init all SIP listeners, aborting*
>>>>
>>>>
>>>>
>>>> *Regards*
>>>> *Burhan Khan*
>>>>
>>>> *+46769568906*
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>>
>>> --
>>> Maksym Sobolyev
>>> Sippy Software, Inc.
>>> Internet Telephony (VoIP) Experts
>>> Tel (Canada): +1-778-783-0474
>>> Tel (Toll-Free): +1-855-747-7779
>>> Fax: +1-866-857-6942
>>> Web: http://www.sippysoft.com
>>> MSN: sales at sippysoft.com
>>> Skype: SippySoft
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>>
>> *Regards*
>> *Burhan Khan*
>>
>> *+46769568906*
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales at sippysoft.com
> Skype: SippySoft
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

*Regards*
*Burhan Khan*

*+46769568906*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/e58c669d/attachment-0001.html>

From darpan.gabani1093 at gmail.com  Thu Jun  4 17:48:15 2020
From: darpan.gabani1093 at gmail.com (Darpan Patel)
Date: Thu, 4 Jun 2020 23:18:15 +0530
Subject: [OpenSIPS-Users] $DLG_dir is getting NULL in onreply_route
Message-ID: <CAKzT-z107dyzrKTGTpGfffpyUXzWi4R4JvJrXCOAfYTw6P_7aw@mail.gmail.com>

Hello , i am getting NULL value of $DLG_dir  as i wanted to check 200 ok
comes from which direction (upstream or downstream).
----------------------------------------------------------------
version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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: edef893c5
main.c compiled on 03:21:55 Jun  2 2020 with gcc 4.8.5
---------------------------------------------------------------------------------------
Implementation :

route[RELAY_ROUTE]{
   t_on_reply("DEFAULT_REPLY_ROUTE");
  .
  .
}

onreply_route[DEFAULT_REPLY_ROUTE]{
         xlog("L_INFO","[$ci][DEFAULT_REPLY_ROUTE]* [$DLG_dir]* ");
          if(is_method("INVITE") && has_totag()){
                  if (t_check_status("200")) {

                                xlog("L_INFO","[$ci][onreply_route] [200]
[PROCESS_RTPENGINE_ANSWER] *[$DLG_dir]* ");
                    }
         }
}
-----------------------------------------------------------------------------------------
log :
Jun  4 13:09:47 sip-t42s /usr/local/sbin/opensips[10338]:
[OGQxMGQ1NTNhYTIzNDk1MGUyOTRjYjY3NjlkMjY1ODI.][DEFAULT_REPLY_ROUTE]
*[<null>]*
Jun  4 13:09:47 sip-t42s /usr/local/sbin/opensips[10338]:
[OGQxMGQ1NTNhYTIzNDk1MGUyOTRjYjY3NjlkMjY1ODI.][onreply_route] [200]
*[<null>]*
--------------------------------------------------------------------------------------------


please kindly help for the same
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/92141518/attachment.html>

From Ben.Newlin at genesys.com  Thu Jun  4 18:12:06 2020
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Thu, 4 Jun 2020 18:12:06 +0000
Subject: [OpenSIPS-Users] $DLG_dir is getting NULL in onreply_route
In-Reply-To: <CAKzT-z107dyzrKTGTpGfffpyUXzWi4R4JvJrXCOAfYTw6P_7aw@mail.gmail.com>
References: <CAKzT-z107dyzrKTGTpGfffpyUXzWi4R4JvJrXCOAfYTw6P_7aw@mail.gmail.com>
Message-ID: <9D60CB5A-E433-4885-884B-8BC8A7056A5A@genesys.com>

Are you sure this is a sequential request? The $DLG_dir variable is only used for sequential requests as the direction indicated is relative to the initial request. [1] The direction for the initial request would always be “downstream”.

[1] https://opensips.org/docs/modules/3.0.x/dialog.html#pv_DLG_dir

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Darpan Patel <darpan.gabani1093 at gmail.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Thursday, June 4, 2020 at 1:49 PM
To: "users at lists.opensips.org" <users at lists.opensips.org>
Subject: [OpenSIPS-Users] $DLG_dir is getting NULL in onreply_route

Hello , i am getting NULL value of $DLG_dir  as i wanted to check 200 ok comes from which direction (upstream or downstream).
----------------------------------------------------------------
version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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: edef893c5
main.c compiled on 03:21:55 Jun  2 2020 with gcc 4.8.5
---------------------------------------------------------------------------------------
Implementation :

route[RELAY_ROUTE]{
   t_on_reply("DEFAULT_REPLY_ROUTE");
  .
  .
}

onreply_route[DEFAULT_REPLY_ROUTE]{
         xlog("L_INFO","[$ci][DEFAULT_REPLY_ROUTE] [$DLG_dir] ");
          if(is_method("INVITE") && has_totag()){
                  if (t_check_status("200")) {

                                xlog("L_INFO","[$ci][onreply_route] [200] [PROCESS_RTPENGINE_ANSWER] [$DLG_dir] ");
                    }
         }
}
-----------------------------------------------------------------------------------------
log :
Jun  4 13:09:47 sip-t42s /usr/local/sbin/opensips[10338]: [OGQxMGQ1NTNhYTIzNDk1MGUyOTRjYjY3NjlkMjY1ODI.][DEFAULT_REPLY_ROUTE] [<null>]
Jun  4 13:09:47 sip-t42s /usr/local/sbin/opensips[10338]: [OGQxMGQ1NTNhYTIzNDk1MGUyOTRjYjY3NjlkMjY1ODI.][onreply_route] [200] [<null>]
--------------------------------------------------------------------------------------------


please kindly help for the same



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/d60520f2/attachment.html>

From calvin.ellison at voxox.com  Thu Jun  4 19:14:51 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Thu, 4 Jun 2020 12:14:51 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
Message-ID: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>

The scenario is INVITE -> MySQL query -> non-200 final response. No
calls are connected here, only dipping things like LRN, Do Not Call,
and Wireless/Landline. A similar service runs on a second port,
specific to a different kind of traffic and dip. We're using async
avp_db_query and memcached, with about 3:1 cache hits.

Our target is up to 10,000 CPS across two opensips servers, which are
dual-CPU Xeon E5620 with 48G RAM. Both are run memcached, and both
servers are using both memcached to share a distributed cache thanks
to this:
'modparam("cachedb_memcached","cachedb_url","memcached:lrn://lrn-d,lrn-e/")'.
At a glance there are over 200mil total cached items, distributed
nearly equally.

The issue is that individual child processes start getting suck at
100% CPU. Logs indicate connection failures to the MySQL database
causing children to run in sync mode, and there are warnings about
delayed timer jobs tm-timer and blcore-expire. Eventually, the service
becomes unresponsive. Restarting opensips restores service and the
children return to single-digit CPU utilization, but eventually,
children get suck again.

I'm not certain if the issue is on the database server, or if the
opensips servers are overloaded, or if the config is just not right
yet.

Is there an established method for fine-tuning these things?
shared memory
process memory
children
db_max_async_connections
listen=... use_children
modparam("tm", "timer_partitions", ?)

What else is worth considering?
Does a child ever return to async mode after running in sync mode?
How do I know when my servers have reached their limit?
opensips.cfg is available on request.

version: opensips 2.4.7 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
F_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: 9e1fcc915
main.c compiled on  with gcc 7

*re-built using dpkg-buildpackage including the patch to support DB
floating point types:
https://opensips.org/pipermail/users/2020-March/042528.html

$ lsb_release -d
Description:    Ubuntu 18.04.4 LTS

$ uname -a
Linux TC-521 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux

$ free -mw
              total        used        free      shared     buffers
   cache   available
Mem:          48281        1085         337          87        1729
   45128       46551

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              16
On-line CPU(s) list: 0-15
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           2
NUMA node(s):        2
Vendor ID:           GenuineIntel
CPU family:          6
Model:               44
Model name:          Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
Stepping:            2
CPU MHz:             2527.029
BogoMIPS:            4788.05
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            12288K
NUMA node0 CPU(s):   0,2,4,6,8,10,12,14
NUMA node1 CPU(s):   1,3,5,7,9,11,13,15
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca
sse4_1 sse4_2 popcnt aes lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow
vnmi flexpriority ept vpid dtherm ida arat flush_l1d

Regards,

Calvin Ellison
Senior Voice Operations Engineer
calvin.ellison at voxox.com


From osas at voipembedded.com  Thu Jun  4 19:41:19 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Thu, 4 Jun 2020 15:41:19 -0400
Subject: [OpenSIPS-Users] Need help using cachedb_local .
In-Reply-To: <CALf-Q46H4DM3517M=5dhbWSG0Qg=9tY9ay7yOK3ZpvfgTY+1iw@mail.gmail.com>
References: <CALf-Q46H4DM3517M=5dhbWSG0Qg=9tY9ay7yOK3ZpvfgTY+1iw@mail.gmail.com>
Message-ID: <CAND0LkvTzVs4jV0Zi2uLzuziUFUj+CSemC=eUBv+c2b8pFm1SQ@mail.gmail.com>

Have you defined the 'collection1' as part of the cache_collections param?
Something like:
modparam("cachedb_local", "cache_collections", "collection1")

Regards,
Ovidiu Sas

On Thu, Jun 4, 2020 at 8:30 AM Sasmita Panda <spanda at 3clogic.com> wrote:
>
> Hi,
>
> modparam("cachedb_local", "cachedb_url", "local:///collection1")
>
>
>  While setting the above parameter in the cachedb_local module I am getting below error .
>
> ERROR:core:set_mod_param_regex: parameter <cachedb_url> not found in module <cachedb_local>
> Jun  4 12:24:15 ip-20-0-114-18 opensips: CRITICAL:core:yyerror: parse error in config file /usr/etc/opensips/opensips_memorycache_registrar.cfg, line 148, column 20-21: Parameter <cachedb_url> not found in module <cachedb_local> - can't set
>
> Its saying the cachedb_url parameter is not found in the module . But the mobile document says the parameter exists . Do suggest if I am doing anything wrong .
>
> Thanks & Regards
> Sasmita Panda
> Senior Network Testing and Software Engineer
> 3CLogic , ph:07827611765
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From ffshoh at gmail.com  Thu Jun  4 19:42:06 2020
From: ffshoh at gmail.com (Jon Abrams)
Date: Thu, 4 Jun 2020 14:42:06 -0500
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
Message-ID: <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>

A) Is the LRN database located locally on the OpenSIPs box or is it remote?
B) Have you tried only doing sync database queries? Async introduces some
overhead, and I'm not sure if it causes extra database connections to be
created. When using sync there is a connection per child process that stays
up.
C) Does the database have enough memory to contain the LRN and DNC datasets
fully in memory? The extra latency for the non-cache hits sent to the
database may stack up if the database has to hit disk.
D) How many child processes are you using now? If you are hitting 100% you
may need to increase them.
E) Are your memcached processes using heavy cpu? If you are caching
multiple lists, I've found it helps to use unique memcached instance per
list.
F) Look for memory related log messages. If the memory starts getting
exhausted you will see defrag messages. This will chew up available
computation cycles.

- Jon Abrams


On Thu, Jun 4, 2020 at 2:17 PM Calvin Ellison <calvin.ellison at voxox.com>
wrote:

> The scenario is INVITE -> MySQL query -> non-200 final response. No
> calls are connected here, only dipping things like LRN, Do Not Call,
> and Wireless/Landline. A similar service runs on a second port,
> specific to a different kind of traffic and dip. We're using async
> avp_db_query and memcached, with about 3:1 cache hits.
>
> Our target is up to 10,000 CPS across two opensips servers, which are
> dual-CPU Xeon E5620 with 48G RAM. Both are run memcached, and both
> servers are using both memcached to share a distributed cache thanks
> to this:
>
> 'modparam("cachedb_memcached","cachedb_url","memcached:lrn://lrn-d,lrn-e/")'.
> At a glance there are over 200mil total cached items, distributed
> nearly equally.
>
> The issue is that individual child processes start getting suck at
> 100% CPU. Logs indicate connection failures to the MySQL database
> causing children to run in sync mode, and there are warnings about
> delayed timer jobs tm-timer and blcore-expire. Eventually, the service
> becomes unresponsive. Restarting opensips restores service and the
> children return to single-digit CPU utilization, but eventually,
> children get suck again.
>
> I'm not certain if the issue is on the database server, or if the
> opensips servers are overloaded, or if the config is just not right
> yet.
>
> Is there an established method for fine-tuning these things?
> shared memory
> process memory
> children
> db_max_async_connections
> listen=... use_children
> modparam("tm", "timer_partitions", ?)
>
> What else is worth considering?
> Does a child ever return to async mode after running in sync mode?
> How do I know when my servers have reached their limit?
> opensips.cfg is available on request.
>
> version: opensips 2.4.7 (x86_64/linux)
> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> F_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: 9e1fcc915
> main.c compiled on  with gcc 7
>
> *re-built using dpkg-buildpackage including the patch to support DB
> floating point types:
> https://opensips.org/pipermail/users/2020-March/042528.html
>
> $ lsb_release -d
> Description:    Ubuntu 18.04.4 LTS
>
> $ uname -a
> Linux TC-521 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> $ free -mw
>               total        used        free      shared     buffers
>    cache   available
> Mem:          48281        1085         337          87        1729
>    45128       46551
>
> $ lscpu
> Architecture:        x86_64
> CPU op-mode(s):      32-bit, 64-bit
> Byte Order:          Little Endian
> CPU(s):              16
> On-line CPU(s) list: 0-15
> Thread(s) per core:  2
> Core(s) per socket:  4
> Socket(s):           2
> NUMA node(s):        2
> Vendor ID:           GenuineIntel
> CPU family:          6
> Model:               44
> Model name:          Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
> Stepping:            2
> CPU MHz:             2527.029
> BogoMIPS:            4788.05
> Virtualization:      VT-x
> L1d cache:           32K
> L1i cache:           32K
> L2 cache:            256K
> L3 cache:            12288K
> NUMA node0 CPU(s):   0,2,4,6,8,10,12,14
> NUMA node1 CPU(s):   1,3,5,7,9,11,13,15
> Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca
> sse4_1 sse4_2 popcnt aes lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow
> vnmi flexpriority ept vpid dtherm ida arat flush_l1d
>
> Regards,
>
> Calvin Ellison
> Senior Voice Operations Engineer
> calvin.ellison at voxox.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/5d68bd0f/attachment.html>

From venefax at gmail.com  Thu Jun  4 21:54:53 2020
From: venefax at gmail.com (Saint Michael)
Date: Thu, 4 Jun 2020 17:54:53 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
Message-ID: <CAC9cSOABL5EoJk5LHfpKYEJav4g-FzEpO4EGg4LMVh5kHETBLw@mail.gmail.com>

Calvin, feel free to login to the container and change the config for
MariaDB, it is located in a single file /etc/my.cnf.
I use TokuDB, a new engine that is better than InnoDB. Lately, I shifted to
RocksDB, which is even better, designed by Facebook.
I have not updated that box because: "if it ain't broke, don't fix it".
But I am open to change the engine in the second container, if you
so desire..
MariaDB is better than MySQL because it gives us a pool of threads,
something that MySQL only gives to paying customers. So I think it should
work.


On Thu, Jun 4, 2020 at 3:44 PM Jon Abrams <ffshoh at gmail.com> wrote:

> A) Is the LRN database located locally on the OpenSIPs box or is it remote?
> B) Have you tried only doing sync database queries? Async introduces some
> overhead, and I'm not sure if it causes extra database connections to be
> created. When using sync there is a connection per child process that stays
> up.
> C) Does the database have enough memory to contain the LRN and DNC
> datasets fully in memory? The extra latency for the non-cache hits sent to
> the database may stack up if the database has to hit disk.
> D) How many child processes are you using now? If you are hitting 100% you
> may need to increase them.
> E) Are your memcached processes using heavy cpu? If you are caching
> multiple lists, I've found it helps to use unique memcached instance per
> list.
> F) Look for memory related log messages. If the memory starts getting
> exhausted you will see defrag messages. This will chew up available
> computation cycles.
>
> - Jon Abrams
>
>
> On Thu, Jun 4, 2020 at 2:17 PM Calvin Ellison <calvin.ellison at voxox.com>
> wrote:
>
>> The scenario is INVITE -> MySQL query -> non-200 final response. No
>> calls are connected here, only dipping things like LRN, Do Not Call,
>> and Wireless/Landline. A similar service runs on a second port,
>> specific to a different kind of traffic and dip. We're using async
>> avp_db_query and memcached, with about 3:1 cache hits.
>>
>> Our target is up to 10,000 CPS across two opensips servers, which are
>> dual-CPU Xeon E5620 with 48G RAM. Both are run memcached, and both
>> servers are using both memcached to share a distributed cache thanks
>> to this:
>>
>> 'modparam("cachedb_memcached","cachedb_url","memcached:lrn://lrn-d,lrn-e/")'.
>> At a glance there are over 200mil total cached items, distributed
>> nearly equally.
>>
>> The issue is that individual child processes start getting suck at
>> 100% CPU. Logs indicate connection failures to the MySQL database
>> causing children to run in sync mode, and there are warnings about
>> delayed timer jobs tm-timer and blcore-expire. Eventually, the service
>> becomes unresponsive. Restarting opensips restores service and the
>> children return to single-digit CPU utilization, but eventually,
>> children get suck again.
>>
>> I'm not certain if the issue is on the database server, or if the
>> opensips servers are overloaded, or if the config is just not right
>> yet.
>>
>> Is there an established method for fine-tuning these things?
>> shared memory
>> process memory
>> children
>> db_max_async_connections
>> listen=... use_children
>> modparam("tm", "timer_partitions", ?)
>>
>> What else is worth considering?
>> Does a child ever return to async mode after running in sync mode?
>> How do I know when my servers have reached their limit?
>> opensips.cfg is available on request.
>>
>> version: opensips 2.4.7 (x86_64/linux)
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>> F_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: 9e1fcc915
>> main.c compiled on  with gcc 7
>>
>> *re-built using dpkg-buildpackage including the patch to support DB
>> floating point types:
>> https://opensips.org/pipermail/users/2020-March/042528.html
>>
>> $ lsb_release -d
>> Description:    Ubuntu 18.04.4 LTS
>>
>> $ uname -a
>> Linux TC-521 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC
>> 2020 x86_64 x86_64 x86_64 GNU/Linux
>>
>> $ free -mw
>>               total        used        free      shared     buffers
>>    cache   available
>> Mem:          48281        1085         337          87        1729
>>    45128       46551
>>
>> $ lscpu
>> Architecture:        x86_64
>> CPU op-mode(s):      32-bit, 64-bit
>> Byte Order:          Little Endian
>> CPU(s):              16
>> On-line CPU(s) list: 0-15
>> Thread(s) per core:  2
>> Core(s) per socket:  4
>> Socket(s):           2
>> NUMA node(s):        2
>> Vendor ID:           GenuineIntel
>> CPU family:          6
>> Model:               44
>> Model name:          Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
>> Stepping:            2
>> CPU MHz:             2527.029
>> BogoMIPS:            4788.05
>> Virtualization:      VT-x
>> L1d cache:           32K
>> L1i cache:           32K
>> L2 cache:            256K
>> L3 cache:            12288K
>> NUMA node0 CPU(s):   0,2,4,6,8,10,12,14
>> NUMA node1 CPU(s):   1,3,5,7,9,11,13,15
>> Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
>> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
>> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca
>> sse4_1 sse4_2 popcnt aes lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow
>> vnmi flexpriority ept vpid dtherm ida arat flush_l1d
>>
>> Regards,
>>
>> Calvin Ellison
>> Senior Voice Operations Engineer
>> calvin.ellison at voxox.com
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200604/8b648a6b/attachment-0001.html>

From calvin.ellison at voxox.com  Fri Jun  5 00:06:00 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Thu, 4 Jun 2020 17:06:00 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
Message-ID: <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>

> A) Is the LRN database located locally on the OpenSIPs box or is it remote?

We are using an F5 BIG-IP to proxy a pool of database servers.
Opensips is showing two connection-related errors:

Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
ERROR:db_mysql:db_mysql_connect: driver error(2013): Lost connection
to MySQL server at 'reading authorization packet', system error: 110
Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
ERROR:db_mysql:db_mysql_new_connection: initial connect failed
Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
ERROR:core:db_init_async: failed to open new DB connection on
mysql://XXXX:XXXX at 10.0.5.38:0/
Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
INFO:db_mysql:db_mysql_async_raw_query: Failed to open new connection
(current: 1 + 8). Running in sync mode!
Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
INFO:db_mysql:switch_state_to_disconnected: disconnect event for
0x7f8903f16d10
Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
INFO:db_mysql:reset_all_statements: resetting all statements on
connection: (0x7f8903f16bb0) 0x7f8903f16d10
Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
INFO:db_mysql:connect_with_retry: re-connected successful for
0x7f8903f16d10

Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
ERROR:db_mysql:db_mysql_connect: driver error(2003): Can't connect to
MySQL server on '10.0.5.38' (110)
Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
ERROR:db_mysql:db_mysql_new_connection: initial connect failed
Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
ERROR:core:db_init_async: failed to open new DB connection on
mysql://XXXX:XXXX at 10.0.5.38:0/
Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
INFO:db_mysql:db_mysql_async_raw_query: Failed to open new connection
(current: 1 + 10). Running in sync mode!
Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
INFO:db_mysql:switch_state_to_disconnected: disconnect event for
0x7f8903f16d10
Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
INFO:db_mysql:reset_all_statements: resetting all statements on
connection: (0x7f8903f16bb0) 0x7f8903f16d10
Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
INFO:db_mysql:connect_with_retry: re-connected successful for
0x7f8903f16d10

MariaDB is also showing an error from its perspective:

2020-06-04 23:40:27 64783 [Warning] Aborted connection 64783 to db:
'unconnected' user: 'anonymous' host: '8.38.42.13' (Got timeout
reading communication packets)

> B) Have you tried only doing sync database queries? Async introduces some overhead, and I'm not sure if it causes extra database connections to be created. When using sync there is a connection per child process that stays up.

Using synchronous mode appeared to be causing context switching issues
under heavy load. We specifically moved to async for this reason and
that appeared to reduce the CPU load dramatically. From the docs:

"Using the asynchronous, "suspend-resume" logic instead of forking a
large number of processes in order to scale also has the advantage of
optimizing system resource usage, increasing its maximal throughput.
By requiring less processes to complete the same amount of work in the
same amount of time, process context switching is minimized and
overall CPU usage is improved. Less processes will also eat up less
system memory."

I've been tweaking each of the configuration settings I've mentioned,
but without any clear path forward. Would 3.x provide any solutions?

Is it possible to have too many children or timer partitions, and
starve opensips with context switches? Would that cause connection
issues?

> C) Does the database have enough memory to contain the LRN and DNC datasets fully in memory? The extra latency for the non-cache hits sent to the database may stack up if the database has to hit disk.

DB says query response time is like 0.001s and doesn't show any sign
of strain. I'm not personally familiar with the TokuDB engine, but I'm
lead to believe the entire dataset is in memory. I have two DBA triple
checking things. It's possible we're hitting a max connections or open
files limit that's set too low. Sometimes our peak hours include
spikes as well.

> D) How many child processes are you using now? If you are hitting 100% you may need to increase them.

Only one hits 100% initially, then they topple over after that. This
seems to be related to the intermittent database connection errors.
We'll see what raising the max connections and ulimits on the server
does. I've also backed off on children and increased the async
connection pool size to result in the same number of total maximum
connections. Presumably this will reduce context switches and timer
delays.

> E) Are your memcached processes using heavy cpu? If you are caching multiple lists, I've found it helps to use unique memcached instance per list.

All of the various SIP dips are the same db stored procedure with many
fields in the response. Those fields are cached as a CSV string, so
any cached dip can be used by any other kind of dip. The same call is
likely to use multiple dips, so we should only hit the DB once per
call regardless of how many different dips we apply.

> F) Look for memory related log messages. If the memory starts getting exhausted you will see defrag messages. This will chew up available computation cycles.

Both opensips servers and the database have plenty of free memory. How
do I know how much shared and process memory to use? I see warnings
about the reactor size shrinking to a percentage of the process memory
but have no idea what that implies.


From david.villasmil.work at gmail.com  Fri Jun  5 00:17:18 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Fri, 5 Jun 2020 01:17:18 +0100
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
Message-ID: <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>

Maybe you are hitting the max connections? How many connections are there
when it starts to show those errors?

On Fri, 5 Jun 2020 at 01:06, Calvin Ellison <calvin.ellison at voxox.com>
wrote:

> > A) Is the LRN database located locally on the OpenSIPs box or is it
> remote?
>
> We are using an F5 BIG-IP to proxy a pool of database servers.
> Opensips is showing two connection-related errors:
>
> Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
> ERROR:db_mysql:db_mysql_connect: driver error(2013): Lost connection
> to MySQL server at 'reading authorization packet', system error: 110
> Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
> ERROR:db_mysql:db_mysql_new_connection: initial connect failed
> Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
> ERROR:core:db_init_async: failed to open new DB connection on
> mysql://XXXX:XXXX at 10.0.5.38:0/
> Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
> INFO:db_mysql:db_mysql_async_raw_query: Failed to open new connection
> (current: 1 + 8). Running in sync mode!
> Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
> INFO:db_mysql:switch_state_to_disconnected: disconnect event for
> 0x7f8903f16d10
> Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
> INFO:db_mysql:reset_all_statements: resetting all statements on
> connection: (0x7f8903f16bb0) 0x7f8903f16d10
> Jun  4 10:41:48 TC-521 /usr/sbin/opensips[12318]:
> INFO:db_mysql:connect_with_retry: re-connected successful for
> 0x7f8903f16d10
>
> Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
> ERROR:db_mysql:db_mysql_connect: driver error(2003): Can't connect to
> MySQL server on '10.0.5.38' (110)
> Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
> ERROR:db_mysql:db_mysql_new_connection: initial connect failed
> Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
> ERROR:core:db_init_async: failed to open new DB connection on
> mysql://XXXX:XXXX at 10.0.5.38:0/
> Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
> INFO:db_mysql:db_mysql_async_raw_query: Failed to open new connection
> (current: 1 + 10). Running in sync mode!
> Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
> INFO:db_mysql:switch_state_to_disconnected: disconnect event for
> 0x7f8903f16d10
> Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
> INFO:db_mysql:reset_all_statements: resetting all statements on
> connection: (0x7f8903f16bb0) 0x7f8903f16d10
> Jun  4 10:44:29 TC-521 /usr/sbin/opensips[12342]:
> INFO:db_mysql:connect_with_retry: re-connected successful for
> 0x7f8903f16d10
>
> MariaDB is also showing an error from its perspective:
>
> 2020-06-04 23:40:27 64783 [Warning] Aborted connection 64783 to db:
> 'unconnected' user: 'anonymous' host: '8.38.42.13' (Got timeout
> reading communication packets)
>
> > B) Have you tried only doing sync database queries? Async introduces
> some overhead, and I'm not sure if it causes extra database connections to
> be created. When using sync there is a connection per child process that
> stays up.
>
> Using synchronous mode appeared to be causing context switching issues
> under heavy load. We specifically moved to async for this reason and
> that appeared to reduce the CPU load dramatically. From the docs:
>
> "Using the asynchronous, "suspend-resume" logic instead of forking a
> large number of processes in order to scale also has the advantage of
> optimizing system resource usage, increasing its maximal throughput.
> By requiring less processes to complete the same amount of work in the
> same amount of time, process context switching is minimized and
> overall CPU usage is improved. Less processes will also eat up less
> system memory."
>
> I've been tweaking each of the configuration settings I've mentioned,
> but without any clear path forward. Would 3.x provide any solutions?
>
> Is it possible to have too many children or timer partitions, and
> starve opensips with context switches? Would that cause connection
> issues?
>
> > C) Does the database have enough memory to contain the LRN and DNC
> datasets fully in memory? The extra latency for the non-cache hits sent to
> the database may stack up if the database has to hit disk.
>
> DB says query response time is like 0.001s and doesn't show any sign
> of strain. I'm not personally familiar with the TokuDB engine, but I'm
> lead to believe the entire dataset is in memory. I have two DBA triple
> checking things. It's possible we're hitting a max connections or open
> files limit that's set too low. Sometimes our peak hours include
> spikes as well.
>
> > D) How many child processes are you using now? If you are hitting 100%
> you may need to increase them.
>
> Only one hits 100% initially, then they topple over after that. This
> seems to be related to the intermittent database connection errors.
> We'll see what raising the max connections and ulimits on the server
> does. I've also backed off on children and increased the async
> connection pool size to result in the same number of total maximum
> connections. Presumably this will reduce context switches and timer
> delays.
>
> > E) Are your memcached processes using heavy cpu? If you are caching
> multiple lists, I've found it helps to use unique memcached instance per
> list.
>
> All of the various SIP dips are the same db stored procedure with many
> fields in the response. Those fields are cached as a CSV string, so
> any cached dip can be used by any other kind of dip. The same call is
> likely to use multiple dips, so we should only hit the DB once per
> call regardless of how many different dips we apply.
>
> > F) Look for memory related log messages. If the memory starts getting
> exhausted you will see defrag messages. This will chew up available
> computation cycles.
>
> Both opensips servers and the database have plenty of free memory. How
> do I know how much shared and process memory to use? I see warnings
> about the reactor size shrinking to a percentage of the process memory
> but have no idea what that implies.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/fb1f5577/attachment-0001.html>

From calvin.ellison at voxox.com  Fri Jun  5 00:37:33 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Thu, 4 Jun 2020 17:37:33 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
Message-ID: <CAL+QDG9sxAq7+Au9ssoJDyZ=i9WaeRjZskyc_rUqmK5ed+oRYQ@mail.gmail.com>

On Thu, Jun 4, 2020 at 5:18 PM David Villasmil
<david.villasmil.work at gmail.com> wrote:
>
> Maybe you are hitting the max connections? How many connections are there when it starts to show those errors?

I'd definitely benefit from a monitor on this. Is this available from
within opensips?


From williamj at exetel.com.au  Fri Jun  5 06:04:37 2020
From: williamj at exetel.com.au (William Jin)
Date: Fri, 5 Jun 2020 06:04:37 +0000
Subject: [OpenSIPS-Users] Question about IP Transit
In-Reply-To: <SG2PR06MB2409E46CB9CB2C9618351D8F9B890@SG2PR06MB2409.apcprd06.prod.outlook.com>
References: <SG2PR06MB2409F18924BA3B0C2BCC04E49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>,
 <SG2PR06MB2409884F3EA53CAA7154FBF49B8B0@SG2PR06MB2409.apcprd06.prod.outlook.com>,
 <SG2PR06MB2409E46CB9CB2C9618351D8F9B890@SG2PR06MB2409.apcprd06.prod.outlook.com>
Message-ID: <SG2PR06MB24091F61F49003B19EBAF2F19B860@SG2PR06MB2409.apcprd06.prod.outlook.com>

OK, I think I figured it out myself.

Have to use force_send_socket(udp:ipv4 address);

--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au>
Sent: Thursday, 4 June 2020 1:35 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Question about IP Transit

Hi,

Does anyone have any idea?

I can send the sip trace if needed.

--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au>
Sent: Tuesday, 2 June 2020 2:48 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Question about IP Transit

Just additional info:
A(v4) => opensips(v4/v6) => B(v6) => C(v6)   - also working
Does that mean if the B number is V6, I need to send the invite to the v6 IP of the opensips? Then the server should handle the ip transit from v6 to v4 again?



--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au>
Sent: Tuesday, 2 June 2020 2:07 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] Question about IP Transit

Hi

We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian
opensips -V
version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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.
main.c compiled on  with gcc 6.3.0

The situation is:
Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6
A(v4) <=> opensips(v4<=>v6) <=> B(v6)

We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue.

A(v4) => opensips(v4/v6) => B(v6)          -     working
A(v4) => opensips(v4/v6) => B(v6) => C(v4)   - not working
A(v4) => opensips(v4/v6) => B(v4) => C(v4)   - working

Could you please shed some light on it?

--
Regards,
William Jin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/2f8b3345/attachment.html>

From spanda at 3clogic.com  Fri Jun  5 06:15:12 2020
From: spanda at 3clogic.com (Sasmita Panda)
Date: Fri, 5 Jun 2020 11:45:12 +0530
Subject: [OpenSIPS-Users] Need help using cachedb_local .
In-Reply-To: <CAND0LkvTzVs4jV0Zi2uLzuziUFUj+CSemC=eUBv+c2b8pFm1SQ@mail.gmail.com>
References: <CALf-Q46H4DM3517M=5dhbWSG0Qg=9tY9ay7yOK3ZpvfgTY+1iw@mail.gmail.com>
 <CAND0LkvTzVs4jV0Zi2uLzuziUFUj+CSemC=eUBv+c2b8pFm1SQ@mail.gmail.com>
Message-ID: <CALf-Q448KT8g97R7D7h6pV9L2ruWsZANZ2EBSzL29K3H3uXAdQ@mail.gmail.com>

For the also it gives same error .

opensips: ERROR:core:set_mod_param_regex: parameter <cache_collections> not
found in module <cachedb_local>

*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


On Fri, Jun 5, 2020 at 1:12 AM Ovidiu Sas <osas at voipembedded.com> wrote:

> Have you defined the 'collection1' as part of the cache_collections param?
> Something like:
> modparam("cachedb_local", "cache_collections", "collection1")
>
> Regards,
> Ovidiu Sas
>
> On Thu, Jun 4, 2020 at 8:30 AM Sasmita Panda <spanda at 3clogic.com> wrote:
> >
> > Hi,
> >
> > modparam("cachedb_local", "cachedb_url", "local:///collection1")
> >
> >
> >  While setting the above parameter in the cachedb_local module I am
> getting below error .
> >
> > ERROR:core:set_mod_param_regex: parameter <cachedb_url> not found in
> module <cachedb_local>
> > Jun  4 12:24:15 ip-20-0-114-18 opensips: CRITICAL:core:yyerror: parse
> error in config file /usr/etc/opensips/opensips_memorycache_registrar.cfg,
> line 148, column 20-21: Parameter <cachedb_url> not found in module
> <cachedb_local> - can't set
> >
> > Its saying the cachedb_url parameter is not found in the module . But
> the mobile document says the parameter exists . Do suggest if I am doing
> anything wrong .
> >
> > Thanks & Regards
> > Sasmita Panda
> > Senior Network Testing and Software Engineer
> > 3CLogic , ph:07827611765
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/9b68c625/attachment-0001.html>

From liviu at opensips.org  Fri Jun  5 07:24:08 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 5 Jun 2020 10:24:08 +0300
Subject: [OpenSIPS-Users] Need help using cachedb_local .
In-Reply-To: <CALf-Q448KT8g97R7D7h6pV9L2ruWsZANZ2EBSzL29K3H3uXAdQ@mail.gmail.com>
References: <CALf-Q46H4DM3517M=5dhbWSG0Qg=9tY9ay7yOK3ZpvfgTY+1iw@mail.gmail.com>
 <CAND0LkvTzVs4jV0Zi2uLzuziUFUj+CSemC=eUBv+c2b8pFm1SQ@mail.gmail.com>
 <CALf-Q448KT8g97R7D7h6pV9L2ruWsZANZ2EBSzL29K3H3uXAdQ@mail.gmail.com>
Message-ID: <8e4a8944-66bc-e1b1-800e-bafb5360a433@opensips.org>

On 6/5/20 9:15 AM, Sasmita Panda wrote:
> For the also it gives same error .
>
> opensips: ERROR:core:set_mod_param_regex: parameter 
> <cache_collections> not found in module <cachedb_local>
> */
> /*

Hi Sasmita,

It looks like you are using OpenSIPS 2.2 or below.  Please upgrade to a 
more modern version and retry.

Regards,

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/c78bdf4b/attachment.html>

From farmorg at gmail.com  Fri Jun  5 08:44:50 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Fri, 5 Jun 2020 09:44:50 +0100
Subject: [OpenSIPS-Users] 3.1 drouting dependencies
Message-ID: <CAOvQDevOcgeAF5ki+AfOy77O-7y475EbabWPi+6FL=70609dCQ@mail.gmail.com>

Hi everyone

I'm seeing some odd issues with routing ACK's and looking through the logs
I  see this:

DBG:core:solve_module_dependencies: module drouting depends on module
qrouting, but it was not loaded!

Checking the docs for drouting() and migration docs I found mention of this
dependency.

Is this correct?

version: opensips 3.1.0-beta (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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: 93798a002
main.c compiled on 12:15:39 Jun  4 2020 with gcc 7

Many thanks!
Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/ec8b7eba/attachment.html>

From liviu at opensips.org  Fri Jun  5 08:47:23 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 5 Jun 2020 11:47:23 +0300
Subject: [OpenSIPS-Users] 3.1 drouting dependencies
In-Reply-To: <CAOvQDevOcgeAF5ki+AfOy77O-7y475EbabWPi+6FL=70609dCQ@mail.gmail.com>
References: <CAOvQDevOcgeAF5ki+AfOy77O-7y475EbabWPi+6FL=70609dCQ@mail.gmail.com>
Message-ID: <503c0559-9688-40b8-1656-d497f362d893@opensips.org>

On 6/5/20 11:44 AM, Mark Farmer wrote:
> I'm seeing some odd issues with routing ACK's and looking through the 
> logs I  see this:
>
> DBG:core:solve_module_dependencies: module drouting depends on module 
> qrouting, but it was not loaded!

Hey Mark,

Notice it's a DEBUG-level message, so it's harmless (it's just a 
best-effort module dependency).  However, you're not the first person 
noticing this, so that log may require some rephrasing ;)

Cheers,

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



From david.villasmil.work at gmail.com  Fri Jun  5 09:47:37 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Fri, 5 Jun 2020 10:47:37 +0100
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG9sxAq7+Au9ssoJDyZ=i9WaeRjZskyc_rUqmK5ed+oRYQ@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG9sxAq7+Au9ssoJDyZ=i9WaeRjZskyc_rUqmK5ed+oRYQ@mail.gmail.com>
Message-ID: <CAFGRPVqvFz0EZZwXb6BiLVAW5w00bu6qsvcGzh6xt-NF1jOeSw@mail.gmail.com>

No idea, but can always check with any of several utilities, I.e.: netstat

On Fri, 5 Jun 2020 at 01:37, Calvin Ellison <calvin.ellison at voxox.com>
wrote:

> On Thu, Jun 4, 2020 at 5:18 PM David Villasmil
> <david.villasmil.work at gmail.com> wrote:
> >
> > Maybe you are hitting the max connections? How many connections are
> there when it starts to show those errors?
>
> I'd definitely benefit from a monitor on this. Is this available from
> within opensips?
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/383b3650/attachment.html>

From farmorg at gmail.com  Fri Jun  5 11:29:31 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Fri, 5 Jun 2020 12:29:31 +0100
Subject: [OpenSIPS-Users] ACK Routing Issue
Message-ID: <CAOvQDetUkLLzeb7duvwW+ZWgeZQWSz4LT39hTJnindqoERyw9g@mail.gmail.com>

Hi everyone

I've upgraded an OpenSIPS box to 3.1 and am now seeing an issue with ACK's
trying to route to an incorrect IP - in this case our own advertised IP.

I think I'm right in saying that PRACK's & ACK's are treated equally and
should route in the same manner? However, PRACK's are routing correctly.

I have this:

if (has_totag()) {
                ---

                # handle hop-by-hop ACK (no routing required)
                #if ( is_method("ACK") && t_check_trans() ) {
                if (is_method("ACK")) {
                        t_relay();
                        exit;
                }
---

Thanks for any ideas!
Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/7127216c/attachment.html>

From diptesh.patel at ecosmob.com  Fri Jun  5 12:00:40 2020
From: diptesh.patel at ecosmob.com (Diptesh Patel)
Date: Fri, 5 Jun 2020 17:30:40 +0530
Subject: [OpenSIPS-Users] ACK Routing Issue
In-Reply-To: <CAOvQDetUkLLzeb7duvwW+ZWgeZQWSz4LT39hTJnindqoERyw9g@mail.gmail.com>
References: <CAOvQDetUkLLzeb7duvwW+ZWgeZQWSz4LT39hTJnindqoERyw9g@mail.gmail.com>
Message-ID: <CAD4_Da0xN2vpdBEpRg=kZpiuqKScVm=OirjRfWCvWQwxZwnVLQ@mail.gmail.com>

Hello Mark,

Are you using Topology Hiding or Loose Routing?

If you are using Topology Hiding then you need to match the topology using
*topology_hiding_match()* first.

It is great if you can share SIP packets.

Thanks & Regards
*Diptesh Patel*
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:*+919898962659*


On Fri, Jun 5, 2020 at 5:00 PM Mark Farmer <farmorg at gmail.com> wrote:

> Hi everyone
>
> I've upgraded an OpenSIPS box to 3.1 and am now seeing an issue with ACK's
> trying to route to an incorrect IP - in this case our own advertised IP.
>
> I think I'm right in saying that PRACK's & ACK's are treated equally and
> should route in the same manner? However, PRACK's are routing correctly.
>
> I have this:
>
> if (has_totag()) {
>                 ---
>
>                 # handle hop-by-hop ACK (no routing required)
>                 #if ( is_method("ACK") && t_check_trans() ) {
>                 if (is_method("ACK")) {
>                         t_relay();
>                         exit;
>                 }
> ---
>
> Thanks for any ideas!
> Mark.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/c93ac42d/attachment-0001.html>

From farmorg at gmail.com  Fri Jun  5 13:05:42 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Fri, 5 Jun 2020 14:05:42 +0100
Subject: [OpenSIPS-Users] ACK Routing Issue
In-Reply-To: <CAD4_Da0xN2vpdBEpRg=kZpiuqKScVm=OirjRfWCvWQwxZwnVLQ@mail.gmail.com>
References: <CAOvQDetUkLLzeb7duvwW+ZWgeZQWSz4LT39hTJnindqoERyw9g@mail.gmail.com>
 <CAD4_Da0xN2vpdBEpRg=kZpiuqKScVm=OirjRfWCvWQwxZwnVLQ@mail.gmail.com>
Message-ID: <CAOvQDesyBiPVqB-fFO7407VWN543MdZPMMS33hn4RF5dL_-MDg@mail.gmail.com>

Thanks Diptesh

I'm using topology hiding, so now I have this:

if (has_totag()) {
                xlog("CUSTOM_LOG: in-dialog $rm has message flags: $mf and
branch flags: $bf");

                #Set correct SIP User-Agent Header
                if (remove_hf("User-Agent")) {
                xlog("CUSTOM_LOG: Setting SIP User-Agent on In-Dialog
Request");
                insert_hf("User-Agent: OpenSIPS\r\n");
                }

                if (!topology_hiding_match() ) {
                        xlog("CUSTOM_LOG: cannot match request to a dialog
\n");
                        send_reply(404,"Not found");
                }

                # handle hop-by-hop ACK (no routing required)
                if ( is_method("ACK") && t_check_trans() ) {
                        xlog("CUSTOM_LOG: ACK detected with valid
transaction - t_relay");
                        t_relay();
                        exit;
                }

I don't see a 404 going out so I think topology_hiding_match is working.
But it tries to send the ACK to itself on it's private interface (I have
mhomed=1).

ACK sip:+44XXXXXXXXXX at 10.150.50.72;did=e07.595f3776 SIP/2.0
Via: SIP/2.0/UDP PUB.LIC.IP.ADDR:5060;branch=z9hG4bKc219.d1f5b08.2
From: <sip:+441204860410 at PUB.LIC.IP.ADDR;user=phone>;tag=gK0c801c8d
To: <sip:+44XXXXXXXXXX at 147.152.17.42>;tag=3800350621-1224267434
Call-ID: 543691539-3800350621-1514620980 at sbc-uk-bs13b.uk.sdin.bt.net
CSeq: 202841 ACK
Max-Forwards: 69
Content-Length: 0

Best regards
Mark.


On Fri, 5 Jun 2020 at 13:03, Diptesh Patel <diptesh.patel at ecosmob.com>
wrote:

> Hello Mark,
>
> Are you using Topology Hiding or Loose Routing?
>
> If you are using Topology Hiding then you need to match the topology using
> *topology_hiding_match()* first.
>
> It is great if you can share SIP packets.
>
> Thanks & Regards
> *Diptesh Patel*
> Software Developer
> Ecosmob Technologies Ltd,
> Ahmedabad
> Mo:*+919898962659*
>
>
> On Fri, Jun 5, 2020 at 5:00 PM Mark Farmer <farmorg at gmail.com> wrote:
>
>> Hi everyone
>>
>> I've upgraded an OpenSIPS box to 3.1 and am now seeing an issue with
>> ACK's trying to route to an incorrect IP - in this case our own advertised
>> IP.
>>
>> I think I'm right in saying that PRACK's & ACK's are treated equally and
>> should route in the same manner? However, PRACK's are routing correctly.
>>
>> I have this:
>>
>> if (has_totag()) {
>>                 ---
>>
>>                 # handle hop-by-hop ACK (no routing required)
>>                 #if ( is_method("ACK") && t_check_trans() ) {
>>                 if (is_method("ACK")) {
>>                         t_relay();
>>                         exit;
>>                 }
>> ---
>>
>> Thanks for any ideas!
>> Mark.
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> *Disclaimer*
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
> *Confidentiality*
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
> *Caution for viruses, malware etc.*
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/f6835a4c/attachment.html>

From johan at democon.be  Fri Jun  5 13:37:55 2020
From: johan at democon.be (Johan De Clercq)
Date: Fri, 5 Jun 2020 13:37:55 +0000
Subject: [OpenSIPS-Users] ACK Routing Issue
In-Reply-To: <CAOvQDesyBiPVqB-fFO7407VWN543MdZPMMS33hn4RF5dL_-MDg@mail.gmail.com>
References: <CAOvQDetUkLLzeb7duvwW+ZWgeZQWSz4LT39hTJnindqoERyw9g@mail.gmail.com>
 <CAD4_Da0xN2vpdBEpRg=kZpiuqKScVm=OirjRfWCvWQwxZwnVLQ@mail.gmail.com>,
 <CAOvQDesyBiPVqB-fFO7407VWN543MdZPMMS33hn4RF5dL_-MDg@mail.gmail.com>
Message-ID: <AM0PR06MB6226A573C17567DF6F1B5E79A7860@AM0PR06MB6226.eurprd06.prod.outlook.com>

Call record route on initial invite.

Outlook voor iOS<https://aka.ms/o0ukef> downloaden
________________________________
Van: Users <users-bounces at lists.opensips.org> namens Mark Farmer <farmorg at gmail.com>
Verzonden: Friday, June 5, 2020 3:05:42 PM
Aan: OpenSIPS users mailling list <users at lists.opensips.org>
Onderwerp: Re: [OpenSIPS-Users] ACK Routing Issue

Thanks Diptesh

I'm using topology hiding, so now I have this:

if (has_totag()) {
                xlog("CUSTOM_LOG: in-dialog $rm has message flags: $mf and branch flags: $bf");

                #Set correct SIP User-Agent Header
                if (remove_hf("User-Agent")) {
                xlog("CUSTOM_LOG: Setting SIP User-Agent on In-Dialog Request");
                insert_hf("User-Agent: OpenSIPS\r\n");
                }

                if (!topology_hiding_match() ) {
                        xlog("CUSTOM_LOG: cannot match request to a dialog \n");
                        send_reply(404,"Not found");
                }

                # handle hop-by-hop ACK (no routing required)
                if ( is_method("ACK") && t_check_trans() ) {
                        xlog("CUSTOM_LOG: ACK detected with valid transaction - t_relay");
                        t_relay();
                        exit;
                }

I don't see a 404 going out so I think topology_hiding_match is working.
But it tries to send the ACK to itself on it's private interface (I have mhomed=1).

ACK sip:+44XXXXXXXXXX at 10.150.50.72<mailto:sip%3A%2B44XXXXXXXXXX at 10.150.50.72>;did=e07.595f3776 SIP/2.0
Via: SIP/2.0/UDP PUB.LIC.IP.ADDR:5060;branch=z9hG4bKc219.d1f5b08.2
From: <sip:+441204860410 at PUB.LIC.IP.ADDR;user=phone>;tag=gK0c801c8d
To: <sip:+44XXXXXXXXXX at 147.152.17.42<mailto:sip%3A%2B44XXXXXXXXXX at 147.152.17.42>>;tag=3800350621-1224267434
Call-ID: 543691539-3800350621-1514620980 at sbc-uk-bs13b.uk.sdin.bt.net<mailto:543691539-3800350621-1514620980 at sbc-uk-bs13b.uk.sdin.bt.net>
CSeq: 202841 ACK
Max-Forwards: 69
Content-Length: 0

Best regards
Mark.


On Fri, 5 Jun 2020 at 13:03, Diptesh Patel <diptesh.patel at ecosmob.com<mailto:diptesh.patel at ecosmob.com>> wrote:
Hello Mark,

Are you using Topology Hiding or Loose Routing?

If you are using Topology Hiding then you need to match the topology using topology_hiding_match() first.

It is great if you can share SIP packets.

Thanks & Regards
Diptesh Patel
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:+919898962659


On Fri, Jun 5, 2020 at 5:00 PM Mark Farmer <farmorg at gmail.com<mailto:farmorg at gmail.com>> wrote:
Hi everyone

I've upgraded an OpenSIPS box to 3.1 and am now seeing an issue with ACK's trying to route to an incorrect IP - in this case our own advertised IP.

I think I'm right in saying that PRACK's & ACK's are treated equally and should route in the same manner? However, PRACK's are routing correctly.

I have this:

if (has_totag()) {
                ---

                # handle hop-by-hop ACK (no routing required)
                #if ( is_method("ACK") && t_check_trans() ) {
                if (is_method("ACK")) {
                        t_relay();
                        exit;
                }
---

Thanks for any ideas!
Mark.


_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Mark Farmer
farmorg at gmail.com<mailto:farmorg at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/cfb99353/attachment-0001.html>

From diptesh.patel at ecosmob.com  Fri Jun  5 13:44:53 2020
From: diptesh.patel at ecosmob.com (Diptesh Patel)
Date: Fri, 5 Jun 2020 19:14:53 +0530
Subject: [OpenSIPS-Users] ACK Routing Issue
In-Reply-To: <CAOvQDesyBiPVqB-fFO7407VWN543MdZPMMS33hn4RF5dL_-MDg@mail.gmail.com>
References: <CAOvQDetUkLLzeb7duvwW+ZWgeZQWSz4LT39hTJnindqoERyw9g@mail.gmail.com>
 <CAD4_Da0xN2vpdBEpRg=kZpiuqKScVm=OirjRfWCvWQwxZwnVLQ@mail.gmail.com>
 <CAOvQDesyBiPVqB-fFO7407VWN543MdZPMMS33hn4RF5dL_-MDg@mail.gmail.com>
Message-ID: <CAD4_Da0Yh-AJ3uzR1cKLBYFd_vB2fX4h5_uvbWc_re7ggVi=2w@mail.gmail.com>

Hello Mark,

You need to modify your script. Let me explain to you how topology
hiding works. If you're using topology hiding then we are hiding the
information from the other node right? So the topology hiding stores your
next hop information. When you call topology_hiding_match() then it will
replace the request uri with the next hop. So you need to use
topology_hiding_match() on every within dialog request(sequential
requests), otherwise it will create looping.

you can check the following snippet which i modified. It helps you !!

if (has_totag()) {
    xlog("CUSTOM_LOG: in-dialog $rm has message flags: $mf and branch
flags: $bf");
    #Set correct SIP User-Agent Header
    if (remove_hf("User-Agent")) {
        xlog("CUSTOM_LOG: Setting SIP User-Agent on In-Dialog Request");
        insert_hf("User-Agent: OpenSIPS\r\n");
    }
    # handle hop-by-hop ACK (no routing required)
    if ( is_method("ACK") && t_check_trans() ) {
        xlog("CUSTOM_LOG: ACK detected with valid transaction - t_relay");
        t_relay();
        exit;
    }
    if (topology_hiding_match()) {
      ##TH match and relay all the within dialog packets.
        t_relay();
        exit;
    } else {
        xlog("CUSTOM_LOG: cannot match request to a dialog \n");
        send_reply(404,"Not found");
        exit;
    }
}


Thanks & Regards
*Diptesh Patel*
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:*+919898962659*


On Fri, Jun 5, 2020 at 6:37 PM Mark Farmer <farmorg at gmail.com> wrote:

> Thanks Diptesh
>
> I'm using topology hiding, so now I have this:
>
> if (has_totag()) {
>                 xlog("CUSTOM_LOG: in-dialog $rm has message flags: $mf and
> branch flags: $bf");
>
>                 #Set correct SIP User-Agent Header
>                 if (remove_hf("User-Agent")) {
>                 xlog("CUSTOM_LOG: Setting SIP User-Agent on In-Dialog
> Request");
>                 insert_hf("User-Agent: OpenSIPS\r\n");
>                 }
>
>                 if (!topology_hiding_match() ) {
>                         xlog("CUSTOM_LOG: cannot match request to a dialog
> \n");
>                         send_reply(404,"Not found");
>                 }
>
>                 # handle hop-by-hop ACK (no routing required)
>                 if ( is_method("ACK") && t_check_trans() ) {
>                         xlog("CUSTOM_LOG: ACK detected with valid
> transaction - t_relay");
>                         t_relay();
>                         exit;
>                 }
>
> I don't see a 404 going out so I think topology_hiding_match is working.
> But it tries to send the ACK to itself on it's private interface (I have
> mhomed=1).
>
> ACK sip:+44XXXXXXXXXX at 10.150.50.72;did=e07.595f3776 SIP/2.0
> Via: SIP/2.0/UDP PUB.LIC.IP.ADDR:5060;branch=z9hG4bKc219.d1f5b08.2
> From: <sip:+441204860410 at PUB.LIC.IP.ADDR;user=phone>;tag=gK0c801c8d
> To: <sip:+44XXXXXXXXXX at 147.152.17.42>;tag=3800350621-1224267434
> Call-ID: 543691539-3800350621-1514620980 at sbc-uk-bs13b.uk.sdin.bt.net
> CSeq: 202841 ACK
> Max-Forwards: 69
> Content-Length: 0
>
> Best regards
> Mark.
>
>
> On Fri, 5 Jun 2020 at 13:03, Diptesh Patel <diptesh.patel at ecosmob.com>
> wrote:
>
>> Hello Mark,
>>
>> Are you using Topology Hiding or Loose Routing?
>>
>> If you are using Topology Hiding then you need to match the topology
>> using *topology_hiding_match()* first.
>>
>> It is great if you can share SIP packets.
>>
>> Thanks & Regards
>> *Diptesh Patel*
>> Software Developer
>> Ecosmob Technologies Ltd,
>> Ahmedabad
>> Mo:*+919898962659*
>>
>>
>> On Fri, Jun 5, 2020 at 5:00 PM Mark Farmer <farmorg at gmail.com> wrote:
>>
>>> Hi everyone
>>>
>>> I've upgraded an OpenSIPS box to 3.1 and am now seeing an issue with
>>> ACK's trying to route to an incorrect IP - in this case our own advertised
>>> IP.
>>>
>>> I think I'm right in saying that PRACK's & ACK's are treated equally and
>>> should route in the same manner? However, PRACK's are routing correctly.
>>>
>>> I have this:
>>>
>>> if (has_totag()) {
>>>                 ---
>>>
>>>                 # handle hop-by-hop ACK (no routing required)
>>>                 #if ( is_method("ACK") && t_check_trans() ) {
>>>                 if (is_method("ACK")) {
>>>                         t_relay();
>>>                         exit;
>>>                 }
>>> ---
>>>
>>> Thanks for any ideas!
>>> Mark.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> *Disclaimer*
>> In addition to generic Disclaimer which you have agreed on our website,
>> any views or opinions presented in this email are solely those of the
>> originator and do not necessarily represent those of the Company or its
>> sister concerns. Any liability (in negligence, contract or otherwise)
>> arising from any third party taking any action, or refraining from taking
>> any action on the basis of any of the information contained in this email
>> is hereby excluded.
>>
>> *Confidentiality*
>> This communication (including any attachment/s) is intended only for the
>> use of the addressee(s) and contains information that is PRIVILEGED AND
>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
>> of this communication is prohibited. Please inform originator if you have
>> received it in error.
>>
>> *Caution for viruses, malware etc.*
>> This communication, including any attachments, may not be free of
>> viruses, trojans, similar or new contaminants/malware, interceptions or
>> interference, and may not be compatible with your systems. You shall carry
>> out virus/malware scanning on your own before opening any attachment to
>> this e-mail. The sender of this e-mail and Company including its sister
>> concerns shall not be liable for any damage that may incur to you as a
>> result of viruses, incompleteness of this message, a delay in receipt of
>> this message or any other computer problems.
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> Mark Farmer
> farmorg at gmail.com
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/df413124/attachment.html>

From farmorg at gmail.com  Fri Jun  5 15:18:16 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Fri, 5 Jun 2020 16:18:16 +0100
Subject: [OpenSIPS-Users] ACK Routing Issue
In-Reply-To: <CAD4_Da0Yh-AJ3uzR1cKLBYFd_vB2fX4h5_uvbWc_re7ggVi=2w@mail.gmail.com>
References: <CAOvQDetUkLLzeb7duvwW+ZWgeZQWSz4LT39hTJnindqoERyw9g@mail.gmail.com>
 <CAD4_Da0xN2vpdBEpRg=kZpiuqKScVm=OirjRfWCvWQwxZwnVLQ@mail.gmail.com>
 <CAOvQDesyBiPVqB-fFO7407VWN543MdZPMMS33hn4RF5dL_-MDg@mail.gmail.com>
 <CAD4_Da0Yh-AJ3uzR1cKLBYFd_vB2fX4h5_uvbWc_re7ggVi=2w@mail.gmail.com>
Message-ID: <CAOvQDevTGjJbgymSE-1n1gxpEXBh221hFDtjmYWbiYb5iDPcgw@mail.gmail.com>

Thanks Diptesh, that seems to have fixed it! :)

Many thanks!
Mark.


On Fri, 5 Jun 2020 at 14:47, Diptesh Patel <diptesh.patel at ecosmob.com>
wrote:

> Hello Mark,
>
> You need to modify your script. Let me explain to you how topology
> hiding works. If you're using topology hiding then we are hiding the
> information from the other node right? So the topology hiding stores your
> next hop information. When you call topology_hiding_match() then it will
> replace the request uri with the next hop. So you need to use
> topology_hiding_match() on every within dialog request(sequential
> requests), otherwise it will create looping.
>
> you can check the following snippet which i modified. It helps you !!
>
> if (has_totag()) {
>     xlog("CUSTOM_LOG: in-dialog $rm has message flags: $mf and branch
> flags: $bf");
>     #Set correct SIP User-Agent Header
>     if (remove_hf("User-Agent")) {
>         xlog("CUSTOM_LOG: Setting SIP User-Agent on In-Dialog Request");
>         insert_hf("User-Agent: OpenSIPS\r\n");
>     }
>     # handle hop-by-hop ACK (no routing required)
>     if ( is_method("ACK") && t_check_trans() ) {
>         xlog("CUSTOM_LOG: ACK detected with valid transaction - t_relay");
>         t_relay();
>         exit;
>     }
>     if (topology_hiding_match()) {
>       ##TH match and relay all the within dialog packets.
>         t_relay();
>         exit;
>     } else {
>         xlog("CUSTOM_LOG: cannot match request to a dialog \n");
>         send_reply(404,"Not found");
>         exit;
>     }
> }
>
>
> Thanks & Regards
> *Diptesh Patel*
> Software Developer
> Ecosmob Technologies Ltd,
> Ahmedabad
> Mo:*+919898962659*
>
>
> On Fri, Jun 5, 2020 at 6:37 PM Mark Farmer <farmorg at gmail.com> wrote:
>
>> Thanks Diptesh
>>
>> I'm using topology hiding, so now I have this:
>>
>> if (has_totag()) {
>>                 xlog("CUSTOM_LOG: in-dialog $rm has message flags: $mf
>> and branch flags: $bf");
>>
>>                 #Set correct SIP User-Agent Header
>>                 if (remove_hf("User-Agent")) {
>>                 xlog("CUSTOM_LOG: Setting SIP User-Agent on In-Dialog
>> Request");
>>                 insert_hf("User-Agent: OpenSIPS\r\n");
>>                 }
>>
>>                 if (!topology_hiding_match() ) {
>>                         xlog("CUSTOM_LOG: cannot match request to a
>> dialog \n");
>>                         send_reply(404,"Not found");
>>                 }
>>
>>                 # handle hop-by-hop ACK (no routing required)
>>                 if ( is_method("ACK") && t_check_trans() ) {
>>                         xlog("CUSTOM_LOG: ACK detected with valid
>> transaction - t_relay");
>>                         t_relay();
>>                         exit;
>>                 }
>>
>> I don't see a 404 going out so I think topology_hiding_match is working.
>> But it tries to send the ACK to itself on it's private interface (I have
>> mhomed=1).
>>
>> ACK sip:+44XXXXXXXXXX at 10.150.50.72;did=e07.595f3776 SIP/2.0
>> Via: SIP/2.0/UDP PUB.LIC.IP.ADDR:5060;branch=z9hG4bKc219.d1f5b08.2
>> From: <sip:+441204860410 at PUB.LIC.IP.ADDR;user=phone>;tag=gK0c801c8d
>> To: <sip:+44XXXXXXXXXX at 147.152.17.42>;tag=3800350621-1224267434
>> Call-ID: 543691539-3800350621-1514620980 at sbc-uk-bs13b.uk.sdin.bt.net
>> CSeq: 202841 ACK
>> Max-Forwards: 69
>> Content-Length: 0
>>
>> Best regards
>> Mark.
>>
>>
>> On Fri, 5 Jun 2020 at 13:03, Diptesh Patel <diptesh.patel at ecosmob.com>
>> wrote:
>>
>>> Hello Mark,
>>>
>>> Are you using Topology Hiding or Loose Routing?
>>>
>>> If you are using Topology Hiding then you need to match the topology
>>> using *topology_hiding_match()* first.
>>>
>>> It is great if you can share SIP packets.
>>>
>>> Thanks & Regards
>>> *Diptesh Patel*
>>> Software Developer
>>> Ecosmob Technologies Ltd,
>>> Ahmedabad
>>> Mo:*+919898962659*
>>>
>>>
>>> On Fri, Jun 5, 2020 at 5:00 PM Mark Farmer <farmorg at gmail.com> wrote:
>>>
>>>> Hi everyone
>>>>
>>>> I've upgraded an OpenSIPS box to 3.1 and am now seeing an issue with
>>>> ACK's trying to route to an incorrect IP - in this case our own advertised
>>>> IP.
>>>>
>>>> I think I'm right in saying that PRACK's & ACK's are treated equally
>>>> and should route in the same manner? However, PRACK's are routing correctly.
>>>>
>>>> I have this:
>>>>
>>>> if (has_totag()) {
>>>>                 ---
>>>>
>>>>                 # handle hop-by-hop ACK (no routing required)
>>>>                 #if ( is_method("ACK") && t_check_trans() ) {
>>>>                 if (is_method("ACK")) {
>>>>                         t_relay();
>>>>                         exit;
>>>>                 }
>>>> ---
>>>>
>>>> Thanks for any ideas!
>>>> Mark.
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>> *Disclaimer*
>>> In addition to generic Disclaimer which you have agreed on our website,
>>> any views or opinions presented in this email are solely those of the
>>> originator and do not necessarily represent those of the Company or its
>>> sister concerns. Any liability (in negligence, contract or otherwise)
>>> arising from any third party taking any action, or refraining from taking
>>> any action on the basis of any of the information contained in this email
>>> is hereby excluded.
>>>
>>> *Confidentiality*
>>> This communication (including any attachment/s) is intended only for the
>>> use of the addressee(s) and contains information that is PRIVILEGED AND
>>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
>>> of this communication is prohibited. Please inform originator if you have
>>> received it in error.
>>>
>>> *Caution for viruses, malware etc.*
>>> This communication, including any attachments, may not be free of
>>> viruses, trojans, similar or new contaminants/malware, interceptions or
>>> interference, and may not be compatible with your systems. You shall carry
>>> out virus/malware scanning on your own before opening any attachment to
>>> this e-mail. The sender of this e-mail and Company including its sister
>>> concerns shall not be liable for any damage that may incur to you as a
>>> result of viruses, incompleteness of this message, a delay in receipt of
>>> this message or any other computer problems.
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>> Mark Farmer
>> farmorg at gmail.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> *Disclaimer*
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
> *Confidentiality*
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
> *Caution for viruses, malware etc.*
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/9db8422a/attachment-0001.html>

From sobomax at sippysoft.com  Sat Jun  6 06:02:18 2020
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Fri, 5 Jun 2020 23:02:18 -0700
Subject: [OpenSIPS-Users] [Announcement] SIP Chronicles #4,
	featuring Mark J. Crane @ FusionPBX
Message-ID: <CAH7qZftMq5AY7JJMntkEi3923w64MhEmm-iYbpfHPYgULx7nJw@mail.gmail.com>

SIP Folks,

First of all thanks everyone who participated in or just watched our first
3 episodes of SIP Chronicles! I think it's safe to say that both myself and
my partner in crime Giovanni have been pleasantly surprised by the
turn-around numbers and general interest our little initiative has
generated!

We have had time to refine and think over our concept and if you ask me
now, SIP Chronicles is not about a particular product, or technology - it's
first and foremost about stories of amazing, passionate people doing
exciting things with SIP technology!

In that spirit, this Saturday we'll bring another story: the story of Mark
J. Crane and his FusionPBX project.  Even if you have never heard about
FusionPBX or FreeSWITCH (which is unlikely) that might be a great
opportunity to learn and hear Mark's story. Or if you are using either one
already - ask Mark a question!

Please join us this Saturday @ 4:30pm UTC: https://youtu.be/CJB7RjiIJ4s

 Thanks and see you soon! :)

-Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200605/a2fe140c/attachment.html>

From solarmon at one-n.co.uk  Mon Jun  8 08:52:29 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Mon, 8 Jun 2020 09:52:29 +0100
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
Message-ID: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>

Hi,

I'm trying to understand whether this is the correct or expected behaviour.

We have two destinations configured in Dispatcher.

What I am noticing is that when we receive 502 Bad Gateway messages (logged
as ("call failed to established with 502 code") from both endpoints. After
both endpoints have returned 502 Bad Gateway, opensips pass back 503
Service Unavailable back to the originating endpoint of the call. However,
subsequent calls are being immediately rejected with 480 Temporarily
Unavailable (logged as "failed to find an available destination,
rejecting") for a period of time.

It seems that opensips is blacklisting the Dispatcher endpoints because of
receiving the 502 Bad Gateway messages. Is this the correct/expected
behaviour? I would have thought the blacklisting should be based on the SIP
OPTIONS sent to the Dispatcher endpoints.

I do not currently see any issues with SIP OPTIONS to these endpoints so
I'm confused as to why they are seemingly blacklisted.

If this is the correct/expected behaviour, can it be changed to only
blacklist based on the SIP OPTIONs pings?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200608/850084d4/attachment.html>

From diptesh.patel at ecosmob.com  Mon Jun  8 09:44:00 2020
From: diptesh.patel at ecosmob.com (Diptesh Patel)
Date: Mon, 8 Jun 2020 15:14:00 +0530
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
Message-ID: <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>

Hello Solarmon,

Need some clarification on term blacklisting, Are you using the blacklist
for Probing Mode of destination? or Are you using the *'ds_define_blacklist
(str)' *parameter. If you are not using the blacklist parameter then below
information help you. It is great if you share your script snippet and
output of *'opensipsctl dispatcher dump'* which shows you the current
status of your destinations.

If you are getting success(200 OK) response on OPTIONS then it is not
possible that you got a negative response from a destination and it will
not be blacklisted(probing mode) in dispatcher until you blacklist(probing
mode) from the script using 'ds_mark_dst()' exported function. I doubt that
you are also getting '502 Bad Gateway' on OPTIONS which is sending to the
destination to check the availability.  If It is right and you want to add
the 502 response as a good response for OPTIONS. you can add the 502
as *'modparam("dispatcher",
"options_reply_codes", "502")'.*

Thanks & Regards
*Diptesh Patel*
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:*+919898962659*


On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk> wrote:

> Hi,
>
> I'm trying to understand whether this is the correct or expected behaviour.
>
> We have two destinations configured in Dispatcher.
>
> What I am noticing is that when we receive 502 Bad Gateway messages
> (logged as ("call failed to established with 502 code") from both
> endpoints. After both endpoints have returned 502 Bad Gateway, opensips
> pass back 503 Service Unavailable back to the originating endpoint of the
> call. However, subsequent calls are being immediately rejected with 480
> Temporarily Unavailable (logged as "failed to find an available
> destination, rejecting") for a period of time.
>
> It seems that opensips is blacklisting the Dispatcher endpoints because of
> receiving the 502 Bad Gateway messages. Is this the correct/expected
> behaviour? I would have thought the blacklisting should be based on the SIP
> OPTIONS sent to the Dispatcher endpoints.
>
> I do not currently see any issues with SIP OPTIONS to these endpoints so
> I'm confused as to why they are seemingly blacklisted.
>
> If this is the correct/expected behaviour, can it be changed to only
> blacklist based on the SIP OPTIONs pings?
>
> Thank you.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200608/db2e6c95/attachment.html>

From solarmon at one-n.co.uk  Mon Jun  8 10:55:06 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Mon, 8 Jun 2020 11:55:06 +0100
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
 <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
Message-ID: <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>

Hi Diptesh ,

Thanks for your reply.

Apologies, I'm using the term 'blacklist' to generally mean that the
endpoints are not available.

Also, the 502 Bad Gateway is response to an INVITE, not SIP OPTIONS,
returned by the far end and the ITSP is just passing that back to us,
because the call has failed. For such call failures, I'm not expecting for
the dispatcher endpoints to be marked as unavailable for routing.

I am not using, or have not set, the '*ds_define_blacklist (str)*' option
in my dispatcher module config.

My probing mode is:

modparam("dispatcher", "ds_probing_mode", 1)

I'm not seeing anything in the logs regarding the dispatcher nodes going
into Probing mode - should there be logs for that, or can it be enabled to
be logged?

When I check the endpoints with ' opensipsctl dispatcher dump' they always
seem to be '*Active*' - so it is either they are like that, or they
may have only been in '*Probing*' mode very briefly. Again, I was hoping to
see mode/state change in the historical logs.

In my *opensips.cfg* (which was created for me) I can see the following
code, which looks like this is where it is introducing this behaviour in
question:

failure_route[call_failover]
{
        xlog("[$ci] call failed to established with $T_reply_code code\n");

        rtpproxy_unforce("$avp(rtpp_set)");

        if (t_was_cancelled()) {
                t_reply("487","Request cancelled");
                exit;
        }

        # any failure indication ?
        if ( t_check_status("[56][0-9][0-9]")
        || (t_check_status("408") && t_local_replied("all"))
        ) {
                xlog("[$ci] destination $rd failed  with $T_reply_code ->
retry\n ");

               * ds_mark_dst("p");*

                if ( ds_next_domain() ) {
                        xlog("[$ci] using new destination <$rd>\n ");

                        # send it out again
                        t_on_failure("call_failover");
                        t_relay();
                        exit;
                } else {
                        xlog("[$ci] no other destination to retry\n ");
                        t_reply("503","Service not available");
                        exit;
                }
        }

        # if call failure, allow the reply to propagate to caller
        exit;
}



Thank you for the tip about the  'modparam("dispatcher",
"options_reply_codes", "502")' option. I will try that if it is not
recommend to change the above code.

Thank you.


On Mon, 8 Jun 2020 at 10:47, Diptesh Patel <diptesh.patel at ecosmob.com>
wrote:

> Hello Solarmon,
>
> Need some clarification on term blacklisting, Are you using the blacklist
> for Probing Mode of destination? or Are you using the *'ds_define_blacklist
> (str)' *parameter. If you are not using the blacklist parameter then
> below information help you. It is great if you share your script snippet
> and output of *'opensipsctl dispatcher dump'* which shows you the current
> status of your destinations.
>
> If you are getting success(200 OK) response on OPTIONS then it is not
> possible that you got a negative response from a destination and it will
> not be blacklisted(probing mode) in dispatcher until you blacklist(probing
> mode) from the script using 'ds_mark_dst()' exported function. I doubt that
> you are also getting '502 Bad Gateway' on OPTIONS which is sending to the
> destination to check the availability.  If It is right and you want to add
> the 502 response as a good response for OPTIONS. you can add the 502 as *'modparam("dispatcher",
> "options_reply_codes", "502")'.*
>
> Thanks & Regards
> *Diptesh Patel*
> Software Developer
> Ecosmob Technologies Ltd,
> Ahmedabad
> Mo:*+919898962659*
>
>
> On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk> wrote:
>
>> Hi,
>>
>> I'm trying to understand whether this is the correct or expected
>> behaviour.
>>
>> We have two destinations configured in Dispatcher.
>>
>> What I am noticing is that when we receive 502 Bad Gateway messages
>> (logged as ("call failed to established with 502 code") from both
>> endpoints. After both endpoints have returned 502 Bad Gateway, opensips
>> pass back 503 Service Unavailable back to the originating endpoint of the
>> call. However, subsequent calls are being immediately rejected with 480
>> Temporarily Unavailable (logged as "failed to find an available
>> destination, rejecting") for a period of time.
>>
>> It seems that opensips is blacklisting the Dispatcher endpoints because
>> of receiving the 502 Bad Gateway messages. Is this the correct/expected
>> behaviour? I would have thought the blacklisting should be based on the SIP
>> OPTIONS sent to the Dispatcher endpoints.
>>
>> I do not currently see any issues with SIP OPTIONS to these endpoints so
>> I'm confused as to why they are seemingly blacklisted.
>>
>> If this is the correct/expected behaviour, can it be changed to only
>> blacklist based on the SIP OPTIONs pings?
>>
>> Thank you.
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> *Disclaimer*
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
> *Confidentiality*
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
> *Caution for viruses, malware etc.*
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200608/089b63a3/attachment-0001.html>

From diptesh.patel at ecosmob.com  Mon Jun  8 12:41:00 2020
From: diptesh.patel at ecosmob.com (Diptesh Patel)
Date: Mon, 8 Jun 2020 18:11:00 +0530
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
 <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
 <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
Message-ID: <CAD4_Da13uJdnLaw9U12p=GP8s39XeBdgjeRW6rXZC_xaBtThHg@mail.gmail.com>

Hello Solarmon,

I think, The * ds_mark_dst("p");* put your destinations on Probing and
after a few seconds you will get the reply for OPTIONS and now your
destinations are Active. Are you making a second call immediately? If yes
then it is clear. Please remove the ds_mark_dst("p"), OpenSIPS
automatically change the destination's state using OPTIONS.

Thanks & Regards
*Diptesh Patel*
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:*+919898962659*


On Mon, Jun 8, 2020 at 4:27 PM solarmon <solarmon at one-n.co.uk> wrote:

> Hi Diptesh ,
>
> Thanks for your reply.
>
> Apologies, I'm using the term 'blacklist' to generally mean that the
> endpoints are not available.
>
> Also, the 502 Bad Gateway is response to an INVITE, not SIP OPTIONS,
> returned by the far end and the ITSP is just passing that back to us,
> because the call has failed. For such call failures, I'm not expecting for
> the dispatcher endpoints to be marked as unavailable for routing.
>
> I am not using, or have not set, the '*ds_define_blacklist (str)*' option
> in my dispatcher module config.
>
> My probing mode is:
>
> modparam("dispatcher", "ds_probing_mode", 1)
>
> I'm not seeing anything in the logs regarding the dispatcher nodes going
> into Probing mode - should there be logs for that, or can it be enabled to
> be logged?
>
> When I check the endpoints with ' opensipsctl dispatcher dump' they always
> seem to be '*Active*' - so it is either they are like that, or they
> may have only been in '*Probing*' mode very briefly. Again, I was hoping
> to see mode/state change in the historical logs.
>
> In my *opensips.cfg* (which was created for me) I can see the following
> code, which looks like this is where it is introducing this behaviour in
> question:
>
> failure_route[call_failover]
> {
>         xlog("[$ci] call failed to established with $T_reply_code code\n");
>
>         rtpproxy_unforce("$avp(rtpp_set)");
>
>         if (t_was_cancelled()) {
>                 t_reply("487","Request cancelled");
>                 exit;
>         }
>
>         # any failure indication ?
>         if ( t_check_status("[56][0-9][0-9]")
>         || (t_check_status("408") && t_local_replied("all"))
>         ) {
>                 xlog("[$ci] destination $rd failed  with $T_reply_code ->
> retry\n ");
>
>                * ds_mark_dst("p");*
>
>                 if ( ds_next_domain() ) {
>                         xlog("[$ci] using new destination <$rd>\n ");
>
>                         # send it out again
>                         t_on_failure("call_failover");
>                         t_relay();
>                         exit;
>                 } else {
>                         xlog("[$ci] no other destination to retry\n ");
>                         t_reply("503","Service not available");
>                         exit;
>                 }
>         }
>
>         # if call failure, allow the reply to propagate to caller
>         exit;
> }
>
>
>
> Thank you for the tip about the  'modparam("dispatcher",
> "options_reply_codes", "502")' option. I will try that if it is not
> recommend to change the above code.
>
> Thank you.
>
>
> On Mon, 8 Jun 2020 at 10:47, Diptesh Patel <diptesh.patel at ecosmob.com>
> wrote:
>
>> Hello Solarmon,
>>
>> Need some clarification on term blacklisting, Are you using the blacklist
>> for Probing Mode of destination? or Are you using the *'ds_define_blacklist
>> (str)' *parameter. If you are not using the blacklist parameter then
>> below information help you. It is great if you share your script snippet
>> and output of *'opensipsctl dispatcher dump'* which shows you the
>> current status of your destinations.
>>
>> If you are getting success(200 OK) response on OPTIONS then it is not
>> possible that you got a negative response from a destination and it will
>> not be blacklisted(probing mode) in dispatcher until you blacklist(probing
>> mode) from the script using 'ds_mark_dst()' exported function. I doubt that
>> you are also getting '502 Bad Gateway' on OPTIONS which is sending to the
>> destination to check the availability.  If It is right and you want to add
>> the 502 response as a good response for OPTIONS. you can add the 502 as *'modparam("dispatcher",
>> "options_reply_codes", "502")'.*
>>
>> Thanks & Regards
>> *Diptesh Patel*
>> Software Developer
>> Ecosmob Technologies Ltd,
>> Ahmedabad
>> Mo:*+919898962659*
>>
>>
>> On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to understand whether this is the correct or expected
>>> behaviour.
>>>
>>> We have two destinations configured in Dispatcher.
>>>
>>> What I am noticing is that when we receive 502 Bad Gateway messages
>>> (logged as ("call failed to established with 502 code") from both
>>> endpoints. After both endpoints have returned 502 Bad Gateway, opensips
>>> pass back 503 Service Unavailable back to the originating endpoint of the
>>> call. However, subsequent calls are being immediately rejected with 480
>>> Temporarily Unavailable (logged as "failed to find an available
>>> destination, rejecting") for a period of time.
>>>
>>> It seems that opensips is blacklisting the Dispatcher endpoints because
>>> of receiving the 502 Bad Gateway messages. Is this the correct/expected
>>> behaviour? I would have thought the blacklisting should be based on the SIP
>>> OPTIONS sent to the Dispatcher endpoints.
>>>
>>> I do not currently see any issues with SIP OPTIONS to these endpoints so
>>> I'm confused as to why they are seemingly blacklisted.
>>>
>>> If this is the correct/expected behaviour, can it be changed to only
>>> blacklist based on the SIP OPTIONs pings?
>>>
>>> Thank you.
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> *Disclaimer*
>> In addition to generic Disclaimer which you have agreed on our website,
>> any views or opinions presented in this email are solely those of the
>> originator and do not necessarily represent those of the Company or its
>> sister concerns. Any liability (in negligence, contract or otherwise)
>> arising from any third party taking any action, or refraining from taking
>> any action on the basis of any of the information contained in this email
>> is hereby excluded.
>>
>> *Confidentiality*
>> This communication (including any attachment/s) is intended only for the
>> use of the addressee(s) and contains information that is PRIVILEGED AND
>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
>> of this communication is prohibited. Please inform originator if you have
>> received it in error.
>>
>> *Caution for viruses, malware etc.*
>> This communication, including any attachments, may not be free of
>> viruses, trojans, similar or new contaminants/malware, interceptions or
>> interference, and may not be compatible with your systems. You shall carry
>> out virus/malware scanning on your own before opening any attachment to
>> this e-mail. The sender of this e-mail and Company including its sister
>> concerns shall not be liable for any damage that may incur to you as a
>> result of viruses, incompleteness of this message, a delay in receipt of
>> this message or any other computer problems.
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200608/68cef419/attachment-0001.html>

From Ben.Newlin at genesys.com  Mon Jun  8 12:44:00 2020
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Mon, 8 Jun 2020 12:44:00 +0000
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
 <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
 <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
Message-ID: <1AA82A57-4BED-4143-B5AC-A8C4599E4157@genesys.com>

Solarmon,

Yes, that code is your issue. While it makes sense to mark the remote destination unreachable on some error responses possibly, or certainly on lack of response, this code is marking the destination unreachable on receipt of any 5xx or 6xx response (or timeout), without regard to whether the response came directly from that node or from further upstream. This does not seem desirable.

The code is also performing failover using the dispatcher for any of these codes, which also does not account for the possibility that the error came from further upstream and trying another dispatcher node may not be warranted or helpful.

If you have control over the nodes that are the dispatcher targets, what we have done is to add a customer header to any error replies sent directly from that node. This allows the receiving node to know that the issue was local to the remote node and not relayed from further upstream and that ds_mark_dst and ds_next_dst are appropriate. We also still check for timeout too, of course. But there are other ways to do this as well.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of solarmon <solarmon at one-n.co.uk>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Monday, June 8, 2020 at 6:57 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being rejected with 480 Temporarily Unavailable

Hi Diptesh ,

Thanks for your reply.

Apologies, I'm using the term 'blacklist' to generally mean that the endpoints are not available.

Also, the 502 Bad Gateway is response to an INVITE, not SIP OPTIONS, returned by the far end and the ITSP is just passing that back to us, because the call has failed. For such call failures, I'm not expecting for the dispatcher endpoints to be marked as unavailable for routing.

I am not using, or have not set, the 'ds_define_blacklist (str)' option in my dispatcher module config.

My probing mode is:

modparam("dispatcher", "ds_probing_mode", 1)

I'm not seeing anything in the logs regarding the dispatcher nodes going into Probing mode - should there be logs for that, or can it be enabled to be logged?

When I check the endpoints with ' opensipsctl dispatcher dump' they always seem to be 'Active' - so it is either they are like that, or they may have only been in 'Probing' mode very briefly. Again, I was hoping to see mode/state change in the historical logs.

In my opensips.cfg (which was created for me) I can see the following code, which looks like this is where it is introducing this behaviour in question:

failure_route[call_failover]
{
        xlog("[$ci] call failed to established with $T_reply_code code\n");

        rtpproxy_unforce("$avp(rtpp_set)");

        if (t_was_cancelled()) {
                t_reply("487","Request cancelled");
                exit;
        }

        # any failure indication ?
        if ( t_check_status("[56][0-9][0-9]")
        || (t_check_status("408") && t_local_replied("all"))
        ) {
                xlog("[$ci] destination $rd failed  with $T_reply_code -> retry\n ");

                ds_mark_dst("p");

                if ( ds_next_domain() ) {
                        xlog("[$ci] using new destination <$rd>\n ");

                        # send it out again
                        t_on_failure("call_failover");
                        t_relay();
                        exit;
                } else {
                        xlog("[$ci] no other destination to retry\n ");
                        t_reply("503","Service not available");
                        exit;
                }
        }

        # if call failure, allow the reply to propagate to caller
        exit;
}


Thank you for the tip about the  'modparam("dispatcher", "options_reply_codes", "502")' option. I will try that if it is not recommend to change the above code.

Thank you.


On Mon, 8 Jun 2020 at 10:47, Diptesh Patel <diptesh.patel at ecosmob.com<mailto:diptesh.patel at ecosmob.com>> wrote:
Hello Solarmon,

Need some clarification on term blacklisting, Are you using the blacklist for Probing Mode of destination? or Are you using the 'ds_define_blacklist (str)' parameter. If you are not using the blacklist parameter then below information help you. It is great if you share your script snippet and output of 'opensipsctl dispatcher dump' which shows you the current status of your destinations.

If you are getting success(200 OK) response on OPTIONS then it is not possible that you got a negative response from a destination and it will not be blacklisted(probing mode) in dispatcher until you blacklist(probing mode) from the script using 'ds_mark_dst()' exported function. I doubt that you are also getting '502 Bad Gateway' on OPTIONS which is sending to the destination to check the availability.  If It is right and you want to add the 502 response as a good response for OPTIONS. you can add the 502 as 'modparam("dispatcher", "options_reply_codes", "502")'.

Thanks & Regards
Diptesh Patel
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:+919898962659


On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk<mailto:solarmon at one-n.co.uk>> wrote:
Hi,

I'm trying to understand whether this is the correct or expected behaviour.

We have two destinations configured in Dispatcher.

What I am noticing is that when we receive 502 Bad Gateway messages (logged as ("call failed to established with 502 code") from both endpoints. After both endpoints have returned 502 Bad Gateway, opensips pass back 503 Service Unavailable back to the originating endpoint of the call. However, subsequent calls are being immediately rejected with 480 Temporarily Unavailable (logged as "failed to find an available destination, rejecting") for a period of time.

It seems that opensips is blacklisting the Dispatcher endpoints because of receiving the 502 Bad Gateway messages. Is this the correct/expected behaviour? I would have thought the blacklisting should be based on the SIP OPTIONS sent to the Dispatcher endpoints.

I do not currently see any issues with SIP OPTIONS to these endpoints so I'm confused as to why they are seemingly blacklisted.

If this is the correct/expected behaviour, can it be changed to only blacklist based on the SIP OPTIONs pings?

Thank you.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200608/b5dadab9/attachment-0001.html>

From williamj at exetel.com.au  Mon Jun  8 23:09:12 2020
From: williamj at exetel.com.au (William Jin)
Date: Mon, 8 Jun 2020 23:09:12 +0000
Subject: [OpenSIPS-Users] question about rtpengine_manage() in failure_route
Message-ID: <SG2PR06MB2409D3D2B24643A4F6878B899B850@SG2PR06MB2409.apcprd06.prod.outlook.com>

Hi All

May I know how can I rewrite the SDP (rtpengine) in the failure route?

The scenario is we use rtpengine_manage() in the first call attempt, if it fails, it uses failure_route, however, we want to change the SDP info.

For example, the call's first attempt is to an ipv6 UAC, when failed, we try ipv4 UAC. We need to change the rtpengine address-family to IP4 so the c= line can follow with an IPv4 address.

We tried to use rtpengine_manage("address-family=IP4"), but looks like the SDP still not changed.

Does anyone have any idea about this? Or is there any other way to achieve this?



--
Regards,
William Jin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200608/94c53c70/attachment.html>

From williamj at exetel.com.au  Tue Jun  9 04:04:44 2020
From: williamj at exetel.com.au (William Jin)
Date: Tue, 9 Jun 2020 04:04:44 +0000
Subject: [OpenSIPS-Users] question about rtpengine_manage() in
	failure_route
In-Reply-To: <SG2PR06MB2409D3D2B24643A4F6878B899B850@SG2PR06MB2409.apcprd06.prod.outlook.com>
References: <SG2PR06MB2409D3D2B24643A4F6878B899B850@SG2PR06MB2409.apcprd06.prod.outlook.com>
Message-ID: <SG2PR06MB2409E6637F569783051D3B6C9B820@SG2PR06MB2409.apcprd06.prod.outlook.com>

Below is a short config example.

route {
...
setflag(CallFWD);
rtpengine_manage();  #say the first call attempt need rtpengine
t_on_failure("handle_failure");
r_relay();
...
}


failure_route[handle_failure] {
...
if (isflagset(CallFWD)){route(handle_callfwd);}
...
}

route[handle_callfwd]{
...
xlog("L_INFO","RB=$rb(application/sdp)");
if (t_relay()){
xlog("L_INFO","Stateful relay done. RB=$rb(application/sdp)");
}
...
}

Looks like the t_relay in the handle_callfwd will inherit the SDP info that rtpengine_manage entered in the first attempt.

Also, another interesting fact is that the SDP info is added while the t_relay is called. Looks like the t_relay is using its data in memory and re-write the SDP. the  $rb(application/sdp) is not changed until the t_relay is called.

How can I, for example, remove the rtpengine related SDP for the second INVITE generated by the failure_route?
I tried rtpengine_delete() in handle_callfwd or rtpengine_manage() in the failure_route which suppose to do rtpengine_delete also, but they don't work as expected.

Thanks in advance.


--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au>
Sent: Tuesday, 9 June 2020 9:09 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] question about rtpengine_manage() in failure_route

Hi All

May I know how can I rewrite the SDP (rtpengine) in the failure route?

The scenario is we use rtpengine_manage() in the first call attempt, if it fails, it uses failure_route, however, we want to change the SDP info.

For example, the call's first attempt is to an ipv6 UAC, when failed, we try ipv4 UAC. We need to change the rtpengine address-family to IP4 so the c= line can follow with an IPv4 address.

We tried to use rtpengine_manage("address-family=IP4"), but looks like the SDP still not changed.

Does anyone have any idea about this? Or is there any other way to achieve this?



--
Regards,
William Jin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200609/4b83a2bf/attachment.html>

From venefax at gmail.com  Tue Jun  9 12:43:17 2020
From: venefax at gmail.com (Saint Michael)
Date: Tue, 9 Jun 2020 08:43:17 -0400
Subject: [OpenSIPS-Users] Maybe it's a bug
Message-ID: <CAC9cSOBCDYCP8S=BXHUFuiE5K3PYrQsUgTDpmpm864R0xWrjpA@mail.gmail.com>

I have been wondering why my billing never matched the invoice from my
carrier and I think I found the issue. I pass a few million calls a day. It
turns out that Opensips is not rounding upwards the ms to calculate
seconds, and that is done at the source code. This issue leads to absurds
like a call with 100 ms being reported as zero seconds, and a call with
1200 ms being reported as 1 second, etc. In the first case, 100ms, my
carrier will consider this call 1 second, rounded to 6 seconds
minimum (6/6). So there a jus lost 6 seconds that I am not charging to my
customer but I am paying for. If you have millions of calls, 50%, that fall
into the lower half of 1000ms, like 24400 ms, that they are reported as 24
seconds, but my carrier thinks is 25 seconds, and he rounds it to 30, there
I lost another 6 seconds.
I talked to Vlad, who I believe wrote the code, and he does not think it is
a bug and I should use the ms and not the seconds. But thousands of
businessmen will not spot this and thus their billing will never match the
carrier, and they will lose money. If anybody thinks for a second that a
call with a 200 OK will be free, is dreaming. Not in America.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200609/5fff36b7/attachment-0001.html>

From liviu at opensips.org  Tue Jun  9 18:58:24 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 9 Jun 2020 21:58:24 +0300
Subject: [OpenSIPS-Users] Maybe it's a bug
In-Reply-To: <CAC9cSOBCDYCP8S=BXHUFuiE5K3PYrQsUgTDpmpm864R0xWrjpA@mail.gmail.com>
References: <CAC9cSOBCDYCP8S=BXHUFuiE5K3PYrQsUgTDpmpm864R0xWrjpA@mail.gmail.com>
Message-ID: <fdf42ea6-7623-b76b-3e3d-1e289af437c0@opensips.org>

On 09.06.2020 15:43, Saint Michael wrote:
> I talked to Vlad, who I believe wrote the code, and he does not think 
> it is a bug and I should use the ms and not the seconds. But thousands 
> of businessmen will not spot this and thus their billing will never 
> match the carrier, and they will lose money. If anybody thinks for a 
> second that a call with a 200 OK will be free, is dreaming. Not in 
> America.

Hi, SM!

Opinion #1: I doubt that anyone who is serious about their billing & 
revenue (e.g. your nitpicky carrier) would leave to randomness the 
answer to the most basic question of: "does our platform correctly bill 
each call?".  No disrespect here, just maybe highlighting the fact that 
your platform could benefit from a bit more testing.

Opinion #2: we could definitely change the default of the 
second-accurate precision to be _greedy_ instead of _generous_. I bet 
most people (myself included) would be more happy with a ceil() [1] 
behavior instead of a trunc() [2] one.  That is: round _upwards_, not 
_downwards_.  More opinions would be useful here!

Best regards,

[1]: man ceil
[2]: man trunc

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com



From johan at democon.be  Tue Jun  9 19:13:58 2020
From: johan at democon.be (Johan De Clercq)
Date: Tue, 9 Jun 2020 19:13:58 +0000
Subject: [OpenSIPS-Users] Maybe it's a bug
In-Reply-To: <fdf42ea6-7623-b76b-3e3d-1e289af437c0@opensips.org>
References: <CAC9cSOBCDYCP8S=BXHUFuiE5K3PYrQsUgTDpmpm864R0xWrjpA@mail.gmail.com>,
 <fdf42ea6-7623-b76b-3e3d-1e289af437c0@opensips.org>
Message-ID: <AM0PR06MB622654BACCEFF2B776033B93A7820@AM0PR06MB6226.eurprd06.prod.outlook.com>

Upwards seems best.

Outlook voor iOS<https://aka.ms/o0ukef> downloaden
________________________________
Van: Users <users-bounces at lists.opensips.org> namens Liviu Chircu <liviu at opensips.org>
Verzonden: Tuesday, June 9, 2020 8:58:24 PM
Aan: OpenSIPS users mailling list <users at lists.opensips.org>
Onderwerp: Re: [OpenSIPS-Users] Maybe it's a bug

On 09.06.2020 15:43, Saint Michael wrote:
> I talked to Vlad, who I believe wrote the code, and he does not think
> it is a bug and I should use the ms and not the seconds. But thousands
> of businessmen will not spot this and thus their billing will never
> match the carrier, and they will lose money. If anybody thinks for a
> second that a call with a 200 OK will be free, is dreaming. Not in
> America.

Hi, SM!

Opinion #1: I doubt that anyone who is serious about their billing &
revenue (e.g. your nitpicky carrier) would leave to randomness the
answer to the most basic question of: "does our platform correctly bill
each call?".  No disrespect here, just maybe highlighting the fact that
your platform could benefit from a bit more testing.

Opinion #2: we could definitely change the default of the
second-accurate precision to be _greedy_ instead of _generous_. I bet
most people (myself included) would be more happy with a ceil() [1]
behavior instead of a trunc() [2] one.  That is: round _upwards_, not
_downwards_.  More opinions would be useful here!

Best regards,

[1]: man ceil
[2]: man trunc

--
Liviu Chircu
www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> | www.opensips-solutions.com<http://www.opensips-solutions.com>


_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200609/40381895/attachment.html>

From david.villasmil.work at gmail.com  Tue Jun  9 19:13:56 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Tue, 9 Jun 2020 20:13:56 +0100
Subject: [OpenSIPS-Users] Maybe it's a bug
In-Reply-To: <fdf42ea6-7623-b76b-3e3d-1e289af437c0@opensips.org>
References: <CAC9cSOBCDYCP8S=BXHUFuiE5K3PYrQsUgTDpmpm864R0xWrjpA@mail.gmail.com>
 <fdf42ea6-7623-b76b-3e3d-1e289af437c0@opensips.org>
Message-ID: <CAFGRPVp+xAvsy_PzfmUeHBNw7m_TJqp+Q2qf48ei=frvEKLkKw@mail.gmail.com>

+1
Always ALWAYS round up, never down (in terms of ms to secs)
+1
Also do your billing were your application is, not on a proxy.

On Tue, 9 Jun 2020 at 19:58, Liviu Chircu <liviu at opensips.org> wrote:

> On 09.06.2020 15:43, Saint Michael wrote:
> > I talked to Vlad, who I believe wrote the code, and he does not think
> > it is a bug and I should use the ms and not the seconds. But thousands
> > of businessmen will not spot this and thus their billing will never
> > match the carrier, and they will lose money. If anybody thinks for a
> > second that a call with a 200 OK will be free, is dreaming. Not in
> > America.
>
> Hi, SM!
>
> Opinion #1: I doubt that anyone who is serious about their billing &
> revenue (e.g. your nitpicky carrier) would leave to randomness the
> answer to the most basic question of: "does our platform correctly bill
> each call?".  No disrespect here, just maybe highlighting the fact that
> your platform could benefit from a bit more testing.
>
> Opinion #2: we could definitely change the default of the
> second-accurate precision to be _greedy_ instead of _generous_. I bet
> most people (myself included) would be more happy with a ceil() [1]
> behavior instead of a trunc() [2] one.  That is: round _upwards_, not
> _downwards_.  More opinions would be useful here!
>
> Best regards,
>
> [1]: man ceil
> [2]: man trunc
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200609/07550879/attachment.html>

From calvin.ellison at voxox.com  Tue Jun  9 19:43:10 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Tue, 9 Jun 2020 12:43:10 -0700
Subject: [OpenSIPS-Users] Maybe it's a bug
In-Reply-To: <AM0PR06MB622654BACCEFF2B776033B93A7820@AM0PR06MB6226.eurprd06.prod.outlook.com>
References: <CAC9cSOBCDYCP8S=BXHUFuiE5K3PYrQsUgTDpmpm864R0xWrjpA@mail.gmail.com>
 <fdf42ea6-7623-b76b-3e3d-1e289af437c0@opensips.org>
 <AM0PR06MB622654BACCEFF2B776033B93A7820@AM0PR06MB6226.eurprd06.prod.outlook.com>
Message-ID: <CAL+QDG-+WNCJGQA7d7nydCzPpt3phDt+N4=U_up4URxffuWRnQ@mail.gmail.com>

+1 to ceil() rounding, and stating in the documentation that this is
the method used. Alternatively, some new option to specify ceiling,
floor, round, truncate, etc.

I can back up SM's claim that a single billing interval discrepancy
will cost people real money. Clarification in the documentation will
help people avoid that pitfall. I also concur with Vlad that the
duration in milliseconds is preferable. The millisecond data can help
to settle any billing disputes from clients or vendors, and it
demystifies CDRs for everyone: one field for actual call duration in
ms, another field for call duration after rounding, and/or one for the
final charged call duration after rounding and billing interval.



Regards,

Calvin Ellison
Senior Voice Operations Engineer
calvin.ellison at voxox.com


On Tue, Jun 9, 2020 at 12:14 PM Johan De Clercq <johan at democon.be> wrote:
>
> Upwards seems best.


From volga629 at networklab.ca  Tue Jun  9 20:57:53 2020
From: volga629 at networklab.ca (Slava Bendersky)
Date: Tue, 9 Jun 2020 16:57:53 -0400 (EDT)
Subject: [OpenSIPS-Users] cluster/cassandra cache
Message-ID: <1663556725.25245.1591736273833.JavaMail.zimbra@skillsearch.ca>

Hello Everyone, 
Opensips v3.1 dev can't connect properly to Cassandra cluster. 

1591735692.141 [ERROR] (cluster_connector.cpp:190:void datastax::internal::core::ClusterConnector::on_connect(datastax::internal::core::ControlConnector*)): Unable to establish a control connection to host 10.100.101.9 because of the following error: Underlying connection error: Received error response 'Invalid or unsupported protocol version (66); supported versions are (3/v3, 4/v4, 5/v5-beta)' (0x0200000A) 
Any help, thank you. 

volga629 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200609/ebb60ccc/attachment.html>

From daniel.zanutti at gmail.com  Tue Jun  9 23:27:21 2020
From: daniel.zanutti at gmail.com (Daniel Zanutti)
Date: Tue, 9 Jun 2020 20:27:21 -0300
Subject: [OpenSIPS-Users] Maybe it's a bug
In-Reply-To: <CAL+QDG-+WNCJGQA7d7nydCzPpt3phDt+N4=U_up4URxffuWRnQ@mail.gmail.com>
References: <CAC9cSOBCDYCP8S=BXHUFuiE5K3PYrQsUgTDpmpm864R0xWrjpA@mail.gmail.com>
 <fdf42ea6-7623-b76b-3e3d-1e289af437c0@opensips.org>
 <AM0PR06MB622654BACCEFF2B776033B93A7820@AM0PR06MB6226.eurprd06.prod.outlook.com>
 <CAL+QDG-+WNCJGQA7d7nydCzPpt3phDt+N4=U_up4URxffuWRnQ@mail.gmail.com>
Message-ID: <CAN0jgiO8Gz8LK6hKq1vjGDNpwdMeoewF7nC+_BgVNenRgmXx+g@mail.gmail.com>

Hi folks

We implemented millisecond billing in our platform, so no need to round on
the Opensips layer, the rounding is done in our business billing layer.
This way customers can have a different rounding than VoIP providers. It's
not a way to penalize customers, but some providers just work differently
than others and you cannot demand them to work "your way".

I suggest store a float (instead of integer) with milliseconds included OR
an option to store milliseconds on a separated column.

Regards


On Tue, Jun 9, 2020 at 4:45 PM Calvin Ellison <calvin.ellison at voxox.com>
wrote:

> +1 to ceil() rounding, and stating in the documentation that this is
> the method used. Alternatively, some new option to specify ceiling,
> floor, round, truncate, etc.
>
> I can back up SM's claim that a single billing interval discrepancy
> will cost people real money. Clarification in the documentation will
> help people avoid that pitfall. I also concur with Vlad that the
> duration in milliseconds is preferable. The millisecond data can help
> to settle any billing disputes from clients or vendors, and it
> demystifies CDRs for everyone: one field for actual call duration in
> ms, another field for call duration after rounding, and/or one for the
> final charged call duration after rounding and billing interval.
>
>
>
> Regards,
>
> Calvin Ellison
> Senior Voice Operations Engineer
> calvin.ellison at voxox.com
>
>
> On Tue, Jun 9, 2020 at 12:14 PM Johan De Clercq <johan at democon.be> wrote:
> >
> > Upwards seems best.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200609/066fec78/attachment.html>

From diptesh.patel at ecosmob.com  Wed Jun 10 04:39:12 2020
From: diptesh.patel at ecosmob.com (Diptesh Patel)
Date: Wed, 10 Jun 2020 10:09:12 +0530
Subject: [OpenSIPS-Users] SIPREC server does not send BYE while capturing
	Early-Media.
Message-ID: <CAD4_Da3qVGQR_=UbiED3_t5r2ef6i=dut-Oe6_cnZhfOF+91EQ@mail.gmail.com>

Hello,

I am using the SIPREC module to send the request to SRS with fail-over.
While recording early media and after Originator Cancel OpenSIPS does not
send a BYE request to the SRS.  Please look at the script snippet of how I
implemented that.

if (is_method ("INVITE"))
    {
      if (siprec_start_recording ("sip:XX.XX.XXX.X00:5060"))
{
 xlog ("L_INFO", "SIP RECORDING THROUGH XX.XX.XXX.X00");
}
      else if (siprec_start_recording ("sip:XX.XX.XXX.X04:5060"))
{
 xlog ("L_INFO", "SIP RECORDING THROUGH XX.XX.XXX.X04");
}
      else
sl_send_reply ("404", "SIPREC Server NOT FOUND ");
    }
}

local_route {
    if(is_method("INVITE")) {
        xlog("L_INFO","LOCAL ROUTE");

subst('/^Contact:(.*)<sip:(.*)>(.*)$/Contact:\1<sip:\2>;+sip.src\3/ig');
    }
}

Thanks & Regards
*Diptesh Patel*
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:*+919898962659*

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/3bef859b/attachment.html>

From razvan at opensips.org  Wed Jun 10 07:57:25 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 10 Jun 2020 10:57:25 +0300
Subject: [OpenSIPS-Users] SIPREC server does not send BYE while
 capturing Early-Media.
In-Reply-To: <CAD4_Da3qVGQR_=UbiED3_t5r2ef6i=dut-Oe6_cnZhfOF+91EQ@mail.gmail.com>
References: <CAD4_Da3qVGQR_=UbiED3_t5r2ef6i=dut-Oe6_cnZhfOF+91EQ@mail.gmail.com>
Message-ID: <a8ae99b0-dd40-729a-f3f5-307c8612c1e0@opensips.org>

Hi, Diptesh!

This is indeed a limitation due to the fact that the module was 
initially designed to work only starting from a 200 OK.

Please open a bug report for this on github so we can address it.

Best regards,

Răzvan

On 6/10/20 7:39 AM, Diptesh Patel wrote:
> Hello,
>
> I am using the SIPREC module to send the request to SRS with 
> fail-over. While recording early media and after Originator Cancel 
> OpenSIPS does not send a BYE request to the SRS.  Please look at the 
> script snippet of how I implemented that.
>
> if (is_method ("INVITE"))
>     {
>       if (siprec_start_recording ("sip:XX.XX.XXX.X00:5060"))
> {
>  xlog ("L_INFO", "SIP RECORDING THROUGH XX.XX.XXX.X00");
> }
>       else if (siprec_start_recording ("sip:XX.XX.XXX.X04:5060"))
> {
>  xlog ("L_INFO", "SIP RECORDING THROUGH XX.XX.XXX.X04");
> }
>       else
> sl_send_reply ("404", "SIPREC Server NOT FOUND ");
>     }
> }
>
> local_route {
>     if(is_method("INVITE")) {
>         xlog("L_INFO","LOCAL ROUTE");
> subst('/^Contact:(.*)<sip:(.*)>(.*)$/Contact:\1<sip:\2>;+sip.src\3/ig');
>     }
> }
>
> Thanks & Regards
> *Diptesh Patel*
> Software Developer
> Ecosmob Technologies Ltd,
> Ahmedabad
> Mo:*+919898962659*
>
> *Disclaimer*
> In addition to generic Disclaimer which you have agreed on our 
> website, any views or opinions presented in this email are solely 
> those of the originator and do not necessarily represent those of the 
> Company or its sister concerns. Any liability (in negligence, contract 
> or otherwise) arising from any third party taking any action, or 
> refraining from taking any action on the basis of any of the 
> information contained in this email is hereby excluded.
>
> *Confidentiality*
> This communication (including any attachment/s) is intended only for 
> the use of the addressee(s) and contains information that is 
> PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, 
> distribution, or copying of this communication is prohibited. Please 
> inform originator if you have received it in error.
>
> *Caution for viruses, malware etc.*
> This communication, including any attachments, may not be free of 
> viruses, trojans, similar or new contaminants/malware, interceptions 
> or interference, and may not be compatible with your systems. You 
> shall carry out virus/malware scanning on your own before opening any 
> attachment to this e-mail. The sender of this e-mail and Company 
> including its sister concerns shall not be liable for any damage that 
> may incur to you as a result of viruses, incompleteness of this 
> message, a delay in receipt of this message or any other computer 
> problems.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/a858fb18/attachment-0001.html>

From razvan at opensips.org  Wed Jun 10 07:59:34 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 10 Jun 2020 10:59:34 +0300
Subject: [OpenSIPS-Users] question about rtpengine_manage() in
 failure_route
In-Reply-To: <SG2PR06MB2409E6637F569783051D3B6C9B820@SG2PR06MB2409.apcprd06.prod.outlook.com>
References: <SG2PR06MB2409D3D2B24643A4F6878B899B850@SG2PR06MB2409.apcprd06.prod.outlook.com>
 <SG2PR06MB2409E6637F569783051D3B6C9B820@SG2PR06MB2409.apcprd06.prod.outlook.com>
Message-ID: <e819c4ee-c0b3-a975-1834-05fa7fbaf619@opensips.org>

Hi, William!


Make sure you call rtpengine_manage() in branch route, not in the 
request route, otherwise all the changes will be inherited throughout 
all the branches further created.


Best regards,

Răzvan


On 6/9/20 7:04 AM, William Jin wrote:
> Below is a short config example.
>
> route {
> ...
> setflag(CallFWD);
> rtpengine_manage();  #say the first call attempt need rtpengine
> t_on_failure("handle_failure");
> r_relay();
> ...
> }
>
>
> failure_route[handle_failure] {
> ...
> if (isflagset(CallFWD)){route(handle_callfwd);}
> ...
> }
>
> route[handle_callfwd]{
> ...
> xlog("L_INFO","RB=$rb(application/sdp)");
> if (t_relay()){
> xlog("L_INFO","Stateful relay done. RB=$rb(application/sdp)");
> }
> ...
> }
>
> Looks like the t_relay in the handle_callfwd will inherit the SDP info 
> that rtpengine_manage entered in the first attempt.
>
> Also, another interesting fact is that the SDP info is added while the 
> t_relay is called. Looks like the t_relay is using its data in memory 
> and re-write the SDP. the $rb(application/sdp) is not changed until 
> the t_relay is called.
>
> How can I, for example, remove the rtpengine related SDP for the 
> second INVITE generated by the failure_route?
> I tried rtpengine_delete() in handle_callfwd or rtpengine_manage() in 
> the failure_route which suppose to do rtpengine_delete also, but they 
> don't work as expected.
>
> Thanks in advance.
>
>
> --
> Regards,
> William Jin
> ------------------------------------------------------------------------
> *From:* Users <users-bounces at lists.opensips.org> on behalf of William 
> Jin <williamj at exetel.com.au>
> *Sent:* Tuesday, 9 June 2020 9:09 AM
> *To:* OpenSIPS users mailling list <users at lists.opensips.org>
> *Subject:* [OpenSIPS-Users] question about rtpengine_manage() in 
> failure_route
> Hi All
>
> May I know how can I rewrite the SDP (rtpengine) in the failure route?
>
> The scenario is we use rtpengine_manage() in the first call attempt, 
> if it fails, it uses failure_route, however, we want to change the SDP 
> info.
>
> For example, the call's first attempt is to an ipv6 UAC, when failed, 
> we try ipv4 UAC. We need to change the rtpengine address-family to IP4 
> so the c= line can follow with an IPv4 address.
>
> We tried to use rtpengine_manage("address-family=IP4"), but looks like 
> the SDP still not changed.
>
> Does anyone have any idea about this? Or is there any other way to 
> achieve this?
>
>
>
> --
> Regards,
> William Jin
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/fbc608c5/attachment.html>

From solarmon at one-n.co.uk  Wed Jun 10 08:11:18 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Wed, 10 Jun 2020 09:11:18 +0100
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <1AA82A57-4BED-4143-B5AC-A8C4599E4157@genesys.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
 <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
 <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
 <1AA82A57-4BED-4143-B5AC-A8C4599E4157@genesys.com>
Message-ID: <CAOXfywP_cTiVF-sS3pjQi=vF=aJkEJ=NyA6dWc0GeATRtS695A@mail.gmail.com>

Hi,

Thanks all for your help.

I have removed the offending line and we are not seeing that behaviour.

Unfortunately, the two dispatcher endpoints are not managed by us. It would
certainly be nice to have an indication that the errors response it from
the far end. Likewise, how could the same be achieved in opensips when we
respond back to our platform?

Thank you.


On Mon, 8 Jun 2020 at 13:46, Ben Newlin <Ben.Newlin at genesys.com> wrote:

> Solarmon,
>
>
>
> Yes, that code is your issue. While it makes sense to mark the remote
> destination unreachable on some error responses possibly, or certainly on
> lack of response, this code is marking the destination unreachable on
> receipt of any 5xx or 6xx response (or timeout), without regard to whether
> the response came directly from that node or from further upstream. This
> does not seem desirable.
>
>
>
> The code is also performing failover using the dispatcher for any of these
> codes, which also does not account for the possibility that the error came
> from further upstream and trying another dispatcher node may not be
> warranted or helpful.
>
>
>
> If you have control over the nodes that are the dispatcher targets, what
> we have done is to add a customer header to any error replies sent directly
> from that node. This allows the receiving node to know that the issue was
> local to the remote node and not relayed from further upstream and that
> ds_mark_dst and ds_next_dst are appropriate. We also still check for
> timeout too, of course. But there are other ways to do this as well.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users <users-bounces at lists.opensips.org> on behalf of solarmon <
> solarmon at one-n.co.uk>
> *Reply-To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Date: *Monday, June 8, 2020 at 6:57 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] 502 Bad Gateway events leads to calls
> being rejected with 480 Temporarily Unavailable
>
>
>
> Hi Diptesh ,
>
>
>
> Thanks for your reply.
>
>
>
> Apologies, I'm using the term 'blacklist' to generally mean that the
> endpoints are not available.
>
>
>
> Also, the 502 Bad Gateway is response to an INVITE, not SIP OPTIONS,
> returned by the far end and the ITSP is just passing that back to us,
> because the call has failed. For such call failures, I'm not expecting for
> the dispatcher endpoints to be marked as unavailable for routing.
>
>
>
> I am not using, or have not set, the '*ds_define_blacklist (str)*' option
> in my dispatcher module config.
>
>
>
> My probing mode is:
>
>
>
> modparam("dispatcher", "ds_probing_mode", 1)
>
>
>
> I'm not seeing anything in the logs regarding the dispatcher nodes going
> into Probing mode - should there be logs for that, or can it be enabled to
> be logged?
>
>
>
> When I check the endpoints with ' opensipsctl dispatcher dump' they always
> seem to be '*Active*' - so it is either they are like that, or they
> may have only been in '*Probing*' mode very briefly. Again, I was hoping
> to see mode/state change in the historical logs.
>
>
>
> In my *opensips.cfg* (which was created for me) I can see the following
> code, which looks like this is where it is introducing this behaviour in
> question:
>
>
>
> failure_route[call_failover]
>
> {
>
>         xlog("[$ci] call failed to established with $T_reply_code code\n");
>
>
>
>         rtpproxy_unforce("$avp(rtpp_set)");
>
>
>
>         if (t_was_cancelled()) {
>
>                 t_reply("487","Request cancelled");
>
>                 exit;
>
>         }
>
>
>
>         # any failure indication ?
>
>         if ( t_check_status("[56][0-9][0-9]")
>
>         || (t_check_status("408") && t_local_replied("all"))
>
>         ) {
>
>                 xlog("[$ci] destination $rd failed  with $T_reply_code ->
> retry\n ");
>
>
>
>                * ds_mark_dst("p");*
>
>
>
>                 if ( ds_next_domain() ) {
>
>                         xlog("[$ci] using new destination <$rd>\n ");
>
>
>
>                         # send it out again
>
>                         t_on_failure("call_failover");
>
>                         t_relay();
>
>                         exit;
>
>                 } else {
>
>                         xlog("[$ci] no other destination to retry\n ");
>
>                         t_reply("503","Service not available");
>
>                         exit;
>
>                 }
>
>         }
>
>
>
>         # if call failure, allow the reply to propagate to caller
>
>         exit;
>
> }
>
>
>
>
>
> Thank you for the tip about the  'modparam("dispatcher",
> "options_reply_codes", "502")' option. I will try that if it is not
> recommend to change the above code.
>
>
>
> Thank you.
>
>
>
>
>
> On Mon, 8 Jun 2020 at 10:47, Diptesh Patel <diptesh.patel at ecosmob.com>
> wrote:
>
> Hello Solarmon,
>
>
>
> Need some clarification on term blacklisting, Are you using the blacklist
> for Probing Mode of destination? or Are you using the *'ds_define_blacklist
> (str)' *parameter. If you are not using the blacklist parameter then
> below information help you. It is great if you share your script snippet
> and output of *'opensipsctl dispatcher dump'* which shows you the current
> status of your destinations.
>
>
>
> If you are getting success(200 OK) response on OPTIONS then it is not
> possible that you got a negative response from a destination and it will
> not be blacklisted(probing mode) in dispatcher until you blacklist(probing
> mode) from the script using 'ds_mark_dst()' exported function. I doubt that
> you are also getting '502 Bad Gateway' on OPTIONS which is sending to the
> destination to check the availability.  If It is right and you want to add
> the 502 response as a good response for OPTIONS. you can add the 502 as *'modparam("dispatcher",
> "options_reply_codes", "502")'.*
>
>
>
> Thanks & Regards
>
> *Diptesh Patel*
>
> Software Developer
>
> Ecosmob Technologies Ltd,
>
> Ahmedabad
>
> Mo:*+919898962659*
>
>
>
>
>
> On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk> wrote:
>
> Hi,
>
>
>
> I'm trying to understand whether this is the correct or expected behaviour.
>
>
>
> We have two destinations configured in Dispatcher.
>
>
>
> What I am noticing is that when we receive 502 Bad Gateway messages
> (logged as ("call failed to established with 502 code") from both
> endpoints. After both endpoints have returned 502 Bad Gateway, opensips
> pass back 503 Service Unavailable back to the originating endpoint of the
> call. However, subsequent calls are being immediately rejected with 480
> Temporarily Unavailable (logged as "failed to find an available
> destination, rejecting") for a period of time.
>
>
>
> It seems that opensips is blacklisting the Dispatcher endpoints because of
> receiving the 502 Bad Gateway messages. Is this the correct/expected
> behaviour? I would have thought the blacklisting should be based on the SIP
> OPTIONS sent to the Dispatcher endpoints.
>
>
>
> I do not currently see any issues with SIP OPTIONS to these endpoints so
> I'm confused as to why they are seemingly blacklisted.
>
>
>
> If this is the correct/expected behaviour, can it be changed to only
> blacklist based on the SIP OPTIONs pings?
>
>
>
> Thank you.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> *Disclaimer*
>
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
>
>
> *Confidentiality*
>
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
>
>
> *Caution for viruses, malware etc.*
>
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/cc886ef6/attachment-0001.html>

From bakern at gmail.com  Wed Jun 10 17:55:21 2020
From: bakern at gmail.com (Nate Baker)
Date: Wed, 10 Jun 2020 13:55:21 -0400
Subject: [OpenSIPS-Users] RTPEngine Setup Delay Between External Users
Message-ID: <CADwrbY20YP+a_9j+2z=0ZAN6tosu0U=8FGw6+p9JMV3jgjxomw@mail.gmail.com>

Hello Everyone,

I'm trying to solve a problem where there is a 3-4 second delay before
audio is connected when using RTPEngine between two external users.  In
this scenario OpenSIPS/RTPEngine is used as sort of an SBC for remote
users, and there is a PBX behind OpenSIPS that just proxies the call (it's
not creating a 2nd call and bridging them).  The server is multihomed (has
a public and private IP).  Trying to visualize it (excuse my poor ASCII
art):

         ___________       _________
UAC --> |           | --> |         |
        | OpenSIPS  |     |  PBX    |
        | RTPEngine |     | (Proxy) |
UAC <-- |___________| <-- |_________|

It seems like since the call ID stays the same RTPEngine is having trouble
establishing the interfaces, even when using any of the "to-tag" or
"via-branch=(1|2|extra)" flags.  So the call connects, and I get audio
after about 3-4 seconds.  During that time the RTPEngine log shows a bunch
of entries like:

INFO: [...]: Switching local interface to x.x.x.x:31000
INFO: [...]: Switching local interface to x.x.x.x:30966
WARNING: More than 30 duplicate packets detected, dropping packet to avoid
potential loop
WARNING: More than 30 duplicate packets detected, dropping packet to avoid
potential loop

After 3-4 seconds with a ton of those messages it confirms peer addresses
back and forth several times, and audio is connected fine for the rest of
the call.  The only way I have been able to get it working properly is to
use the "call-id=" flag and set a custom call-id for each.  Can anyone
recommend the way this should be handled?  Or is setting a custom call-id
the appropriate way to handle this?

Thanks,
Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/2e1fdfed/attachment.html>

From osas at voipembedded.com  Wed Jun 10 18:49:26 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 10 Jun 2020 14:49:26 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
	proxy (22:Invalid argument)
Message-ID: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>

Hello all,

I'm running opensips 3.1.0-beta (latest version) and experiencing
connectivity issues to the rtpengine daemon running on the same host:
ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
(22:Invalid argument)
ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
respond, disable it
ERROR:rtpengine:rtpe_function_call: no available proxies

After an opensips restart, everything comes to normal.
I was running previously opensips 3.1.0-dev and everything was working fine.

The issue starts showing up after a few days with very little traffic.
Is there anyone experiencing this issue?


Thanks,
Ovidiu

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From calvin.ellison at voxox.com  Wed Jun 10 20:18:09 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Wed, 10 Jun 2020 13:18:09 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
Message-ID: <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>

We've checked our F5 BigIP configuration and added a second database server
to the pool. Both DBs have been checked for max connections, open files,
etc. Memcached has been moved to a dedicated server. Using a SIPp scenario
for load testing from a separate host, things seem to fall apart on
OpenSIPS around 3,000 CPS with every CPU core at or near 100% and no logs
indicating fallback to sync/blocking mode. Both databases barely noticed
the few hundred connections. Does this seem reasonable for a dual CPU
server with 8 cores and 16 threads?

https://ark.intel.com/content/www/us/en/ark/products/47925/intel-xeon-processor-e5620-12m-cache-2-40-ghz-5-86-gt-s-intel-qpi.html

What is the OpenSIPS opinion on Hyper-Threading?

Is there a way to estimate max CPS based on SPECrate, BogoMIPS, or some
other metric?

I would love to know if my opensips.cfg has any mistakes, omissions, or
inefficiencies. Is there a person or group who does sanity checks?

What should I be looking at within OpenSIPS during a load test to identify
bottlenecks?

I'm still looking for guidance on the things below, especially children
vs timer_partitions:

Is there an established method for fine-tuning these things?
> shared memory
> process memory
> children
> db_max_async_connections
> listen=... use_children
> modparam("tm", "timer_partitions", ?)


What else is worth considering?

Regards,

Calvin Ellison
Senior Voice Operations Engineer
calvin.ellison at voxox.com

On Thu, Jun 4, 2020 at 5:18 PM David Villasmil <
david.villasmil.work at gmail.com> wrote:
>
> Maybe you are hitting the max connections? How many connections are there
when it starts to show those errors?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/d33770b2/attachment.html>

From ffshoh at gmail.com  Wed Jun 10 21:13:30 2020
From: ffshoh at gmail.com (Jon Abrams)
Date: Wed, 10 Jun 2020 16:13:30 -0500
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
Message-ID: <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>

I built a similar functioning platform back in 2015 based on similar
hardware (Westmere Xeons, hyperthreading enabled)  running bare metal on
Centos6. At some point we bumped it up to dual X5670s (cheap upgrade
nowadays), but it was handling 12000 CPS peaks on 1 server with 3000-5000
CPS sustained for large parts of the day. I don't think you are too far off
in hardware.
This was on version 1.9, so there was no Async. IIRC it was either 32 or 64
children. Async requires the TM module which adds additional overhead and
memory allocation.
The LRN database was stored in mysql with a very simple table (TN, LRN) to
keep memory usage down so that it could be pinned in memory (server had 48
or 72GB I think). MySQL was set to dump the innodb buffer cache to disk on
restart so that the whole database would be back in memory on restart.
Doing a full table scan would initially populate the MySQL cache.
Blacklists and other smaller datasets were stored in OpenSIPs using the
userblacklist module. There are better ways to do that in version 2 and
onwards. Bigger list were stored in memcached. I prefer redis for this
purpose now.

I would suggest simplifying testing by using a single MySQL server and
bypassing the F5 to eliminate that as a source of connection problems or
additional latencies.
In the OpenSIPs script, eliminate everything but 1 dip, probably just dip
the LRN to start.
Performance test the stripped down scenario with sipp. Based on past
experience, you should be able to hit or come close to your performance
goal with only 1 dip in play.
If you do hit your performance targets, keep adding more dips one by one
until it breaks.
If you can't reach your performance target with this stripped down
scenario, then I'd suggest testing without the async and transactions
enabled. I wouldn't think transactions would be a necessity in this
scenario. I ran into CPS problems on that other open source SIP server when
using async under heavy load. The transaction creation was chewing up CPU
and memory. I'm not sure how different the implementation is here.
I seem to start having problems with sipp when I hit a few thousand CPS due
to it being single threaded. You probably will need to run multiple
parallel sipp processes for your load test, if not already.
If using an OS with systemd journald for logging, that will be a big
bottleneck in of itself with even small amounts of logging.
In 1.9, I hacked together a module to create a timestamp string with ms for
logging query latencies for diagnostic purposes. There may be a better out
of the box way to do it now.
For children sizing, I would suggest benchmarking with at least 16 children
and then doubling it to compare performance.
Watch the logs for out of memory or defragment messages and bump up shared
memory or package memory if necessary. Package memory is probably going to
be your problem, but it doesn't sound like it is a problem yet.

BR,
Jon Abrams
















On Wed, Jun 10, 2020 at 3:20 PM Calvin Ellison <calvin.ellison at voxox.com>
wrote:

> We've checked our F5 BigIP configuration and added a second database
> server to the pool. Both DBs have been checked for max connections, open
> files, etc. Memcached has been moved to a dedicated server. Using a SIPp
> scenario for load testing from a separate host, things seem to fall apart
> on OpenSIPS around 3,000 CPS with every CPU core at or near 100% and no
> logs indicating fallback to sync/blocking mode. Both databases barely
> noticed the few hundred connections. Does this seem reasonable for a dual
> CPU server with 8 cores and 16 threads?
>
>
> https://ark.intel.com/content/www/us/en/ark/products/47925/intel-xeon-processor-e5620-12m-cache-2-40-ghz-5-86-gt-s-intel-qpi.html
>
> What is the OpenSIPS opinion on Hyper-Threading?
>
> Is there a way to estimate max CPS based on SPECrate, BogoMIPS, or some
> other metric?
>
> I would love to know if my opensips.cfg has any mistakes, omissions, or
> inefficiencies. Is there a person or group who does sanity checks?
>
> What should I be looking at within OpenSIPS during a load test to identify
> bottlenecks?
>
> I'm still looking for guidance on the things below, especially children
> vs timer_partitions:
>
> Is there an established method for fine-tuning these things?
>> shared memory
>> process memory
>> children
>> db_max_async_connections
>> listen=... use_children
>> modparam("tm", "timer_partitions", ?)
>
>
> What else is worth considering?
>
> Regards,
>
> Calvin Ellison
> Senior Voice Operations Engineer
> calvin.ellison at voxox.com
>
> On Thu, Jun 4, 2020 at 5:18 PM David Villasmil <
> david.villasmil.work at gmail.com> wrote:
> >
> > Maybe you are hitting the max connections? How many connections are
> there when it starts to show those errors?
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/0c69f3b5/attachment-0001.html>

From venefax at gmail.com  Wed Jun 10 22:59:06 2020
From: venefax at gmail.com (Saint Michael)
Date: Wed, 10 Jun 2020 18:59:06 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
Message-ID: <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>

I do 3000+ CPS with Opensips and MySQL using unixODBC, no problem.  My
query is for routing only. I read a 280 MM table (RocksDB)  for every call.
So it's comparable.
It seems to work flawlessly. However, I only use $60.000 servers from Dell,
R920s, with 64 physical cores and 120 threads, plus 1.5 TB of RAM. My
Opensips is under Vmware ESX 6.X.
Honestly, I paid an Opensips guru to assemble the application for me.
I designed the logic base on my previous switch for Asterisk that could not
handle the pressure. Basically all routing is done in MariaDB. Opensips
just asks a question using a Stored Procedure.
The brain is the database, and opensips executes instructions. It just
works.


On Wed, Jun 10, 2020 at 5:15 PM Jon Abrams <ffshoh at gmail.com> wrote:

> I built a similar functioning platform back in 2015 based on similar
> hardware (Westmere Xeons, hyperthreading enabled)  running bare metal on
> Centos6. At some point we bumped it up to dual X5670s (cheap upgrade
> nowadays), but it was handling 12000 CPS peaks on 1 server with 3000-5000
> CPS sustained for large parts of the day. I don't think you are too far off
> in hardware.
> This was on version 1.9, so there was no Async. IIRC it was either 32 or
> 64 children. Async requires the TM module which adds additional overhead
> and memory allocation.
> The LRN database was stored in mysql with a very simple table (TN, LRN) to
> keep memory usage down so that it could be pinned in memory (server had 48
> or 72GB I think). MySQL was set to dump the innodb buffer cache to disk on
> restart so that the whole database would be back in memory on restart.
> Doing a full table scan would initially populate the MySQL cache.
> Blacklists and other smaller datasets were stored in OpenSIPs using the
> userblacklist module. There are better ways to do that in version 2 and
> onwards. Bigger list were stored in memcached. I prefer redis for this
> purpose now.
>
> I would suggest simplifying testing by using a single MySQL server and
> bypassing the F5 to eliminate that as a source of connection problems or
> additional latencies.
> In the OpenSIPs script, eliminate everything but 1 dip, probably just dip
> the LRN to start.
> Performance test the stripped down scenario with sipp. Based on past
> experience, you should be able to hit or come close to your performance
> goal with only 1 dip in play.
> If you do hit your performance targets, keep adding more dips one by one
> until it breaks.
> If you can't reach your performance target with this stripped down
> scenario, then I'd suggest testing without the async and transactions
> enabled. I wouldn't think transactions would be a necessity in this
> scenario. I ran into CPS problems on that other open source SIP server when
> using async under heavy load. The transaction creation was chewing up CPU
> and memory. I'm not sure how different the implementation is here.
> I seem to start having problems with sipp when I hit a few thousand CPS
> due to it being single threaded. You probably will need to run multiple
> parallel sipp processes for your load test, if not already.
> If using an OS with systemd journald for logging, that will be a big
> bottleneck in of itself with even small amounts of logging.
> In 1.9, I hacked together a module to create a timestamp string with ms
> for logging query latencies for diagnostic purposes. There may be a better
> out of the box way to do it now.
> For children sizing, I would suggest benchmarking with at least 16
> children and then doubling it to compare performance.
> Watch the logs for out of memory or defragment messages and bump up shared
> memory or package memory if necessary. Package memory is probably going to
> be your problem, but it doesn't sound like it is a problem yet.
>
> BR,
> Jon Abrams
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jun 10, 2020 at 3:20 PM Calvin Ellison <calvin.ellison at voxox.com>
> wrote:
>
>> We've checked our F5 BigIP configuration and added a second database
>> server to the pool. Both DBs have been checked for max connections, open
>> files, etc. Memcached has been moved to a dedicated server. Using a SIPp
>> scenario for load testing from a separate host, things seem to fall apart
>> on OpenSIPS around 3,000 CPS with every CPU core at or near 100% and no
>> logs indicating fallback to sync/blocking mode. Both databases barely
>> noticed the few hundred connections. Does this seem reasonable for a dual
>> CPU server with 8 cores and 16 threads?
>>
>>
>> https://ark.intel.com/content/www/us/en/ark/products/47925/intel-xeon-processor-e5620-12m-cache-2-40-ghz-5-86-gt-s-intel-qpi.html
>>
>> What is the OpenSIPS opinion on Hyper-Threading?
>>
>> Is there a way to estimate max CPS based on SPECrate, BogoMIPS, or some
>> other metric?
>>
>> I would love to know if my opensips.cfg has any mistakes, omissions, or
>> inefficiencies. Is there a person or group who does sanity checks?
>>
>> What should I be looking at within OpenSIPS during a load test to
>> identify bottlenecks?
>>
>> I'm still looking for guidance on the things below, especially children
>> vs timer_partitions:
>>
>> Is there an established method for fine-tuning these things?
>>> shared memory
>>> process memory
>>> children
>>> db_max_async_connections
>>> listen=... use_children
>>> modparam("tm", "timer_partitions", ?)
>>
>>
>> What else is worth considering?
>>
>> Regards,
>>
>> Calvin Ellison
>> Senior Voice Operations Engineer
>> calvin.ellison at voxox.com
>>
>> On Thu, Jun 4, 2020 at 5:18 PM David Villasmil <
>> david.villasmil.work at gmail.com> wrote:
>> >
>> > Maybe you are hitting the max connections? How many connections are
>> there when it starts to show those errors?
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200610/eaa1b4e1/attachment.html>

From farmorg at gmail.com  Thu Jun 11 10:15:53 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Thu, 11 Jun 2020 11:15:53 +0100
Subject: [OpenSIPS-Users] Write acc_extra data to separate table
Message-ID: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>

Hi everyone

I have a couple of extra fields in my acc database table which is added by
acc_extra. This causes issues when upgrading.
I would prefer to have that data stored in a different database/table.

Is there a nice way to do that?
OpenSIPS 3.0 in this case.

Many thanks
Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/33c41d1d/attachment.html>

From Johan at democon.be  Thu Jun 11 10:29:48 2020
From: Johan at democon.be (Johan De Clercq)
Date: Thu, 11 Jun 2020 12:29:48 +0200
Subject: [OpenSIPS-Users] Write acc_extra data to separate table
In-Reply-To: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>
References: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>
Message-ID: <CAEVWGm-QkyuzRfCdqCDtdirHq5n3qzbetMGeakYDvHd4HEyPOg@mail.gmail.com>

If I am not wrong, you can specify the accounting table and db in the
module params.
Hence make a copy of the table, insert in a new db, add your extra column
and adapt the module parameters.

wkr,

Op do 11 jun. 2020 om 12:18 schreef Mark Farmer <farmorg at gmail.com>:

> Hi everyone
>
> I have a couple of extra fields in my acc database table which is added by
> acc_extra. This causes issues when upgrading.
> I would prefer to have that data stored in a different database/table.
>
> Is there a nice way to do that?
> OpenSIPS 3.0 in this case.
>
> Many thanks
> Mark.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/357259c7/attachment-0001.html>

From farmorg at gmail.com  Thu Jun 11 10:38:51 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Thu, 11 Jun 2020 11:38:51 +0100
Subject: [OpenSIPS-Users] Write acc_extra data to separate table
In-Reply-To: <CAEVWGm-QkyuzRfCdqCDtdirHq5n3qzbetMGeakYDvHd4HEyPOg@mail.gmail.com>
References: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>
 <CAEVWGm-QkyuzRfCdqCDtdirHq5n3qzbetMGeakYDvHd4HEyPOg@mail.gmail.com>
Message-ID: <CAOvQDevNeyPyJUJoX7gz+6XR+DN2vcFBkqZgQ4oNu1deqZvEqw@mail.gmail.com>

Thanks for the reply Johan, I'm not sure that's quite what I'm looking for.
I'd like the usual acc data to be written to the normal acc table but my
extra data written to a different table, preferably in a different database.

Many thanks
Mark.


On Thu, 11 Jun 2020 at 11:32, Johan De Clercq <Johan at democon.be> wrote:

> If I am not wrong, you can specify the accounting table and db in the
> module params.
> Hence make a copy of the table, insert in a new db, add your extra column
> and adapt the module parameters.
>
> wkr,
>
> Op do 11 jun. 2020 om 12:18 schreef Mark Farmer <farmorg at gmail.com>:
>
>> Hi everyone
>>
>> I have a couple of extra fields in my acc database table which is
>> added by acc_extra. This causes issues when upgrading.
>> I would prefer to have that data stored in a different database/table.
>>
>> Is there a nice way to do that?
>> OpenSIPS 3.0 in this case.
>>
>> Many thanks
>> Mark.
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/be5274aa/attachment.html>

From david.villasmil.work at gmail.com  Thu Jun 11 10:55:52 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 11 Jun 2020 11:55:52 +0100
Subject: [OpenSIPS-Users] Write acc_extra data to separate table
In-Reply-To: <CAOvQDevNeyPyJUJoX7gz+6XR+DN2vcFBkqZgQ4oNu1deqZvEqw@mail.gmail.com>
References: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>
 <CAEVWGm-QkyuzRfCdqCDtdirHq5n3qzbetMGeakYDvHd4HEyPOg@mail.gmail.com>
 <CAOvQDevNeyPyJUJoX7gz+6XR+DN2vcFBkqZgQ4oNu1deqZvEqw@mail.gmail.com>
Message-ID: <CAFGRPVqTRg6HwoVsjVwDX2M8jv+0jcfo8QZhn6rNaHkXkDWVyA@mail.gmail.com>

You’re going to need to use sqlops for that, I think.

On Thu, 11 Jun 2020 at 11:39, Mark Farmer <farmorg at gmail.com> wrote:

> Thanks for the reply Johan, I'm not sure that's quite what I'm looking for.
> I'd like the usual acc data to be written to the normal acc table but my
> extra data written to a different table, preferably in a different database.
>
> Many thanks
> Mark.
>
>
> On Thu, 11 Jun 2020 at 11:32, Johan De Clercq <Johan at democon.be> wrote:
>
>> If I am not wrong, you can specify the accounting table and db in the
>> module params.
>> Hence make a copy of the table, insert in a new db, add your extra column
>> and adapt the module parameters.
>>
>> wkr,
>>
>> Op do 11 jun. 2020 om 12:18 schreef Mark Farmer <farmorg at gmail.com>:
>>
>>> Hi everyone
>>>
>>> I have a couple of extra fields in my acc database table which is
>>> added by acc_extra. This causes issues when upgrading.
>>> I would prefer to have that data stored in a different database/table.
>>>
>>> Is there a nice way to do that?
>>> OpenSIPS 3.0 in this case.
>>>
>>> Many thanks
>>> Mark.
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> Mark Farmer
> farmorg at gmail.com
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/1457d922/attachment.html>

From farmorg at gmail.com  Thu Jun 11 11:07:12 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Thu, 11 Jun 2020 12:07:12 +0100
Subject: [OpenSIPS-Users] Write acc_extra data to separate table
In-Reply-To: <CAFGRPVqTRg6HwoVsjVwDX2M8jv+0jcfo8QZhn6rNaHkXkDWVyA@mail.gmail.com>
References: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>
 <CAEVWGm-QkyuzRfCdqCDtdirHq5n3qzbetMGeakYDvHd4HEyPOg@mail.gmail.com>
 <CAOvQDevNeyPyJUJoX7gz+6XR+DN2vcFBkqZgQ4oNu1deqZvEqw@mail.gmail.com>
 <CAFGRPVqTRg6HwoVsjVwDX2M8jv+0jcfo8QZhn6rNaHkXkDWVyA@mail.gmail.com>
Message-ID: <CAOvQDetjdDhpJL8CdRRS7VVVx5hON4Gc_v38=j6YrjSERV40KQ@mail.gmail.com>

Hmm... Doesn't seem to exist in OpenSIPS.

How do others do this kind of thing?



On Thu, 11 Jun 2020 at 11:58, David Villasmil <
david.villasmil.work at gmail.com> wrote:

> You’re going to need to use sqlops for that, I think.
>
> On Thu, 11 Jun 2020 at 11:39, Mark Farmer <farmorg at gmail.com> wrote:
>
>> Thanks for the reply Johan, I'm not sure that's quite what I'm looking
>> for.
>> I'd like the usual acc data to be written to the normal acc table but my
>> extra data written to a different table, preferably in a different database.
>>
>> Many thanks
>> Mark.
>>
>>
>> On Thu, 11 Jun 2020 at 11:32, Johan De Clercq <Johan at democon.be> wrote:
>>
>>> If I am not wrong, you can specify the accounting table and db in the
>>> module params.
>>> Hence make a copy of the table, insert in a new db, add your extra
>>> column and adapt the module parameters.
>>>
>>> wkr,
>>>
>>> Op do 11 jun. 2020 om 12:18 schreef Mark Farmer <farmorg at gmail.com>:
>>>
>>>> Hi everyone
>>>>
>>>> I have a couple of extra fields in my acc database table which is
>>>> added by acc_extra. This causes issues when upgrading.
>>>> I would prefer to have that data stored in a different database/table.
>>>>
>>>> Is there a nice way to do that?
>>>> OpenSIPS 3.0 in this case.
>>>>
>>>> Many thanks
>>>> Mark.
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>> Mark Farmer
>> farmorg at gmail.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.work at gmail.com
> phone: +34669448337
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/d820e12f/attachment-0001.html>

From razvan at opensips.org  Thu Jun 11 11:14:24 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Thu, 11 Jun 2020 14:14:24 +0300
Subject: [OpenSIPS-Users] [BLOG] New Call API tool has been released
Message-ID: <956925fd-2917-2c5f-32dc-906a3b115e55@opensips.org>

Hi, everyone!

We have just released the first version of the new Call API tool[1].
This tool can be used to manage calls through an API. You can find out 
more information about what it can do and how it works in the blog post 
I've just published[2].
So please give it a try, and make sure to send us your feedback about it!

[1] https://github.com/OpenSIPS/call-api
[2] 
https://blog.opensips.org/2020/06/11/calls-management-using-the-new-call-api-tool/

Happy hacking!

-- 
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com


From rrevels at bandwidth.com  Thu Jun 11 13:15:42 2020
From: rrevels at bandwidth.com (Richard Revels)
Date: Thu, 11 Jun 2020 09:15:42 -0400
Subject: [OpenSIPS-Users] avp_insert
Message-ID: <CAE-NtRc9K-t8+G1H5_zAa2R5q31mB7ibSL1pknQz2_Jydd=NUA@mail.gmail.com>

I feel like this function would be a lot more useful if the last argument
would accept a variable rather than a static int.

https://opensips.org/html/docs/modules/2.1.x/avpops.html#idp5679392

Richard Revels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/b1deb2d7/attachment.html>

From bogdan at opensips.org  Thu Jun 11 14:33:05 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 11 Jun 2020 17:33:05 +0300
Subject: [OpenSIPS-Users] avp_insert
In-Reply-To: <CAE-NtRc9K-t8+G1H5_zAa2R5q31mB7ibSL1pknQz2_Jydd=NUA@mail.gmail.com>
References: <CAE-NtRc9K-t8+G1H5_zAa2R5q31mB7ibSL1pknQz2_Jydd=NUA@mail.gmail.com>
Message-ID: <6e6fa63b-a2ae-aaf9-4f25-84005090181a@opensips.org>

Hey Richard,

Agreed, but nothing we can do about 2.1 - it is old and unmaintained.

Starting 3.0, the all the script functions accept parameters via variables.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/11/20 4:15 PM, Richard Revels wrote:
> I feel like this function would be a lot more useful if the last 
> argument would accept a variable rather than a static int.
>
> https://opensips.org/html/docs/modules/2.1.x/avpops.html#idp5679392
>
> Richard Revels
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/78d3d1a5/attachment.html>

From david.villasmil.work at gmail.com  Thu Jun 11 14:48:20 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 11 Jun 2020 15:48:20 +0100
Subject: [OpenSIPS-Users] Write acc_extra data to separate table
In-Reply-To: <CAOvQDetjdDhpJL8CdRRS7VVVx5hON4Gc_v38=j6YrjSERV40KQ@mail.gmail.com>
References: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>
 <CAEVWGm-QkyuzRfCdqCDtdirHq5n3qzbetMGeakYDvHd4HEyPOg@mail.gmail.com>
 <CAOvQDevNeyPyJUJoX7gz+6XR+DN2vcFBkqZgQ4oNu1deqZvEqw@mail.gmail.com>
 <CAFGRPVqTRg6HwoVsjVwDX2M8jv+0jcfo8QZhn6rNaHkXkDWVyA@mail.gmail.com>
 <CAOvQDetjdDhpJL8CdRRS7VVVx5hON4Gc_v38=j6YrjSERV40KQ@mail.gmail.com>
Message-ID: <CAFGRPVqi52iKz9j47ZDGUr_zOOKZEFJ-DkwwG4Ld_kNNLNmodQ@mail.gmail.com>

You could use
https://opensips.org/html/docs/modules/1.7.x/avpops.html#id293960
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337


On Thu, Jun 11, 2020 at 12:07 PM Mark Farmer <farmorg at gmail.com> wrote:

> Hmm... Doesn't seem to exist in OpenSIPS.
>
> How do others do this kind of thing?
>
>
>
> On Thu, 11 Jun 2020 at 11:58, David Villasmil <
> david.villasmil.work at gmail.com> wrote:
>
>> You’re going to need to use sqlops for that, I think.
>>
>> On Thu, 11 Jun 2020 at 11:39, Mark Farmer <farmorg at gmail.com> wrote:
>>
>>> Thanks for the reply Johan, I'm not sure that's quite what I'm looking
>>> for.
>>> I'd like the usual acc data to be written to the normal acc table but my
>>> extra data written to a different table, preferably in a different database.
>>>
>>> Many thanks
>>> Mark.
>>>
>>>
>>> On Thu, 11 Jun 2020 at 11:32, Johan De Clercq <Johan at democon.be> wrote:
>>>
>>>> If I am not wrong, you can specify the accounting table and db in the
>>>> module params.
>>>> Hence make a copy of the table, insert in a new db, add your extra
>>>> column and adapt the module parameters.
>>>>
>>>> wkr,
>>>>
>>>> Op do 11 jun. 2020 om 12:18 schreef Mark Farmer <farmorg at gmail.com>:
>>>>
>>>>> Hi everyone
>>>>>
>>>>> I have a couple of extra fields in my acc database table which is
>>>>> added by acc_extra. This causes issues when upgrading.
>>>>> I would prefer to have that data stored in a different database/table.
>>>>>
>>>>> Is there a nice way to do that?
>>>>> OpenSIPS 3.0 in this case.
>>>>>
>>>>> Many thanks
>>>>> Mark.
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>>
>>> --
>>> Mark Farmer
>>> farmorg at gmail.com
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> --
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.work at gmail.com
>> phone: +34669448337
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> Mark Farmer
> farmorg at gmail.com
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/5b160fd6/attachment.html>

From bogdan at opensips.org  Thu Jun 11 14:48:40 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 11 Jun 2020 17:48:40 +0300
Subject: [OpenSIPS-Users] Write acc_extra data to separate table
In-Reply-To: <CAOvQDevNeyPyJUJoX7gz+6XR+DN2vcFBkqZgQ4oNu1deqZvEqw@mail.gmail.com>
References: <CAOvQDeu12StZVWn-=sYNbXf69zKXhePXkx1nW63g5RjDO2Gyow@mail.gmail.com>
 <CAEVWGm-QkyuzRfCdqCDtdirHq5n3qzbetMGeakYDvHd4HEyPOg@mail.gmail.com>
 <CAOvQDevNeyPyJUJoX7gz+6XR+DN2vcFBkqZgQ4oNu1deqZvEqw@mail.gmail.com>
Message-ID: <7b64bfda-832d-bc13-6052-5315639e3722@opensips.org>

Hi Mark,

If you want to have full control over the DB usage for the ACC data, I 
would suggest to use the event_route module to capture the ACC_CDR event 
(produced by the acc module) - this event will expose all the acc data 
(extra + legs). In the event route you use the avp_db_query() function 
(from the avpops) module to place the acc fields in whatever tables / DB 
you want.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/11/20 1:38 PM, Mark Farmer wrote:
> Thanks for the reply Johan, I'm not sure that's quite what I'm looking 
> for.
> I'd like the usual acc data to be written to the normal acc table but 
> my extra data written to a different table, preferably in a different 
> database.
>
> Many thanks
> Mark.
>
>
> On Thu, 11 Jun 2020 at 11:32, Johan De Clercq <Johan at democon.be 
> <mailto:Johan at democon.be>> wrote:
>
>     If I am not wrong, you can specify the accounting table and db in
>     the module params.
>     Hence make a copy of the table, insert in a new db, add your extra
>     column and adapt the module parameters.
>
>     wkr,
>
>     Op do 11 jun. 2020 om 12:18 schreef Mark Farmer <farmorg at gmail.com
>     <mailto:farmorg at gmail.com>>:
>
>         Hi everyone
>
>         I have a couple of extra fields in my acc database table which
>         is added by acc_extra. This causes issues when upgrading.
>         I would prefer to have that data stored in a different
>         database/table.
>
>         Is there a nice way to do that?
>         OpenSIPS 3.0 in this case.
>
>         Many thanks
>         Mark.
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> -- 
> Mark Farmer
> farmorg at gmail.com <mailto:farmorg at gmail.com>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/d2a9bbe6/attachment-0001.html>

From rrevels at bandwidth.com  Thu Jun 11 15:45:29 2020
From: rrevels at bandwidth.com (Richard Revels)
Date: Thu, 11 Jun 2020 11:45:29 -0400
Subject: [OpenSIPS-Users] avp_insert
In-Reply-To: <6e6fa63b-a2ae-aaf9-4f25-84005090181a@opensips.org>
References: <CAE-NtRc9K-t8+G1H5_zAa2R5q31mB7ibSL1pknQz2_Jydd=NUA@mail.gmail.com>
 <6e6fa63b-a2ae-aaf9-4f25-84005090181a@opensips.org>
Message-ID: <CAE-NtRdopBtpsvfouQrzLFgcw7cscGtbTbnUw=vQUUB+neHayQ@mail.gmail.com>

Ah.  I should have paid more attention.  I meant to paste the link for the
2.4 Docs.

However, your point is well taken.  I need to spend more time getting more
current rather than working in older versions.

Richard



On Thu, Jun 11, 2020 at 10:33 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hey Richard,
>
> Agreed, but nothing we can do about 2.1 - it is old and unmaintained.
>
> Starting 3.0, the all the script functions accept parameters via variables.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>
> On 6/11/20 4:15 PM, Richard Revels wrote:
>
> I feel like this function would be a lot more useful if the last argument
> would accept a variable rather than a static int.
>
> https://opensips.org/html/docs/modules/2.1.x/avpops.html#idp5679392
>
> Richard Revels
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/67c4ee6c/attachment.html>

From diptesh.patel at ecosmob.com  Thu Jun 11 19:13:02 2020
From: diptesh.patel at ecosmob.com (Diptesh Patel)
Date: Fri, 12 Jun 2020 00:43:02 +0530
Subject: [OpenSIPS-Users] adding and reading a SIP header to a 302
	Redirect
In-Reply-To: <CAC9cSOBdN7fyRPJM2UZRNtBi_Y0Du8M1tFbN30HubqVF_s95ng@mail.gmail.com>
References: <CAC9cSOBdN7fyRPJM2UZRNtBi_Y0Du8M1tFbN30HubqVF_s95ng@mail.gmail.com>
Message-ID: <CAD4_Da3mKa2Se9GeCX2+DTTNuOXFJ99Z_q==yaEojzNzUzniZA@mail.gmail.com>

Hello,

The next destination(s) should be decided based on Contact Header(s) of 3xx
Responses. You can configure one or more destinations based on priority and
fail-over enabled to multiple destinations. But in your case I found,
Contact Header is malformed i.e. *Contact: <sip:16317918378>. *

Thanks & Regards
*Diptesh Patel*
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:*+919898962659*


On Sat, May 30, 2020 at 5:47 PM Saint Michael <venefax at gmail.com> wrote:

> I need to add a new SIP header to the response below.
>
>
> if ($rm=="INVITE") {
>     /* add the redirect destinations as branches */
>     $branch = "sip:batman at gotham.com";
>     $branch = $avp(my_custom_uri);
>     /* sending a 3xx reply will automatically push all
>      * existing branches as Contact URIs */
>     send_reply("302","Moved Temporarily");
>     exit;
> }
> the final result should be:
>
> SIP/2.0 302 Moved Temporarily
> Via: SIP/2.0/UDP 172.16.7.254:52169
> ;rport=52169;received=47.205.172.89;branch=z9hG4bK-524287-1---129f4244aaba9f04
> Call-ID: 102650Mzg4NmFiNTQzOGY5NDJmNjM3OTYzNmE5MzNlZDIwZmI
> From: "XXXXX" <sip:XXX4433019 at XXX.124.224.87>;tag=81a25c36
> To: <sip:16317918378 at XXX
> .124.224.87>;tag=9e198dc4-7ce8-433d-ae23-05b9bc14d55a
>
> Identity:eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyI2MzE3OTE4Mzc4Il19LCJpYXQiOjE1OTA4MTEyMzgsIm9yaWciOnsidG4iOiI3Mjc0NDMzMDE5In0sIm9yaWdpZCI6IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9.AKViDWA3uonP6tt5cKBh0FUPY5zBuJnwZLQNTrp9LCWJ-vLY1Xx5i3_oXGh1ERL4tnD-KK5wsP3FdByDa_cjGw;info=<
> https://cert.example.org/passport.cer>;alg=ES256;ppt=shaken
> CSeq: 1 INVITE
> Server: Asterisk PBX 16.10.0
> Contact: <sip:16317918378>
> Reason: Q.850;cause=0
> Content-Length:  0
>
> also if I get that packet at my end, how do I extract the Identity header
> and apply it to the next INVITE?
> Is this even doable?
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/217f1f31/attachment.html>

From goup2010 at gmail.com  Thu Jun 11 20:35:42 2020
From: goup2010 at gmail.com (Dragomir Haralambiev)
Date: Thu, 11 Jun 2020 23:35:42 +0300
Subject: [OpenSIPS-Users] install RTPEngine on Centos 8
In-Reply-To: <CA+x3AxoshYvGEigoVkcSDmkn_wj=LLGqXBaa_Nnnjosspy6v9g@mail.gmail.com>
References: <CADzurOJNYvQ=A1KzLfNu2bU3M8k4VbiEzYKMAHhXRd_ea8xLig@mail.gmail.com>
 <CA+x3AxoshYvGEigoVkcSDmkn_wj=LLGqXBaa_Nnnjosspy6v9g@mail.gmail.com>
Message-ID: <CADzurOJnb2DcJ9cg1Baa9TueKNE8WBgoQ9dMe=K9tWLGUycCow@mail.gmail.com>

Hello,

Thanks for your reply.
I try to instal RTPEngine but receive follow errors:
# dnf install ngcp-rtpengine
Last metadata expiration check: 0:28:59 ago on Thu 11 Jun 2020 10:33:39 PM
EEST.
Error:
Problem: conflicting requests
- nothing provides libavcodec.so.58()(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libavcodec.so.58(LIBAVCODEC_58)(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libavfilter.so.7()(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libavformat.so.58()(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libavformat.so.58(LIBAVFORMAT_58)(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libavutil.so.56()(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libavutil.so.56(LIBAVUTIL_56)(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libswresample.so.3()(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides libswresample.so.3(LIBSWRESAMPLE_3)(64bit) needed by
ngcp-rtpengine-8.4.1.1-1.el8.x86_64
- nothing provides ffmpeg-libs needed by ngcp-rtpengine-8.4.1.1-1.el8.x86_64

What I do to install this package?

На чт, 4.06.2020 г. в 15:35 Denys Pozniak <denys.pozniak at gmail.com> написа:

> Hello!
> Try to use my build (not tested, as is):
> https://copr.fedorainfracloud.org/coprs/denysp/rtpengine-centos8/
>
>
> чт, 4 июн. 2020 г. в 12:20, Dragomir Haralambiev <goup2010 at gmail.com>:
>
>> Hello,
>>
>> I need to  install RTPEngine on Centos 8?
>> Any help
>>
>> Best regards,
>> Dragomir
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
>
> BR,
> Denys Pozniak
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200611/36b801c8/attachment.html>

From abalashov at evaristesys.com  Thu Jun 11 22:57:59 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Thu, 11 Jun 2020 18:57:59 -0400
Subject: [OpenSIPS-Users] install RTPEngine on Centos 8
In-Reply-To: <CADzurOJnb2DcJ9cg1Baa9TueKNE8WBgoQ9dMe=K9tWLGUycCow@mail.gmail.com>
References: <CADzurOJNYvQ=A1KzLfNu2bU3M8k4VbiEzYKMAHhXRd_ea8xLig@mail.gmail.com>
 <CA+x3AxoshYvGEigoVkcSDmkn_wj=LLGqXBaa_Nnnjosspy6v9g@mail.gmail.com>
 <CADzurOJnb2DcJ9cg1Baa9TueKNE8WBgoQ9dMe=K9tWLGUycCow@mail.gmail.com>
Message-ID: <917b4b5f-1296-5364-f919-77d641df80f5@evaristesys.com>

You may consider building from source. It's actually quite easy and 
avoids this kind of pain.

On 6/11/20 4:35 PM, Dragomir Haralambiev wrote:
> Hello,
> 
> Thanks for your reply.
> I try to instal RTPEngine but receive follow errors:
> # dnf install ngcp-rtpengine
> Last metadata expiration check: 0:28:59 ago on Thu 11 Jun 2020 10:33:39 
> PM EEST.
> Error:
> Problem: conflicting requests
> - nothing provides libavcodec.so.58()(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavcodec.so.58(LIBAVCODEC_58)(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavfilter.so.7()(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavformat.so.58()(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavformat.so.58(LIBAVFORMAT_58)(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavutil.so.56()(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavutil.so.56(LIBAVUTIL_56)(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libswresample.so.3()(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libswresample.so.3(LIBSWRESAMPLE_3)(64bit) needed by 
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides ffmpeg-libs needed by ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> 
> What I do to install this package?
> 
> На чт, 4.06.2020 г. в 15:35 Denys Pozniak <denys.pozniak at gmail.com 
> <mailto:denys.pozniak at gmail.com>> написа:
> 
>     Hello!
>     Try to use my build (not tested, as is):
>     https://copr.fedorainfracloud.org/coprs/denysp/rtpengine-centos8/
> 
> 
>     чт, 4 июн. 2020 г. в 12:20, Dragomir Haralambiev <goup2010 at gmail.com
>     <mailto:goup2010 at gmail.com>>:
> 
>         Hello,
> 
>         I need to  install RTPEngine on Centos 8?
>         Any help
> 
>         Best regards,
>         Dragomir
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> 
>     -- 
> 
>     BR,
>     Denys Pozniak
> 
> 
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From denys.pozniak at gmail.com  Fri Jun 12 08:56:12 2020
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Fri, 12 Jun 2020 11:56:12 +0300
Subject: [OpenSIPS-Users] install RTPEngine on Centos 8
In-Reply-To: <CADzurOJnb2DcJ9cg1Baa9TueKNE8WBgoQ9dMe=K9tWLGUycCow@mail.gmail.com>
References: <CADzurOJNYvQ=A1KzLfNu2bU3M8k4VbiEzYKMAHhXRd_ea8xLig@mail.gmail.com>
 <CA+x3AxoshYvGEigoVkcSDmkn_wj=LLGqXBaa_Nnnjosspy6v9g@mail.gmail.com>
 <CADzurOJnb2DcJ9cg1Baa9TueKNE8WBgoQ9dMe=K9tWLGUycCow@mail.gmail.com>
Message-ID: <CA+x3AxpmW4o-2DFn7HhUFHY_+t+3uLzuJip7BqkxJb5zqggACw@mail.gmail.com>

Hello,

Did you add external repos (rpmfusion and epel)?
https://rpmfusion.org/Configuration/

[root at localhost ~]# rpm -qa | grep rtpengine
ngcp-rtpengine-kernel-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-debugsource-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-debuginfo-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-recording-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-recording-debuginfo-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-dkms-8.4.1.1-2.el8.noarch
ngcp-rtpengine-kernel-debuginfo-8.4.1.1-2.el8.x86_64

[root at localhost ~]# cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)


чт, 11 июн. 2020 г. в 23:38, Dragomir Haralambiev <goup2010 at gmail.com>:

> Hello,
>
> Thanks for your reply.
> I try to instal RTPEngine but receive follow errors:
> # dnf install ngcp-rtpengine
> Last metadata expiration check: 0:28:59 ago on Thu 11 Jun 2020 10:33:39 PM
> EEST.
> Error:
> Problem: conflicting requests
> - nothing provides libavcodec.so.58()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavcodec.so.58(LIBAVCODEC_58)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavfilter.so.7()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavformat.so.58()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavformat.so.58(LIBAVFORMAT_58)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavutil.so.56()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavutil.so.56(LIBAVUTIL_56)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libswresample.so.3()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libswresample.so.3(LIBSWRESAMPLE_3)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides ffmpeg-libs needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
>
> What I do to install this package?
>
> На чт, 4.06.2020 г. в 15:35 Denys Pozniak <denys.pozniak at gmail.com>
> написа:
>
>> Hello!
>> Try to use my build (not tested, as is):
>> https://copr.fedorainfracloud.org/coprs/denysp/rtpengine-centos8/
>>
>>
>> чт, 4 июн. 2020 г. в 12:20, Dragomir Haralambiev <goup2010 at gmail.com>:
>>
>>> Hello,
>>>
>>> I need to  install RTPEngine on Centos 8?
>>> Any help
>>>
>>> Best regards,
>>> Dragomir
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>>
>> BR,
>> Denys Pozniak
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

BR,
Denys Pozniak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/99e0023d/attachment.html>

From bogdan at opensips.org  Fri Jun 12 10:39:06 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 12 Jun 2020 13:39:06 +0300
Subject: [OpenSIPS-Users] adding and reading a SIP header to a 302
 Redirect
In-Reply-To: <CAC9cSOBdN7fyRPJM2UZRNtBi_Y0Du8M1tFbN30HubqVF_s95ng@mail.gmail.com>
References: <CAC9cSOBdN7fyRPJM2UZRNtBi_Y0Du8M1tFbN30HubqVF_s95ng@mail.gmail.com>
Message-ID: <3f9d3283-29f6-f880-5456-7afe150ebf9a@opensips.org>

Take a look at the append_to_reply() [1] function.

[1] 
https://opensips.org/docs/modules/3.1.x/sipmsgops.html#func_append_to_reply

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 5/30/20 3:14 PM, Saint Michael wrote:
> I need to add a new SIP header to the response below.
>
>
> if ($rm=="INVITE") {
>     /* add the redirect destinations as branches */
>     $branch = "sip:batman at gotham.com <mailto:sip%3Abatman at gotham.com>";
>     $branch = $avp(my_custom_uri);
>     /* sending a 3xx reply will automatically push all
>      * existing branches as Contact URIs */
>     send_reply("302","Moved Temporarily");
>     exit;
> }
> the final result should be:
>
> SIP/2.0 302 Moved Temporarily
> Via: SIP/2.0/UDP 
> 172.16.7.254:52169;rport=52169;received=47.205.172.89;branch=z9hG4bK-524287-1---129f4244aaba9f04
> Call-ID: 102650Mzg4NmFiNTQzOGY5NDJmNjM3OTYzNmE5MzNlZDIwZmI
> From: "XXXXX" <sip:XXX4433019 at XXX.124.224.87>;tag=81a25c36
> To: 
> <sip:16317918378 at XXX.124.224.87>;tag=9e198dc4-7ce8-433d-ae23-05b9bc14d55a
> Identity:eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyI2MzE3OTE4Mzc4Il19LCJpYXQiOjE1OTA4MTEyMzgsIm9yaWciOnsidG4iOiI3Mjc0NDMzMDE5In0sIm9yaWdpZCI6IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9.AKViDWA3uonP6tt5cKBh0FUPY5zBuJnwZLQNTrp9LCWJ-vLY1Xx5i3_oXGh1ERL4tnD-KK5wsP3FdByDa_cjGw;info=<https://cert.example.org/passport.cer>;alg=ES256;ppt=shaken
> CSeq: 1 INVITE
> Server: Asterisk PBX 16.10.0
> Contact: <sip:16317918378>
> Reason: Q.850;cause=0
> Content-Length:  0
>
> also if I get that packet at my end, how do I extract the Identity 
> header and apply it to the next INVITE?
> Is this even doable?
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/1538870f/attachment.html>

From farmorg at gmail.com  Fri Jun 12 12:10:54 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Fri, 12 Jun 2020 13:10:54 +0100
Subject: [OpenSIPS-Users] opensips-cli error
In-Reply-To: <435e0899-730c-c50c-fc7c-b158062090a2@opensips.org>
References: <CAOvQDevj57DyEarOSqWffBVM6_K7MxwbKgB6GtduKZ-X9C9uhQ@mail.gmail.com>
 <cb4dcc94-9f80-cdd0-2b49-9712159a8ef7@opensips.org>
 <CAOvQDeu8_-ieXMUEgAonCcXVVexM8PGG9FEjVLKq6BamGuwNOw@mail.gmail.com>
 <6d2ecaf8-1b99-f17c-8f79-f3be657f7ae8@opensips.org>
 <CAOvQDeuyJbdjtq2veXc9wMuKf=rKHU=_VzL=xd2-X6e6bqw1rw@mail.gmail.com>
 <1f7cfe38-a9b0-0979-4563-7577bba79488@opensips.org>
 <CAOvQDes4Uv_ut_c4EONsopx8g0Hcstxoe2UvpupOPkfn5SfybA@mail.gmail.com>
 <01740933-476f-253f-8855-52ea26a3302a@opensips.org>
 <CAOvQDet5H9EBNFEtA=Y6pqAokpHNHP=+=pXQ5wkbjAn4=km_JQ@mail.gmail.com>
 <a7f045f4-00fb-45d9-937f-ad5ea325aaba@opensips.org>
 <CAOvQDev-MVSzXVyeKy4ruB-ZfAuCea_OELJs277PcP26JvCEYg@mail.gmail.com>
 <593aba4f-2ba8-be49-295a-994efbff7400@opensips.org>
 <CAOvQDetusMTcQYbpw6=Cpb1k+ZhhivurdOPjfDRT-C9HNORsOg@mail.gmail.com>
 <CAOvQDevtVK6ORSyrMRoLn1tMQ2Q4RMkz22D2FdNtZBuHB6QhAw@mail.gmail.com>
 <faa4a8fc-b97e-c1c7-e078-fb157cd55587@opensips.org>
 <CAOvQDese5ohNuFp3XoS4SRxQthoPv-h-m3V=1c6Q=bx5OWtsjA@mail.gmail.com>
 <435e0899-730c-c50c-fc7c-b158062090a2@opensips.org>
Message-ID: <CAOvQDesTj==wRS3fGDK-43u+csCDwrodQWxLNLpfVw5SVGXS3Q@mail.gmail.com>

This one has reared it's head again today. I did a fresh install on 2 boxes
but I forgot to make sure the deps were installed one of them.
Now when I try to run opensips-cli I get the error again. The other box
with the deps preinstalled is fine. I've tried reinstalling opensips-cli
several times but no luck.

This is the install log & error:

/usr/local/src/opensips-cli# python3 setup.py install clean
/usr/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution
option: 'long_description_content_type'
  warnings.warn(msg)
running install
running bdist_egg
running egg_info
creating opensipscli.egg-info
writing opensipscli.egg-info/PKG-INFO
writing dependency_links to opensipscli.egg-info/dependency_links.txt
writing requirements to opensipscli.egg-info/requires.txt
writing top-level names to opensipscli.egg-info/top_level.txt
writing manifest file 'opensipscli.egg-info/SOURCES.txt'
reading manifest file 'opensipscli.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching 'MANIFEST'
writing manifest file 'opensipscli.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build
creating build/lib
creating build/lib/opensipscli
copying opensipscli/__init__.py -> build/lib/opensipscli
copying opensipscli/main.py -> build/lib/opensipscli
copying opensipscli/comm.py -> build/lib/opensipscli
copying opensipscli/db.py -> build/lib/opensipscli
copying opensipscli/cli.py -> build/lib/opensipscli
copying opensipscli/module.py -> build/lib/opensipscli
copying opensipscli/config.py -> build/lib/opensipscli
copying opensipscli/logger.py -> build/lib/opensipscli
copying opensipscli/defaults.py -> build/lib/opensipscli
creating build/lib/opensipscli/modules
copying opensipscli/modules/__init__.py -> build/lib/opensipscli/modules
copying opensipscli/modules/tls.py -> build/lib/opensipscli/modules
copying opensipscli/modules/diagnose.py -> build/lib/opensipscli/modules
copying opensipscli/modules/trap.py -> build/lib/opensipscli/modules
copying opensipscli/modules/instance.py -> build/lib/opensipscli/modules
copying opensipscli/modules/user.py -> build/lib/opensipscli/modules
copying opensipscli/modules/mi.py -> build/lib/opensipscli/modules
copying opensipscli/modules/trace.py -> build/lib/opensipscli/modules
copying opensipscli/modules/database.py -> build/lib/opensipscli/modules
creating build/lib/opensipscli/communication
copying opensipscli/communication/__init__.py ->
build/lib/opensipscli/communication
copying opensipscli/communication/http.py ->
build/lib/opensipscli/communication
copying opensipscli/communication/fifo.py ->
build/lib/opensipscli/communication
copying opensipscli/communication/jsonrpc_helper.py ->
build/lib/opensipscli/communication
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/egg
creating build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/__init__.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/main.py ->
build/bdist.linux-x86_64/egg/opensipscli
creating build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/__init__.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/tls.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/diagnose.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/trap.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/instance.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/user.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/mi.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/trace.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/database.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/comm.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/db.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/cli.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/module.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/config.py ->
build/bdist.linux-x86_64/egg/opensipscli
creating build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/__init__.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/http.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/fifo.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/jsonrpc_helper.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/logger.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/defaults.py ->
build/bdist.linux-x86_64/egg/opensipscli
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/__init__.py to
__init__.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/main.py to
main.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/__init__.py
to __init__.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/tls.py to
tls.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/diagnose.py
to diagnose.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/trap.py to
trap.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/instance.py
to instance.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/user.py to
user.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/mi.py to
mi.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/trace.py to
trace.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/modules/database.py
to database.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/comm.py to
comm.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/db.py to
db.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/cli.py to
cli.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/module.py to
module.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/config.py to
config.cpython-36.pyc
byte-compiling
build/bdist.linux-x86_64/egg/opensipscli/communication/__init__.py to
__init__.cpython-36.pyc
byte-compiling
build/bdist.linux-x86_64/egg/opensipscli/communication/http.py to
http.cpython-36.pyc
byte-compiling
build/bdist.linux-x86_64/egg/opensipscli/communication/fifo.py to
fifo.cpython-36.pyc
byte-compiling
build/bdist.linux-x86_64/egg/opensipscli/communication/jsonrpc_helper.py to
jsonrpc_helper.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/logger.py to
logger.cpython-36.pyc
byte-compiling build/bdist.linux-x86_64/egg/opensipscli/defaults.py to
defaults.cpython-36.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
installing scripts to build/bdist.linux-x86_64/egg/EGG-INFO/scripts
running install_scripts
running build_scripts
creating build/scripts-3.6
copying and adjusting bin/opensips-cli -> build/scripts-3.6
changing mode of build/scripts-3.6/opensips-cli from 644 to 755
creating build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-3.6/opensips-cli ->
build/bdist.linux-x86_64/egg/EGG-INFO/scripts
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/opensips-cli
to 755
copying opensipscli.egg-info/PKG-INFO ->
build/bdist.linux-x86_64/egg/EGG-INFO
copying opensipscli.egg-info/SOURCES.txt ->
build/bdist.linux-x86_64/egg/EGG-INFO
copying opensipscli.egg-info/dependency_links.txt ->
build/bdist.linux-x86_64/egg/EGG-INFO
copying opensipscli.egg-info/requires.txt ->
build/bdist.linux-x86_64/egg/EGG-INFO
copying opensipscli.egg-info/top_level.txt ->
build/bdist.linux-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
opensipscli.modules.__pycache__.__init__.cpython-36: module references
__path__
creating dist
creating 'dist/opensipscli-0.1.0-py3.6.egg' and adding
'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing opensipscli-0.1.0-py3.6.egg
removing
'/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg' (and
everything under it)
creating /usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg
Extracting opensipscli-0.1.0-py3.6.egg to
/usr/local/lib/python3.6/dist-packages
opensipscli 0.1.0 is already the active version in easy-install.pth
Installing opensips-cli script to /usr/local/bin

Installed /usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg
Processing dependencies for opensipscli==0.1.0
Searching for SQLAlchemy==1.3.3
Best match: SQLAlchemy 1.3.3
Processing SQLAlchemy-1.3.3-py3.6-linux-x86_64.egg
SQLAlchemy 1.3.3 is already the active version in easy-install.pth

Using
/usr/local/lib/python3.6/dist-packages/SQLAlchemy-1.3.3-py3.6-linux-x86_64.egg
Searching for SQLAlchemy-Utils==0.36.6
Best match: SQLAlchemy-Utils 0.36.6
Adding SQLAlchemy-Utils 0.36.6 to easy-install.pth file

Using /usr/local/lib/python3.6/dist-packages
Searching for mysqlclient==1.3.14
Best match: mysqlclient 1.3.14
Processing mysqlclient-1.3.14-py3.6-linux-x86_64.egg
mysqlclient 1.3.14 is already the active version in easy-install.pth

Using
/usr/local/lib/python3.6/dist-packages/mysqlclient-1.3.14-py3.6-linux-x86_64.egg
Searching for six==1.11.0
Best match: six 1.11.0
Adding six 1.11.0 to easy-install.pth file

Using /usr/lib/python3/dist-packages
Finished processing dependencies for opensipscli==0.1.0
running clean
removed './build/lib/opensipscli/__init__.py'
removed './build/lib/opensipscli/main.py'
removed './build/lib/opensipscli/modules/__init__.py'
removed './build/lib/opensipscli/modules/tls.py'
removed './build/lib/opensipscli/modules/diagnose.py'
removed './build/lib/opensipscli/modules/trap.py'
removed './build/lib/opensipscli/modules/instance.py'
removed './build/lib/opensipscli/modules/user.py'
removed './build/lib/opensipscli/modules/mi.py'
removed './build/lib/opensipscli/modules/trace.py'
removed './build/lib/opensipscli/modules/database.py'
removed directory './build/lib/opensipscli/modules'
removed './build/lib/opensipscli/comm.py'
removed './build/lib/opensipscli/db.py'
removed './build/lib/opensipscli/cli.py'
removed './build/lib/opensipscli/module.py'
removed './build/lib/opensipscli/config.py'
removed './build/lib/opensipscli/communication/__init__.py'
removed './build/lib/opensipscli/communication/http.py'
removed './build/lib/opensipscli/communication/fifo.py'
removed './build/lib/opensipscli/communication/jsonrpc_helper.py'
removed directory './build/lib/opensipscli/communication'
removed './build/lib/opensipscli/logger.py'
removed './build/lib/opensipscli/defaults.py'
removed directory './build/lib/opensipscli'
removed directory './build/lib'
removed './build/scripts-3.6/opensips-cli'
removed directory './build/scripts-3.6'
removed directory './build/bdist.linux-x86_64'
removed directory './build'
removed './dist/opensipscli-0.1.0-py3.6.egg'
removed directory './dist'
removed './opensipscli.egg-info/top_level.txt'
removed './opensipscli.egg-info/PKG-INFO'
removed './opensipscli.egg-info/requires.txt'
removed './opensipscli.egg-info/SOURCES.txt'
removed './opensipscli.egg-info/dependency_links.txt'
removed directory './opensipscli.egg-info'
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli#
root at sbc-pstn-els-1:/usr/local/src/opensips-cli# opensips-cli
Traceback (most recent call last):
  File "/usr/local/bin/opensips-cli", line 4, in <module>
    __import__('pkg_resources').run_script('opensipscli==0.1.0',
'opensips-cli')
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
658, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1429, in run_script
    .format(**locals()),
pkg_resources.ResolutionError: Script 'scripts/opensips-cli' not found in
metadata at None

As before I can run it OK from the source dir:

python3 bin/opensips-cli

Beyond that I'm rather stuck. Any ideas?

Many thanks
Mark.


On Tue, 21 May 2019 at 16:30, Liviu Chircu <liviu at opensips.org> wrote:

> And this is now fixed as well in the latest version.  The new install
> best practice is:
>
> sudo python3 setup.py install clean
>
> Soon enough, this job will be taken over by some nice opensips-cli
> package... *drool*
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
> On 21.05.2019 17:53, Mark Farmer wrote:
> > Great thanks. I can confirm that removing the opensipscli.egg-info
> > directory fixes the issue here also.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/be268982/attachment-0001.html>

From liviu at opensips.org  Fri Jun 12 12:13:49 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 12 Jun 2020 15:13:49 +0300
Subject: [OpenSIPS-Users] opensips-cli error
In-Reply-To: <CAOvQDesTj==wRS3fGDK-43u+csCDwrodQWxLNLpfVw5SVGXS3Q@mail.gmail.com>
References: <CAOvQDevj57DyEarOSqWffBVM6_K7MxwbKgB6GtduKZ-X9C9uhQ@mail.gmail.com>
 <6d2ecaf8-1b99-f17c-8f79-f3be657f7ae8@opensips.org>
 <CAOvQDeuyJbdjtq2veXc9wMuKf=rKHU=_VzL=xd2-X6e6bqw1rw@mail.gmail.com>
 <1f7cfe38-a9b0-0979-4563-7577bba79488@opensips.org>
 <CAOvQDes4Uv_ut_c4EONsopx8g0Hcstxoe2UvpupOPkfn5SfybA@mail.gmail.com>
 <01740933-476f-253f-8855-52ea26a3302a@opensips.org>
 <CAOvQDet5H9EBNFEtA=Y6pqAokpHNHP=+=pXQ5wkbjAn4=km_JQ@mail.gmail.com>
 <a7f045f4-00fb-45d9-937f-ad5ea325aaba@opensips.org>
 <CAOvQDev-MVSzXVyeKy4ruB-ZfAuCea_OELJs277PcP26JvCEYg@mail.gmail.com>
 <593aba4f-2ba8-be49-295a-994efbff7400@opensips.org>
 <CAOvQDetusMTcQYbpw6=Cpb1k+ZhhivurdOPjfDRT-C9HNORsOg@mail.gmail.com>
 <CAOvQDevtVK6ORSyrMRoLn1tMQ2Q4RMkz22D2FdNtZBuHB6QhAw@mail.gmail.com>
 <faa4a8fc-b97e-c1c7-e078-fb157cd55587@opensips.org>
 <CAOvQDese5ohNuFp3XoS4SRxQthoPv-h-m3V=1c6Q=bx5OWtsjA@mail.gmail.com>
 <435e0899-730c-c50c-fc7c-b158062090a2@opensips.org>
 <CAOvQDesTj==wRS3fGDK-43u+csCDwrodQWxLNLpfVw5SVGXS3Q@mail.gmail.com>
Message-ID: <fb1a5da9-b121-feb7-764a-336de93ef215@opensips.org>

On 12.06.2020 15:10, Mark Farmer wrote:
> root at sbc-pstn-els-1:/usr/local/src/opensips-cli# opensips-cli
> Traceback (most recent call last):
>   File "/usr/local/bin/opensips-cli", line 4, in <module>
> __import__('pkg_resources').run_script('opensipscli==0.1.0', 
> 'opensips-cli')
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", 
> line 658, in run_script
>     self.require(requires)[0].run_script(script_name, ns)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", 
> line 1429, in run_script
>     .format(**locals()),
> pkg_resources.ResolutionError: Script 'scripts/opensips-cli' not found 
> in metadata at None
>
> As before I can run it OK from the source dir:
>
> python3 bin/opensips-cli
>
> Beyond that I'm rather stuck. Any ideas?

Hi, Mark!

Can you please do:

sudo updatedb
locate opensipscli

... and provide the output?  I suspect there are some lingering 
directories under "/usr/local/lib/python..." which we must "rm -fr", 
then the install will be clean.

Regards,

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com



From farmorg at gmail.com  Fri Jun 12 12:28:32 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Fri, 12 Jun 2020 13:28:32 +0100
Subject: [OpenSIPS-Users] opensips-cli error
In-Reply-To: <fb1a5da9-b121-feb7-764a-336de93ef215@opensips.org>
References: <CAOvQDevj57DyEarOSqWffBVM6_K7MxwbKgB6GtduKZ-X9C9uhQ@mail.gmail.com>
 <6d2ecaf8-1b99-f17c-8f79-f3be657f7ae8@opensips.org>
 <CAOvQDeuyJbdjtq2veXc9wMuKf=rKHU=_VzL=xd2-X6e6bqw1rw@mail.gmail.com>
 <1f7cfe38-a9b0-0979-4563-7577bba79488@opensips.org>
 <CAOvQDes4Uv_ut_c4EONsopx8g0Hcstxoe2UvpupOPkfn5SfybA@mail.gmail.com>
 <01740933-476f-253f-8855-52ea26a3302a@opensips.org>
 <CAOvQDet5H9EBNFEtA=Y6pqAokpHNHP=+=pXQ5wkbjAn4=km_JQ@mail.gmail.com>
 <a7f045f4-00fb-45d9-937f-ad5ea325aaba@opensips.org>
 <CAOvQDev-MVSzXVyeKy4ruB-ZfAuCea_OELJs277PcP26JvCEYg@mail.gmail.com>
 <593aba4f-2ba8-be49-295a-994efbff7400@opensips.org>
 <CAOvQDetusMTcQYbpw6=Cpb1k+ZhhivurdOPjfDRT-C9HNORsOg@mail.gmail.com>
 <CAOvQDevtVK6ORSyrMRoLn1tMQ2Q4RMkz22D2FdNtZBuHB6QhAw@mail.gmail.com>
 <faa4a8fc-b97e-c1c7-e078-fb157cd55587@opensips.org>
 <CAOvQDese5ohNuFp3XoS4SRxQthoPv-h-m3V=1c6Q=bx5OWtsjA@mail.gmail.com>
 <435e0899-730c-c50c-fc7c-b158062090a2@opensips.org>
 <CAOvQDesTj==wRS3fGDK-43u+csCDwrodQWxLNLpfVw5SVGXS3Q@mail.gmail.com>
 <fb1a5da9-b121-feb7-764a-336de93ef215@opensips.org>
Message-ID: <CAOvQDes1HDJ-U7SnKEb5xhWxXA0FZ5ocwpdU1PGPCqNhjcjR+w@mail.gmail.com>

Hi Liviu, as requested:

locate opensipscli
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0.egg-info
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/PKG-INFO
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/SOURCES.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/dependency_links.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/not-zip-safe
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/requires.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/scripts
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/top_level.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/scripts/opensips-cli
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__init__.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/cli.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/comm.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/config.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/db.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/defaults.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/logger.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/main.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/module.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/__init__.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/cli.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/comm.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/config.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/db.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/defaults.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/logger.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/main.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/module.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__init__.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/fifo.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/http.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/jsonrpc_helper.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/__init__.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/fifo.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/http.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/jsonrpc_helper.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__init__.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/database.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/diagnose.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/instance.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/mi.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/tls.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/trace.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/trap.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/user.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/__init__.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/database.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/diagnose.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/instance.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/mi.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/tls.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/trace.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/trap.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__/user.cpython-36.pyc
/usr/local/src/opensips-cli/opensipscli
/usr/local/src/opensips-cli/opensipscli/__init__.py
/usr/local/src/opensips-cli/opensipscli/__pycache__
/usr/local/src/opensips-cli/opensipscli/cli.py
/usr/local/src/opensips-cli/opensipscli/comm.py
/usr/local/src/opensips-cli/opensipscli/communication
/usr/local/src/opensips-cli/opensipscli/config.py
/usr/local/src/opensips-cli/opensipscli/db.py
/usr/local/src/opensips-cli/opensipscli/defaults.py
/usr/local/src/opensips-cli/opensipscli/logger.py
/usr/local/src/opensips-cli/opensipscli/main.py
/usr/local/src/opensips-cli/opensipscli/module.py
/usr/local/src/opensips-cli/opensipscli/modules
/usr/local/src/opensips-cli/opensipscli/__pycache__/__init__.cpython-36.pyc
/usr/local/src/opensips-cli/opensipscli/__pycache__/defaults.cpython-36.pyc
/usr/local/src/opensips-cli/opensipscli/communication/__init__.py
/usr/local/src/opensips-cli/opensipscli/communication/fifo.py
/usr/local/src/opensips-cli/opensipscli/communication/http.py
/usr/local/src/opensips-cli/opensipscli/communication/jsonrpc_helper.py
/usr/local/src/opensips-cli/opensipscli/modules/__init__.py
/usr/local/src/opensips-cli/opensipscli/modules/database.py
/usr/local/src/opensips-cli/opensipscli/modules/diagnose.py
/usr/local/src/opensips-cli/opensipscli/modules/instance.py
/usr/local/src/opensips-cli/opensipscli/modules/mi.py
/usr/local/src/opensips-cli/opensipscli/modules/tls.py
/usr/local/src/opensips-cli/opensipscli/modules/trace.py
/usr/local/src/opensips-cli/opensipscli/modules/trap.py
/usr/local/src/opensips-cli/opensipscli/modules/user.py



On Fri, 12 Jun 2020 at 13:15, Liviu Chircu <liviu at opensips.org> wrote:

> On 12.06.2020 15:10, Mark Farmer wrote:
> > root at sbc-pstn-els-1:/usr/local/src/opensips-cli# opensips-cli
> > Traceback (most recent call last):
> >   File "/usr/local/bin/opensips-cli", line 4, in <module>
> > __import__('pkg_resources').run_script('opensipscli==0.1.0',
> > 'opensips-cli')
> >   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> > line 658, in run_script
> >     self.require(requires)[0].run_script(script_name, ns)
> >   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> > line 1429, in run_script
> >     .format(**locals()),
> > pkg_resources.ResolutionError: Script 'scripts/opensips-cli' not found
> > in metadata at None
> >
> > As before I can run it OK from the source dir:
> >
> > python3 bin/opensips-cli
> >
> > Beyond that I'm rather stuck. Any ideas?
>
> Hi, Mark!
>
> Can you please do:
>
> sudo updatedb
> locate opensipscli
>
> ... and provide the output?  I suspect there are some lingering
> directories under "/usr/local/lib/python..." which we must "rm -fr",
> then the install will be clean.
>
> Regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/96d4d906/attachment-0001.html>

From liviu at opensips.org  Fri Jun 12 12:35:28 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 12 Jun 2020 15:35:28 +0300
Subject: [OpenSIPS-Users] opensips-cli error
In-Reply-To: <CAOvQDes1HDJ-U7SnKEb5xhWxXA0FZ5ocwpdU1PGPCqNhjcjR+w@mail.gmail.com>
References: <CAOvQDevj57DyEarOSqWffBVM6_K7MxwbKgB6GtduKZ-X9C9uhQ@mail.gmail.com>
 <1f7cfe38-a9b0-0979-4563-7577bba79488@opensips.org>
 <CAOvQDes4Uv_ut_c4EONsopx8g0Hcstxoe2UvpupOPkfn5SfybA@mail.gmail.com>
 <01740933-476f-253f-8855-52ea26a3302a@opensips.org>
 <CAOvQDet5H9EBNFEtA=Y6pqAokpHNHP=+=pXQ5wkbjAn4=km_JQ@mail.gmail.com>
 <a7f045f4-00fb-45d9-937f-ad5ea325aaba@opensips.org>
 <CAOvQDev-MVSzXVyeKy4ruB-ZfAuCea_OELJs277PcP26JvCEYg@mail.gmail.com>
 <593aba4f-2ba8-be49-295a-994efbff7400@opensips.org>
 <CAOvQDetusMTcQYbpw6=Cpb1k+ZhhivurdOPjfDRT-C9HNORsOg@mail.gmail.com>
 <CAOvQDevtVK6ORSyrMRoLn1tMQ2Q4RMkz22D2FdNtZBuHB6QhAw@mail.gmail.com>
 <faa4a8fc-b97e-c1c7-e078-fb157cd55587@opensips.org>
 <CAOvQDese5ohNuFp3XoS4SRxQthoPv-h-m3V=1c6Q=bx5OWtsjA@mail.gmail.com>
 <435e0899-730c-c50c-fc7c-b158062090a2@opensips.org>
 <CAOvQDesTj==wRS3fGDK-43u+csCDwrodQWxLNLpfVw5SVGXS3Q@mail.gmail.com>
 <fb1a5da9-b121-feb7-764a-336de93ef215@opensips.org>
 <CAOvQDes1HDJ-U7SnKEb5xhWxXA0FZ5ocwpdU1PGPCqNhjcjR+w@mail.gmail.com>
Message-ID: <ba17b48c-1a23-cc3b-7b3b-ad30a1ea4b70@opensips.org>

On 12.06.2020 15:28, Mark Farmer wrote:
> locate opensipscli
> /usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO

OK, so let's clear the install and redo it:

sudo rm -fr /usr/local/lib/python3.6/dist-packages/opensipscli*

cd /usr/local/src/opensips-cli

git pull --rebase

sudo python3 setup.py install clean

cd # go back to home dir

opensips-cli

Hopefully, the last command should work!  Curious to see if it works on 
your system as well, as it often solves this problem for me (although I 
still don't quite understand what I'm doing...)

PS: you don't have to do this on every "git pull --rebase".  Just when 
it "breaks"...

Regards,

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com



From farmorg at gmail.com  Fri Jun 12 13:12:31 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Fri, 12 Jun 2020 14:12:31 +0100
Subject: [OpenSIPS-Users] opensips-cli error
In-Reply-To: <ba17b48c-1a23-cc3b-7b3b-ad30a1ea4b70@opensips.org>
References: <CAOvQDevj57DyEarOSqWffBVM6_K7MxwbKgB6GtduKZ-X9C9uhQ@mail.gmail.com>
 <1f7cfe38-a9b0-0979-4563-7577bba79488@opensips.org>
 <CAOvQDes4Uv_ut_c4EONsopx8g0Hcstxoe2UvpupOPkfn5SfybA@mail.gmail.com>
 <01740933-476f-253f-8855-52ea26a3302a@opensips.org>
 <CAOvQDet5H9EBNFEtA=Y6pqAokpHNHP=+=pXQ5wkbjAn4=km_JQ@mail.gmail.com>
 <a7f045f4-00fb-45d9-937f-ad5ea325aaba@opensips.org>
 <CAOvQDev-MVSzXVyeKy4ruB-ZfAuCea_OELJs277PcP26JvCEYg@mail.gmail.com>
 <593aba4f-2ba8-be49-295a-994efbff7400@opensips.org>
 <CAOvQDetusMTcQYbpw6=Cpb1k+ZhhivurdOPjfDRT-C9HNORsOg@mail.gmail.com>
 <CAOvQDevtVK6ORSyrMRoLn1tMQ2Q4RMkz22D2FdNtZBuHB6QhAw@mail.gmail.com>
 <faa4a8fc-b97e-c1c7-e078-fb157cd55587@opensips.org>
 <CAOvQDese5ohNuFp3XoS4SRxQthoPv-h-m3V=1c6Q=bx5OWtsjA@mail.gmail.com>
 <435e0899-730c-c50c-fc7c-b158062090a2@opensips.org>
 <CAOvQDesTj==wRS3fGDK-43u+csCDwrodQWxLNLpfVw5SVGXS3Q@mail.gmail.com>
 <fb1a5da9-b121-feb7-764a-336de93ef215@opensips.org>
 <CAOvQDes1HDJ-U7SnKEb5xhWxXA0FZ5ocwpdU1PGPCqNhjcjR+w@mail.gmail.com>
 <ba17b48c-1a23-cc3b-7b3b-ad30a1ea4b70@opensips.org>
Message-ID: <CAOvQDevXysBTa8wn5jROhcF3y+qpHgDJxGOzTk3LqVTizhGOZw@mail.gmail.com>

That got it Liviu :)

Thank you!
Mark.


On Fri, 12 Jun 2020 at 13:37, Liviu Chircu <liviu at opensips.org> wrote:

> On 12.06.2020 15:28, Mark Farmer wrote:
> > locate opensipscli
> >
> /usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO
>
> OK, so let's clear the install and redo it:
>
> sudo rm -fr /usr/local/lib/python3.6/dist-packages/opensipscli*
>
> cd /usr/local/src/opensips-cli
>
> git pull --rebase
>
> sudo python3 setup.py install clean
>
> cd # go back to home dir
>
> opensips-cli
>
> Hopefully, the last command should work!  Curious to see if it works on
> your system as well, as it often solves this problem for me (although I
> still don't quite understand what I'm doing...)
>
> PS: you don't have to do this on every "git pull --rebase".  Just when
> it "breaks"...
>
> Regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/8266d764/attachment.html>

From mrsanvicente at gmail.com  Fri Jun 12 18:48:23 2020
From: mrsanvicente at gmail.com (Mario San Vicente)
Date: Fri, 12 Jun 2020 13:48:23 -0500
Subject: [OpenSIPS-Users] opensipsctl fifo dlg_list not working on 3.1
Message-ID: <CA+B81WLxgkD9qj9e_Xv0O69rBkaHp8u8X9KQu6MyWq52EVxdwA@mail.gmail.com>

Hello Everybody!,

I have been using "opensipsctl fifo dlg_list" on opensips 2.4 to count the
active calls and it works fine.  Now that i have migrated to 3.1, the call
flow is working fine,  but the same command is not working, after typing
the command it just hang out.

I get the following error on the logs :

localhost /usr/local/sbin/opensips[25782]: ERROR:mi_fifo:mi_fifo_server:
cannot parse command: osips_rply_7bcc7ad0

[root at localhost opensips]# opensips -V
version: opensips 3.1.0-beta (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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: 5fb9059
main.c compiled on 13:01:28 Jun 12 2020 with gcc 4.8.5


Can you confirm if this is a bug?  Do you need any other information?

Thanks





-- 
Mario San Vicente
Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/90273c84/attachment.html>

From bogdan at opensips.org  Fri Jun 12 21:22:23 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Sat, 13 Jun 2020 00:22:23 +0300
Subject: [OpenSIPS-Users] opensipsctl fifo dlg_list not working on 3.1
In-Reply-To: <CA+B81WLxgkD9qj9e_Xv0O69rBkaHp8u8X9KQu6MyWq52EVxdwA@mail.gmail.com>
References: <CA+B81WLxgkD9qj9e_Xv0O69rBkaHp8u8X9KQu6MyWq52EVxdwA@mail.gmail.com>
Message-ID: <97cd6182-9caa-106a-bca3-d1a33ac54e28@opensips.org>

Hey MArio,

Starting 3.0 the MI interface changed as syntax and the opensipsctl was 
deprecated in favour of the opensips-cli
     https://github.com/OpenSIPS/opensips-cli

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/12/20 9:48 PM, Mario San Vicente wrote:
> Hello Everybody!,
>
> I have been using "opensipsctl fifo dlg_list" on opensips 2.4 to count 
> the active calls and it works fine.  Now that i have migrated to 3.1, 
> the call flow is working fine,  but the same command is not working, 
> after typing the command it just hang out.
>
> I get the following error on the logs :
>
> localhost /usr/local/sbin/opensips[25782]: 
> ERROR:mi_fifo:mi_fifo_server: cannot parse command: osips_rply_7bcc7ad0
>
> [root at localhost opensips]# opensips -V
> version: opensips 3.1.0-beta (x86_64/linux)
> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, 
> Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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: 5fb9059
> main.c compiled on 13:01:28 Jun 12 2020 with gcc 4.8.5
>
>
> Can you confirm if this is a bug?  Do you need any other information?
>
> Thanks
>
>
>
>
>
> -- 
> Mario San Vicente
> Cheers!
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200613/6d689ab6/attachment.html>

From mrsanvicente at gmail.com  Fri Jun 12 21:53:49 2020
From: mrsanvicente at gmail.com (mrsanvicente)
Date: Fri, 12 Jun 2020 16:53:49 -0500
Subject: [OpenSIPS-Users] opensipsctl fifo dlg_list not working on 3.1
In-Reply-To: <97cd6182-9caa-106a-bca3-d1a33ac54e28@opensips.org>
References: <97cd6182-9caa-106a-bca3-d1a33ac54e28@opensips.org>
Message-ID: <B6727134-16E0-4F4D-AA08-E0FDAFC9347A@gmail.com>

Ohh!   Thank  you Bogdan.

Mario San Vicente
Best regards

> El 12 jun 2020, a la(s) 16:22, Bogdan-Andrei Iancu <bogdan at opensips.org> escribió:
> 
>  Hey MArio,
> 
> Starting 3.0 the MI interface changed as syntax and the opensipsctl was deprecated in favour of the opensips-cli
>     https://github.com/OpenSIPS/opensips-cli
> 
> Regards,
>  Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> 
> On 6/12/20 9:48 PM, Mario San Vicente wrote:
>> Hello Everybody!,
>> 
>> I have been using "opensipsctl fifo dlg_list" on opensips 2.4 to count the active calls and it works fine.  Now that i have migrated to 3.1, the call flow is working fine,  but the same command is not working, after typing the command it just hang out.
>> 
>> I get the following error on the logs :
>> 
>> localhost /usr/local/sbin/opensips[25782]: ERROR:mi_fifo:mi_fifo_server: cannot parse command: osips_rply_7bcc7ad0
>> 
>> [root at localhost opensips]# opensips -V
>> version: opensips 3.1.0-beta (x86_64/linux)
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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: 5fb9059
>> main.c compiled on 13:01:28 Jun 12 2020 with gcc 4.8.5
>> 
>> 
>> Can you confirm if this is a bug?  Do you need any other information?
>> 
>> Thanks
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Mario San Vicente
>> Cheers!
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/4151844e/attachment.html>

From calvin.ellison at voxox.com  Fri Jun 12 22:02:41 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Fri, 12 Jun 2020 15:02:41 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
Message-ID: <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>

 I noticed a way-too-small receive buffer value in the OpenSIPS startup
messages and it turns out that a fresh Ubuntu 18 Server install has
absolutely terrible sysctl defaults for high-performance networking. I got
my 8-core lab from less than 2,000 CPS up to 14,000 CPS using a spread of
all dips in non-async mode just by setting the following to match
"maxbuffer=16777216":

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Does OpenSIPS have guidelines for sysclt and other OS parameters?

Async requires the TM module which adds additional overhead and memory
> allocation.


According to with the docs:
"By requiring less processes to complete the same amount of work in the
same amount of time, process context switching is minimized and
overall CPU usage is improved. Less processes will also eat up less
system memory."

So which is it? When should async be used, and when should async not be
used? One can only invest so many hours in load testing combinations of
sync/async, the number of children, timer_partitions, etc. Some fuzzy math
based on CPU core count, SpecInt Rate, BogoMIPS, etc. would be a great
starting point.

Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.ellison at voxox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/0817e482/attachment-0001.html>

From abalashov at evaristesys.com  Fri Jun 12 22:50:28 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 12 Jun 2020 18:50:28 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
Message-ID: <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>

There's no free lunch, but it seems like you and others want one. :-) 
Increasing these values just increases the depth of the kernel's packet 
queue for the sync processes to consume as able. It doesn't mean they're 
able, and accordingly, request response time will go up.

A healthy system that is able to keep up with the load you're throwing 
at it should show a receive queue at +/- 0 most of the time, maybe with 
some ephemeral spikes but generally trending around 0. If packets are 
stacking up in the RecvQ, it means the SIP worker processes aren't 
available enough to consume them all in a timely fashion.

Leaning on async won't help here if the workload is largely CPU-bound. 
If it's largely bound over waiting on network I/O from external 
services, it merely deputises the problem of notifying you when there's 
a response from those services to the kernel. But - vitally - it won't 
get your requests processed faster, and setup latency is a very 
important consideration in real-time communications, especially from the 
perspective of interoperability with the synchronous/circuit-switched PSTN.

In short, async isn't magic, and neither is increasing the receive 
queue. It's simple thermodynamics; there's only so much CPU available, 
and depending on the nature of the workload, throughput becomes more a 
linear function of available CPU hardware threads, or less, but slower, 
if it's largely I/O-bound.

The metaphor of a balloon is appropriate. You're pushing the problem 
around by squeezing one part of the balloon, causing another to enlarge. 
Various parts of the balloon can be squeezed - async vs. sync, various 
queues and buffers, etc. But the internal volume of air held by the 
balloon is more or less the same. A little slack can be added into the 
system through your rmem_max technique, as long as you're willing to 
tolerate increased processing latency--and it will generate increased 
latency; if it didn't, you wouldn't need to increase it--but ultimately, 
you're just pushing the air around the balloon. A fixed amount of CPU 
and memory is available to accommodate the large number of processes 
that sleep on an external I/O-bound workload, and there are diminishing 
returns from both internal OpenSIPS contention and context switching.

I'm not saying there aren't some local minima and maxima, but they 
aren't as magnitudinal as folks think. It's not that Ubuntu Server is 
mistuned, it's that you're abusing it. :-) You can't put the milk back 
in the cow, although it's quite a spectacle ...

-- Alex

On 6/12/20 6:02 PM, Calvin Ellison wrote:
> I noticed a way-too-small receive buffer value in the OpenSIPS startup 
> messages and it turns out that a fresh Ubuntu 18 Server install has 
> absolutely terrible sysctl defaults for high-performance networking. I 
> got my 8-core lab from less than 2,000 CPS up to 14,000 CPS using a 
> spread of all dips in non-async mode just by setting the following to 
> match "maxbuffer=16777216":
> 
> net.core.rmem_max = 16777216
> net.core.wmem_max = 16777216
> 
> Does OpenSIPS have guidelines for sysclt and other OS parameters?
> 
>     Async requires the TM module which adds additional overhead and
>     memory allocation.
> 
> 
> According to with the docs:
> "By requiring less processes to complete the same amount of work in the
> same amount of time, process context switching is minimized and
> overall CPU usage is improved. Less processes will also eat up less
> system memory."
> 
> So which is it? When should async be used, and when should async not be 
> used? One can only invest so many hours in load testing combinations of 
> sync/async, the number of children, timer_partitions, etc. Some fuzzy 
> math based on CPU core count, SpecInt Rate, BogoMIPS, etc. would be a 
> great starting point.
> 
> Regards,
> 
> *Calvin Ellison*
> Senior Voice Operations Engineer
> calvin.ellison at voxox.com <mailto:calvin.ellison at voxox.com>
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From abalashov at evaristesys.com  Fri Jun 12 23:02:10 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 12 Jun 2020 19:02:10 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
Message-ID: <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>

Perhaps a simpler way look at it: buffers. It's in the name - they 
buffer things.

If your "work queue" buffer (which is what the packet RecvQ 
fundamentally is) is chronically full, to the degree that it needs 
increased significantly, it means things aren't consistently leaving out 
at the other end at the same velocity that they're coming in.

In small amounts, this regulating capacity is acceptable and 
necessary--that's why buffers exist.

But increasing the depth of the queue by 78x (if I'm not mistaken, 
212992 is the default--at least, it is on all my CentOS 7.x and 8.x 
systems, which I guess also have "absolutely terrible sysctl defaults") 
is faker than a Ponzi scheme. In some other contexts, this would be 
called morally bankrupt and intellectually fraudulent. I guess here we 
call it "mad dialer CPS" or whatever.

-- Alex

On 6/12/20 6:50 PM, Alex Balashov wrote:
> There's no free lunch, but it seems like you and others want one. :-) 
> Increasing these values just increases the depth of the kernel's packet 
> queue for the sync processes to consume as able. It doesn't mean they're 
> able, and accordingly, request response time will go up.
> 
> A healthy system that is able to keep up with the load you're throwing 
> at it should show a receive queue at +/- 0 most of the time, maybe with 
> some ephemeral spikes but generally trending around 0. If packets are 
> stacking up in the RecvQ, it means the SIP worker processes aren't 
> available enough to consume them all in a timely fashion.
> 
> Leaning on async won't help here if the workload is largely CPU-bound. 
> If it's largely bound over waiting on network I/O from external 
> services, it merely deputises the problem of notifying you when there's 
> a response from those services to the kernel. But - vitally - it won't 
> get your requests processed faster, and setup latency is a very 
> important consideration in real-time communications, especially from the 
> perspective of interoperability with the synchronous/circuit-switched PSTN.
> 
> In short, async isn't magic, and neither is increasing the receive 
> queue. It's simple thermodynamics; there's only so much CPU available, 
> and depending on the nature of the workload, throughput becomes more a 
> linear function of available CPU hardware threads, or less, but slower, 
> if it's largely I/O-bound.
> 
> The metaphor of a balloon is appropriate. You're pushing the problem 
> around by squeezing one part of the balloon, causing another to enlarge. 
> Various parts of the balloon can be squeezed - async vs. sync, various 
> queues and buffers, etc. But the internal volume of air held by the 
> balloon is more or less the same. A little slack can be added into the 
> system through your rmem_max technique, as long as you're willing to 
> tolerate increased processing latency--and it will generate increased 
> latency; if it didn't, you wouldn't need to increase it--but ultimately, 
> you're just pushing the air around the balloon. A fixed amount of CPU 
> and memory is available to accommodate the large number of processes 
> that sleep on an external I/O-bound workload, and there are diminishing 
> returns from both internal OpenSIPS contention and context switching.
> 
> I'm not saying there aren't some local minima and maxima, but they 
> aren't as magnitudinal as folks think. It's not that Ubuntu Server is 
> mistuned, it's that you're abusing it. :-) You can't put the milk back 
> in the cow, although it's quite a spectacle ...
> 
> -- Alex
> 
> On 6/12/20 6:02 PM, Calvin Ellison wrote:
>> I noticed a way-too-small receive buffer value in the OpenSIPS startup 
>> messages and it turns out that a fresh Ubuntu 18 Server install has 
>> absolutely terrible sysctl defaults for high-performance networking. I 
>> got my 8-core lab from less than 2,000 CPS up to 14,000 CPS using a 
>> spread of all dips in non-async mode just by setting the following to 
>> match "maxbuffer=16777216":
>>
>> net.core.rmem_max = 16777216
>> net.core.wmem_max = 16777216
>>
>> Does OpenSIPS have guidelines for sysclt and other OS parameters?
>>
>>     Async requires the TM module which adds additional overhead and
>>     memory allocation.
>>
>>
>> According to with the docs:
>> "By requiring less processes to complete the same amount of work in the
>> same amount of time, process context switching is minimized and
>> overall CPU usage is improved. Less processes will also eat up less
>> system memory."
>>
>> So which is it? When should async be used, and when should async not 
>> be used? One can only invest so many hours in load testing 
>> combinations of sync/async, the number of children, timer_partitions, 
>> etc. Some fuzzy math based on CPU core count, SpecInt Rate, BogoMIPS, 
>> etc. would be a great starting point.
>>
>> Regards,
>>
>> *Calvin Ellison*
>> Senior Voice Operations Engineer
>> calvin.ellison at voxox.com <mailto:calvin.ellison at voxox.com>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From calvin.ellison at voxox.com  Fri Jun 12 23:08:07 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Fri, 12 Jun 2020 16:08:07 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
Message-ID: <CAL+QDG_4h=iwo-5qp5Ynf16xRrTkgCwNgCVqcytzcEBYhJ0OSA@mail.gmail.com>

I don't disagree that there is a physical limit to what any hardware can
achieve. However, there was a dramatic difference between the default
setting and the increased setting. I have no explanation for this, as I am
not a kernel or network developer.  I'm happy to run the load test again
both ways and see if there was any difference in response times.


On Fri, Jun 12, 2020 at 3:51 PM Alex Balashov <abalashov at evaristesys.com>
wrote:

> There's no free lunch, but it seems like you and others want one. :-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/71527e9a/attachment.html>

From abalashov at evaristesys.com  Fri Jun 12 23:13:41 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 12 Jun 2020 19:13:41 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG_4h=iwo-5qp5Ynf16xRrTkgCwNgCVqcytzcEBYhJ0OSA@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <CAL+QDG_4h=iwo-5qp5Ynf16xRrTkgCwNgCVqcytzcEBYhJ0OSA@mail.gmail.com>
Message-ID: <7c16612f-4cc6-bdff-a450-403b07cde968@evaristesys.com>

On 6/12/20 7:08 PM, Calvin Ellison wrote:

> I don't disagree that there is a physical limit to what any hardware can 
> achieve. However, there was a dramatic difference between the default 
> setting and the increased setting.
I do: the default setting leaves packets beyond the depth of the queue 
dropped, which, in the case of SIP requests and some responses, causes 
them to be retransmitted, which creates a positive feedback loop. 
Letting them stack up allows more of them to be attended to eventually, 
reducing that dynamic.

But telling the OS network stack to hold more packets because you can't 
process them fast enough isn't a solution to the problem of not 
processing them fast enough. You're infinitely better off just 
processing them faster.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From calvin.ellison at voxox.com  Fri Jun 12 23:20:30 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Fri, 12 Jun 2020 16:20:30 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
Message-ID: <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>

I think the important point here is that the receive buffers are used to
hold received data until it is read by the application. In fact, too small
of a receive buffer would cause packets to be discarded outright,
regardless of how fast the application can respond. Not knowing how large
of a buffer is needed was the problem, not the raw processing power. It
doesn't matter how fast I can eat if the server only has very small plates
to bring the food every trip from the kitchen.


On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov <abalashov at evaristesys.com>
wrote:

> Perhaps a simpler way look at it: buffers. It's in the name - they
> buffer things.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/30b20b9f/attachment-0001.html>

From abalashov at evaristesys.com  Fri Jun 12 23:28:14 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 12 Jun 2020 19:28:14 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
Message-ID: <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>

On 6/12/20 7:20 PM, Calvin Ellison wrote:

> I think the important point here is that the receive buffers are used to 
> hold received data until it is read by the application. In fact, too 
> small of a receive buffer would cause packets to be discarded outright, 
> regardless of how fast the application can respond. Not knowing how 
> large of a buffer is needed was the problem, not the raw processing 
> power. It doesn't matter how fast I can eat if the server only has very 
> small plates to bring the food every trip from the kitchen.

In absolute terms, this is true. But if your kitchen is putting out so 
much food that not even ~200,000 plates "in flight" will do, you've got 
a bigger problem to address and adding more plates is just papering it 
over.

Monitor your receive queue scrupulously at a very high timing 
resolution. If you found default values for rmem_max to be "absolutely 
terrible", that means the backlog was increasing monotonically until you 
ran out of space. If you increase the queue depth, you will be able to 
prolong this effect for a while.

The kernel's packet queue is a backstop--an emergency release valve, not 
a main thoroughfare. It's there to help you deal with ephemeral 
congestion caused by things like periodic big-lock background process 
contention, scheduler hiccups, disk controller patrol reads, etc.  But 
the base load should result in a long-run queue backlog of zero. 
Applications which properly cope with their workload don't cause 
non-trivial packet or connection queueing on the OS side.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From david.villasmil.work at gmail.com  Fri Jun 12 23:35:09 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Sat, 13 Jun 2020 00:35:09 +0100
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
 <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
Message-ID: <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>

Basically, the application is not processing the received packets as
quickly as it should, so the kernel stores the packets in the buffer so it
doesn’t have to throw them away.

It’s not so difficult to understand. If this is happening all the time, you
won’t solve this by making the buffer bigger. You solve this by figuring
out why the application is not processing the packets fast enough.


On Sat, 13 Jun 2020 at 00:28, Alex Balashov <abalashov at evaristesys.com>
wrote:

> On 6/12/20 7:20 PM, Calvin Ellison wrote:
>
> > I think the important point here is that the receive buffers are used to
> > hold received data until it is read by the application. In fact, too
> > small of a receive buffer would cause packets to be discarded outright,
> > regardless of how fast the application can respond. Not knowing how
> > large of a buffer is needed was the problem, not the raw processing
> > power. It doesn't matter how fast I can eat if the server only has very
> > small plates to bring the food every trip from the kitchen.
>
> In absolute terms, this is true. But if your kitchen is putting out so
> much food that not even ~200,000 plates "in flight" will do, you've got
> a bigger problem to address and adding more plates is just papering it
> over.
>
> Monitor your receive queue scrupulously at a very high timing
> resolution. If you found default values for rmem_max to be "absolutely
> terrible", that means the backlog was increasing monotonically until you
> ran out of space. If you increase the queue depth, you will be able to
> prolong this effect for a while.
>
> The kernel's packet queue is a backstop--an emergency release valve, not
> a main thoroughfare. It's there to help you deal with ephemeral
> congestion caused by things like periodic big-lock background process
> contention, scheduler hiccups, disk controller patrol reads, etc.  But
> the base load should result in a long-run queue backlog of zero.
> Applications which properly cope with their workload don't cause
> non-trivial packet or connection queueing on the OS side.
>
> -- Alex
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200613/a767c952/attachment.html>

From calvin.ellison at voxox.com  Fri Jun 12 23:38:24 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Fri, 12 Jun 2020 16:38:24 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
Message-ID: <CAL+QDG_p3dooJ2uqq9irVMA1dqjUn3xVp+Pt-zr-5LZhsR6d8w@mail.gmail.com>

I doubt the system will be using all of that buffer. I also don't know if
the issue was in the receive buffer or send buffer since I changed both at
once. Many resources are available online from people who have already done
much more scientific testing that indicate the default values should be
increased for certain applications, which is the reason I changed it to
begin with. There's no one-size-fits all for server configurations, and
what works for this UDP application with a small number of clients might
not work well for a different application with many TCS connections.

"absolutely terrible" may be too strong of a way to put it, but that the
before and after don't lie.

On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov <abalashov at evaristesys.com>
wrote:

> But increasing the depth of the queue by 78x (if I'm not mistaken,
> 212992 is the default--at least, it is on all my CentOS 7.x and 8.x
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/e2b4604e/attachment.html>

From david.villasmil.work at gmail.com  Fri Jun 12 23:49:41 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Sat, 13 Jun 2020 00:49:41 +0100
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG_p3dooJ2uqq9irVMA1dqjUn3xVp+Pt-zr-5LZhsR6d8w@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG_p3dooJ2uqq9irVMA1dqjUn3xVp+Pt-zr-5LZhsR6d8w@mail.gmail.com>
Message-ID: <CAFGRPVrs65fNgp+2WEKZmo37ACo04AqFQs9-E19kGfr19hTHbQ@mail.gmail.com>

Keep in mundo the don’t make Ubuntu for SIP applications, which have their
own idiosyncrasies. They make it general purpose. So finding a value that
doesn’t work perfectly with what you need for this very specific
application, is not a big deal.

On Sat, 13 Jun 2020 at 00:38, Calvin Ellison <calvin.ellison at voxox.com>
wrote:

> I doubt the system will be using all of that buffer. I also don't know if
> the issue was in the receive buffer or send buffer since I changed both at
> once. Many resources are available online from people who have already done
> much more scientific testing that indicate the default values should be
> increased for certain applications, which is the reason I changed it to
> begin with. There's no one-size-fits all for server configurations, and
> what works for this UDP application with a small number of clients might
> not work well for a different application with many TCS connections.
>
> "absolutely terrible" may be too strong of a way to put it, but that the
> before and after don't lie.
>
> On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov <abalashov at evaristesys.com>
> wrote:
>
>> But increasing the depth of the queue by 78x (if I'm not mistaken,
>> 212992 is the default--at least, it is on all my CentOS 7.x and 8.x
>>
>> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200613/87a873b8/attachment-0001.html>

From calvin.ellison at voxox.com  Fri Jun 12 23:58:38 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Fri, 12 Jun 2020 16:58:38 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAFGRPVrs65fNgp+2WEKZmo37ACo04AqFQs9-E19kGfr19hTHbQ@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG_p3dooJ2uqq9irVMA1dqjUn3xVp+Pt-zr-5LZhsR6d8w@mail.gmail.com>
 <CAFGRPVrs65fNgp+2WEKZmo37ACo04AqFQs9-E19kGfr19hTHbQ@mail.gmail.com>
Message-ID: <CAL+QDG8RA3TbS2FgKb4NHmHBVKXe8VQjP7NL9pviZ+_E=t-VwQ@mail.gmail.com>

Agreed it's not a big deal that the kernel default is 212992, it's that
value because it's enough for lots of things. It is a big deal not being
aware of its effect on things could be the difference between less than
3,000 CPS and more than 10,000.

On Fri, Jun 12, 2020 at 4:50 PM David Villasmil <
david.villasmil.work at gmail.com> wrote:

> Keep in mundo the don’t make Ubuntu for SIP applications, which have their
> own idiosyncrasies. They make it general purpose. So finding a value that
> doesn’t work perfectly with what you need for this very specific
> application, is not a big deal.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/24cd8154/attachment.html>

From calvin.ellison at voxox.com  Sat Jun 13 00:03:16 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Fri, 12 Jun 2020 17:03:16 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
 <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
 <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>
Message-ID: <CAL+QDG_nf5_NsJD2rC8XQdRjx_jOy_ScYjnFyE9yUQtkuTd15w@mail.gmail.com>

On Fri, Jun 12, 2020 at 4:35 PM David Villasmil <
david.villasmil.work at gmail.com> wrote:

> Basically, the application is not processing the received packets as
> quickly as it should, so the kernel stores the packets in the buffer so it
> doesn’t have to throw them away.
>
> It’s not so difficult to understand. If this is happening all the time,
> you won’t solve this by making the buffer bigger. You solve this by
> figuring out why the application is not processing the packets fast enough.
>

That's been the point of this discussion. Unfortunately, there answers so
far have added to up "keep changing settings until you find what works
best" and "buffers are a Ponzi scheme" despite and immediate 3x performance
increase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/351f3b4a/attachment.html>

From abalashov at evaristesys.com  Sat Jun 13 00:15:46 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 12 Jun 2020 20:15:46 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAFGRPVrs65fNgp+2WEKZmo37ACo04AqFQs9-E19kGfr19hTHbQ@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG_p3dooJ2uqq9irVMA1dqjUn3xVp+Pt-zr-5LZhsR6d8w@mail.gmail.com>
 <CAFGRPVrs65fNgp+2WEKZmo37ACo04AqFQs9-E19kGfr19hTHbQ@mail.gmail.com>
Message-ID: <03e7f89a-1d1e-4c8e-c39d-c42456281782@evaristesys.com>

The value is perfectly reasonable for an application that is properly 
coping with its request load.

On 6/12/20 7:49 PM, David Villasmil wrote:
> Keep in mundo the don’t make Ubuntu for SIP applications, which have 
> their own idiosyncrasies. They make it general purpose. So finding a 
> value that doesn’t work perfectly with what you need for this very 
> specific application, is not a big deal.
> 
> On Sat, 13 Jun 2020 at 00:38, Calvin Ellison <calvin.ellison at voxox.com 
> <mailto:calvin.ellison at voxox.com>> wrote:
> 
>     I doubt the system will be using all of that buffer. I also don't
>     know if the issue was in the receive buffer or send buffer since I
>     changed both at once. Many resources are available online from
>     people who have already done much more scientific testing that
>     indicate the default values should be increased for certain
>     applications, which is the reason I changed it to begin with.
>     There's no one-size-fits all for server configurations, and what
>     works for this UDP application with a small number of clients might
>     not work well for a different application with many TCS connections.
> 
>     "absolutely terrible" may be too strong of a way to put it, but that
>     the before and after don't lie.
> 
>     On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov
>     <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote:
> 
>         But increasing the depth of the queue by 78x (if I'm not mistaken,
>         212992 is the default--at least, it is on all my CentOS 7.x and 8.x
> 
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> -- 
> Regards,
> 
> David Villasmil
> email: david.villasmil.work at gmail.com 
> <mailto:david.villasmil.work at gmail.com>
> phone: +34669448337
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From abalashov at evaristesys.com  Sat Jun 13 00:23:18 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 12 Jun 2020 20:23:18 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG_nf5_NsJD2rC8XQdRjx_jOy_ScYjnFyE9yUQtkuTd15w@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
 <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
 <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>
 <CAL+QDG_nf5_NsJD2rC8XQdRjx_jOy_ScYjnFyE9yUQtkuTd15w@mail.gmail.com>
Message-ID: <08f7fafa-4f0f-c819-0b3c-1d8636b59863@evaristesys.com>

On 6/12/20 8:03 PM, Calvin Ellison wrote:

> That's been the point of this discussion. Unfortunately, there answers 
> so far have added to up "keep changing settings until you find what 
> works best" and "buffers are a Ponzi scheme" despite and immediate 3x 
> performance increase.

Perhaps if one adopts a rather esoteric understanding of "performance 
increase" ... in principle, queueing more packets indicates the 
opposite. In that light, one could look at a lower receive queue depth 
as an optimisation, actually.

One should see the forest for the trees, instead of cultivating a myopic 
preoccupation with short-term, stop-gap solutions.

Two things are logically possible:

(1) The receive queue backlog keeps stacking up until the size of 16.7m 
is exhausted as well; this is clearly not happening, or it would not be 
triumphantly claimed as a solution;

(2) The higher buffer provides the elasticity needed to cope with 
stochastic I/O wait conditions which, for a given base CPS load, occur 
within a certain range of latencies and at a certain frequency 
distribution. Because the blocking conditions are not always uniformly 
present--they're stochastic, after all--in those low-tide moments, the 
receive queue drains.

The larger buffer solves #2, but not by way of providing for a 
"performance increase". Nothing is performing better. It's a lever--a 
quite imperfect one--to cope with the fact that something is performing 
_quite poorly_. However, fortunately for you, it happens on an 
intermittent basis, otherwise you'd have quickly encountered scenario #1.

#2 is a better and more manageable problem than #1, in strictly relative 
terms, but both are pathological and need to be addressed. To say that 
this amounts to a "tuning" or "optimisation" that yields a "performance 
increase" is profoundly misleading.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From calvin.ellison at voxox.com  Sat Jun 13 01:11:46 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Fri, 12 Jun 2020 18:11:46 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <08f7fafa-4f0f-c819-0b3c-1d8636b59863@evaristesys.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAP9sNzGppQbSdV6wWLe8gk8cfid2dML6fYzDE+JWyWH1DNguNA@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
 <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
 <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>
 <CAL+QDG_nf5_NsJD2rC8XQdRjx_jOy_ScYjnFyE9yUQtkuTd15w@mail.gmail.com>
 <08f7fafa-4f0f-c819-0b3c-1d8636b59863@evaristesys.com>
Message-ID: <CAL+QDG9toB_tSPvCBcyL0njeMuR2CRaqfSufuP3GvW6JtpF=yA@mail.gmail.com>

On Fri, Jun 12, 2020 at 5:23 PM Alex Balashov <abalashov at evaristesys.com>
wrote:

> One should see the forest for the trees, instead of cultivating a myopic
> preoccupation with short-term, stop-gap solutions.
>

Understanding that text lacks tone, this a rather offputting comment for a
mailing list intended to help users. I appreciate your time and feedback,
there's no need to be insulting. Perhaps you could stop assuming what my
preoccupations and scope of vision are and concentrate on the problem and
the solution? The question now is why increasing buffers made any
difference at all.

You suggested to "Monitor your receive queue scrupulously at a very high
timing resolution". How do I do this?

You propose there is a pathological issue and the increased buffer size is
masking it. How do I determine what that issue is?

I've asked repeatedly about children, shared memory, process
memory, timer_partitions, etc. but the only answers have been "try more".
I've been trying more and less of these things two weeks and changing the
buffers was the only thing that appeared to have any immediate impact. How
do I know when enough is enough versus too much?

Note, there have been no memory-related log messages. The 16-thread servers
have 48GB RAM and the 8-thread servers have 16GB. I'm happy to give all
that to OpenSIPS once I know the right way to carve it up.

Should I even be using 2.4?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200612/81b28c33/attachment-0001.html>

From abalashov at evaristesys.com  Sat Jun 13 01:42:03 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 12 Jun 2020 21:42:03 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG9toB_tSPvCBcyL0njeMuR2CRaqfSufuP3GvW6JtpF=yA@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
 <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
 <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>
 <CAL+QDG_nf5_NsJD2rC8XQdRjx_jOy_ScYjnFyE9yUQtkuTd15w@mail.gmail.com>
 <08f7fafa-4f0f-c819-0b3c-1d8636b59863@evaristesys.com>
 <CAL+QDG9toB_tSPvCBcyL0njeMuR2CRaqfSufuP3GvW6JtpF=yA@mail.gmail.com>
Message-ID: <b8118afc-e070-c0f1-f7c4-ea90a54c8166@evaristesys.com>

On 6/12/20 9:11 PM, Calvin Ellison wrote:

> You suggested to "Monitor your receive queue scrupulously at a very high 
> timing resolution". How do I do this?

If using pre-systemd systems, e.g. EL6:

# netstat --inet -n -l | grep 5060

If it's systemd and beyond -- I'm sure Ubuntu Server 18 is, though I 
have no experience with it:

# ss -4nl | grep 5060

Example:

---
[root at allegro-1 ~]# ss -4nl | grep 5060
udp    UNCONN     0      0      10.150.20.5:5060                  *:* 

udp    UNCONN     0      0      10.150.20.2:5060                  *:* 

udp    UNCONN     0      0      209.51.167.66:5060                  *:* 

tcp    LISTEN     0      128    10.150.20.2:5060                  *:* 

---

The third column there (all-0s) is the RecvQ, as can be gleaned from the 
header this command outputs:

----
Netid  State      Recv-Q Send-Q Local Address:Port               Peer 
Address:Port
---

For `netstat`, it would be the second column.

To monitor it at a low interval, for example 200 ms (5 times per sec), 
you could do something like:

---
#!/bin/bash

while : ; do
	echo -n "$(date +"%T.%3N"): "
	ss -4nl | grep 5060 | head -1 | awk '{print $3}'
	sleep 0.2
done
---

That should give you some idea of where the value sits in general.

> You propose there is a pathological issue and the increased buffer size 
> is masking it. How do I determine what that issue is?

Without knowing what your exact routing workflow is, I can't say.

However, 99.9% of the time, it occurs in blocking queries to databases 
or other data sources.

> I've asked repeatedly about children, shared memory, process 
> memory, timer_partitions, etc. but the only answers have been "try 
> more". I've been trying more and less of these things two weeks and 
> changing the buffers was the only thing that appeared to have any 
> immediate impact. How do I know when enough is enough versus too much?

I wrote this article several years ago for Kamailio, but the same basic 
considerations apply to OpenSIPS:

http://www.evaristesys.com/blog/tuning-kamailio-for-high-throughput-and-performance/

"Try more" is definitely not the answer except in cases where the 
workload is overwhelmingly network I/O-bound and/or database-bound. 
Otherwise, the most natural course of action would be to spawn a 
functionally infinite number of children. However, children create 
context switches, contend with each other for CPU time (less a concern 
if most of the workload is waiting on blocking external I/O) and fight 
for various global shared memory structures and locks (still a concern 
regardless). So, there is a point of diminishing returns for any given 
workload. All other things being equal, as per the article, the 
reasonable number of child processes is equal to the number of available 
CPU threads (in /proc/cpuinfo). This number can be increased if the 
workload is very I/O-bound, but only to a point. It's hard to say 
exactly what that point is, and it does have to be empirically 
determined, but I would not run more than 2 * (CPU threads).

> Note, there have been no memory-related log messages. The 16-thread 
> servers have 48GB RAM and the 8-thread servers have 16GB. I'm happy to 
> give all that to OpenSIPS once I know the right way to carve it up.

I see no rationality in giving it all to OpenSIPS.

It's worth bearing in mind that there are two kinds of memory allocations:

- Shared memory, used by the system for global/system-wide data 
constructs, such as transaction memory, dialog state, etc.;

- Package memory, memory that is private to each process and used for 
handling the immediate message. That means every child process 
pre-allocates the package memory requested, so this value should of 
course be much, much smaller than your shared memory pool size.

But still, when you consider all the data that OpenSIPS needs to keep in 
the course of call processing, a lot of it is ephemeral and 
transaction-associated. Once the call is set up, the INVITE transaction 
is disposed. Other call state may add up to a few kilobytes per call at 
most (notwithstanding page sizes and blocks in the underlying 
allocator), but nothing on the order of gigabytes upon gigabytes. 
Assuming 4 KB per call and 200,000 concurrent calls, that's ~800 MB, and 
that is a very generous assumption indeed.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From venefax at gmail.com  Sat Jun 13 14:51:15 2020
From: venefax at gmail.com (Saint Michael)
Date: Sat, 13 Jun 2020 10:51:15 -0400
Subject: [OpenSIPS-Users] New kernel, new errror
Message-ID: <CAC9cSOAOm2hS48L5k3_w7zeumEZsap84MhgE3=C+mU1PsMbPjg@mail.gmail.com>

/usr/local/sbin/opensipsctl fifo get_statistics
I get
/usr/local//lib64/opensips/opensipsctl/opensipsctl.fifo: line 121:
/tmp/opensips_fifo: Permission denied

My new kernel is
5.4.0-37-generic
Any idea what am I doing wrong?
How can I know how may open channels I have?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200613/03af613f/attachment.html>

From venefax at gmail.com  Sat Jun 13 15:30:49 2020
From: venefax at gmail.com (Saint Michael)
Date: Sat, 13 Jun 2020 11:30:49 -0400
Subject: [OpenSIPS-Users] New Errors
Message-ID: <CAC9cSOBRMdEpmaegccrdF7abq=ROmc1wuWy6o2FWwtjRu_YhyA@mail.gmail.com>

WARNING:dialog:register_dlgcb: Cannot register callbacks in DELETED state
(type 2000)!
ERROR:acc:acc_onreply: cannot register callback for context serialization
Any idea what these errors mean?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200613/b23859d5/attachment.html>

From osas at voipembedded.com  Sat Jun 13 18:57:01 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Sat, 13 Jun 2020 14:57:01 -0400
Subject: [OpenSIPS-Users] New kernel, new errror
In-Reply-To: <CAC9cSOAOm2hS48L5k3_w7zeumEZsap84MhgE3=C+mU1PsMbPjg@mail.gmail.com>
References: <CAC9cSOAOm2hS48L5k3_w7zeumEZsap84MhgE3=C+mU1PsMbPjg@mail.gmail.com>
Message-ID: <CAND0LksHwGQfmrE9kGon_r13cgoAu9KNjcsuCmpS3JgVGs=6fQ@mail.gmail.com>

Most likely the user that is running the command doesn't have
write|execute access to the fifo file.

-ovidiu

On Sat, Jun 13, 2020 at 10:52 AM Saint Michael <venefax at gmail.com> wrote:
>
> /usr/local/sbin/opensipsctl fifo get_statistics
> I get
> /usr/local//lib64/opensips/opensipsctl/opensipsctl.fifo: line 121: /tmp/opensips_fifo: Permission denied
>
> My new kernel is
> 5.4.0-37-generic
> Any idea what am I doing wrong?
> How can I know how may open channels I have?
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From venefax at gmail.com  Sat Jun 13 19:02:37 2020
From: venefax at gmail.com (Saint Michael)
Date: Sat, 13 Jun 2020 15:02:37 -0400
Subject: [OpenSIPS-Users] New kernel, new errror
In-Reply-To: <CAND0LksHwGQfmrE9kGon_r13cgoAu9KNjcsuCmpS3JgVGs=6fQ@mail.gmail.com>
References: <CAC9cSOAOm2hS48L5k3_w7zeumEZsap84MhgE3=C+mU1PsMbPjg@mail.gmail.com>
 <CAND0LksHwGQfmrE9kGon_r13cgoAu9KNjcsuCmpS3JgVGs=6fQ@mail.gmail.com>
Message-ID: <CAC9cSOCxrPoFUmkfs3QTn7_ww23h=cf8MAbiF1AzZF5gfwjQpQ@mail.gmail.com>

Not really, I am root. The fifo es also owned by root.


On Sat, Jun 13, 2020 at 2:59 PM Ovidiu Sas <osas at voipembedded.com> wrote:

> Most likely the user that is running the command doesn't have
> write|execute access to the fifo file.
>
> -ovidiu
>
> On Sat, Jun 13, 2020 at 10:52 AM Saint Michael <venefax at gmail.com> wrote:
> >
> > /usr/local/sbin/opensipsctl fifo get_statistics
> > I get
> > /usr/local//lib64/opensips/opensipsctl/opensipsctl.fifo: line 121:
> /tmp/opensips_fifo: Permission denied
> >
> > My new kernel is
> > 5.4.0-37-generic
> > Any idea what am I doing wrong?
> > How can I know how may open channels I have?
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200613/3795f28d/attachment.html>

From venefax at gmail.com  Sun Jun 14 11:16:08 2020
From: venefax at gmail.com (Saint Michael)
Date: Sun, 14 Jun 2020 07:16:08 -0400
Subject: [OpenSIPS-Users] CDR no longer work for permission denied
Message-ID: <CAC9cSOAuK+fUVYAV5g_3OEk1pU1h6cpTXEw-Htoii9_BsKz5zg@mail.gmail.com>

/usr/local/sbin/opensipsctl fifo flat_rotate
/usr/local//lib64/opensips/opensipsctl/opensipsctl.fifo: line 121:
/tmp/opensips_fifo: Permission denied
This happened after upgrading my kernel to 5.4.0-37-generic
although I cannot see the connection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200614/88eb3683/attachment.html>

From williamj at exetel.com.au  Sun Jun 14 23:43:19 2020
From: williamj at exetel.com.au (William Jin)
Date: Sun, 14 Jun 2020 23:43:19 +0000
Subject: [OpenSIPS-Users] question about rtpengine_manage() in
 failure_route
In-Reply-To: <e819c4ee-c0b3-a975-1834-05fa7fbaf619@opensips.org>
References: <SG2PR06MB2409D3D2B24643A4F6878B899B850@SG2PR06MB2409.apcprd06.prod.outlook.com>
 <SG2PR06MB2409E6637F569783051D3B6C9B820@SG2PR06MB2409.apcprd06.prod.outlook.com>,
 <e819c4ee-c0b3-a975-1834-05fa7fbaf619@opensips.org>
Message-ID: <SG2PR06MB2409F31F2BA47817E74DE4EE9B9F0@SG2PR06MB2409.apcprd06.prod.outlook.com>

Hi Razvan,

Many thanks for your advice.

Yes, I can confirm the branch_route did the trick.

--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of Răzvan Crainea <razvan at opensips.org>
Sent: Wednesday, 10 June 2020 5:59 PM
To: users at lists.opensips.org <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] question about rtpengine_manage() in failure_route


Hi, William!


Make sure you call rtpengine_manage() in branch route, not in the request route, otherwise all the changes will be inherited throughout all the branches further created.


Best regards,

Răzvan


On 6/9/20 7:04 AM, William Jin wrote:
Below is a short config example.

route {
...
setflag(CallFWD);
rtpengine_manage();  #say the first call attempt need rtpengine
t_on_failure("handle_failure");
r_relay();
...
}


failure_route[handle_failure] {
...
if (isflagset(CallFWD)){route(handle_callfwd);}
...
}

route[handle_callfwd]{
...
xlog("L_INFO","RB=$rb(application/sdp)");
if (t_relay()){
xlog("L_INFO","Stateful relay done. RB=$rb(application/sdp)");
}
...
}

Looks like the t_relay in the handle_callfwd will inherit the SDP info that rtpengine_manage entered in the first attempt.

Also, another interesting fact is that the SDP info is added while the t_relay is called. Looks like the t_relay is using its data in memory and re-write the SDP. the  $rb(application/sdp) is not changed until the t_relay is called.

How can I, for example, remove the rtpengine related SDP for the second INVITE generated by the failure_route?
I tried rtpengine_delete() in handle_callfwd or rtpengine_manage() in the failure_route which suppose to do rtpengine_delete also, but they don't work as expected.

Thanks in advance.


--
Regards,
William Jin
________________________________
From: Users <users-bounces at lists.opensips.org><mailto:users-bounces at lists.opensips.org> on behalf of William Jin <williamj at exetel.com.au><mailto:williamj at exetel.com.au>
Sent: Tuesday, 9 June 2020 9:09 AM
To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Subject: [OpenSIPS-Users] question about rtpengine_manage() in failure_route

Hi All

May I know how can I rewrite the SDP (rtpengine) in the failure route?

The scenario is we use rtpengine_manage() in the first call attempt, if it fails, it uses failure_route, however, we want to change the SDP info.

For example, the call's first attempt is to an ipv6 UAC, when failed, we try ipv4 UAC. We need to change the rtpengine address-family to IP4 so the c= line can follow with an IPv4 address.

We tried to use rtpengine_manage("address-family=IP4"), but looks like the SDP still not changed.

Does anyone have any idea about this? Or is there any other way to achieve this?



--
Regards,
William Jin



_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200614/a184e22c/attachment.html>

From vladp at opensips.org  Mon Jun 15 16:07:13 2020
From: vladp at opensips.org (Vlad Patrascu)
Date: Mon, 15 Jun 2020 19:07:13 +0300
Subject: [OpenSIPS-Users] cluster/cassandra cache
In-Reply-To: <1663556725.25245.1591736273833.JavaMail.zimbra@skillsearch.ca>
References: <1663556725.25245.1591736273833.JavaMail.zimbra@skillsearch.ca>
Message-ID: <706bd6b6-fc17-c1f8-1eea-e34b10bdf2b7@opensips.org>

Hi Slava,

Can you open a ticket on Github for this? And also include there the 
Cassandra version and other relevant information (as per the issue 
template).

Regards,

On 09.06.2020 23:57, Slava Bendersky via Users wrote:
> Hello Everyone,
> Opensips v3.1 dev can't connect properly to Cassandra cluster.
>
> 1591735692.141 [ERROR] (cluster_connector.cpp:190:void 
> datastax::internal::core::ClusterConnector::on_connect(datastax::internal::core::ControlConnector*)): 
> Unable to establish a control connection to host 10.100.101.9 because 
> of the following error: Underlying connection error: Received error 
> response 'Invalid or unsupported protocol version (66); supported 
> versions are (3/v3, 4/v4, 5/v5-beta)' (0x0200000A)
>  Any help, thank you.
>
> volga629
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200615/b297541d/attachment.html>

From calvin.ellison at voxox.com  Mon Jun 15 20:04:35 2020
From: calvin.ellison at voxox.com (Calvin Ellison)
Date: Mon, 15 Jun 2020 13:04:35 -0700
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <b8118afc-e070-c0f1-f7c4-ea90a54c8166@evaristesys.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAL+QDG9yzFeaywF92wtR3ECBvksiM+bAmEhSccQm33vkDCzOdQ@mail.gmail.com>
 <CAFGRPVo0VcYjSJF=7x9sK49kREGswHmujkzdVdvN6Z4x4JOQ5A@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
 <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
 <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>
 <CAL+QDG_nf5_NsJD2rC8XQdRjx_jOy_ScYjnFyE9yUQtkuTd15w@mail.gmail.com>
 <08f7fafa-4f0f-c819-0b3c-1d8636b59863@evaristesys.com>
 <CAL+QDG9toB_tSPvCBcyL0njeMuR2CRaqfSufuP3GvW6JtpF=yA@mail.gmail.com>
 <b8118afc-e070-c0f1-f7c4-ea90a54c8166@evaristesys.com>
Message-ID: <CAL+QDG_v4fJOOWtsFGA0DkcWRnYvrsPmJ5U0CUZDmnu4tgci_Q@mail.gmail.com>

I attempted to reproduce the original breakdown around 3000 CPS using the
default 212992 byte receive buffer and could not, which tells me I broke a
cardinal rule of load testing and changed more than one thing at a time.
Also, don't do load testing when tired. I suspect that I had also made a
change to the sipp scenario recv/sched loops, or I had unknowingly
broken something while checking out the tuned package.

I deeply appreciate Alex's instance that I was wrong and to keep digging. I
am happy to retract my claim regarding "absolutely terrible sysctl
defaults". Using synchronous/blocking DB queries, the 8-core server reached
14,000 CPS, at which point I declared it fixed and went to bed. It could
probably go higher: there's only one DB query with a <10ms response time,
Memcache for the query response, and some logic to decide how to respond.
There's only a single non-200 final response, so it's probably as
minimalist as it gets.

If anyone else is trying to tune their setup, I think Alex's advice to "not
run more than 2 * (CPU threads) [children]" is the best place to start. I
had inherited this project from someone else's work under version 1.11 and
they had used 128 children. They were using remote DB servers with much
higher latency than the local DBs we have today, so that might have been
the reason. Or they were just wrong to being with.

The Description for Asynchronous Statements is extremely tempting and was
what started me down that path; it might be missing a qualification that
Async can be an improvement for slow blocking operations, but the
additional overhead may be a disadvantage for very fast blocking
operations.

Thank you to everyone who responded to this topic.

Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.ellison at voxox.com


On Fri, Jun 12, 2020 at 6:42 PM Alex Balashov <abalashov at evaristesys.com>
wrote:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200615/41d4ccba/attachment.html>

From solarmon at one-n.co.uk  Tue Jun 16 13:17:32 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Tue, 16 Jun 2020 14:17:32 +0100
Subject: [OpenSIPS-Users] Homer docker integration - "api/preferences.php"
	file
Message-ID: <CAOXfywN3aeDi9Z4G2Ur4XwhK=hYTodgG8vCmLxNCRy-3QxYEXA@mail.gmail.com>

Hi,

I'm trying to set up and integrate Homer with my opensips setup.

I have managed to install Homer on separate VM, using the docker method as
described at:

https://github.com/sipcapture/homer/wiki/Quick-Install#-quick-install

(I had to set SELINUX to permissive or disable for it to build - see
https://github.com/sipcapture/homer7-docker/issues/81).

I'm following this guide on how to integrate Homer with opensips:

https://blog.opensips.org/2017/08/02/opensips-control-panel-and-homer-integration/

On there, it talks about configuring Homer in the "api/preferences.php"
file.

With my limited experience and knowledge on Docker I'm not sure how/where
to find this config file.

Can somebody tell me where this  "api/preferences.php" file can be found
within the Docker environment.

Or can these settings be set within the Homer admin GUI Admin Settings
instead? It looks like in the Advanced section of Settings I am able to add
parameters, but it needs to have a 'category' assigned to it, which I don't
know what it should be (if this is the equivalent way to do.it).

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200616/05d94a63/attachment.html>

From pkelly at gmail.com  Tue Jun 16 13:37:51 2020
From: pkelly at gmail.com (Pete Kelly)
Date: Tue, 16 Jun 2020 14:37:51 +0100
Subject: [OpenSIPS-Users] Registrar+TLS+NAT question (OpenSIPS 3.0.1)
Message-ID: <CAEWH9M9XCYO1i0gkChRakJQPQx=+dFtCczgn1AJ_ANmO4JBjsQ@mail.gmail.com>

Hi

I am running a Registrar in a natted location (AWS) which is currently
accessed via a tls socket.

The listen parameter for the tls socket uses an alias to set the publicly
advertised address, along the lines of:

listen=tls:172.3.4.5:5061 AS tls:99.88.77.66:5061

however this public alias is also being set as the Socket when the AOR is
stored in the usrloc module.

  "Socket": "tls:99.88.77.66:5061"

When I then do a lookup() on a registered user, it is failing to route as I
believe the socket is being set to the public alias. It was working fine
when there was no TLS involved.

Is there an obvious way I can try to fix this? (I've tried
using force_send_socket(tls:172.3.4.5:5061) after the lookup, but that
isn't helping either)

Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200616/c35b3e2b/attachment.html>

From abalashov at evaristesys.com  Tue Jun 16 21:33:35 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 16 Jun 2020 17:33:35 -0400
Subject: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
In-Reply-To: <CAL+QDG_v4fJOOWtsFGA0DkcWRnYvrsPmJ5U0CUZDmnu4tgci_Q@mail.gmail.com>
References: <CAL+QDG8Y9GTwAmSGGrNmwTmXYyFshDHoEXoa-2Rh28qM2V6vXQ@mail.gmail.com>
 <CAL+QDG_5ySWSw1mYcPxmUgW7Ln2DL7GzAsxMiCWeXh=ouAt-_w@mail.gmail.com>
 <CAP9sNzF3NajDC_oF83v+mWTeUNvfXqjyfzDca2BhWF-Uo83xVw@mail.gmail.com>
 <CAC9cSOAMnuzmu0Ptw-pJz=YigZxS4+QcYMWg5Mu0ETMCau_B3g@mail.gmail.com>
 <CAL+QDG8PO5qL1v5Wkpp13xW3Pw9eittiZB-BRkBgzo+ZzYOvKg@mail.gmail.com>
 <41fc7683-7fca-1096-e04f-cf4bd1b25d12@evaristesys.com>
 <e6a224cd-3217-93a7-22af-fc681104b97d@evaristesys.com>
 <CAL+QDG9V=HS9av8HyUHUdB2SZL0Xvti00-bT=cux6rWsZ4s=dQ@mail.gmail.com>
 <eed0e285-c735-52df-8467-58159f788550@evaristesys.com>
 <CAFGRPVokxX-7hB6jBwyu5PxyoYSA4C=iLekPXc3oSJSBagxJEg@mail.gmail.com>
 <CAL+QDG_nf5_NsJD2rC8XQdRjx_jOy_ScYjnFyE9yUQtkuTd15w@mail.gmail.com>
 <08f7fafa-4f0f-c819-0b3c-1d8636b59863@evaristesys.com>
 <CAL+QDG9toB_tSPvCBcyL0njeMuR2CRaqfSufuP3GvW6JtpF=yA@mail.gmail.com>
 <b8118afc-e070-c0f1-f7c4-ea90a54c8166@evaristesys.com>
 <CAL+QDG_v4fJOOWtsFGA0DkcWRnYvrsPmJ5U0CUZDmnu4tgci_Q@mail.gmail.com>
Message-ID: <eb571dc4-8334-a21e-bd27-e356b3fd2561@evaristesys.com>

Hi Calvin,

I'm really glad you were able to get things sorted out, and I apologise 
if the thread got testy. I do appreciate your follow-up, which I think 
will benefit readers looking for similar answers.

A few inline thoughts:

On 6/15/20 4:04 PM, Calvin Ellison wrote:

> I attempted to reproduce the original breakdown around 3000 CPS using 
> the default 212992 byte receive buffer and could not, which tells me I 
> broke a cardinal rule of load testing and changed more than one thing at 
> a time. Also, don't do load testing when tired. I suspect that I had 
> also made a change to the sipp scenario recv/sched loops, or I had 
> unknowingly broken something while checking out the tuned package.

In several decades of doing backend systems programming, I've not found 
tuning Linux kernel defaults to be generally fruitful for improving 
throughput to any non-trivial degree. The defaults are sensible for 
almost all use-cases, all the more so given modern hardware and 
multi-core processors and the rest.

This is in sharp contrast to the conservative defaults some applications 
(e.g. Apache, MySQL) ship with on many distributions. I think the idea 
behind such conservative settings is to constrain the application so 
that in the event of a DDoS or similar event, it does not take over all 
available hardware resources, which would impede response and resolution.

But on the kernel settings, the only impactful changes I have ever seen 
are minor adjustments to slightly improve very niche server load 
problems of a rather global nature (e.g. related to I/O scheduling, NIC 
issues, storage, etc). This wasn't that kind of scenario.

In most respects, it just follows from first principles and Occam's 
Razor, IMHO. There's no reason for kernels to ship tuned unnecessarily 
conservatively to deny average users something on the order of _several 
times'_ more performance from their hardware, and any effort to do that 
would be readily apparent and, it stands to reason, staunchly opposed. 
It therefore also stands to reason that there isn't some silver bullet 
or magic setting that unlocks multiplicative performance gains, if only 
one just knows the secret sauce or thinks to tweak it--for the simple 
reason that if such a tweak existed, it would be systemically 
rationalised away, absent a clear and persuasive basis for such an 
artificial and contrived limit to exist. I cannot conceive of what such 
a basis would look like, and I'd like to think that's not just a failure 
of imagination.

Or in other words, it goes with the commonsensical, "If it seems too 
good to be true, it is," intuition. The basic fundamentals of the 
application, and to a lesser but still very significant extent the 
hardware (in terms of its relative homogeneity nowadays), determine 
99.9% of the performance characteristics, and matter a thousand times 
more than literally anything one can tweak.

> I deeply appreciate Alex's instance that I was wrong and to keep 
> digging. I am happy to retract my claim regarding "absolutely terrible 
> sysctl defaults". Using synchronous/blocking DB queries, the 8-core 
> server reached 14,000 CPS, at which point I declared it fixed and went 
> to bed. It could probably go higher: there's only one DB query with a 
> <10ms response time, Memcache for the query response, and some logic to 
> decide how to respond. There's only a single non-200 final response, so 
> it's probably as minimalist as it gets.

I would agree that with such a minimal call processing loop, given a 
generous number of CPU cores you shouldn't be terribly limited.

> If anyone else is trying to tune their setup, I think Alex's advice to 
> "not run more than 2 * (CPU threads) [children]" is the best place to 
> start. I had inherited this project from someone else's work under 
> version 1.11 and they had used 128 children. They were using remote DB 
> servers with much higher latency than the local DBs we have today, so 
> that might have been the reason. Or they were just wrong to being with.

Aye. Barring a workload consisting of exceptionally latent blocking 
service queries, there's really not a valid reason to ever have that 
many child processes, and even if one does have such a workload, plenty 
of reasons to lean on the fundamental latency problem rather than 
working around it with more child processes.

With the proviso that I am not an expert in modern-day OpenSIPS 
concurrency innards, the common OpenSER heritage prescribes a preforked 
worker process pool with SysV shared memory for inter-process 
communication (IPC). Like any shared memory space, this requires mutex 
locking so that multiple threads (in this case, processes) don't 
access/modify the same data structures at the same time* in ways that 
step on the others. Because every process holds and waits on these 
locks, this model works well when there aren't very many processes and 
their path to execution is mostly clear and not especially volatile, and 
when as little data is shared as possible. If you add a lot of 
processes, then there's a lot of fighting among them for internal locks 
and for CPU time, even if the execution cycle per se is fairly 
efficient. If you have 16 cores and 128 child processes, those processes 
are going to be fighting for those cores if they execute efficiently, 
while suffering from some amount of internal concurrency gridlock if 
they are not executing efficiently. Thus, 128 is for almost all cases 
very far beyond the sweet spot.

By analogy, think of a large multi-lane highway where almost all cars 
travel at more or less a constant speed, and, vitally, almost always 
stay in their lane, only very seldom making a lane change. As anyone who 
has ever been stuck in traffic knows, small speed changes by individual 
actors or small groups of cars can set off huge compression waves that 
have impact for miles back, and lane changes also have accordion 
effects. It's not a perfect analogy by any means, but it kind of conveys 
some sense of the general problem of contention. You really want to keep 
the "lanes" clear and eliminate all possible sources of friction, 
variance, and overlap.

* For exclusion purposes; of course, there's no such thing as truly 
simultaneous execution.

> The Description for Asynchronous Statements is extremely tempting and 
> was what started me down that path; it might be missing a qualification 
> that Async can be an improvement for slow blocking operations, but the 
> additional overhead may be a disadvantage for very fast blocking 
> operations.

There is indeed a certain amount of overhead in pushing data around 
multiple threads, the locking of shared data structures involved in 
doing so, etc. For slow, blocking operations, there's nevertheless an 
advantage, but if the operations aren't especially blocking, in many 
cases all that "async" stuff is just extra overhead.

Asynchronous tricks which deputise notification of the availability of 
further work or I/O to the kernel can be pretty efficient, just because 
life in kernel space is pretty efficient. But async execution in 
user-space requires user-space contrivances that suffer from all the 
problems of user-space in turn, so the economics can be really 
different. Mileage of course greatly varies with the implementation details.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From ag at ag-projects.com  Wed Jun 17 15:49:59 2020
From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 17 Jun 2020 12:49:59 -0300
Subject: [OpenSIPS-Users] Push notifications server
Message-ID: <977736CA-6D31-4BBC-9BA6-A498B8D132E9@ag-projects.com>

Hello,

We just made public a mobile push notification server that may help in various scenarios.

An integration guide for OpenSIPS is available in the source code.

https://ag-projects.com/news/sylk-pushserver/

Regards,
Adrian


 

From gmaruzz at gmail.com  Wed Jun 17 16:07:35 2020
From: gmaruzz at gmail.com (Giovanni Maruzzelli)
Date: Wed, 17 Jun 2020 18:07:35 +0200
Subject: [OpenSIPS-Users] Push notifications server
In-Reply-To: <977736CA-6D31-4BBC-9BA6-A498B8D132E9@ag-projects.com>
References: <977736CA-6D31-4BBC-9BA6-A498B8D132E9@ag-projects.com>
Message-ID: <CALXCt0q8B6m-5Pu1T1s5Y_EYJjfnU3Y9h7WqTvYqtX4H0D1+gw@mail.gmail.com>

Wow Adrian,

seems impressive!

Congratulations and thanks!!

-giovanni



On Wed, Jun 17, 2020 at 5:52 PM Adrian Georgescu <ag at ag-projects.com> wrote:

> Hello,
>
> We just made public a mobile push notification server that may help in
> various scenarios.
>
> An integration guide for OpenSIPS is available in the source code.
>
> https://ag-projects.com/news/sylk-pushserver/
>
> Regards,
> Adrian
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200617/176bcceb/attachment.html>

From adjolin at gmail.com  Wed Jun 17 18:15:32 2020
From: adjolin at gmail.com (Vic Jolin)
Date: Thu, 18 Jun 2020 02:15:32 +0800
Subject: [OpenSIPS-Users] Fwd: Opensips 3.0 permission table not sending
	proper context info
In-Reply-To: <CAA+eT4kkhGs1wGC7Tps3NAq3qzcmYQqFx4u1jjuJatY-hU1hFA@mail.gmail.com>
References: <CAA+eT4kkhGs1wGC7Tps3NAq3qzcmYQqFx4u1jjuJatY-hU1hFA@mail.gmail.com>
Message-ID: <CAA+eT4nMZwpFntXYh1sHm952216k-K_Q_nB1GzjUE55oDpg5Tg@mail.gmail.com>

Hi all, I have IP addresses setup in my mysql table address

+----+-----+----------------+------+------+-------+---------+--------------+
| id | grp | ip             | mask | port | proto | pattern | context_info |
+----+-----+----------------+------+------+-------+---------+--------------+
|  9 |   1 | x.x.x.x   |    1 | 5060 | any   |         | 10           |
+----+-----+----------------+------+------+-------+---------+--------------+

But when I check source address in opensips.cfg

check_source_address( 1, $avp(groupid))
xlog("Call coming from trunk with $avp(groupid)\n");

The output thou is:
*Call coming from trunk with 1*

Can anyone shed some light on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200618/bf5996fa/attachment.html>

From adjolin at gmail.com  Wed Jun 17 18:18:53 2020
From: adjolin at gmail.com (Vic Jolin)
Date: Thu, 18 Jun 2020 02:18:53 +0800
Subject: [OpenSIPS-Users] opensips-cli dp_reload not working
Message-ID: <CAA+eT4kmDqfDhKV+dN9wF9pU_jx8P-OpJXPaPzawRRg9_HP=sg@mail.gmail.com>

Hi,

I've been trying to get my dialplan to reload but Im still getting the old
dialplan when I test.
the old dialplan has attributes on it, but I removed it, and when I tried

opensips-cli -x mi dp_reload

I am still getting the old attribute.

Anything else I should do or check?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200618/92c59e7e/attachment.html>

From bogdan at opensips.org  Wed Jun 17 18:29:30 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 17 Jun 2020 21:29:30 +0300
Subject: [OpenSIPS-Users] opensips-cli dp_reload not working
In-Reply-To: <CAA+eT4kmDqfDhKV+dN9wF9pU_jx8P-OpJXPaPzawRRg9_HP=sg@mail.gmail.com>
References: <CAA+eT4kmDqfDhKV+dN9wF9pU_jx8P-OpJXPaPzawRRg9_HP=sg@mail.gmail.com>
Message-ID: <84716f47-0f78-7249-ce7a-7416ac6286e0@opensips.org>

Hi,

Do you see any errors in the logs, after reload ?

Also, if you switch the DBG/4 log_level, do you see the logs for the 
reload ?

Maybe your tests are not accurate enough to spot the reload.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/17/20 9:18 PM, Vic Jolin wrote:
> Hi,
>
> I've been trying to get my dialplan to reload but Im still getting the 
> old dialplan when I test.
> the old dialplan has attributes on it, but I removed it, and when I tried
>
> opensips-cli -x mi dp_reload
>
> I am still getting the old attribute.
>
> Anything else I should do or check?
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200617/d8a9da10/attachment.html>

From solarmon at one-n.co.uk  Thu Jun 18 09:13:42 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Thu, 18 Jun 2020 10:13:42 +0100
Subject: [OpenSIPS-Users] HEPv3 siptrace to Homer v7 - "Trailing stray
	characters"
Message-ID: <CAOXfywMAudqfKJEkaLR8LaXCnFARt70mTywggrUekZU3cM7ZzA@mail.gmail.com>

Hi,

I'm trying to set up siptrace to send HEPv3 packets to a Homer 7 setup.

Currently this is not working and it seems the HEPv3 packets coming from
opensips is not being ingested for some reason. Using hepgen (
https://github.com/sipcapture/hepgen.js) to generate test HEPv3 traffic on
the same opensips nodes is successful.

When comparing both he captured opensips and hepgen generated HEPv3 packets
I notice the following difference which might explain why the opensips
HEPv3 packets are not being ingested.

I'm using the HEP dissector plugin for Wireshark from:

https://github.com/sipcapture/hep-wireshark

The opensips HEPv3 packet is decoded as HEPv3 by the dissector plugin, but
it gives a working about "Trailing stray characters" for the packet.
Inspecting the packet further I see that there is indeed extra data at the
end. For example, the for the HEPv3 packet for INVITE there is the
following data:

.....70110F001-0000FA9B-5EEA5D1C-0000000E at ip.address

(IP address sanitised)

This seems to be the same value as for the Call-ID header:

Call-ID: 0110F001-0000FA9B-5EEA5D1C-0000000E at ip.address

I have the following config, which I pulled together from various sources -
so I'm not sure whether this is correct or causing this issue:

### HEP Capture

#TCP Hep listener
listen=hep_tcp:w.x.y.z:6060
#UDP Hep listener
listen=hep_udp:w.x.y.z:6060

loadmodule "proto_hep.so"
modparam("proto_hep", "hep_id",
"[homer]a.b.c.d:9060;transport=tcp;version=3;")

#loadmodule "tls_mgm.so"
#loadmodule "proto_tls.so"
#modparam("proto_tls", "trace_destination", "homer")
#modparam("proto_tls", "trace_filter_route", "trans_tracer")

loadmodule "siptrace.so"
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_id", "[traceid]uri=hep:homer")

###

and I'm call sip_trace() withing the main route{} function (just for
testing at the moment):

sip_trace("traceid","M","sip");

Why is opensips adding this extra data at the end of the HEPv3 packets and
is this expected/normal?

If not expected/normal how should I change the opensips config to resolve
it.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200618/96bd76b2/attachment.html>

From johan at democon.be  Sat Jun 20 15:50:16 2020
From: johan at democon.be (Johan De Clercq)
Date: Sat, 20 Jun 2020 15:50:16 +0000
Subject: [OpenSIPS-Users] Push notifications server
In-Reply-To: <977736CA-6D31-4BBC-9BA6-A498B8D132E9@ag-projects.com>
References: <977736CA-6D31-4BBC-9BA6-A498B8D132E9@ag-projects.com>
Message-ID: <AM0PR06MB6226FF561B94FC6F4EB1AC11A7990@AM0PR06MB6226.eurprd06.prod.outlook.com>

Adrian,
Where can I download this ?

Outlook voor iOS<https://aka.ms/o0ukef> downloaden
________________________________
Van: Users <users-bounces at lists.opensips.org> namens Adrian Georgescu <ag at ag-projects.com>
Verzonden: woensdag, juni 17, 2020 5:53 PM
Aan: OpenSIPS users mailling list
Onderwerp: [OpenSIPS-Users] Push notifications server

Hello,

We just made public a mobile push notification server that may help in various scenarios.

An integration guide for OpenSIPS is available in the source code.

https://ag-projects.com/news/sylk-pushserver/

Regards,
Adrian



_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200620/05b825cb/attachment.html>

From ag at ag-projects.com  Sat Jun 20 16:26:59 2020
From: ag at ag-projects.com (Adrian Georgescu)
Date: Sat, 20 Jun 2020 13:26:59 -0300
Subject: [OpenSIPS-Users] Push notifications server
In-Reply-To: <AM0PR06MB6226FF561B94FC6F4EB1AC11A7990@AM0PR06MB6226.eurprd06.prod.outlook.com>
References: <977736CA-6D31-4BBC-9BA6-A498B8D132E9@ag-projects.com>
 <AM0PR06MB6226FF561B94FC6F4EB1AC11A7990@AM0PR06MB6226.eurprd06.prod.outlook.com>
Message-ID: <BEF97569-8127-4F64-99AC-7486FAA1F211@ag-projects.com>

Download instructions are listed here:

https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-June/003458.html <https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-June/003458.html>


> On 20 Jun 2020, at 12:50, Johan De Clercq <Johan at democon.be> wrote:
> 
> Adrian, 
> Where can I download this ?
> 
> Outlook voor iOS <https://aka.ms/o0ukef> downloaden
> Van: Users <users-bounces at lists.opensips.org> namens Adrian Georgescu <ag at ag-projects.com>
> Verzonden: woensdag, juni 17, 2020 5:53 PM
> Aan: OpenSIPS users mailling list
> Onderwerp: [OpenSIPS-Users] Push notifications server
>  
> Hello,
> 
> We just made public a mobile push notification server that may help in various scenarios.
> 
> An integration guide for OpenSIPS is available in the source code.
> 
> https://ag-projects.com/news/sylk-pushserver/ <https://ag-projects.com/news/sylk-pushserver/>
> 
> Regards,
> Adrian
> 
> 
>  
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200620/301dc934/attachment.html>

From bogdan at opensips.org  Mon Jun 22 11:36:41 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 22 Jun 2020 14:36:41 +0300
Subject: [OpenSIPS-Users] =?utf-8?q?=5BReleases=5D_OpenSIPS_2=2E4=2E8_and_?=
 =?utf-8?q?3=2E0=2E3_minor_releases=E2=80=8B_-_planing?=
Message-ID: <b9723a63-eed8-1a9d-6b31-801d48191769@opensips.org>

Hi all,

The 30th of June is the day we planned to release the OpenSIPS 2.4.8 and 
3.0.3 minor versions, with more fixes and better stability for you, our 
users.

Best regards,

-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com



From bogdan at opensips.org  Mon Jun 22 16:41:20 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 22 Jun 2020 19:41:20 +0300
Subject: [OpenSIPS-Users] opensips-cli dp_reload not working
In-Reply-To: <CAA+eT4k5qg06PsKn+2_qWQjBwd4myONwh5FOL8DXhm=uQ+rYdA@mail.gmail.com>
References: <CAA+eT4kmDqfDhKV+dN9wF9pU_jx8P-OpJXPaPzawRRg9_HP=sg@mail.gmail.com>
 <84716f47-0f78-7249-ce7a-7416ac6286e0@opensips.org>
 <CAA+eT4k5qg06PsKn+2_qWQjBwd4myONwh5FOL8DXhm=uQ+rYdA@mail.gmail.com>
Message-ID: <f7a9cc51-3285-3e17-6bfe-26fcfa5fbbcb@opensips.org>

Vic,

What is the exact opensips version you have ? (opensips -V)

Also, please provide the log (in debug mode) generated during the reload 
attempt.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/17/20 10:01 PM, Vic Jolin wrote:
> Bogdan,
>
> Hi, the dialplan loads properly on start up, it just doesn't reload on 
> opensips-cli
>
> although when I do
> opensips-cli -x mi dp_reload
>
> It returns OK
>
> On Thu, Jun 18, 2020 at 2:29 AM Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi,
>
>     Do you see any errors in the logs, after reload ?
>
>     Also, if you switch the DBG/4 log_level, do you see the logs for
>     the reload ?
>
>     Maybe your tests are not accurate enough to spot the reload.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        https://www.opensips-solutions.com
>
>     On 6/17/20 9:18 PM, Vic Jolin wrote:
>>     Hi,
>>
>>     I've been trying to get my dialplan to reload but Im still
>>     getting the old dialplan when I test.
>>     the old dialplan has attributes on it, but I removed it, and when
>>     I tried
>>
>>     opensips-cli -x mi dp_reload
>>
>>     I am still getting the old attribute.
>>
>>     Anything else I should do or check?
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200622/92411bcf/attachment.html>

From bogdan at opensips.org  Mon Jun 22 17:17:08 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 22 Jun 2020 20:17:08 +0300
Subject: [OpenSIPS-Users] Fwd: Opensips 3.0 permission table not sending
 proper context info
In-Reply-To: <CAA+eT4nMZwpFntXYh1sHm952216k-K_Q_nB1GzjUE55oDpg5Tg@mail.gmail.com>
References: <CAA+eT4kkhGs1wGC7Tps3NAq3qzcmYQqFx4u1jjuJatY-hU1hFA@mail.gmail.com>
 <CAA+eT4nMZwpFntXYh1sHm952216k-K_Q_nB1GzjUE55oDpg5Tg@mail.gmail.com>
Message-ID: <ef3ad3c3-9cc0-d425-9fda-f96ae7091af8@opensips.org>

Vic,

I just did a quick test with

loadmodule "db_mysql.so"
loadmodule "permissions.so"
modparam("permissions", "db_url", 
"mysql://opensips:opensipsrw at localhost/opensips")

####### Routing Logic ########

startup_route {
     check_address( 1, "1.2.3.4" , 5060, "ANY", $avp(groupid));
     xlog("Call coming from trunk with $avp(groupid)\n");
}

mysql> select * from address \G
*************************** 1. row ***************************
           id: 1
          grp: 1
           ip: 1.2.3.4
         mask: 1
         port: 5060
        proto: any
      pattern: NULL
context_info: 10
1 row in set (0.00 sec)

And I got "Call coming from trunk with 10"

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/17/20 9:15 PM, Vic Jolin wrote:
>
> Hi all, I have IP addresses setup in my mysql table address
>
> +----+-----+----------------+------+------+-------+---------+--------------+
> | id | grp | ip             | mask | port | proto | pattern | 
> context_info |
> +----+-----+----------------+------+------+-------+---------+--------------+
> |  9 |   1 | x.x.x.x   |    1 | 5060 | any   |         | 10           |
> +----+-----+----------------+------+------+-------+---------+--------------+
>
> But when I check source address in opensips.cfg
>
> check_source_address( 1, $avp(groupid))
> xlog("Call coming from trunk with $avp(groupid)\n");
>
> The output thou is:
> *Call coming from trunk with 1*
> *
> *
> Can anyone shed some light on this?
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200622/b5e589b8/attachment.html>

From bogdan at opensips.org  Mon Jun 22 17:19:04 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 22 Jun 2020 20:19:04 +0300
Subject: [OpenSIPS-Users] HEPv3 siptrace to Homer v7 - "Trailing stray
 characters"
In-Reply-To: <CAOXfywMAudqfKJEkaLR8LaXCnFARt70mTywggrUekZU3cM7ZzA@mail.gmail.com>
References: <CAOXfywMAudqfKJEkaLR8LaXCnFARt70mTywggrUekZU3cM7ZzA@mail.gmail.com>
Message-ID: <a7ef83d8-e3ce-8f4f-797b-37442f3b300c@opensips.org>

Hi,

What is the exact OpenSIPS version you have (opensips -V) ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/18/20 12:13 PM, solarmon wrote:
> Hi,
>
> I'm trying to set up siptrace to send HEPv3 packets to a Homer 7 setup.
>
> Currently this is not working and it seems the HEPv3 packets coming 
> from opensips is not being ingested for some reason. Using hepgen 
> (https://github.com/sipcapture/hepgen.js) to generate test HEPv3 
> traffic on the same opensips nodes is successful.
>
> When comparing both he captured opensips and hepgen generated HEPv3 
> packets I notice the following difference which might explain why the 
> opensips HEPv3 packets are not being ingested.
>
> I'm using the HEP dissector plugin for Wireshark from:
>
> https://github.com/sipcapture/hep-wireshark
>
> The opensips HEPv3 packet is decoded as HEPv3 by the dissector plugin, 
> but it gives a working about "Trailing stray characters" for the 
> packet. Inspecting the packet further I see that there is indeed extra 
> data at the end. For example, the for the HEPv3 packet for INVITE 
> there is the following data:
>
> .....70110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>
> (IP address sanitised)
>
> This seems to be the same value as for the Call-ID header:
>
> Call-ID: 0110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>
> I have the following config, which I pulled together from various 
> sources - so I'm not sure whether this is correct or causing this issue:
>
> ### HEP Capture
>
> #TCP Hep listener
> listen=hep_tcp:w.x.y.z:6060
> #UDP Hep listener
> listen=hep_udp:w.x.y.z:6060
>
> loadmodule "proto_hep.so"
> modparam("proto_hep", "hep_id", 
> "[homer]a.b.c.d:9060;transport=tcp;version=3;")
>
> #loadmodule "tls_mgm.so"
> #loadmodule "proto_tls.so"
> #modparam("proto_tls", "trace_destination", "homer")
> #modparam("proto_tls", "trace_filter_route", "trans_tracer")
>
> loadmodule "siptrace.so"
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_id", "[traceid]uri=hep:homer")
>
> ###
>
> and I'm call sip_trace() withing the main route{} function (just for 
> testing at the moment):
>
> sip_trace("traceid","M","sip");
>
> Why is opensips adding this extra data at the end of the HEPv3 packets 
> and is this expected/normal?
>
> If not expected/normal how should I change the opensips config to 
> resolve it.
>
> Thank you.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200622/e8df6194/attachment.html>

From bogdan at opensips.org  Mon Jun 22 17:27:00 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 22 Jun 2020 20:27:00 +0300
Subject: [OpenSIPS-Users] Registrar+TLS+NAT question (OpenSIPS 3.0.1)
In-Reply-To: <CAEWH9M9XCYO1i0gkChRakJQPQx=+dFtCczgn1AJ_ANmO4JBjsQ@mail.gmail.com>
References: <CAEWH9M9XCYO1i0gkChRakJQPQx=+dFtCczgn1AJ_ANmO4JBjsQ@mail.gmail.com>
Message-ID: <e84bdccc-7a20-9404-119e-8925d2aa5468@opensips.org>

Hey Pete,

If you do an xlog on $fs after the lookup, what do you see there ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/16/20 4:37 PM, Pete Kelly wrote:
> Hi
>
> I am running a Registrar in a natted location (AWS) which is currently 
> accessed via a tls socket.
>
> The listen parameter for the tls socket uses an alias to set the 
> publicly advertised address, along the lines of:
>
> listen=tls:172.3.4.5:5061 <http://172.3.4.5:5061> AS 
> tls:99.88.77.66:5061 <http://99.88.77.66:5061>
>
> however this public alias is also being set as the Socket when the 
> AOR is stored in the usrloc module.
>
>   "Socket": "tls:99.88.77.66:5061 <http://99.88.77.66:5061>"
>
> When I then do a lookup() on a registered user, it is failing to route 
> as I believe the socket is being set to the public alias. It was 
> working fine when there was no TLS involved.
>
> Is there an obvious way I can try to fix this? (I've tried 
> using force_send_socket(tls:172.3.4.5:5061 <http://172.3.4.5:5061>) 
> after the lookup, but that isn't helping either)
>
> Pete
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200622/804b80ce/attachment.html>

From osas at voipembedded.com  Mon Jun 22 18:33:27 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 22 Jun 2020 14:33:27 -0400
Subject: [OpenSIPS-Users] Homer docker integration -
	"api/preferences.php" file
In-Reply-To: <CAOXfywN3aeDi9Z4G2Ur4XwhK=hYTodgG8vCmLxNCRy-3QxYEXA@mail.gmail.com>
References: <CAOXfywN3aeDi9Z4G2Ur4XwhK=hYTodgG8vCmLxNCRy-3QxYEXA@mail.gmail.com>
Message-ID: <CAND0LktRiP=OovDJq+gyy0eCgx0xUA7NLAMsCLdbyVtq0NE7tg@mail.gmail.com>

On Tue, Jun 16, 2020 at 09:18 solarmon <solarmon at one-n.co.uk> wrote:

> Hi,
>
> I'm trying to set up and integrate Homer with my opensips setup.
>
> I have managed to install Homer on separatevittttbg VM, using the docker
> method as described at:
>
> https://github.com/sipcapture/homer/wiki/Quick-Install#-quick-install
>
> (I had to set SELINUX to permissive or disable for it to build - see
> https://github.com/sipcapture/homer7-docker/issues/81).
>
> I'm following this guide on how to integrate Homer with opensips:
>
>
> https://blog.opensips.org/2017/08/02/opensips-control-panel-and-homer-integration/
>
> On there, it talks about configuring Homer in the "api/preferences.php"
> file.
>
> With my limited experience and knowledge on Docker I'm not sure how/where
> to find this config file.
>
> Can somebody tell me where this  "api/preferences.php" file can be found
> within the Docker environment.
>
> Or can these settings be set within the Homer admin GUI Admin Settings
> instead? It looks like in the Advanced section of Settings I am able to add
> parameters, but it needs to have a 'category' assigned to it, which I don't
> know what it should be (if this is the equivalent way to do.it).
>
> Thank you!
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200622/c7badf43/attachment-0001.html>

From solarmon at one-n.co.uk  Mon Jun 22 20:54:43 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Mon, 22 Jun 2020 21:54:43 +0100
Subject: [OpenSIPS-Users] HEPv3 siptrace to Homer v7 - "Trailing stray
	characters"
In-Reply-To: <a7ef83d8-e3ce-8f4f-797b-37442f3b300c@opensips.org>
References: <CAOXfywMAudqfKJEkaLR8LaXCnFARt70mTywggrUekZU3cM7ZzA@mail.gmail.com>
 <a7ef83d8-e3ce-8f4f-797b-37442f3b300c@opensips.org>
Message-ID: <CAOXfywPLk6B9C0zJNTCoFg4eoGSGi0o0BrjNtuQ5GDb3p1ORTQ@mail.gmail.com>

Hi,

I had opened a GitHub for this issue:

https://github.com/OpenSIPS/opensips/issues/2146

(Sorry, I seem to have forgotten to put a title on it)

The opensips version is 2.4:

version: opensips 2.4.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
F_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: 3a566f1
main.c compiled on 09:53:43 Mar 15 2019



Thank you.

On Mon, 22 Jun 2020, 18:19 Bogdan-Andrei Iancu, <bogdan at opensips.org> wrote:

> Hi,
>
> What is the exact OpenSIPS version you have (opensips -V) ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>
> On 6/18/20 12:13 PM, solarmon wrote:
>
> Hi,
>
> I'm trying to set up siptrace to send HEPv3 packets to a Homer 7 setup.
>
> Currently this is not working and it seems the HEPv3 packets coming from
> opensips is not being ingested for some reason. Using hepgen (
> https://github.com/sipcapture/hepgen.js) to generate test HEPv3 traffic
> on the same opensips nodes is successful.
>
> When comparing both he captured opensips and hepgen generated HEPv3
> packets I notice the following difference which might explain why the
> opensips HEPv3 packets are not being ingested.
>
> I'm using the HEP dissector plugin for Wireshark from:
>
> https://github.com/sipcapture/hep-wireshark
>
> The opensips HEPv3 packet is decoded as HEPv3 by the dissector plugin, but
> it gives a working about "Trailing stray characters" for the packet.
> Inspecting the packet further I see that there is indeed extra data at the
> end. For example, the for the HEPv3 packet for INVITE there is the
> following data:
>
> .....70110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>
> (IP address sanitised)
>
> This seems to be the same value as for the Call-ID header:
>
> Call-ID: 0110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>
> I have the following config, which I pulled together from various sources
> - so I'm not sure whether this is correct or causing this issue:
>
> ### HEP Capture
>
> #TCP Hep listener
> listen=hep_tcp:w.x.y.z:6060
> #UDP Hep listener
> listen=hep_udp:w.x.y.z:6060
>
> loadmodule "proto_hep.so"
> modparam("proto_hep", "hep_id",
> "[homer]a.b.c.d:9060;transport=tcp;version=3;")
>
> #loadmodule "tls_mgm.so"
> #loadmodule "proto_tls.so"
> #modparam("proto_tls", "trace_destination", "homer")
> #modparam("proto_tls", "trace_filter_route", "trans_tracer")
>
> loadmodule "siptrace.so"
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_id", "[traceid]uri=hep:homer")
>
> ###
>
> and I'm call sip_trace() withing the main route{} function (just for
> testing at the moment):
>
> sip_trace("traceid","M","sip");
>
> Why is opensips adding this extra data at the end of the HEPv3 packets and
> is this expected/normal?
>
> If not expected/normal how should I change the opensips config to resolve
> it.
>
> Thank you.
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200622/43babd7e/attachment.html>

From adjolin at gmail.com  Mon Jun 22 22:23:06 2020
From: adjolin at gmail.com (Vic Jolin)
Date: Tue, 23 Jun 2020 06:23:06 +0800
Subject: [OpenSIPS-Users] dp_reload does not reload from database
Message-ID: <CAA+eT4nYncaLK+jZWUDJrJ7yLEDNX+=ZD+hz9B41hhc9DfJVeQ@mail.gmail.com>

Hi,

So I have this dialplan with attributes on it, and then I decided to remove
those attributes and after doing that  I executed "*opensips-cli -x mi
dp_reload*" and it says *OK*, but when I tried to dial, it still shows the
attributes.

I am using opensips 3.0, anything I can check?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/6532818e/attachment.html>

From rembgrets at gmail.com  Tue Jun 23 06:56:30 2020
From: rembgrets at gmail.com (ryan embgrets)
Date: Tue, 23 Jun 2020 11:56:30 +0500
Subject: [OpenSIPS-Users] Possibilities to handle short duration calls using
 new capabilities in opensips 3.1
Message-ID: <CAJ_X8k7Xq-fD76of47+qXcDFjcifi=N71nE8xZj13ZnDqnocMA@mail.gmail.com>

Greetings,

I would like to have awesome community suggestions in handling the short
duration calls.

My clients send short duration calls towards opensips.
So if a client sends me BYE within 6 seconds of the call, I would like to
terminate the client leg and keep carrier leg alive beyond a few seconds,
either by transferring the second leg(carrier side) to freeswitch, or
playing some media using rtpengine/rtpproxy at opensips side.

I would like to ask, is it something that can efficiently be done using new
capabilities in opensips 3.1?

How do other people handle this?

PS: I cannot restrict my client to not send me short duration calls, so
looking for an opensips way to handle this.

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/2d1e2abc/attachment.html>

From shegsdaps at gmail.com  Wed Jun  3 11:33:26 2020
From: shegsdaps at gmail.com (Segun Odunade)
Date: Wed, 03 Jun 2020 11:33:26 -0000
Subject: [OpenSIPS-Users] Help with Opensips Installation
Message-ID: <CAB=bwUfcy-MR0FYUsXs10-L5=mZK+4RAkJTtU4ju2xOYvFEr9A@mail.gmail.com>

Hi,

I recently tried to install opensips 24 on Ubuntu 18.04.4. I was able to
start and stop Opensips service successfully, however, when I installed
opensips-cp I ran into some issues.

For example, when I log into Opensips control panel, after clicking on
domain tab and reload server I get this error message:

"Sending to *json:127.0.0.1:8888/json <http://127.0.0.1:8888/json>* : Failed
to connect to 127.0.0.1 port 8888: Connection refused"

I ensured to configure httpd, which was in opensips.cfg but I still get the
same error.

I would appreciate it if you could assist me in resolving this issue. Thank
you.


Shegs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200603/8d62b20e/attachment-0001.html>

From Ben.Newlin at genesys.com  Mon Jun  8 12:46:21 2020
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Mon, 8 Jun 2020 12:46:21 +0000
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <CAD4_Da13uJdnLaw9U12p=GP8s39XeBdgjeRW6rXZC_xaBtThHg@mail.gmail.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
 <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
 <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
 <CAD4_Da13uJdnLaw9U12p=GP8s39XeBdgjeRW6rXZC_xaBtThHg@mail.gmail.com>
Message-ID: <3D86331D-0688-49BB-9F88-0619C80ABE07@genesys.com>

He is also performing dispatcher failover in these cases using ds_next_domain, which may not be necessary or warranted on an error code relayed from further upstream. Just removing ds_mark_dst will not resolve that. Although some extra unnecessary failover in error cases may not be an issue.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Diptesh Patel <diptesh.patel at ecosmob.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Monday, June 8, 2020 at 8:43 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being rejected with 480 Temporarily Unavailable

Hello Solarmon,

I think, The  ds_mark_dst("p"); put your destinations on Probing and after a few seconds you will get the reply for OPTIONS and now your destinations are Active. Are you making a second call immediately? If yes then it is clear. Please remove the ds_mark_dst("p"), OpenSIPS automatically change the destination's state using OPTIONS.

Thanks & Regards
Diptesh Patel
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:+919898962659


On Mon, Jun 8, 2020 at 4:27 PM solarmon <solarmon at one-n.co.uk<mailto:solarmon at one-n.co.uk>> wrote:
Hi Diptesh ,

Thanks for your reply.

Apologies, I'm using the term 'blacklist' to generally mean that the endpoints are not available.

Also, the 502 Bad Gateway is response to an INVITE, not SIP OPTIONS, returned by the far end and the ITSP is just passing that back to us, because the call has failed. For such call failures, I'm not expecting for the dispatcher endpoints to be marked as unavailable for routing.

I am not using, or have not set, the 'ds_define_blacklist (str)' option in my dispatcher module config.

My probing mode is:

modparam("dispatcher", "ds_probing_mode", 1)

I'm not seeing anything in the logs regarding the dispatcher nodes going into Probing mode - should there be logs for that, or can it be enabled to be logged?

When I check the endpoints with ' opensipsctl dispatcher dump' they always seem to be 'Active' - so it is either they are like that, or they may have only been in 'Probing' mode very briefly. Again, I was hoping to see mode/state change in the historical logs.

In my opensips.cfg (which was created for me) I can see the following code, which looks like this is where it is introducing this behaviour in question:

failure_route[call_failover]
{
        xlog("[$ci] call failed to established with $T_reply_code code\n");

        rtpproxy_unforce("$avp(rtpp_set)");

        if (t_was_cancelled()) {
                t_reply("487","Request cancelled");
                exit;
        }

        # any failure indication ?
        if ( t_check_status("[56][0-9][0-9]")
        || (t_check_status("408") && t_local_replied("all"))
        ) {
                xlog("[$ci] destination $rd failed  with $T_reply_code -> retry\n ");

                ds_mark_dst("p");

                if ( ds_next_domain() ) {
                        xlog("[$ci] using new destination <$rd>\n ");

                        # send it out again
                        t_on_failure("call_failover");
                        t_relay();
                        exit;
                } else {
                        xlog("[$ci] no other destination to retry\n ");
                        t_reply("503","Service not available");
                        exit;
                }
        }

        # if call failure, allow the reply to propagate to caller
        exit;
}


Thank you for the tip about the  'modparam("dispatcher", "options_reply_codes", "502")' option. I will try that if it is not recommend to change the above code.

Thank you.


On Mon, 8 Jun 2020 at 10:47, Diptesh Patel <diptesh.patel at ecosmob.com<mailto:diptesh.patel at ecosmob.com>> wrote:
Hello Solarmon,

Need some clarification on term blacklisting, Are you using the blacklist for Probing Mode of destination? or Are you using the 'ds_define_blacklist (str)' parameter. If you are not using the blacklist parameter then below information help you. It is great if you share your script snippet and output of 'opensipsctl dispatcher dump' which shows you the current status of your destinations.

If you are getting success(200 OK) response on OPTIONS then it is not possible that you got a negative response from a destination and it will not be blacklisted(probing mode) in dispatcher until you blacklist(probing mode) from the script using 'ds_mark_dst()' exported function. I doubt that you are also getting '502 Bad Gateway' on OPTIONS which is sending to the destination to check the availability.  If It is right and you want to add the 502 response as a good response for OPTIONS. you can add the 502 as 'modparam("dispatcher", "options_reply_codes", "502")'.

Thanks & Regards
Diptesh Patel
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:+919898962659


On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk<mailto:solarmon at one-n.co.uk>> wrote:
Hi,

I'm trying to understand whether this is the correct or expected behaviour.

We have two destinations configured in Dispatcher.

What I am noticing is that when we receive 502 Bad Gateway messages (logged as ("call failed to established with 502 code") from both endpoints. After both endpoints have returned 502 Bad Gateway, opensips pass back 503 Service Unavailable back to the originating endpoint of the call. However, subsequent calls are being immediately rejected with 480 Temporarily Unavailable (logged as "failed to find an available destination, rejecting") for a period of time.

It seems that opensips is blacklisting the Dispatcher endpoints because of receiving the 502 Bad Gateway messages. Is this the correct/expected behaviour? I would have thought the blacklisting should be based on the SIP OPTIONS sent to the Dispatcher endpoints.

I do not currently see any issues with SIP OPTIONS to these endpoints so I'm confused as to why they are seemingly blacklisted.

If this is the correct/expected behaviour, can it be changed to only blacklist based on the SIP OPTIONs pings?

Thank you.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200608/6b22e479/attachment-0001.html>

From razvan at opensips.org  Tue Jun 23 08:08:32 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 23 Jun 2020 11:08:32 +0300
Subject: [OpenSIPS-Users] New Errors
In-Reply-To: <CAC9cSOBRMdEpmaegccrdF7abq=ROmc1wuWy6o2FWwtjRu_YhyA@mail.gmail.com>
References: <CAC9cSOBRMdEpmaegccrdF7abq=ROmc1wuWy6o2FWwtjRu_YhyA@mail.gmail.com>
Message-ID: <406858b1-aa16-538c-6d33-4f399fe60b77@opensips.org>

Hi, Michael!

I believe you are running the do_accounting() function with the "CDR" 
flag on a BYE message - this is not correct, the "cdr" flag should only 
be used on initial INVITEs.

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 6/13/20 6:30 PM, Saint Michael wrote:
> WARNING:dialog:register_dlgcb: Cannot register callbacks in DELETED 
> state (type 2000)!
> ERROR:acc:acc_onreply: cannot register callback for context serialization
> Any idea what these errors mean?
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


From razvan at opensips.org  Tue Jun 23 08:10:12 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 23 Jun 2020 11:10:12 +0300
Subject: [OpenSIPS-Users] CDR no longer work for permission denied
In-Reply-To: <CAC9cSOAuK+fUVYAV5g_3OEk1pU1h6cpTXEw-Htoii9_BsKz5zg@mail.gmail.com>
References: <CAC9cSOAuK+fUVYAV5g_3OEk1pU1h6cpTXEw-Htoii9_BsKz5zg@mail.gmail.com>
Message-ID: <72a4b699-4d63-0df9-3e05-1fb45c5e2f4b@opensips.org>

Can you provide more information abut the environment you're running on?
Is it debian or redhat based, could you send us the fifo file 
permissions, as well as the user OpenSIPS is running with?

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 6/14/20 2:16 PM, Saint Michael wrote:
> /usr/local/sbin/opensipsctl fifo flat_rotate
> /usr/local//lib64/opensips/opensipsctl/opensipsctl.fifo: line 121: 
> /tmp/opensips_fifo: Permission denied
> This happened after upgrading my kernel to 5.4.0-37-generic
> although I cannot see the connection.
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


From solarmon at one-n.co.uk  Tue Jun 23 08:43:31 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Tue, 23 Jun 2020 09:43:31 +0100
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <3D86331D-0688-49BB-9F88-0619C80ABE07@genesys.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
 <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
 <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
 <CAD4_Da13uJdnLaw9U12p=GP8s39XeBdgjeRW6rXZC_xaBtThHg@mail.gmail.com>
 <3D86331D-0688-49BB-9F88-0619C80ABE07@genesys.com>
Message-ID: <CAOXfywMoyi9AfW_gzt7o9R2uWuns-VDWXF3d1qossfN72kX52g@mail.gmail.com>

Hi Ben,

Removing "ds_mark_dst" for this particular case resolved the behaviour of
unnecessarily/incorrectly putting the endpoint into Probing mode. I don't
understand the code completely (it was written for us) but this small
change is good enough for us, for now.

Thank you.

On Tue, 23 Jun 2020 at 08:15, Ben Newlin <Ben.Newlin at genesys.com> wrote:

> He is also performing dispatcher failover in these cases using
> ds_next_domain, which may not be necessary or warranted on an error code
> relayed from further upstream. Just removing ds_mark_dst will not resolve
> that. Although some extra unnecessary failover in error cases may not be an
> issue.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users <users-bounces at lists.opensips.org> on behalf of Diptesh
> Patel <diptesh.patel at ecosmob.com>
> *Reply-To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Date: *Monday, June 8, 2020 at 8:43 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] 502 Bad Gateway events leads to calls
> being rejected with 480 Temporarily Unavailable
>
>
>
> Hello Solarmon,
>
>
>
> I think, The * ds_mark_dst("p");* put your destinations on Probing and
> after a few seconds you will get the reply for OPTIONS and now your
> destinations are Active. Are you making a second call immediately? If yes
> then it is clear. Please remove the ds_mark_dst("p"), OpenSIPS
> automatically change the destination's state using OPTIONS.
>
>
>
> Thanks & Regards
>
> *Diptesh Patel*
>
> Software Developer
>
> Ecosmob Technologies Ltd,
>
> Ahmedabad
>
> Mo:*+919898962659*
>
>
>
>
>
> On Mon, Jun 8, 2020 at 4:27 PM solarmon <solarmon at one-n.co.uk> wrote:
>
> Hi Diptesh ,
>
>
>
> Thanks for your reply.
>
>
>
> Apologies, I'm using the term 'blacklist' to generally mean that the
> endpoints are not available.
>
>
>
> Also, the 502 Bad Gateway is response to an INVITE, not SIP OPTIONS,
> returned by the far end and the ITSP is just passing that back to us,
> because the call has failed. For such call failures, I'm not expecting for
> the dispatcher endpoints to be marked as unavailable for routing.
>
>
>
> I am not using, or have not set, the '*ds_define_blacklist (str)*' option
> in my dispatcher module config.
>
>
>
> My probing mode is:
>
>
>
> modparam("dispatcher", "ds_probing_mode", 1)
>
>
>
> I'm not seeing anything in the logs regarding the dispatcher nodes going
> into Probing mode - should there be logs for that, or can it be enabled to
> be logged?
>
>
>
> When I check the endpoints with ' opensipsctl dispatcher dump' they always
> seem to be '*Active*' - so it is either they are like that, or they
> may have only been in '*Probing*' mode very briefly. Again, I was hoping
> to see mode/state change in the historical logs.
>
>
>
> In my *opensips.cfg* (which was created for me) I can see the following
> code, which looks like this is where it is introducing this behaviour in
> question:
>
>
>
> failure_route[call_failover]
>
> {
>
>         xlog("[$ci] call failed to established with $T_reply_code code\n");
>
>
>
>         rtpproxy_unforce("$avp(rtpp_set)");
>
>
>
>         if (t_was_cancelled()) {
>
>                 t_reply("487","Request cancelled");
>
>                 exit;
>
>         }
>
>
>
>         # any failure indication ?
>
>         if ( t_check_status("[56][0-9][0-9]")
>
>         || (t_check_status("408") && t_local_replied("all"))
>
>         ) {
>
>                 xlog("[$ci] destination $rd failed  with $T_reply_code ->
> retry\n ");
>
>
>
>                * ds_mark_dst("p");*
>
>
>
>                 if ( ds_next_domain() ) {
>
>                         xlog("[$ci] using new destination <$rd>\n ");
>
>
>
>                         # send it out again
>
>                         t_on_failure("call_failover");
>
>                         t_relay();
>
>                         exit;
>
>                 } else {
>
>                         xlog("[$ci] no other destination to retry\n ");
>
>                         t_reply("503","Service not available");
>
>                         exit;
>
>                 }
>
>         }
>
>
>
>         # if call failure, allow the reply to propagate to caller
>
>         exit;
>
> }
>
>
>
>
>
> Thank you for the tip about the  'modparam("dispatcher",
> "options_reply_codes", "502")' option. I will try that if it is not
> recommend to change the above code.
>
>
>
> Thank you.
>
>
>
>
>
> On Mon, 8 Jun 2020 at 10:47, Diptesh Patel <diptesh.patel at ecosmob.com>
> wrote:
>
> Hello Solarmon,
>
>
>
> Need some clarification on term blacklisting, Are you using the blacklist
> for Probing Mode of destination? or Are you using the *'ds_define_blacklist
> (str)' *parameter. If you are not using the blacklist parameter then
> below information help you. It is great if you share your script snippet
> and output of *'opensipsctl dispatcher dump'* which shows you the current
> status of your destinations.
>
>
>
> If you are getting success(200 OK) response on OPTIONS then it is not
> possible that you got a negative response from a destination and it will
> not be blacklisted(probing mode) in dispatcher until you blacklist(probing
> mode) from the script using 'ds_mark_dst()' exported function. I doubt that
> you are also getting '502 Bad Gateway' on OPTIONS which is sending to the
> destination to check the availability.  If It is right and you want to add
> the 502 response as a good response for OPTIONS. you can add the 502 as *'modparam("dispatcher",
> "options_reply_codes", "502")'.*
>
>
>
> Thanks & Regards
>
> *Diptesh Patel*
>
> Software Developer
>
> Ecosmob Technologies Ltd,
>
> Ahmedabad
>
> Mo:*+919898962659*
>
>
>
>
>
> On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk> wrote:
>
> Hi,
>
>
>
> I'm trying to understand whether this is the correct or expected behaviour.
>
>
>
> We have two destinations configured in Dispatcher.
>
>
>
> What I am noticing is that when we receive 502 Bad Gateway messages
> (logged as ("call failed to established with 502 code") from both
> endpoints. After both endpoints have returned 502 Bad Gateway, opensips
> pass back 503 Service Unavailable back to the originating endpoint of the
> call. However, subsequent calls are being immediately rejected with 480
> Temporarily Unavailable (logged as "failed to find an available
> destination, rejecting") for a period of time.
>
>
>
> It seems that opensips is blacklisting the Dispatcher endpoints because of
> receiving the 502 Bad Gateway messages. Is this the correct/expected
> behaviour? I would have thought the blacklisting should be based on the SIP
> OPTIONS sent to the Dispatcher endpoints.
>
>
>
> I do not currently see any issues with SIP OPTIONS to these endpoints so
> I'm confused as to why they are seemingly blacklisted.
>
>
>
> If this is the correct/expected behaviour, can it be changed to only
> blacklist based on the SIP OPTIONs pings?
>
>
>
> Thank you.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> *Disclaimer*
>
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
>
>
> *Confidentiality*
>
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
>
>
> *Caution for viruses, malware etc.*
>
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> *Disclaimer*
>
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
>
>
> *Confidentiality*
>
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
>
>
> *Caution for viruses, malware etc.*
>
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/ac4ff39f/attachment-0001.html>

From bogdan at opensips.org  Tue Jun 23 10:01:13 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Jun 2020 13:01:13 +0300
Subject: [OpenSIPS-Users] HEPv3 siptrace to Homer v7 - "Trailing stray
 characters"
In-Reply-To: <CAOXfywPLk6B9C0zJNTCoFg4eoGSGi0o0BrjNtuQ5GDb3p1ORTQ@mail.gmail.com>
References: <CAOXfywMAudqfKJEkaLR8LaXCnFARt70mTywggrUekZU3cM7ZzA@mail.gmail.com>
 <a7ef83d8-e3ce-8f4f-797b-37442f3b300c@opensips.org>
 <CAOXfywPLk6B9C0zJNTCoFg4eoGSGi0o0BrjNtuQ5GDb3p1ORTQ@mail.gmail.com>
Message-ID: <c6e60188-8edd-d42b-b91f-100aef8ab773@opensips.org>

OK, let's continue on the ticket.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/22/20 11:54 PM, solarmon wrote:
> Hi,
>
> I had opened a GitHub for this issue:
>
> https://github.com/OpenSIPS/opensips/issues/2146
>
> (Sorry, I seem to have forgotten to put a title on it)
>
> The opensips version is 2.4:
>
> |version: opensips 2.4.5 (x86_64/linux) flags: STATS: On, 
> DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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: 3a566f1 main.c 
> compiled on 09:53:43 Mar 15 2019 |
>
>
> Thank you.
>
> On Mon, 22 Jun 2020, 18:19 Bogdan-Andrei Iancu, <bogdan at opensips.org 
> <mailto:bogdan at opensips.org>> wrote:
>
>     Hi,
>
>     What is the exact OpenSIPS version you have (opensips -V) ?
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        https://www.opensips-solutions.com
>
>     On 6/18/20 12:13 PM, solarmon wrote:
>>     Hi,
>>
>>     I'm trying to set up siptrace to send HEPv3 packets to a Homer 7
>>     setup.
>>
>>     Currently this is not working and it seems the HEPv3 packets
>>     coming from opensips is not being ingested for some reason. Using
>>     hepgen (https://github.com/sipcapture/hepgen.js) to generate test
>>     HEPv3 traffic on the same opensips nodes is successful.
>>
>>     When comparing both he captured opensips and hepgen generated
>>     HEPv3 packets I notice the following difference which might
>>     explain why the opensips HEPv3 packets are not being ingested.
>>
>>     I'm using the HEP dissector plugin for Wireshark from:
>>
>>     https://github.com/sipcapture/hep-wireshark
>>
>>     The opensips HEPv3 packet is decoded as HEPv3 by the dissector
>>     plugin, but it gives a working about "Trailing stray characters"
>>     for the packet. Inspecting the packet further I see that there is
>>     indeed extra data at the end. For example, the for the HEPv3
>>     packet for INVITE there is the following data:
>>
>>     .....70110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>>
>>     (IP address sanitised)
>>
>>     This seems to be the same value as for the Call-ID header:
>>
>>     Call-ID: 0110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>>     <mailto:0110F001-0000FA9B-5EEA5D1C-0000000E at ip.address>
>>
>>     I have the following config, which I pulled together from various
>>     sources - so I'm not sure whether this is correct or causing this
>>     issue:
>>
>>     ### HEP Capture
>>
>>     #TCP Hep listener
>>     listen=hep_tcp:w.x.y.z:6060
>>     #UDP Hep listener
>>     listen=hep_udp:w.x.y.z:6060
>>
>>     loadmodule "proto_hep.so"
>>     modparam("proto_hep", "hep_id",
>>     "[homer]a.b.c.d:9060;transport=tcp;version=3;")
>>
>>     #loadmodule "tls_mgm.so"
>>     #loadmodule "proto_tls.so"
>>     #modparam("proto_tls", "trace_destination", "homer")
>>     #modparam("proto_tls", "trace_filter_route", "trans_tracer")
>>
>>     loadmodule "siptrace.so"
>>     modparam("siptrace", "trace_on", 1)
>>     modparam("siptrace", "trace_id", "[traceid]uri=hep:homer")
>>
>>     ###
>>
>>     and I'm call sip_trace() withing the main route{} function (just
>>     for testing at the moment):
>>
>>     sip_trace("traceid","M","sip");
>>
>>     Why is opensips adding this extra data at the end of the HEPv3
>>     packets and is this expected/normal?
>>
>>     If not expected/normal how should I change the opensips config to
>>     resolve it.
>>
>>     Thank you.
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/bb55ae1f/attachment.html>

From adrian.fretwell at topgreen.co.uk  Tue Jun 23 10:35:57 2020
From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell)
Date: Tue, 23 Jun 2020 11:35:57 +0100
Subject: [OpenSIPS-Users] Nathelper - will not send SIP OPTIONS pings
Message-ID: <48eb36c7-db5a-173d-f33b-01d43e009c42@topgreen.co.uk>

Hello All,

Opensips v3.0.

I have a simple routing script that implements a mid-registrar. All of 
the endpoints are behind NAT so I need the proxy to send keep alive pings.

I have the nathelper module loaded with the following configuration:

/* --- Module NATHELPER ---------------

  NAT traversal helper module
  ------------------------------------*/
loadmodule "nathelper.so"
modparam("nathelper", "natping_interval", 30)
modparam("nathelper", "ping_nated_only", 0)
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "sipping_bflag", "SIPPING_ENABLE")
modparam("nathelper", "sipping_from", "sip:pinger at mrp1.xxxx.uk")
modparam("nathelper", "received_avp", "$avp(received_nh)")
modparam("nathelper", "ping_threshold", 5)
modparam("nathelper", "max_pings_lost", 3)
modparam("nathelper", "natping_partitions", 4)
modparam("nathelper", "remove_on_timeout_bflag", "SIPPING_RTO")
modparam("nathelper", "natping_tcp", 1)

The nathelper module is sending the 4 byte UDP packets (verified by 
packet capture), but I cannot get it to send SIP OPTIONS pings.

According to paragraph 1.2 (NAT pinging types), there are two types, UDP 
package and SIP request.  I cannot work out how to make it use SIP request.

I assume that I do need SIP OPTIONS pings for the removal_on_timeout to 
work.

Can anyone point me in the right direction please?



Kind regards,

Adrian Fretwell
Sibthorpe
Nottinghamshire

UK.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/afce7232/attachment.html>

From venefax at gmail.com  Tue Jun 23 12:03:23 2020
From: venefax at gmail.com (Saint Michael)
Date: Tue, 23 Jun 2020 08:03:23 -0400
Subject: [OpenSIPS-Users] CDR no longer work for permission denied
In-Reply-To: <72a4b699-4d63-0df9-3e05-1fb45c5e2f4b@opensips.org>
References: <CAC9cSOAuK+fUVYAV5g_3OEk1pU1h6cpTXEw-Htoii9_BsKz5zg@mail.gmail.com>
 <72a4b699-4d63-0df9-3e05-1fb45c5e2f4b@opensips.org>
Message-ID: <CAC9cSOBHhpQMAreJoOVULMV6m_jP9wvMzJoZcT2fbfMauCAypw@mail.gmail.com>

Please ask Vlad Paiu. He fixed it. It turns out that in the new kernel
5.4.0-37-generic of Ubuntu 20.04, the fifo has a lock, so he took these
steps:
mkdir /home/opensips
chown -R opensips:opensips /home/opensips/
/etc/opensips/opensips.cfg , changed to modparam("mi_fifo", "fifo_name",
"/home/opensips/opensips_fifo")
/usr/local/etc/opensips/opensipsctlrc , added
OSIPS_FIFO="/home/opensips/opensips_fifo"

I think this should the canonical way this should work.




On Tue, Jun 23, 2020 at 4:12 AM Răzvan Crainea <razvan at opensips.org> wrote:

> Can you provide more information abut the environment you're running on?
> Is it debian or redhat based, could you send us the fifo file
> permissions, as well as the user OpenSIPS is running with?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 6/14/20 2:16 PM, Saint Michael wrote:
> > /usr/local/sbin/opensipsctl fifo flat_rotate
> > /usr/local//lib64/opensips/opensipsctl/opensipsctl.fifo: line 121:
> > /tmp/opensips_fifo: Permission denied
> > This happened after upgrading my kernel to 5.4.0-37-generic
> > although I cannot see the connection.
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/88edc1af/attachment-0001.html>

From bogdan at opensips.org  Tue Jun 23 13:33:08 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Jun 2020 16:33:08 +0300
Subject: [OpenSIPS-Users] Nathelper - will not send SIP OPTIONS pings
In-Reply-To: <48eb36c7-db5a-173d-f33b-01d43e009c42@topgreen.co.uk>
References: <48eb36c7-db5a-173d-f33b-01d43e009c42@topgreen.co.uk>
Message-ID: <321d9390-58b3-8979-3d33-d13851068527@opensips.org>

Hi Adrian,

Do you set the SIPPING_ENABLE bflag before saving the contact ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/23/20 1:35 PM, Adrian Fretwell wrote:
>
> Hello All,
>
> Opensips v3.0.
>
> I have a simple routing script that implements a mid-registrar.  All 
> of the endpoints are behind NAT so I need the proxy to send keep alive 
> pings.
>
> I have the nathelper module loaded with the following configuration:
>
> /* --- Module NATHELPER ---------------
>
>  NAT traversal helper module
>  ------------------------------------*/
> loadmodule "nathelper.so"
> modparam("nathelper", "natping_interval", 30)
> modparam("nathelper", "ping_nated_only", 0)
> modparam("nathelper", "sipping_method", "OPTIONS")
> modparam("nathelper", "sipping_bflag", "SIPPING_ENABLE")
> modparam("nathelper", "sipping_from", "sip:pinger at mrp1.xxxx.uk")
> modparam("nathelper", "received_avp", "$avp(received_nh)")
> modparam("nathelper", "ping_threshold", 5)
> modparam("nathelper", "max_pings_lost", 3)
> modparam("nathelper", "natping_partitions", 4)
> modparam("nathelper", "remove_on_timeout_bflag", "SIPPING_RTO")
> modparam("nathelper", "natping_tcp", 1)
>
> The nathelper module is sending the 4 byte UDP packets (verified by 
> packet capture), but I cannot get it to send SIP OPTIONS pings.
>
> According to paragraph 1.2 (NAT pinging types), there are two types, 
> UDP package and SIP request.  I cannot work out how to make it use SIP 
> request.
>
> I assume that I do need SIP OPTIONS pings for the removal_on_timeout 
> to work.
>
> Can anyone point me in the right direction please?
>
>
>
> Kind regards,
>
> Adrian Fretwell
> Sibthorpe
> Nottinghamshire
>
> UK.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/0a8bd9c3/attachment.html>

From adrian.fretwell at topgreen.co.uk  Tue Jun 23 14:31:22 2020
From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell)
Date: Tue, 23 Jun 2020 15:31:22 +0100
Subject: [OpenSIPS-Users] Nathelper - will not send SIP OPTIONS pings
In-Reply-To: <321d9390-58b3-8979-3d33-d13851068527@opensips.org>
References: <48eb36c7-db5a-173d-f33b-01d43e009c42@topgreen.co.uk>
 <321d9390-58b3-8979-3d33-d13851068527@opensips.org>
Message-ID: <c008c5ae-7a5f-0a7b-4124-9cd228cb2e69@topgreen.co.uk>

Hi Bogdan,

Thankyou, SIPPING_ENABLE bflag was olny being set where nat_uac_test was 
returning true.

When I set SIPPING_ENABLE bflag irrespective of nat_uac_test, I see the 
SIP OPTIONS pings.

I did not realise that even with modparam("nathelper", 
"ping_nated_only", 0) set, the bflag was still required for the OPTIONS 
ping.

Thank you again.


Kind regards,

Adrian Fretwell

Sibthorpe
Nottinghamshire
UK.


On 23/06/2020 14:33, Bogdan-Andrei Iancu wrote:
> Hi Adrian,
>
> Do you set the SIPPING_ENABLE bflag before saving the contact ?
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
>
> On 6/23/20 1:35 PM, Adrian Fretwell wrote:
>>
>> Hello All,
>>
>> Opensips v3.0.
>>
>> I have a simple routing script that implements a mid-registrar.  All 
>> of the endpoints are behind NAT so I need the proxy to send keep 
>> alive pings.
>>
>> I have the nathelper module loaded with the following configuration:
>>
>> /* --- Module NATHELPER ---------------
>>
>>  NAT traversal helper module
>>  ------------------------------------*/
>> loadmodule "nathelper.so"
>> modparam("nathelper", "natping_interval", 30)
>> modparam("nathelper", "ping_nated_only", 0)
>> modparam("nathelper", "sipping_method", "OPTIONS")
>> modparam("nathelper", "sipping_bflag", "SIPPING_ENABLE")
>> modparam("nathelper", "sipping_from", "sip:pinger at mrp1.xxxx.uk")
>> modparam("nathelper", "received_avp", "$avp(received_nh)")
>> modparam("nathelper", "ping_threshold", 5)
>> modparam("nathelper", "max_pings_lost", 3)
>> modparam("nathelper", "natping_partitions", 4)
>> modparam("nathelper", "remove_on_timeout_bflag", "SIPPING_RTO")
>> modparam("nathelper", "natping_tcp", 1)
>>
>> The nathelper module is sending the 4 byte UDP packets (verified by 
>> packet capture), but I cannot get it to send SIP OPTIONS pings.
>>
>> According to paragraph 1.2 (NAT pinging types), there are two types, 
>> UDP package and SIP request.  I cannot work out how to make it use 
>> SIP request.
>>
>> I assume that I do need SIP OPTIONS pings for the removal_on_timeout 
>> to work.
>>
>> Can anyone point me in the right direction please?
>>
>>
>>
>> Kind regards,
>>
>> Adrian Fretwell
>> Sibthorpe
>> Nottinghamshire
>>
>> UK.
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/ba500b3d/attachment.html>

From Ben.Newlin at genesys.com  Tue Jun 23 12:37:22 2020
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Tue, 23 Jun 2020 12:37:22 +0000
Subject: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being
 rejected with 480 Temporarily Unavailable
In-Reply-To: <CAOXfywMoyi9AfW_gzt7o9R2uWuns-VDWXF3d1qossfN72kX52g@mail.gmail.com>
References: <CAOXfywP_HZVRYEnkGbKR2oLPSwpbu8RJQ6+9zfYsLZViNbeD7w@mail.gmail.com>
 <CAD4_Da2OxFmzpHmFvLcOBRb88bqaKX3N0VwYObTprvzBa=mRPg@mail.gmail.com>
 <CAOXfywO+o2vm+5zz+EjTZBuv7sCm3MiWZ4QAguZtrAPjYW6z9g@mail.gmail.com>
 <CAD4_Da13uJdnLaw9U12p=GP8s39XeBdgjeRW6rXZC_xaBtThHg@mail.gmail.com>
 <3D86331D-0688-49BB-9F88-0619C80ABE07@genesys.com>
 <CAOXfywMoyi9AfW_gzt7o9R2uWuns-VDWXF3d1qossfN72kX52g@mail.gmail.com>
Message-ID: <6CB3B496-FAD0-4FE4-B0CB-3F7F8B171CC1@genesys.com>

Yes, I saw your other response. I had sent this reply before that and it appears to have gotten stuck in the email list until now. ☺

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of solarmon <solarmon at one-n.co.uk>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Tuesday, June 23, 2020 at 4:45 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being rejected with 480 Temporarily Unavailable

Hi Ben,

Removing "ds_mark_dst" for this particular case resolved the behaviour of unnecessarily/incorrectly putting the endpoint into Probing mode. I don't understand the code completely (it was written for us) but this small change is good enough for us, for now.

Thank you.

On Tue, 23 Jun 2020 at 08:15, Ben Newlin <Ben.Newlin at genesys.com<mailto:Ben.Newlin at genesys.com>> wrote:
He is also performing dispatcher failover in these cases using ds_next_domain, which may not be necessary or warranted on an error code relayed from further upstream. Just removing ds_mark_dst will not resolve that. Although some extra unnecessary failover in error cases may not be an issue.

Ben Newlin

From: Users <users-bounces at lists.opensips.org<mailto:users-bounces at lists.opensips.org>> on behalf of Diptesh Patel <diptesh.patel at ecosmob.com<mailto:diptesh.patel at ecosmob.com>>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
Date: Monday, June 8, 2020 at 8:43 AM
To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] 502 Bad Gateway events leads to calls being rejected with 480 Temporarily Unavailable

Hello Solarmon,

I think, The  ds_mark_dst("p"); put your destinations on Probing and after a few seconds you will get the reply for OPTIONS and now your destinations are Active. Are you making a second call immediately? If yes then it is clear. Please remove the ds_mark_dst("p"), OpenSIPS automatically change the destination's state using OPTIONS.

Thanks & Regards
Diptesh Patel
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:+919898962659


On Mon, Jun 8, 2020 at 4:27 PM solarmon <solarmon at one-n.co.uk<mailto:solarmon at one-n.co.uk>> wrote:
Hi Diptesh ,

Thanks for your reply.

Apologies, I'm using the term 'blacklist' to generally mean that the endpoints are not available.

Also, the 502 Bad Gateway is response to an INVITE, not SIP OPTIONS, returned by the far end and the ITSP is just passing that back to us, because the call has failed. For such call failures, I'm not expecting for the dispatcher endpoints to be marked as unavailable for routing.

I am not using, or have not set, the 'ds_define_blacklist (str)' option in my dispatcher module config.

My probing mode is:

modparam("dispatcher", "ds_probing_mode", 1)

I'm not seeing anything in the logs regarding the dispatcher nodes going into Probing mode - should there be logs for that, or can it be enabled to be logged?

When I check the endpoints with ' opensipsctl dispatcher dump' they always seem to be 'Active' - so it is either they are like that, or they may have only been in 'Probing' mode very briefly. Again, I was hoping to see mode/state change in the historical logs.

In my opensips.cfg (which was created for me) I can see the following code, which looks like this is where it is introducing this behaviour in question:

failure_route[call_failover]
{
        xlog("[$ci] call failed to established with $T_reply_code code\n");

        rtpproxy_unforce("$avp(rtpp_set)");

        if (t_was_cancelled()) {
                t_reply("487","Request cancelled");
                exit;
        }

        # any failure indication ?
        if ( t_check_status("[56][0-9][0-9]")
        || (t_check_status("408") && t_local_replied("all"))
        ) {
                xlog("[$ci] destination $rd failed  with $T_reply_code -> retry\n ");

                ds_mark_dst("p");

                if ( ds_next_domain() ) {
                        xlog("[$ci] using new destination <$rd>\n ");

                        # send it out again
                        t_on_failure("call_failover");
                        t_relay();
                        exit;
                } else {
                        xlog("[$ci] no other destination to retry\n ");
                        t_reply("503","Service not available");
                        exit;
                }
        }

        # if call failure, allow the reply to propagate to caller
        exit;
}


Thank you for the tip about the  'modparam("dispatcher", "options_reply_codes", "502")' option. I will try that if it is not recommend to change the above code.

Thank you.


On Mon, 8 Jun 2020 at 10:47, Diptesh Patel <diptesh.patel at ecosmob.com<mailto:diptesh.patel at ecosmob.com>> wrote:
Hello Solarmon,

Need some clarification on term blacklisting, Are you using the blacklist for Probing Mode of destination? or Are you using the 'ds_define_blacklist (str)' parameter. If you are not using the blacklist parameter then below information help you. It is great if you share your script snippet and output of 'opensipsctl dispatcher dump' which shows you the current status of your destinations.

If you are getting success(200 OK) response on OPTIONS then it is not possible that you got a negative response from a destination and it will not be blacklisted(probing mode) in dispatcher until you blacklist(probing mode) from the script using 'ds_mark_dst()' exported function. I doubt that you are also getting '502 Bad Gateway' on OPTIONS which is sending to the destination to check the availability.  If It is right and you want to add the 502 response as a good response for OPTIONS. you can add the 502 as 'modparam("dispatcher", "options_reply_codes", "502")'.

Thanks & Regards
Diptesh Patel
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:+919898962659


On Mon, Jun 8, 2020 at 2:24 PM solarmon <solarmon at one-n.co.uk<mailto:solarmon at one-n.co.uk>> wrote:
Hi,

I'm trying to understand whether this is the correct or expected behaviour.

We have two destinations configured in Dispatcher.

What I am noticing is that when we receive 502 Bad Gateway messages (logged as ("call failed to established with 502 code") from both endpoints. After both endpoints have returned 502 Bad Gateway, opensips pass back 503 Service Unavailable back to the originating endpoint of the call. However, subsequent calls are being immediately rejected with 480 Temporarily Unavailable (logged as "failed to find an available destination, rejecting") for a period of time.

It seems that opensips is blacklisting the Dispatcher endpoints because of receiving the 502 Bad Gateway messages. Is this the correct/expected behaviour? I would have thought the blacklisting should be based on the SIP OPTIONS sent to the Dispatcher endpoints.

I do not currently see any issues with SIP OPTIONS to these endpoints so I'm confused as to why they are seemingly blacklisted.

If this is the correct/expected behaviour, can it be changed to only blacklist based on the SIP OPTIONs pings?

Thank you.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/434301c1/attachment-0001.html>

From farmorg at gmail.com  Tue Jun 23 15:06:44 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Tue, 23 Jun 2020 16:06:44 +0100
Subject: [OpenSIPS-Users] Specify Port for db_url
Message-ID: <CAOvQDetjdN5fFujvEFnGi=S1LyyRdyj8U8qqDKN6Mq2Ogc5qDw@mail.gmail.com>

Hi everyone

I need to connect the acc module to a different DB which uses haproxy on
port 3308.

I've checked the documentation for acc but there's no mention of database
ports.
Is it possible to specify a different port?

For example:

modparam("acc", "db_url", "mysql://username:password at XXX.XXX.XXX.XXX
:3308/opensips_cdr")

opensips 3.0.2

Many thanks!
Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/cf5b2466/attachment.html>

From liviu at opensips.org  Tue Jun 23 15:07:32 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 23 Jun 2020 18:07:32 +0300
Subject: [OpenSIPS-Users] Specify Port for db_url
In-Reply-To: <CAOvQDetjdN5fFujvEFnGi=S1LyyRdyj8U8qqDKN6Mq2Ogc5qDw@mail.gmail.com>
References: <CAOvQDetjdN5fFujvEFnGi=S1LyyRdyj8U8qqDKN6Mq2Ogc5qDw@mail.gmail.com>
Message-ID: <99098b38-374d-ebdd-8824-6d973a06fee8@opensips.org>

On 23.06.2020 18:06, Mark Farmer wrote:
> Is it possible to specify a different port?

Yes

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com



From farmorg at gmail.com  Tue Jun 23 15:34:07 2020
From: farmorg at gmail.com (Mark Farmer)
Date: Tue, 23 Jun 2020 16:34:07 +0100
Subject: [OpenSIPS-Users] Specify Port for db_url
In-Reply-To: <99098b38-374d-ebdd-8824-6d973a06fee8@opensips.org>
References: <CAOvQDetjdN5fFujvEFnGi=S1LyyRdyj8U8qqDKN6Mq2Ogc5qDw@mail.gmail.com>
 <99098b38-374d-ebdd-8824-6d973a06fee8@opensips.org>
Message-ID: <CAOvQDet6ay1S=76+Kic=Ry7vzgKL7xOMs7iiOvrvEO2mY_qUzA@mail.gmail.com>

Thanks :)


On Tue, 23 Jun 2020 at 16:09, Liviu Chircu <liviu at opensips.org> wrote:

> On 23.06.2020 18:06, Mark Farmer wrote:
> > Is it possible to specify a different port?
>
> Yes
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200623/794a9751/attachment.html>

From ffshoh at gmail.com  Tue Jun 23 19:43:34 2020
From: ffshoh at gmail.com (Jon Abrams)
Date: Tue, 23 Jun 2020 14:43:34 -0500
Subject: [OpenSIPS-Users] Possibilities to handle short duration calls
 using new capabilities in opensips 3.1
In-Reply-To: <CAJ_X8k7Xq-fD76of47+qXcDFjcifi=N71nE8xZj13ZnDqnocMA@mail.gmail.com>
References: <CAJ_X8k7Xq-fD76of47+qXcDFjcifi=N71nE8xZj13ZnDqnocMA@mail.gmail.com>
Message-ID: <CAP9sNzEvPQnT2V0997mW3Exp+HQN7Aj-ShdWPnmbN9aaivgiZQ@mail.gmail.com>

You may be able to use the load_dialog_ctx()/unload_dialog_ctx()
dialog functions to peek at the dialog when a BYE is received, prior
to invoking match_dialog(). If it is a BYE from the calling party that
you wish to delay, use an async sleep() to delay the call of
match_dialog() and relay of the BYE to the far end. I do something
similar now in 2.2 with a slightly patched dialog module.

- Jon


On Tue, Jun 23, 2020 at 1:58 AM ryan embgrets <rembgrets at gmail.com> wrote:
>
> Greetings,
>
> I would like to have awesome community suggestions in handling the short duration calls.
>
> My clients send short duration calls towards opensips.
> So if a client sends me BYE within 6 seconds of the call, I would like to terminate the client leg and keep carrier leg alive beyond a few seconds, either by transferring the second leg(carrier side) to freeswitch, or playing some media using rtpengine/rtpproxy at opensips side.
>
> I would like to ask, is it something that can efficiently be done using new capabilities in opensips 3.1?
>
> How do other people handle this?
>
> PS: I cannot restrict my client to not send me short duration calls, so looking for an opensips way to handle this.
>
> Ryan
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


From osas at voipembedded.com  Wed Jun 24 04:32:57 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 24 Jun 2020 00:32:57 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
	proxy (22:Invalid argument)
In-Reply-To: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
Message-ID: <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>

This is happening also on the latest 3.0.
The weird thing is that opensips doesn't send anything to rtpengine.
The first opensips/rtpengine exchange on the initial INVITE works ok,
but the opensips/rtpengine exchange on the 200ok fails (no command is
sent by opensips - confirmed by running ngrep on the loopback
interface).
On the next call, the initial offer works fine, but the answer fails
due to no command issued by opensips.

version: opensips 3.0.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
main.c compiled on 09:36:42 Jun 22 2020 with gcc 9

-ovidiu


On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>
> Hello all,
>
> I'm running opensips 3.1.0-beta (latest version) and experiencing
> connectivity issues to the rtpengine daemon running on the same host:
> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> (22:Invalid argument)
> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
> respond, disable it
> ERROR:rtpengine:rtpe_function_call: no available proxies
>
> After an opensips restart, everything comes to normal.
> I was running previously opensips 3.1.0-dev and everything was working fine.
>
> The issue starts showing up after a few days with very little traffic.
> Is there anyone experiencing this issue?
>
>
> Thanks,
> Ovidiu
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From razvan at opensips.org  Wed Jun 24 05:58:47 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 24 Jun 2020 08:58:47 +0300
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
Message-ID: <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>

Hi, Ovidiu!

I doubt this is a problem of OpenSIPS version, but rather of the OS you 
are running on. I suspect that error comes from the fact that the bson 
resulted has more than IOV_MAX elements, which if I recall correctly it 
was 15 on some OSes.
We had a similar problem in rtpproy[1], where we had merged the buffers 
in a single one just to pass over this limitation. Could you check if 
you are facing a similar issue?

[1] 
https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> This is happening also on the latest 3.0.
> The weird thing is that opensips doesn't send anything to rtpengine.
> The first opensips/rtpengine exchange on the initial INVITE works ok,
> but the opensips/rtpengine exchange on the 200ok fails (no command is
> sent by opensips - confirmed by running ngrep on the loopback
> interface).
> On the next call, the initial offer works fine, but the answer fails
> due to no command issued by opensips.
> 
> version: opensips 3.0.2 (x86_64/linux)
> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
> main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> 
> -ovidiu
> 
> 
> On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>
>> Hello all,
>>
>> I'm running opensips 3.1.0-beta (latest version) and experiencing
>> connectivity issues to the rtpengine daemon running on the same host:
>> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
>> (22:Invalid argument)
>> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
>> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
>> respond, disable it
>> ERROR:rtpengine:rtpe_function_call: no available proxies
>>
>> After an opensips restart, everything comes to normal.
>> I was running previously opensips 3.1.0-dev and everything was working fine.
>>
>> The issue starts showing up after a few days with very little traffic.
>> Is there anyone experiencing this issue?
>>
>>
>> Thanks,
>> Ovidiu
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
> 
> 
> 


From solarmon at one-n.co.uk  Wed Jun 24 09:16:50 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Wed, 24 Jun 2020 10:16:50 +0100
Subject: [OpenSIPS-Users] rtpproxy 'Memory State' 'status'
Message-ID: <CAOXfywPiVfmSy12ZB_Tk=FKWdriWZJRQP307OHgwmAzoS9rZJg@mail.gmail.com>

Hi,

The command "opensipsctl fifo rtpproxy_show" does not return the 'status'
of the rtpproxy node.

In OpenSIPS Control Panel, the RTPProxy table has a '*Memory State*' column
which seems to be the 'status' of that node.

How can I get this 'Memory State' 'status' in command line form so that it
can be scripted? I want to be able to get a health status of the rtpproxy
from OpenSIPS point of view and graph it over a period of time.

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/2b93340a/attachment.html>

From spanda at 3clogic.com  Wed Jun 24 10:52:02 2020
From: spanda at 3clogic.com (Sasmita Panda)
Date: Wed, 24 Jun 2020 16:22:02 +0530
Subject: [OpenSIPS-Users] Need to configure CIDR range on dr_gateways table .
Message-ID: <CALf-Q44GPdxZCVf1gMSVsBkn=aLhB7v8ZKc0hSOSnD47rf1t0g@mail.gmail.com>

Hi All ,

In dr_gateways table in address column can I configure an IP range . like
CIDR address . The schema says " GW/destination address as name/IP[:port] "
.


How I will add CIDR address ? Is this possible or not ?

*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/a215eea2/attachment.html>

From bogdan at opensips.org  Wed Jun 24 12:47:36 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 24 Jun 2020 15:47:36 +0300
Subject: [OpenSIPS-Users] Need to configure CIDR range on dr_gateways
 table .
In-Reply-To: <CALf-Q44GPdxZCVf1gMSVsBkn=aLhB7v8ZKc0hSOSnD47rf1t0g@mail.gmail.com>
References: <CALf-Q44GPdxZCVf1gMSVsBkn=aLhB7v8ZKc0hSOSnD47rf1t0g@mail.gmail.com>
Message-ID: <29fa9371-eb28-d423-65f5-986f34bd371e@opensips.org>

Hi Sasmita,

No, only one IP addr or FQDN.

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/24/20 1:52 PM, Sasmita Panda wrote:
> Hi All ,
>
> In dr_gateways table in address column can I configure an IP range . 
> like CIDR address . The schema says " GW/destination address as 
> name/IP[:port] " .
>
>
> How I will add CIDR address ? Is this possible or not ?
>
> */Thanks & Regards/*
> /Sasmita Panda/
> /Senior Network Testing and Software Engineer/
> /3CLogic , ph:07827611765/
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/3e72d5b4/attachment-0001.html>

From bogdan at opensips.org  Wed Jun 24 12:49:06 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 24 Jun 2020 15:49:06 +0300
Subject: [OpenSIPS-Users] rtpproxy 'Memory State' 'status'
In-Reply-To: <CAOXfywPiVfmSy12ZB_Tk=FKWdriWZJRQP307OHgwmAzoS9rZJg@mail.gmail.com>
References: <CAOXfywPiVfmSy12ZB_Tk=FKWdriWZJRQP307OHgwmAzoS9rZJg@mail.gmail.com>
Message-ID: <c3b75031-2a98-ee0e-5534-f3587dab5131@opensips.org>

Hi,

In CP, the `status` is the status from the SQL table and the `memory 
status` is the status provided by the MU rtpproxy_show.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/24/20 12:16 PM, solarmon wrote:
> Hi,
>
> The command "opensipsctl fifo rtpproxy_show" does not return the 
> 'status' of the rtpproxy node.
>
> In OpenSIPS Control Panel, the RTPProxy table has a '*Memory State*' 
> column which seems to be the 'status' of that node.
>
> How can I get this 'Memory State' 'status' in command line form so 
> that it can be scripted? I want to be able to get a health status of 
> the rtpproxy from OpenSIPS point of view and graph it over a period of 
> time.
>
> Thank you!
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/bd34d8eb/attachment.html>

From bogdan at opensips.org  Wed Jun 24 12:53:58 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 24 Jun 2020 15:53:58 +0300
Subject: [OpenSIPS-Users] Possibilities to handle short duration calls
 using new capabilities in opensips 3.1
In-Reply-To: <CAP9sNzEvPQnT2V0997mW3Exp+HQN7Aj-ShdWPnmbN9aaivgiZQ@mail.gmail.com>
References: <CAJ_X8k7Xq-fD76of47+qXcDFjcifi=N71nE8xZj13ZnDqnocMA@mail.gmail.com>
 <CAP9sNzEvPQnT2V0997mW3Exp+HQN7Aj-ShdWPnmbN9aaivgiZQ@mail.gmail.com>
Message-ID: <5dfaca63-4c6b-32d9-fc13-a4c9eec4bd2e@opensips.org>

Nice one Jon !

doing a ++ here, maybe when loading the dialog ctx (before the match), 
in the call duration is less than 6 secs, you can reply with 200 OK to 
the BYE and set a dialog timeout for whatever number of sec you still 
have to get to the 6 secs duration - so when you get to the overall 6 
secs, OpenSIPS will send the BYEs to both parties.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com

On 6/23/20 10:43 PM, Jon Abrams wrote:
> You may be able to use the load_dialog_ctx()/unload_dialog_ctx()
> dialog functions to peek at the dialog when a BYE is received, prior
> to invoking match_dialog(). If it is a BYE from the calling party that
> you wish to delay, use an async sleep() to delay the call of
> match_dialog() and relay of the BYE to the far end. I do something
> similar now in 2.2 with a slightly patched dialog module.
>
> - Jon
>
>
> On Tue, Jun 23, 2020 at 1:58 AM ryan embgrets <rembgrets at gmail.com> wrote:
>> Greetings,
>>
>> I would like to have awesome community suggestions in handling the short duration calls.
>>
>> My clients send short duration calls towards opensips.
>> So if a client sends me BYE within 6 seconds of the call, I would like to terminate the client leg and keep carrier leg alive beyond a few seconds, either by transferring the second leg(carrier side) to freeswitch, or playing some media using rtpengine/rtpproxy at opensips side.
>>
>> I would like to ask, is it something that can efficiently be done using new capabilities in opensips 3.1?
>>
>> How do other people handle this?
>>
>> PS: I cannot restrict my client to not send me short duration calls, so looking for an opensips way to handle this.
>>
>> Ryan
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From osas at voipembedded.com  Wed Jun 24 12:54:36 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 24 Jun 2020 08:54:36 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
Message-ID: <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>

Hello Razvan,

The system is a debian buster one.
I patched the code:
#ifdef IOV_MAX
    LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
#else
    LM_NOTICE("no IOV_MAX\n");
#endif

and I get:
NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
in the logs.

Then I patched the code again to check how many buffers are being used:
The max so far was 73:
LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
got me:
NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)

I will continue to monitor the system to see if there is a correlation
between the error and the number of buffers.

Thanks,
Ovidiu

On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
>
> Hi, Ovidiu!
>
> I doubt this is a problem of OpenSIPS version, but rather of the OS you
> are running on. I suspect that error comes from the fact that the bson
> resulted has more than IOV_MAX elements, which if I recall correctly it
> was 15 on some OSes.
> We had a similar problem in rtpproy[1], where we had merged the buffers
> in a single one just to pass over this limitation. Could you check if
> you are facing a similar issue?
>
> [1]
> https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> > This is happening also on the latest 3.0.
> > The weird thing is that opensips doesn't send anything to rtpengine.
> > The first opensips/rtpengine exchange on the initial INVITE works ok,
> > but the opensips/rtpengine exchange on the 200ok fails (no command is
> > sent by opensips - confirmed by running ngrep on the loopback
> > interface).
> > On the next call, the initial offer works fine, but the answer fails
> > due to no command issued by opensips.
> >
> > version: opensips 3.0.2 (x86_64/linux)
> > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> > Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
> > main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> >
> > -ovidiu
> >
> >
> > On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> >>
> >> Hello all,
> >>
> >> I'm running opensips 3.1.0-beta (latest version) and experiencing
> >> connectivity issues to the rtpengine daemon running on the same host:
> >> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> >> (22:Invalid argument)
> >> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
> >> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
> >> respond, disable it
> >> ERROR:rtpengine:rtpe_function_call: no available proxies
> >>
> >> After an opensips restart, everything comes to normal.
> >> I was running previously opensips 3.1.0-dev and everything was working fine.
> >>
> >> The issue starts showing up after a few days with very little traffic.
> >> Is there anyone experiencing this issue?
> >>
> >>
> >> Thanks,
> >> Ovidiu
> >>
> >> --
> >> VoIP Embedded, Inc.
> >> http://www.voipembedded.com
> >
> >
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From solarmon at one-n.co.uk  Wed Jun 24 13:31:21 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Wed, 24 Jun 2020 14:31:21 +0100
Subject: [OpenSIPS-Users] rtpproxy 'Memory State' 'status'
In-Reply-To: <c3b75031-2a98-ee0e-5534-f3587dab5131@opensips.org>
References: <CAOXfywPiVfmSy12ZB_Tk=FKWdriWZJRQP307OHgwmAzoS9rZJg@mail.gmail.com>
 <c3b75031-2a98-ee0e-5534-f3587dab5131@opensips.org>
Message-ID: <CAOXfywOx+bCvKDn81EuRyCbdRJ+FQacwhWL9hBP-W-Qu4i8Ewg@mail.gmail.com>

Hi Bogdan-Andrei,

There is only 'Memory State' in CP. There is no 'status' in CP.

Sorry, what is 'MU'?

I'm using opensips 2.4.x if that makes any difference.

Thank you.

On Wed, 24 Jun 2020 at 13:49, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi,
>
> In CP, the `status` is the status from the SQL table and the `memory
> status` is the status provided by the MU rtpproxy_show.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>
> On 6/24/20 12:16 PM, solarmon wrote:
>
> Hi,
>
> The command "opensipsctl fifo rtpproxy_show" does not return the 'status'
> of the rtpproxy node.
>
> In OpenSIPS Control Panel, the RTPProxy table has a '*Memory State*'
> column which seems to be the 'status' of that node.
>
> How can I get this 'Memory State' 'status' in command line form so that it
> can be scripted? I want to be able to get a health status of the rtpproxy
> from OpenSIPS point of view and graph it over a period of time.
>
> Thank you!
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/829de89a/attachment.html>

From alain.bieuzent at free.fr  Wed Jun 24 14:44:40 2020
From: alain.bieuzent at free.fr (Alain Bieuzent)
Date: Wed, 24 Jun 2020 16:44:40 +0200
Subject: [OpenSIPS-Users] log_level=3 and L_INFO
Message-ID: <4DB3F647-8022-4A80-A105-73AEE6BC5C1F@free.fr>

Hi all,

 

I just migrate an opensips from 2.4.7 to 3.0.2.

 

When I enable log_level to 3, i didn’t see xlog message when level is set to L_INFO.

I saw only message when level of xlog is set to L_WARN.

 

Is there a changed between 2.4 and 3.0 ?

 

thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/b3d73812/attachment-0001.html>

From osas at voipembedded.com  Wed Jun 24 15:14:04 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 24 Jun 2020 11:14:04 -0400
Subject: [OpenSIPS-Users] log_level=3 and L_INFO
In-Reply-To: <4DB3F647-8022-4A80-A105-73AEE6BC5C1F@free.fr>
References: <4DB3F647-8022-4A80-A105-73AEE6BC5C1F@free.fr>
Message-ID: <CAND0LkvkcXeor05UbKz0=vdgiBsv9aFCHPo8FqSW4CX6XSDhXQ@mail.gmail.com>

Take a look at xlog_print_level param:
https://www.opensips.org/Documentation/Script-CoreParameters-3-0#toc90

-ovidiu


On Wed, Jun 24, 2020 at 10:45 Alain Bieuzent <alain.bieuzent at free.fr> wrote:

> Hi all,
>
>
>
> I just migrate an opensips from 2.4.7 to 3.0.2.
>
>
>
> When I enable log_level to 3, i didn’t see xlog message when level is set
> to L_INFO.
>
> I saw only message when level of xlog is set to L_WARN.
>
>
>
> Is there a changed between 2.4 and 3.0 ?
>
>
>
> thanks
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/191eecf9/attachment.html>

From osas at voipembedded.com  Wed Jun 24 15:17:16 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 24 Jun 2020 11:17:16 -0400
Subject: [OpenSIPS-Users] log_level=3 and L_INFO
In-Reply-To: <CAND0LkvkcXeor05UbKz0=vdgiBsv9aFCHPo8FqSW4CX6XSDhXQ@mail.gmail.com>
References: <4DB3F647-8022-4A80-A105-73AEE6BC5C1F@free.fr>
 <CAND0LkvkcXeor05UbKz0=vdgiBsv9aFCHPo8FqSW4CX6XSDhXQ@mail.gmail.com>
Message-ID: <CAND0LktL-5HVbfkofVQdLc=JR0n31PHUC0bA98Gxv_htP02=VA@mail.gmail.com>

Also, check the migration documentation:
https://www.opensips.org/Documentation/Migration

-ovidiu

On Wed, Jun 24, 2020 at 11:14 Ovidiu Sas <osas at voipembedded.com> wrote:

> Take a look at xlog_print_level param:
> https://www.opensips.org/Documentation/Script-CoreParameters-3-0#toc90
>
> -ovidiu
>
>
> On Wed, Jun 24, 2020 at 10:45 Alain Bieuzent <alain.bieuzent at free.fr>
> wrote:
>
>> Hi all,
>>
>>
>>
>> I just migrate an opensips from 2.4.7 to 3.0.2.
>>
>>
>>
>> When I enable log_level to 3, i didn’t see xlog message when level is set
>> to L_INFO.
>>
>> I saw only message when level of xlog is set to L_WARN.
>>
>>
>>
>> Is there a changed between 2.4 and 3.0 ?
>>
>>
>>
>> thanks
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/663705c5/attachment.html>

From alain.bieuzent at free.fr  Wed Jun 24 15:34:06 2020
From: alain.bieuzent at free.fr (Alain Bieuzent)
Date: Wed, 24 Jun 2020 17:34:06 +0200
Subject: [OpenSIPS-Users] log_level=3 and L_INFO
In-Reply-To: <CAND0LkvkcXeor05UbKz0=vdgiBsv9aFCHPo8FqSW4CX6XSDhXQ@mail.gmail.com>
References: <4DB3F647-8022-4A80-A105-73AEE6BC5C1F@free.fr>
 <CAND0LkvkcXeor05UbKz0=vdgiBsv9aFCHPo8FqSW4CX6XSDhXQ@mail.gmail.com>
Message-ID: <49E8DB53-650D-430A-B054-578D9E2E4DCB@free.fr>

Thanks for this fast replu, didn’t see this new xlog_level.

 

Regards

 

De : Users <users-bounces at lists.opensips.org> au nom de Ovidiu Sas <osas at voipembedded.com>
Répondre à : OpenSIPS users mailling list <users at lists.opensips.org>
Date : mercredi 24 juin 2020 à 17:15
À : OpenSIPS users mailling list <users at lists.opensips.org>
Objet : Re: [OpenSIPS-Users] log_level=3 and L_INFO

 

Take a look at xlog_print_level param:

https://www.opensips.org/Documentation/Script-CoreParameters-3-0#toc90

 

-ovidiu

 

 

On Wed, Jun 24, 2020 at 10:45 Alain Bieuzent <alain.bieuzent at free.fr> wrote:

Hi all,

 

I just migrate an opensips from 2.4.7 to 3.0.2.

 

When I enable log_level to 3, i didn’t see xlog message when level is set to L_INFO.

I saw only message when level of xlog is set to L_WARN.

 

Is there a changed between 2.4 and 3.0 ?

 

thanks

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

-- 

VoIP Embedded, Inc.
http://www.voipembedded.com

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/bb8f2045/attachment.html>

From tpaivaa at gmail.com  Wed Jun 24 16:13:52 2020
From: tpaivaa at gmail.com (Tomi Hakkarainen)
Date: Wed, 24 Jun 2020 19:13:52 +0300
Subject: [OpenSIPS-Users] rtpproxy 'Memory State' 'status'
In-Reply-To: <CAOXfywOx+bCvKDn81EuRyCbdRJ+FQacwhWL9hBP-W-Qu4i8Ewg@mail.gmail.com>
References: <CAOXfywOx+bCvKDn81EuRyCbdRJ+FQacwhWL9hBP-W-Qu4i8Ewg@mail.gmail.com>
Message-ID: <63109AE3-D87B-4FC6-A3CB-F53CB4B90B60@gmail.com>

Hi,

I believe MU is just typo should be MI

The ’status’ should also be retrieved differently not with the 
$ opensipsctl fifo rtpproxy_show
command

I think you can get the ’status’ directly from the database with SQL query. 

Tomi


On 24. Jun 2020, at 16.33, solarmon <solarmon at one-n.co.uk> wrote:


Hi Bogdan-Andrei,

There is only 'Memory State' in CP. There is no 'status' in CP.

Sorry, what is 'MU'?

I'm using opensips 2.4.x if that makes any difference.

Thank you.

> On Wed, 24 Jun 2020 at 13:49, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> Hi,
> 
> In CP, the `status` is the status from the SQL table and the `memory status` is the status provided by the MU rtpproxy_show.
> 
> Regards,
>  Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> 
>> On 6/24/20 12:16 PM, solarmon wrote:
>> Hi,
>> 
>> The command "opensipsctl fifo rtpproxy_show" does not return the 'status' of the rtpproxy node.
>> 
>> In OpenSIPS Control Panel, the RTPProxy table has a 'Memory State' column which seems to be the 'status' of that node.
>> 
>> How can I get this 'Memory State' 'status' in command line form so that it can be scripted? I want to be able to get a health status of the rtpproxy from OpenSIPS point of view and graph it over a period of time.
>> 
>> Thank you!
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/d515a633/attachment-0001.html>

From venefax at gmail.com  Wed Jun 24 16:31:50 2020
From: venefax at gmail.com (Saint Michael)
Date: Wed, 24 Jun 2020 12:31:50 -0400
Subject: [OpenSIPS-Users] crashes
Message-ID: <CAC9cSOBvdLEDOZ-RHsp+aW2P9k9UvFqNOyLbsATucj_3ySrk5Q@mail.gmail.com>

dmesg shows this:
[849895.444677] opensips[37151]: segfault at 0 ip 000055f471304456 sp
00007ffc04f79dc0 error 6 in opensips[55f4711ce000+2ec000]
[849895.444690] Code: 5b 08 48 85 db 75 ef 48 83 c1 10 48 39 d1 75 d3 e9 3d
fe ff ff 4c 8b 4b 10 4c 8b 43 08 49 81 fe 00 40 00 00 0f 87 6a 01 00 00
<4d> 89 01 48 8b 7b 08 4d 89 f7 49 c1 ef 03 49 c1 e7 04 49 01 ef 49
[849895.690104] opensips[37055]: segfault at 21 ip 000055f47130574c sp
00007ffc04f7a150 error 4 in opensips[55f4711ce000+2ec000]
[849895.690117] Code: 8d 78 50 45 31 f6 31 ed 45 31 ed 4c 8d 64 24 60 4c 89
64 24 28 45 89 f3 49 8b 17 48 85 d2 0f 84 8b 02 00 00 44 89 eb 49 89 d0
<49> 03 28 4d 8b 40 08 83 c3 01 41 89 dc 45 29 ec 4d 85 c0 75 eb 45

but opensips is not generating the dumps in /home/opensips
I have of course
cho 1 > /proc/sys/kernel/core_uses_pid and echo 1 >
/proc/sys/fs/suid_dumpable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/07108679/attachment.html>

From solarmon at one-n.co.uk  Wed Jun 24 17:22:49 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Wed, 24 Jun 2020 18:22:49 +0100
Subject: [OpenSIPS-Users] rtpproxy 'Memory State' 'status'
In-Reply-To: <63109AE3-D87B-4FC6-A3CB-F53CB4B90B60@gmail.com>
References: <CAOXfywOx+bCvKDn81EuRyCbdRJ+FQacwhWL9hBP-W-Qu4i8Ewg@mail.gmail.com>
 <63109AE3-D87B-4FC6-A3CB-F53CB4B90B60@gmail.com>
Message-ID: <CAOXfywNtmXBMWXrUjt7tvMVW5_W8PkmHYpaSQRP7VJeOkA7mAw@mail.gmail.com>

Hi Tomi,

The "opensipsctl fifo rtpproxy_show" command does not give a 'status', but
a 'disabled' value - for example:

Set:: 0
        node:: udp:<IP Address>:7898 index=0 disabled=0 weight=1
recheck_ticks=0
        node:: udp: <IP Address> :7898 index=1 disabled=0 weight=1
recheck_ticks=0
        node:: udp: <IP Address> :7898 index=2 disabled=0 weight=1
recheck_ticks=0

Is this 'disabled' value meant to mean a config or running status?

I thought this 'disabled' value is meant to mean whether it has been
disabled in config - i.e. if you add "=0" to the URI address of the
configured rtpproxy node. This is not these same as whether the rtpproxy is
active/healthy - which is what "Memory State" in CP is meant to mean?

Thank you.

On Wed, 24 Jun 2020 at 17:15, Tomi Hakkarainen <tpaivaa at gmail.com> wrote:

> Hi,
>
> I believe MU is just typo should be MI
>
> The ’status’ should also be retrieved differently not with the
>
> $ opensipsctl fifo rtpproxy_show
>
> command
>
> I think you can get the ’status’ directly from the database with SQL
> query.
>
> Tomi
>
>
> On 24. Jun 2020, at 16.33, solarmon <solarmon at one-n.co.uk> wrote:
>
> 
> Hi Bogdan-Andrei,
>
> There is only 'Memory State' in CP. There is no 'status' in CP.
>
> Sorry, what is 'MU'?
>
> I'm using opensips 2.4.x if that makes any difference.
>
> Thank you.
>
> On Wed, 24 Jun 2020 at 13:49, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi,
>>
>> In CP, the `status` is the status from the SQL table and the `memory
>> status` is the status provided by the MU rtpproxy_show.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>
>> On 6/24/20 12:16 PM, solarmon wrote:
>>
>> Hi,
>>
>> The command "opensipsctl fifo rtpproxy_show" does not return the 'status'
>> of the rtpproxy node.
>>
>> In OpenSIPS Control Panel, the RTPProxy table has a '*Memory State*'
>> column which seems to be the 'status' of that node.
>>
>> How can I get this 'Memory State' 'status' in command line form so that
>> it can be scripted? I want to be able to get a health status of the
>> rtpproxy from OpenSIPS point of view and graph it over a period of time.
>>
>> Thank you!
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/bc6d1fdd/attachment.html>

From rob.dyck at telus.net  Wed Jun 24 21:36:04 2020
From: rob.dyck at telus.net (Robert Dyck)
Date: Wed, 24 Jun 2020 14:36:04 -0700
Subject: [OpenSIPS-Users] Useless NAT check with IPV6
Message-ID: <3700868.VqM8IeB0Os@blacky.mylan>

Context: opensips 3.0.2

I wanted to cleanup a working configuration so I eliminated the NAT check if the address family 
was IPV6. This was in the initial request route. I was surprised to see that an IPV6 INVITE would 
fail. The REGISTERs were good.

Could someone explain to me what is happening.
Thanks, Rob

Config and debug on failure

       if ($af == "INET") { 

un 24 10:09:34 [1682250] Branch index is 0  

Debug of NAT check, working scenario

Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200624/4243792f/attachment.html>

From Rajesh.Govindaraj at ipc.com  Thu Jun 25 04:36:08 2020
From: Rajesh.Govindaraj at ipc.com (Govindaraj, Rajesh)
Date: Thu, 25 Jun 2020 04:36:08 +0000
Subject: [OpenSIPS-Users] Opensips presence active-active cluster in 2.4.7
Message-ID: <BLAPR15MB3795B5047E5865D30724B215E3920@BLAPR15MB3795.namprd15.prod.outlook.com>

Hi Forum Members,

We have successfully brought of Federated opensips presence cluster and now focusing on getting Active-Active Configuration with shared DB (in each region) working for HA scenario.

We are facing some basic issues and would like to hear if we are missing something very basic. We are writing this mail after some long sessions of debugging.

Presence related configuration:

modparam("presence","server_address","sip:sa at 10.207.232.168:5060")
modparam("xcap|presence|clusterer", "db_url","mysql://bhanu:WElcome12#@10.207.232.168/opensips")
modparam("presence_xml", "force_active", 1)
modparam("presence", "fallback2db", 1)
modparam("presence", "cluster_id", 1)
modparam("presence", "cluster_federation_mode", 1)
modparam("presence", "cluster_sharing_tags", "A=active")
#modparam("presence", "cluster_sharing_tags" ,"B=backup")
modparam("presence", "cluster_pres_events" ,"presence, dialog;sla, message-summary")
modparam("presence", "db_update_period", 1)
#modparam("presence", "clean_period", 10)
modparam("presence", "active_watchers_table", "active_watchers")


Issue 1: Publish on one server(Server A) results in cluster replication on other server(Server B). Handle_replicated_publish method is invoked in Server B, however the below error is seen, as server B is also inserting the entry to presentity table, which seems wrong. Is it a race scenario? If yes we don't how to mitigate it. We have the shared DB outside both opensips servers running.

Logs:

Jun 25 00:17:38 [18288] DBG:presence:handle_replicated_publish: Updating presentity
Jun 25 00:17:38 [18288] DBG:presence:update_pres_etag: etag = a.1593058326.29320.3.1
Jun 25 00:17:38 [18288] DBG:presence:update_presentity: inserting 8 cols into table
Jun 25 00:17:38 [18288] CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Duplicate entry '1000-10.207.232.168-presence-a.1593058326.29320.3.1' for key 'presentity.presentity_idx'
Jun 25 00:17:38 [18288] ERROR:core:db_do_insert: error while submitting query
Jun 25 00:17:38 [18288] ERROR:presence:update_presentity: inserting new record in database
Jun 25 00:17:38 [18288] DBG:presence:next_turn_phtable: new current turn is 1 for <sip:1000 at 10.207.232.168>
Jun 25 00:17:38 [18288] ERROR:presence:handle_replicated_publish: failed to update presentity based on replicated Publish
Jun 25 00:17:38 [18288] ERROR:presence:handle_replicated_publish: failed to handle bin packet 101 from node 2


Issue 2: Active Watcher table is not getting update with entry. Not able to conclude is it a delay in writing the cache entry to DB or something else. If it is delay to write to db, not sure if there are any parameters available to make this entry faster (to take of server going down - HA)

Also in one case, we thought even though active_watchers table did not had an entry, opensips will be able to operate with cache values, but when replicated publish is received, seeing this log,

Logs:

Jun 25 00:13:16 [29319] DBG:presence:handle_replicated_publish: Updating presentity
Jun 25 00:13:16 [29319] DBG:presence:search_phtable_etag: pres_uri= sip:1001 at 10.207.232.168, event=1, etag= a.1593058321.18289.1.0
Jun 25 00:13:16 [29319] DBG:presence:search_phtable_etag: found etag = a.1593058321.18289.1.0
Jun 25 00:13:16 [29319] DBG:presence:update_presentity: pres <sip:1001 at 10.207.232.168> my turn is 1, current turn is 1
Jun 25 00:13:16 [29319] DBG:presence:update_pres_etag: etag = a.1593058321.18289.3.1
Jun 25 00:13:16 [29319] DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected
Jun 25 00:13:16 [29319] DBG:presence:get_subs_db: querying database table = active_watchers
Jun 25 00:13:16 [29319] DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected
Jun 25 00:13:16 [29319] DBG:core:db_new_result: allocate 48 bytes for result set at 0x7fe80282a240
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: 16 columns returned from the query
Jun 25 00:13:16 [29319] DBG:core:db_allocate_columns: allocate 448 bytes for result columns at 0x7fe80284f880

--------
-------
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fe80284f9e0)[14]=[local_contact]
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fe80284f9f0)[15]=[version]
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query
Jun 25 00:13:16 [29319] DBG:presence:get_subs_db: The query for subscribtion for [uri]= sip:1001 at 10.207.232.168 for [event]= presence returned no result
Jun 25 00:13:16 [29319] DBG:core:db_free_columns: freeing result columns at 0x7fe80284f880
Jun 25 00:13:16 [29319] DBG:core:db_free_rows: freeing 0 rows


As always Thanks for all help.,

__________________________________________________________
INFORMATION CLASSIFICATION: IPC PROPRIETARY

Rajeshkumar Govindaraj
Senior Software Engineer
777 Commerce Drive,
Fairfield, CT-06825

Follow us on twitter: @ipc_Systems_Inc    www.ipc.com<http://www.ipc.com/>

[cid:image006.jpg at 01D1940F.3E021840]




DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. 
If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have received it in error. 
Unintended recipients are prohibited from taking action on the basis of information in this e-mail. 
E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, 
deleted or interfered with without the knowledge of the sender or the intended recipient. 
If you are not comfortable with the risks associated with e-mail messages, 
you may decide not to use e-mail to communicate with IPC. IPC reserves the right, 
to the extent and under circumstances permitted by applicable law, 
to retain, monitor and intercept e-mail messages to and from its systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/8bacc5b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3563 bytes
Desc: image003.jpg
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/8bacc5b0/attachment-0001.jpg>

From adjolin at gmail.com  Thu Jun 25 14:33:55 2020
From: adjolin at gmail.com (Vic Jolin)
Date: Thu, 25 Jun 2020 22:33:55 +0800
Subject: [OpenSIPS-Users] opensips-cli dp_reload not working
In-Reply-To: <f7a9cc51-3285-3e17-6bfe-26fcfa5fbbcb@opensips.org>
References: <CAA+eT4kmDqfDhKV+dN9wF9pU_jx8P-OpJXPaPzawRRg9_HP=sg@mail.gmail.com>
 <84716f47-0f78-7249-ce7a-7416ac6286e0@opensips.org>
 <CAA+eT4k5qg06PsKn+2_qWQjBwd4myONwh5FOL8DXhm=uQ+rYdA@mail.gmail.com>
 <f7a9cc51-3285-3e17-6bfe-26fcfa5fbbcb@opensips.org>
Message-ID: <CAA+eT4kL638Byq2rHY4Z9mmmAovcx87H5Jssrqz=_faLQL-Hcg@mail.gmail.com>

Bogdan,

Below is the debug output when reloading dialplan

>From what I have noticed, after a successful dp_reload, and then making the
1st test call, the next calls will have the same context result as the
first one, even if the dialplan is different.

So, for example we tested and got context drgID=1 from the dialplan that
matches, the consecutive dial plan matches will have the same context.





*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc8ad38: pr 0
next 0x7f458dc8b140 match_exp ^662261(.+) match_flags 0, subst_exp
^662261(.+), repl_exp 61\1 and attrs  and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc8b140: pr 0
next 0x7f458dc96470 match_exp ^2266(.+) match_flags 0, subst_exp ^2266(.+),
repl_exp \1 and attrs user=2266; gateway=gtps and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96470: pr 0
next 0x7f458dc96800 match_exp ^6[0-9][0-9][0-9](.+) match_flags 0,
subst_exp ^6[0-9][0-9][0-9](.+), repl_exp \1 and attrs  and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96800: pr 0
next 0x7f458dc96bc0 match_exp ^55551(.+) match_flags 0, subst_exp
^55551(.+), repl_exp 1\1 and attrs drgID=12 and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96bc0: pr 0
next 0x7f458dc96f88 match_exp ^979744(.+) match_flags 0, subst_exp
^979744(.+), repl_exp 44\1 and attrs user=9797; gateway=gtps and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96f88: pr 0
next 0x7f458dc97308 match_exp ^8000(.+) match_flags 0, subst_exp ^8000(.+),
repl_exp \1 and attrs  and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc97308: pr 0
next 0x7f458dc976d0 match_exp ^40011(.+) match_flags 0, subst_exp
^40011(.+), repl_exp 1\1 and attrs gateway=GTPS_VTTel and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc976d0: pr 0
next 0x7f458dc97a98 match_exp ^22001(.+) match_flags 0, subst_exp
^22001(.+), repl_exp 1\1 and attrs gateway=GTPS_VTTel and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc97a98: pr 0
next 0x7f458dc97e18 match_exp ^9000(.+) match_flags 0, subst_exp ^9000(.+),
repl_exp \1 and attrs  and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc97e18: pr 0
next 0x7f458dc98198 match_exp ^400244(.+) match_flags 0, subst_exp
^400244(.+), repl_exp 44\1 and attrs  and timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc98198: pr 65
next 0x7f458dc98568 match_exp ^12121(.+) match_flags 0, subst_exp
^12121(.+), repl_exp 1\1 and attrs user=1212; gateway=GTPS_VTTel and
timerec *

*Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc98568: pr 99
next (nil) match_exp ^30111(.+) match_flags 0, subst_exp ^30111(.+),
repl_exp 1\1 and attrs  and timerec *

*Jun 25 07:46:14 [13757] DBG:core:db_free_columns: freeing result columns
at 0x7f45a142e5a0*

*Jun 25 07:46:14 [13757] DBG:core:db_free_rows: freeing 0 rows*

*Jun 25 07:46:14 [13757] DBG:core:db_free_result: freeing result set at
0x7f45a13fd7d0*






On Tue, Jun 23, 2020 at 12:41 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Vic,
>
> What is the exact opensips version you have ? (opensips -V)
>
> Also, please provide the log (in debug mode) generated during the reload
> attempt.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>
> On 6/17/20 10:01 PM, Vic Jolin wrote:
>
> Bogdan,
>
> Hi, the dialplan loads properly on start up, it just doesn't reload on
> opensips-cli
>
> although when I do
> opensips-cli -x mi dp_reload
>
> It returns OK
>
> On Thu, Jun 18, 2020 at 2:29 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi,
>>
>> Do you see any errors in the logs, after reload ?
>>
>> Also, if you switch the DBG/4 log_level, do you see the logs for the
>> reload ?
>>
>> Maybe your tests are not accurate enough to spot the reload.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>
>> On 6/17/20 9:18 PM, Vic Jolin wrote:
>>
>> Hi,
>>
>> I've been trying to get my dialplan to reload but Im still getting the
>> old dialplan when I test.
>> the old dialplan has attributes on it, but I removed it, and when I tried
>>
>> opensips-cli -x mi dp_reload
>>
>> I am still getting the old attribute.
>>
>> Anything else I should do or check?
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/8ed79524/attachment.html>

From adjolin at gmail.com  Thu Jun 25 14:47:50 2020
From: adjolin at gmail.com (Vic Jolin)
Date: Thu, 25 Jun 2020 22:47:50 +0800
Subject: [OpenSIPS-Users] do_routing with failover to shorter prefix
Message-ID: <CAA+eT4ka9E=PpKe0+4vfO8wtNghVz9v2nxds3nxhtvdeursNgA@mail.gmail.com>

Hi,

So I have this in my opensips.cfg

if ( !do_routing($(avp(drgID){s.int}),,,,,$var(gw_attributes)) ) {
send_reply(404,"No Route found");
exit;
}

And I know that do_routing will match on the longer prefix on dr_rules
table first.

My question is

Now after failing on all the routes, can we still do another do_routing
with shorter prefix matching?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/fc34fa90/attachment.html>

From Ben.Newlin at genesys.com  Thu Jun 25 14:59:31 2020
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Thu, 25 Jun 2020 14:59:31 +0000
Subject: [OpenSIPS-Users] do_routing with failover to shorter prefix
In-Reply-To: <CAA+eT4ka9E=PpKe0+4vfO8wtNghVz9v2nxds3nxhtvdeursNgA@mail.gmail.com>
References: <CAA+eT4ka9E=PpKe0+4vfO8wtNghVz9v2nxds3nxhtvdeursNgA@mail.gmail.com>
Message-ID: <E23DE851-CD4A-42CF-AAD9-9014A6522FDF@genesys.com>

Yes, our configuration calls do_routing multiple times for different failover cases. You may want to verify this but I believe that the additional calls will append to the relevant AVPs used by the module, so if you haven’t routed to all destinations, you may need to clear out the AVPs prior to calling it again. I’m not positive on that part though; it may overwrite existing values.

We created a little helper route to do this:

route[clear_dr_avps]
{
  avp_delete("$avp(dr_ruri)/g");
  avp_delete("$avp(dr_gw_id)/g");
  avp_delete("$avp(dr_gw_prfx)/g");
  avp_delete("$avp(dr_rule_id)/g");
  avp_delete("$avp(dr_rule_prfx)/g");
  avp_delete("$avp(dr_carr_id)/g");
}

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Vic Jolin <adjolin at gmail.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Thursday, June 25, 2020 at 10:49 AM
To: "users at lists.opensips.org" <users at lists.opensips.org>
Subject: [OpenSIPS-Users] do_routing with failover to shorter prefix

Hi,

So I have this in my opensips.cfg

if ( !do_routing($(avp(drgID){s.int<http://s.int>}),,,,,$var(gw_attributes)) ) {
send_reply(404,"No Route found");
exit;
}

And I know that do_routing will match on the longer prefix on dr_rules table first.

My question is

Now after failing on all the routes, can we still do another do_routing with shorter prefix matching?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/5c1bd970/attachment-0001.html>

From liviu at opensips.org  Thu Jun 25 16:25:21 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 25 Jun 2020 19:25:21 +0300
Subject: [OpenSIPS-Users] Problem with add_rr_param() in v2.4.7
In-Reply-To: <000201d62fb2$70949c40$51bdd4c0$@smartvox.co.uk>
References: <000201d62fb2$70949c40$51bdd4c0$@smartvox.co.uk>
Message-ID: <a8c3e491-b636-83c6-3fb9-22d41ec8b802@opensips.org>

On 21.05.2020 23:57, John Quick wrote:
> I finally made some more time to investigate this bug and can now confirm
> that it only happens when a dialog is created before you call add_rr_param()
> So, in your test, please add this line at the start:
>
>    create_dialog("B");
>
> then you should see the error happening.

Hi, John!

Thanks to your excellent instructions, I was able to reproduce your 
scenario and confirm that:

* latest 2.4.7 release (96517d4860e0) has this bug
* initial 2.4.6 release (edef893c5af) does _not_ have the bug

Using this information and the ol' trusty `git bisect`, I managed to 
pinpoint the exact commit which broke things:

commit c263182ee4dd692212ca310feb8a902714b93b45
Author: Varghese Paul <vpaul at livevox.com>
Date:   Wed Jun 19 13:39:51 2019 -0700

     Do not simply link the buffered lumps, but better clone them -> 
this will avoid a mixage of lump types (shm versus pkg) when using async()

  modules/rr/record.c | 5 +----
  1 file changed, 1 insertion(+), 4 deletions(-)

Currently investigating what happened over there and working towards a 
solution! :)

Best regards,

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com



From rembgrets at gmail.com  Thu Jun 25 16:42:59 2020
From: rembgrets at gmail.com (ryan embgrets)
Date: Thu, 25 Jun 2020 21:42:59 +0500
Subject: [OpenSIPS-Users] Possibilities to handle short duration calls
 using new capabilities in opensips 3.1
In-Reply-To: <5dfaca63-4c6b-32d9-fc13-a4c9eec4bd2e@opensips.org>
References: <CAJ_X8k7Xq-fD76of47+qXcDFjcifi=N71nE8xZj13ZnDqnocMA@mail.gmail.com>
 <CAP9sNzEvPQnT2V0997mW3Exp+HQN7Aj-ShdWPnmbN9aaivgiZQ@mail.gmail.com>
 <5dfaca63-4c6b-32d9-fc13-a4c9eec4bd2e@opensips.org>
Message-ID: <CAJ_X8k5_Vm_mVSz-K0Q70x15HodLevkOtV8ZyusoncdA_zabJQ@mail.gmail.com>

Thanks, Jon , Bogdan for the assistance.
So, I added the below snippet after the has_totag section of my
configuration.

   if (is_method("BYE") && $si = "192.168.10.20") {
                if ( load_dialog_ctx("$ci") ) {
                        xlog("The dialog $var(callid) has an already
duration of $DLG_lifetime seconds with $DLG_dir\n");
                        if($DLG_lifetime < 10 ) {
                                $DLG_timeout = 10 - $DLG_lifetime ;
                                send_reply(200, "OK");
                                exit;
                        }
                        unload_dialog_ctx();
                }
        }

And it seems to work, I wanted to check if the above snippet looks good?

Is there a way to send bye to only Carrier side?

I see CDRs get written after dialog timeouts, but can I get CDRs with
duration when I receive a bye from the client not on dialog timeout?

Thanks again for your time.

Ryan.





On Wed, 24 Jun 2020 at 17:55, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Nice one Jon !
>
> doing a ++ here, maybe when loading the dialog ctx (before the match),
> in the call duration is less than 6 secs, you can reply with 200 OK to
> the BYE and set a dialog timeout for whatever number of sec you still
> have to get to the 6 secs duration - so when you get to the overall 6
> secs, OpenSIPS will send the BYEs to both parties.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
>
> On 6/23/20 10:43 PM, Jon Abrams wrote:
> > You may be able to use the load_dialog_ctx()/unload_dialog_ctx()
> > dialog functions to peek at the dialog when a BYE is received, prior
> > to invoking match_dialog(). If it is a BYE from the calling party that
> > you wish to delay, use an async sleep() to delay the call of
> > match_dialog() and relay of the BYE to the far end. I do something
> > similar now in 2.2 with a slightly patched dialog module.
> >
> > - Jon
> >
> >
> > On Tue, Jun 23, 2020 at 1:58 AM ryan embgrets <rembgrets at gmail.com>
> wrote:
> >> Greetings,
> >>
> >> I would like to have awesome community suggestions in handling the
> short duration calls.
> >>
> >> My clients send short duration calls towards opensips.
> >> So if a client sends me BYE within 6 seconds of the call, I would like
> to terminate the client leg and keep carrier leg alive beyond a few
> seconds, either by transferring the second leg(carrier side) to freeswitch,
> or playing some media using rtpengine/rtpproxy at opensips side.
> >>
> >> I would like to ask, is it something that can efficiently be done using
> new capabilities in opensips 3.1?
> >>
> >> How do other people handle this?
> >>
> >> PS: I cannot restrict my client to not send me short duration calls, so
> looking for an opensips way to handle this.
> >>
> >> Ryan
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/abbadedf/attachment.html>

From rob.dyck at telus.net  Thu Jun 25 16:56:39 2020
From: rob.dyck at telus.net (Robert Dyck)
Date: Thu, 25 Jun 2020 09:56:39 -0700
Subject: [OpenSIPS-Users] Useless NAT check with IPV6
In-Reply-To: <3700868.VqM8IeB0Os@blacky.mylan>
References: <3700868.VqM8IeB0Os@blacky.mylan>
Message-ID: <2694478.ZfL8zNpBrT@blacky.mylan>

I have submitted bug #2154.
I believe it is a registration problem. The "received" should never be null in the location table.

On Wednesday, June 24, 2020 2:36:04 P.M. PDT Robert Dyck wrote:


Context: opensips 3.0.2

I wanted to cleanup a working configuration so I eliminated the NAT check if the address family 
was IPV6. This was in the initial request route. I was surprised to see that an IPV6 INVITE would 
fail. The REGISTERs were good.

Could someone explain to me what is happening.
Thanks, Rob

Config and debug on failure

       if ($af == "INET") { 

un 24 10:09:34 [1682250] Branch index is 0  

Debug of NAT check, working scenario

Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/5df2ec1c/attachment-0001.html>

From osas at voipembedded.com  Thu Jun 25 17:02:58 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Thu, 25 Jun 2020 13:02:58 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
Message-ID: <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>

It seems that when we have more than roughly 1000 buffers, the send fails.

-ovidiu

On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>
> Hello Razvan,
>
> The system is a debian buster one.
> I patched the code:
> #ifdef IOV_MAX
>     LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> #else
>     LM_NOTICE("no IOV_MAX\n");
> #endif
>
> and I get:
> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> in the logs.
>
> Then I patched the code again to check how many buffers are being used:
> The max so far was 73:
> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> got me:
> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
>
> I will continue to monitor the system to see if there is a correlation
> between the error and the number of buffers.
>
> Thanks,
> Ovidiu
>
> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
> >
> > Hi, Ovidiu!
> >
> > I doubt this is a problem of OpenSIPS version, but rather of the OS you
> > are running on. I suspect that error comes from the fact that the bson
> > resulted has more than IOV_MAX elements, which if I recall correctly it
> > was 15 on some OSes.
> > We had a similar problem in rtpproy[1], where we had merged the buffers
> > in a single one just to pass over this limitation. Could you check if
> > you are facing a similar issue?
> >
> > [1]
> > https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> >
> > Răzvan Crainea
> > OpenSIPS Core Developer
> > http://www.opensips-solutions.com
> >
> > On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> > > This is happening also on the latest 3.0.
> > > The weird thing is that opensips doesn't send anything to rtpengine.
> > > The first opensips/rtpengine exchange on the initial INVITE works ok,
> > > but the opensips/rtpengine exchange on the 200ok fails (no command is
> > > sent by opensips - confirmed by running ngrep on the loopback
> > > interface).
> > > On the next call, the initial offer works fine, but the answer fails
> > > due to no command issued by opensips.
> > >
> > > version: opensips 3.0.2 (x86_64/linux)
> > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> > > Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
> > > main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> > >
> > > -ovidiu
> > >
> > >
> > > On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> > >>
> > >> Hello all,
> > >>
> > >> I'm running opensips 3.1.0-beta (latest version) and experiencing
> > >> connectivity issues to the rtpengine daemon running on the same host:
> > >> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> > >> (22:Invalid argument)
> > >> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
> > >> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
> > >> respond, disable it
> > >> ERROR:rtpengine:rtpe_function_call: no available proxies
> > >>
> > >> After an opensips restart, everything comes to normal.
> > >> I was running previously opensips 3.1.0-dev and everything was working fine.
> > >>
> > >> The issue starts showing up after a few days with very little traffic.
> > >> Is there anyone experiencing this issue?
> > >>
> > >>
> > >> Thanks,
> > >> Ovidiu
> > >>
> > >> --
> > >> VoIP Embedded, Inc.
> > >> http://www.voipembedded.com
> > >
> > >
> > >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From osas at voipembedded.com  Thu Jun 25 17:03:47 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Thu, 25 Jun 2020 13:03:47 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
Message-ID: <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>

We will need to add a param to control the max number of buffers.

-ovidiu

On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>
> It seems that when we have more than roughly 1000 buffers, the send fails.
>
> -ovidiu
>
> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
> >
> > Hello Razvan,
> >
> > The system is a debian buster one.
> > I patched the code:
> > #ifdef IOV_MAX
> >     LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> > #else
> >     LM_NOTICE("no IOV_MAX\n");
> > #endif
> >
> > and I get:
> > NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> > in the logs.
> >
> > Then I patched the code again to check how many buffers are being used:
> > The max so far was 73:
> > LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> > got me:
> > NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
> >
> > I will continue to monitor the system to see if there is a correlation
> > between the error and the number of buffers.
> >
> > Thanks,
> > Ovidiu
> >
> > On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
> > >
> > > Hi, Ovidiu!
> > >
> > > I doubt this is a problem of OpenSIPS version, but rather of the OS you
> > > are running on. I suspect that error comes from the fact that the bson
> > > resulted has more than IOV_MAX elements, which if I recall correctly it
> > > was 15 on some OSes.
> > > We had a similar problem in rtpproy[1], where we had merged the buffers
> > > in a single one just to pass over this limitation. Could you check if
> > > you are facing a similar issue?
> > >
> > > [1]
> > > https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> > >
> > > Răzvan Crainea
> > > OpenSIPS Core Developer
> > > http://www.opensips-solutions.com
> > >
> > > On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> > > > This is happening also on the latest 3.0.
> > > > The weird thing is that opensips doesn't send anything to rtpengine.
> > > > The first opensips/rtpengine exchange on the initial INVITE works ok,
> > > > but the opensips/rtpengine exchange on the 200ok fails (no command is
> > > > sent by opensips - confirmed by running ngrep on the loopback
> > > > interface).
> > > > On the next call, the initial offer works fine, but the answer fails
> > > > due to no command issued by opensips.
> > > >
> > > > version: opensips 3.0.2 (x86_64/linux)
> > > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> > > > Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
> > > > main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> > > >
> > > > -ovidiu
> > > >
> > > >
> > > > On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> > > >>
> > > >> Hello all,
> > > >>
> > > >> I'm running opensips 3.1.0-beta (latest version) and experiencing
> > > >> connectivity issues to the rtpengine daemon running on the same host:
> > > >> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> > > >> (22:Invalid argument)
> > > >> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
> > > >> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
> > > >> respond, disable it
> > > >> ERROR:rtpengine:rtpe_function_call: no available proxies
> > > >>
> > > >> After an opensips restart, everything comes to normal.
> > > >> I was running previously opensips 3.1.0-dev and everything was working fine.
> > > >>
> > > >> The issue starts showing up after a few days with very little traffic.
> > > >> Is there anyone experiencing this issue?
> > > >>
> > > >>
> > > >> Thanks,
> > > >> Ovidiu
> > > >>
> > > >> --
> > > >> VoIP Embedded, Inc.
> > > >> http://www.voipembedded.com
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users at lists.opensips.org
> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From ffshoh at gmail.com  Thu Jun 25 17:44:01 2020
From: ffshoh at gmail.com (Jon Abrams)
Date: Thu, 25 Jun 2020 12:44:01 -0500
Subject: [OpenSIPS-Users] Possibilities to handle short duration calls
 using new capabilities in opensips 3.1
In-Reply-To: <CAJ_X8k5_Vm_mVSz-K0Q70x15HodLevkOtV8ZyusoncdA_zabJQ@mail.gmail.com>
References: <CAJ_X8k7Xq-fD76of47+qXcDFjcifi=N71nE8xZj13ZnDqnocMA@mail.gmail.com>
 <CAP9sNzEvPQnT2V0997mW3Exp+HQN7Aj-ShdWPnmbN9aaivgiZQ@mail.gmail.com>
 <5dfaca63-4c6b-32d9-fc13-a4c9eec4bd2e@opensips.org>
 <CAJ_X8k5_Vm_mVSz-K0Q70x15HodLevkOtV8ZyusoncdA_zabJQ@mail.gmail.com>
Message-ID: <CAP9sNzFDPLRMkBoAJrP=YMJR8yYASpiB9QJ3MmUcpm-suqQX_Q@mail.gmail.com>

This is what my snippets look like. I save the actual receive time for
the BYE for accounting purposes, as the CDR will have the time of the
dialog timeout or when the called party hangs up. I didn't find a way
to prevent the BYE message from going to both parties on dialog
timeout, but by then the caller side just ignores it with an 481
Transaction Does Not Exist.

if (is_method("BYE")) {
            if(match_dialog_only()) { # this is my hacked match_dialog
which basically just does the load_ctx without triggering the chain
reaction of callbacks
                xlog("$ci: Dialog status is $DLG_status . Direction
$DLG_dir $dlg_val(caller_bye_ts)");
                $var(holdup_time) = $dlg_val(holdup_sec); #get the
dialog holdup timer value
                $var(holdup_time) = $(var(holdup_time){s.int});

                if ($DLG_dir=="downstream" && $var(holdup_time) !=
NULL && $var(holdup_time) > 0) { # only trigger if the caller hung up
and the timer is set
                    xlog("$ci: BYE holdup timer is $var(holdup_time)
seconds. Call has run $DLG_lifetime seconds");

                    if($DLG_lifetime < $var(holdup_time)) {
                        $dlg_val(caller_bye_ts)=""+$Ts; # save the
actual bye receive time to put in a cdr avp
                        $var(holdup_secs) = $var(holdup_time) - $DLG_lifetime;
                        xlog("$ci: BYE holdup timer started for
$var(holdup_secs) seconds.");
                        sl_send_reply("200", "OK");
                        $DLG_timeout = $var(holdup_secs)+1;
                        async(sleep("$var(holdup_secs)"), after_sleep);
                    }
                }
                match_dialog_process(); # match_dialog() would go here
            }
        }
....
route[after_sleep] {
    xlog("$ci: BYE holdup timer finished. Dialog status is $DLG_status");
    if ($DLG_status == 4) { # make sure we haven't received a bye from
the called party
        if (match_dialog_process()) { # you would want to do the
dialog_match() here
            xlog("$ci: Relaying delayed BYE");
            t_relay();
        }
        else {
            xlog("$ci: Dialog not matched. Callee bye preempted.");
        }
    }
    else {
        xlog("$ci: Delayed bye dialog is terminated. Not forwarding.");
    }
    exit;
}

On Thu, Jun 25, 2020 at 11:43 AM ryan embgrets <rembgrets at gmail.com> wrote:
>
> Thanks, Jon , Bogdan for the assistance.
> So, I added the below snippet after the has_totag section of my configuration.
>
>    if (is_method("BYE") && $si = "192.168.10.20") {
>                 if ( load_dialog_ctx("$ci") ) {
>                         xlog("The dialog $var(callid) has an already duration of $DLG_lifetime seconds with $DLG_dir\n");
>                         if($DLG_lifetime < 10 ) {
>                                 $DLG_timeout = 10 - $DLG_lifetime ;
>                                 send_reply(200, "OK");
>                                 exit;
>                         }
>                         unload_dialog_ctx();
>                 }
>         }
>
> And it seems to work, I wanted to check if the above snippet looks good?
>
> Is there a way to send bye to only Carrier side?
>
> I see CDRs get written after dialog timeouts, but can I get CDRs with duration when I receive a bye from the client not on dialog timeout?
>
> Thanks again for your time.
>
> Ryan.
>
>
>
>
>
> On Wed, 24 Jun 2020 at 17:55, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>>
>> Nice one Jon !
>>
>> doing a ++ here, maybe when loading the dialog ctx (before the match),
>> in the call duration is less than 6 secs, you can reply with 200 OK to
>> the BYE and set a dialog timeout for whatever number of sec you still
>> have to get to the 6 secs duration - so when you get to the overall 6
>> secs, OpenSIPS will send the BYEs to both parties.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    https://www.opensips-solutions.com
>>
>> On 6/23/20 10:43 PM, Jon Abrams wrote:
>> > You may be able to use the load_dialog_ctx()/unload_dialog_ctx()
>> > dialog functions to peek at the dialog when a BYE is received, prior
>> > to invoking match_dialog(). If it is a BYE from the calling party that
>> > you wish to delay, use an async sleep() to delay the call of
>> > match_dialog() and relay of the BYE to the far end. I do something
>> > similar now in 2.2 with a slightly patched dialog module.
>> >
>> > - Jon
>> >
>> >
>> > On Tue, Jun 23, 2020 at 1:58 AM ryan embgrets <rembgrets at gmail.com> wrote:
>> >> Greetings,
>> >>
>> >> I would like to have awesome community suggestions in handling the short duration calls.
>> >>
>> >> My clients send short duration calls towards opensips.
>> >> So if a client sends me BYE within 6 seconds of the call, I would like to terminate the client leg and keep carrier leg alive beyond a few seconds, either by transferring the second leg(carrier side) to freeswitch, or playing some media using rtpengine/rtpproxy at opensips side.
>> >>
>> >> I would like to ask, is it something that can efficiently be done using new capabilities in opensips 3.1?
>> >>
>> >> How do other people handle this?
>> >>
>> >> PS: I cannot restrict my client to not send me short duration calls, so looking for an opensips way to handle this.
>> >>
>> >> Ryan
>> >> _______________________________________________
>> >> Users mailing list
>> >> Users at lists.opensips.org
>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


From rob.dyck at telus.net  Thu Jun 25 18:53:18 2020
From: rob.dyck at telus.net (Robert Dyck)
Date: Thu, 25 Jun 2020 11:53:18 -0700
Subject: [OpenSIPS-Users] Useless NAT check with IPV6
In-Reply-To: <2694478.ZfL8zNpBrT@blacky.mylan>
References: <3700868.VqM8IeB0Os@blacky.mylan> <2694478.ZfL8zNpBrT@blacky.mylan>
Message-ID: <2506398.kXSN5OTJKJ@blacky.mylan>

The bug report was deemed unnecessary. For those searching the archive you can eliminate this 
type of error by ensuring that your script employs fix_nated_register and fix_nated_contact. 
Without it the contact will contain gibbrish and the location table will not record the actual 
address in the "received" field. Call routing will fail. This applies whether or not the contact is 
nated when GRUU is in use. Perhaps uncommon once but always present in WEBRTC.

On Thursday, June 25, 2020 9:56:39 A.M. PDT Robert Dyck wrote:


I have submitted bug #2154.
I believe it is a registration problem. The "received" should never be null in the location table.

On Wednesday, June 24, 2020 2:36:04 P.M. PDT Robert Dyck wrote:


Context: opensips 3.0.2

I wanted to cleanup a working configuration so I eliminated the NAT check if the address family 
was IPV6. This was in the initial request route. I was surprised to see that an IPV6 INVITE would 
fail. The REGISTERs were good.

Could someone explain to me what is happening.
Thanks, Rob

Config and debug on failure

       if ($af == "INET") { 

un 24 10:09:34 [1682250] Branch index is 0  

Debug of NAT check, working scenario

Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE 







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/ac850986/attachment.html>

From liviu at opensips.org  Thu Jun 25 19:10:18 2020
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 25 Jun 2020 22:10:18 +0300
Subject: [OpenSIPS-Users] Problem with add_rr_param() in v2.4.7
In-Reply-To: <a8c3e491-b636-83c6-3fb9-22d41ec8b802@opensips.org>
References: <000201d62fb2$70949c40$51bdd4c0$@smartvox.co.uk>
 <a8c3e491-b636-83c6-3fb9-22d41ec8b802@opensips.org>
Message-ID: <1d647cab-3b88-6f3e-f7bc-84629b27b7e1@opensips.org>

On 25.06.2020 19:25, Liviu Chircu wrote:
> Currently investigating what happened over there and working towards a 
> solution! :)

A fix for the issue [1] is now available on latest 2.4.7 and above.  
Many thanks for the report and for your patience, John!

Cheers,

[1]: https://github.com/OpenSIPS/opensips/commit/e3ca95ecd0b

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com



From sanderson at ArnoldMagnetics.com  Thu Jun 25 21:29:08 2020
From: sanderson at ArnoldMagnetics.com (Samuel Anderson)
Date: Thu, 25 Jun 2020 21:29:08 +0000
Subject: [OpenSIPS-Users] SUBSCRIBE & NOTIFY - NAT Problems
Message-ID: <19a0eb8b5b954e7ea51d5f5160748a18@ArnoldMagnetics.com>

Hi Everyone,

I use OpenSIPS as an SBC for an Asterisk server. The OpenSIPS server is multi-homed and has an interface on the WAN and DMZ. I'm able to make calls and send sequential requests in a dialog, such as INVITEs and BYEs, from endpoints behind NAT without any issues. My problem is when the endpoints try to  SUBSCRIBE, and Asterisk sends a NOTIFY message back. OpenSIPS is sending the NOTIFY to the original contact header specified in the SUBSCRIBE request. It is not sending the NOTIFY to the address it received it from. It does rewrite the contact header when the SUBSCRIBE message is sent to Asterisk, and OpenSIPS also sends the 200 OK reply to the correct address.

How can I configure OpenSIPS to send the additional NOTIFY messages within the dialog to the address it received it from? I've tried to create a dialog for SUBSCRIBE requests, but it looks like that only works for INVITEs. Any help would be appreciated. It currently works fine with INVITEs and BYEs.

I use double record routes, topology hiding, and the dialog module. I also set "fix_nated_contact" when the SUBSCRIBE is received.

Thank you for your assistance.

-Sam

This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.

Thank you.


From osas at voipembedded.com  Thu Jun 25 23:29:10 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Thu, 25 Jun 2020 19:29:10 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
 <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
Message-ID: <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>

It looks like the hidden IOV_MAX is set to 1024 in debian.
I tested a patch and all looks good.
It seems that there is an error in the code: writev has the wrong
number of iovcnt (should be one less).
I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).

-ovidiu

On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>
> We will need to add a param to control the max number of buffers.
>
> -ovidiu
>
> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> >
> > It seems that when we have more than roughly 1000 buffers, the send fails.
> >
> > -ovidiu
> >
> > On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
> > >
> > > Hello Razvan,
> > >
> > > The system is a debian buster one.
> > > I patched the code:
> > > #ifdef IOV_MAX
> > >     LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> > > #else
> > >     LM_NOTICE("no IOV_MAX\n");
> > > #endif
> > >
> > > and I get:
> > > NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> > > in the logs.
> > >
> > > Then I patched the code again to check how many buffers are being used:
> > > The max so far was 73:
> > > LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> > > got me:
> > > NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
> > >
> > > I will continue to monitor the system to see if there is a correlation
> > > between the error and the number of buffers.
> > >
> > > Thanks,
> > > Ovidiu
> > >
> > > On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
> > > >
> > > > Hi, Ovidiu!
> > > >
> > > > I doubt this is a problem of OpenSIPS version, but rather of the OS you
> > > > are running on. I suspect that error comes from the fact that the bson
> > > > resulted has more than IOV_MAX elements, which if I recall correctly it
> > > > was 15 on some OSes.
> > > > We had a similar problem in rtpproy[1], where we had merged the buffers
> > > > in a single one just to pass over this limitation. Could you check if
> > > > you are facing a similar issue?
> > > >
> > > > [1]
> > > > https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> > > >
> > > > Răzvan Crainea
> > > > OpenSIPS Core Developer
> > > > http://www.opensips-solutions.com
> > > >
> > > > On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> > > > > This is happening also on the latest 3.0.
> > > > > The weird thing is that opensips doesn't send anything to rtpengine.
> > > > > The first opensips/rtpengine exchange on the initial INVITE works ok,
> > > > > but the opensips/rtpengine exchange on the 200ok fails (no command is
> > > > > sent by opensips - confirmed by running ngrep on the loopback
> > > > > interface).
> > > > > On the next call, the initial offer works fine, but the answer fails
> > > > > due to no command issued by opensips.
> > > > >
> > > > > version: opensips 3.0.2 (x86_64/linux)
> > > > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> > > > > Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
> > > > > main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> > > > >
> > > > > -ovidiu
> > > > >
> > > > >
> > > > > On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> > > > >>
> > > > >> Hello all,
> > > > >>
> > > > >> I'm running opensips 3.1.0-beta (latest version) and experiencing
> > > > >> connectivity issues to the rtpengine daemon running on the same host:
> > > > >> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> > > > >> (22:Invalid argument)
> > > > >> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
> > > > >> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
> > > > >> respond, disable it
> > > > >> ERROR:rtpengine:rtpe_function_call: no available proxies
> > > > >>
> > > > >> After an opensips restart, everything comes to normal.
> > > > >> I was running previously opensips 3.1.0-dev and everything was working fine.
> > > > >>
> > > > >> The issue starts showing up after a few days with very little traffic.
> > > > >> Is there anyone experiencing this issue?
> > > > >>
> > > > >>
> > > > >> Thanks,
> > > > >> Ovidiu
> > > > >>
> > > > >> --
> > > > >> VoIP Embedded, Inc.
> > > > >> http://www.voipembedded.com
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users at lists.opensips.org
> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > >
> > >
> > >
> > > --
> > > VoIP Embedded, Inc.
> > > http://www.voipembedded.com
> >
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From sanderson at ArnoldMagnetics.com  Thu Jun 25 23:58:55 2020
From: sanderson at ArnoldMagnetics.com (Samuel Anderson)
Date: Thu, 25 Jun 2020 23:58:55 +0000
Subject: [OpenSIPS-Users] SUBSCRIBE & NOTIFY - NAT Problems
Message-ID: <384e503489134ed29e0855dd88707f42@ArnoldMagnetics.com>

Hi Everyone,

I figured it out. I needed to add fix_nated_contact() on the reply route for the notify messages. The 200 OK messages were overwriting the contact from the corrected SUBSCRIBE request. After doing this, OpenSIPS now sends the NOTIFY messages to the correct address.


        if (has_totag()) {
                if (topology_hiding_match()) {
                        xlog("Successfully matched this request to a topology hiding dialog. \n");
                        xlog("Calller side callid is $ci \n");
                        xlog("Callee side callid  is $TH_callee_callid \n");
                        if (is_method("NOTIFY")){
                                fix_nated_contact();
                                t_on_reply("NOTIFYReply");
                        }
                        t_relay();
                        exit;
        }

onreply_route[NOTIFYReply] {

        #NAT for 200 OK replys
        if (t_check_status("(200)")) {
                fix_nated_contact();
        }
}


Thank you,

-Sam Anderson

-----Original Message-----
From: Samuel Anderson 
Sent: Thursday, June 25, 2020 5:29 PM
To: 'users at lists.opensips.org' <users at lists.opensips.org>
Subject: SUBSCRIBE & NOTIFY - NAT Problems

Hi Everyone,

I use OpenSIPS as an SBC for an Asterisk server. The OpenSIPS server is multi-homed and has an interface on the WAN and DMZ. I'm able to make calls and send sequential requests in a dialog, such as INVITEs and BYEs, from endpoints behind NAT without any issues. My problem is when the endpoints try to  SUBSCRIBE, and Asterisk sends a NOTIFY message back. OpenSIPS is sending the NOTIFY to the original contact header specified in the SUBSCRIBE request. It is not sending the NOTIFY to the address it received it from. It does rewrite the contact header when the SUBSCRIBE message is sent to Asterisk, and OpenSIPS also sends the 200 OK reply to the correct address.

How can I configure OpenSIPS to send the additional NOTIFY messages within the dialog to the address it received it from? I've tried to create a dialog for SUBSCRIBE requests, but it looks like that only works for INVITEs. Any help would be appreciated. It currently works fine with INVITEs and BYEs.

I use double record routes, topology hiding, and the dialog module. I also set "fix_nated_contact" when the SUBSCRIBE is received.

Thank you for your assistance.

-Sam

This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.

Thank you.


From razvan at opensips.org  Fri Jun 26 07:54:04 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Fri, 26 Jun 2020 10:54:04 +0300
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
 <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
 <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>
Message-ID: <ba59f732-2576-d1c9-09b6-2b5c9e16d1bd@opensips.org>

Hi, Ovidiu!

So you're saying that the IOV_MAX is not explicitly defined, but it does 
fail after 1024 buffers, correct? If so, perhaps we should limit the 
number of buffers to 1024, if not already defined.
I did notice the extra vcnt as well, but I though that was related to 
the fact that it allocates one extra iovec (at the headr) for the 
cookie, and sometime uses it, sometime doesn't. Nevertheless, it is 
consistent on both cases, UNIX & UDP, both have that vcnt + 1. Now I 
haven't checked whether this is correct or not, could you please confirm?

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 6/26/20 2:29 AM, Ovidiu Sas wrote:
> It looks like the hidden IOV_MAX is set to 1024 in debian.
> I tested a patch and all looks good.
> It seems that there is an error in the code: writev has the wrong
> number of iovcnt (should be one less).
> I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).
> 
> -ovidiu
> 
> On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>
>> We will need to add a param to control the max number of buffers.
>>
>> -ovidiu
>>
>> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>
>>> It seems that when we have more than roughly 1000 buffers, the send fails.
>>>
>>> -ovidiu
>>>
>>> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>
>>>> Hello Razvan,
>>>>
>>>> The system is a debian buster one.
>>>> I patched the code:
>>>> #ifdef IOV_MAX
>>>>      LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
>>>> #else
>>>>      LM_NOTICE("no IOV_MAX\n");
>>>> #endif
>>>>
>>>> and I get:
>>>> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
>>>> in the logs.
>>>>
>>>> Then I patched the code again to check how many buffers are being used:
>>>> The max so far was 73:
>>>> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
>>>> got me:
>>>> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
>>>>
>>>> I will continue to monitor the system to see if there is a correlation
>>>> between the error and the number of buffers.
>>>>
>>>> Thanks,
>>>> Ovidiu
>>>>
>>>> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
>>>>>
>>>>> Hi, Ovidiu!
>>>>>
>>>>> I doubt this is a problem of OpenSIPS version, but rather of the OS you
>>>>> are running on. I suspect that error comes from the fact that the bson
>>>>> resulted has more than IOV_MAX elements, which if I recall correctly it
>>>>> was 15 on some OSes.
>>>>> We had a similar problem in rtpproy[1], where we had merged the buffers
>>>>> in a single one just to pass over this limitation. Could you check if
>>>>> you are facing a similar issue?
>>>>>
>>>>> [1]
>>>>> https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
>>>>>
>>>>> Răzvan Crainea
>>>>> OpenSIPS Core Developer
>>>>> http://www.opensips-solutions.com
>>>>>
>>>>> On 6/24/20 7:32 AM, Ovidiu Sas wrote:
>>>>>> This is happening also on the latest 3.0.
>>>>>> The weird thing is that opensips doesn't send anything to rtpengine.
>>>>>> The first opensips/rtpengine exchange on the initial INVITE works ok,
>>>>>> but the opensips/rtpengine exchange on the 200ok fails (no command is
>>>>>> sent by opensips - confirmed by running ngrep on the loopback
>>>>>> interface).
>>>>>> On the next call, the initial offer works fine, but the answer fails
>>>>>> due to no command issued by opensips.
>>>>>>
>>>>>> version: opensips 3.0.2 (x86_64/linux)
>>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>>>>>> Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
>>>>>> main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
>>>>>>
>>>>>> -ovidiu
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I'm running opensips 3.1.0-beta (latest version) and experiencing
>>>>>>> connectivity issues to the rtpengine daemon running on the same host:
>>>>>>> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
>>>>>>> (22:Invalid argument)
>>>>>>> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
>>>>>>> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
>>>>>>> respond, disable it
>>>>>>> ERROR:rtpengine:rtpe_function_call: no available proxies
>>>>>>>
>>>>>>> After an opensips restart, everything comes to normal.
>>>>>>> I was running previously opensips 3.1.0-dev and everything was working fine.
>>>>>>>
>>>>>>> The issue starts showing up after a few days with very little traffic.
>>>>>>> Is there anyone experiencing this issue?
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ovidiu
>>>>>>>
>>>>>>> --
>>>>>>> VoIP Embedded, Inc.
>>>>>>> http://www.voipembedded.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>> --
>>>> VoIP Embedded, Inc.
>>>> http://www.voipembedded.com
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
> 
> 
> 


From osas at voipembedded.com  Fri Jun 26 13:35:54 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 26 Jun 2020 09:35:54 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <ba59f732-2576-d1c9-09b6-2b5c9e16d1bd@opensips.org>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
 <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
 <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>
 <ba59f732-2576-d1c9-09b6-2b5c9e16d1bd@opensips.org>
Message-ID: <CAND0LksGYHaT0-Pu2KTQdJOpO7EPeAK0-nwLSdJy6J7h1do+hA@mail.gmail.com>

Hello Razvan,

On ubuntu we have a failure for more then 1024 buffers. There is something
defined in some experimental headers (as __IOV_MAX), but the IOV_MAX define
is not visible in the rtpengine module.

And yes, there is an extra buffer. I guess the length of that extra buffer
was zero and that’s why it didn’t create issues. But as soon as I
concatenated the buffer, the issue showed up and I had an extra trailing
string at the end of the rtpengine command that was sent on the wire.
After reducing  the number of buffers by one, all was good on both
scenarios: sending with and without concatenated buffers.
I will prepare a fix for it and push it.

-ovidiu

On Fri, Jun 26, 2020 at 03:55 Răzvan Crainea <razvan at opensips.org> wrote:

> Hi, Ovidiu!
>
> So you're saying that the IOV_MAX is not explicitly defined, but it does
> fail after 1024 buffers, correct? If so, perhaps we should limit the
> number of buffers to 1024, if not already defined.
> I did notice the extra vcnt as well, but I though that was related to
> the fact that it allocates one extra iovec (at the headr) for the
> cookie, and sometime uses it, sometime doesn't. Nevertheless, it is
> consistent on both cases, UNIX & UDP, both have that vcnt + 1. Now I
> haven't checked whether this is correct or not, could you please confirm?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 6/26/20 2:29 AM, Ovidiu Sas wrote:
> > It looks like the hidden IOV_MAX is set to 1024 in debian.
> > I tested a patch and all looks good.
> > It seems that there is an error in the code: writev has the wrong
> > number of iovcnt (should be one less).
> > I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).
> >
> > -ovidiu
> >
> > On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas <osas at voipembedded.com>
> wrote:
> >>
> >> We will need to add a param to control the max number of buffers.
> >>
> >> -ovidiu
> >>
> >> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com>
> wrote:
> >>>
> >>> It seems that when we have more than roughly 1000 buffers, the send
> fails.
> >>>
> >>> -ovidiu
> >>>
> >>> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com>
> wrote:
> >>>>
> >>>> Hello Razvan,
> >>>>
> >>>> The system is a debian buster one.
> >>>> I patched the code:
> >>>> #ifdef IOV_MAX
> >>>>      LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> >>>> #else
> >>>>      LM_NOTICE("no IOV_MAX\n");
> >>>> #endif
> >>>>
> >>>> and I get:
> >>>> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> >>>> in the logs.
> >>>>
> >>>> Then I patched the code again to check how many buffers are being
> used:
> >>>> The max so far was 73:
> >>>> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> >>>> got me:
> >>>> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v ,
> 73)
> >>>>
> >>>> I will continue to monitor the system to see if there is a correlation
> >>>> between the error and the number of buffers.
> >>>>
> >>>> Thanks,
> >>>> Ovidiu
> >>>>
> >>>> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org>
> wrote:
> >>>>>
> >>>>> Hi, Ovidiu!
> >>>>>
> >>>>> I doubt this is a problem of OpenSIPS version, but rather of the OS
> you
> >>>>> are running on. I suspect that error comes from the fact that the
> bson
> >>>>> resulted has more than IOV_MAX elements, which if I recall correctly
> it
> >>>>> was 15 on some OSes.
> >>>>> We had a similar problem in rtpproy[1], where we had merged the
> buffers
> >>>>> in a single one just to pass over this limitation. Could you check if
> >>>>> you are facing a similar issue?
> >>>>>
> >>>>> [1]
> >>>>>
> https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> >>>>>
> >>>>> Răzvan Crainea
> >>>>> OpenSIPS Core Developer
> >>>>> http://www.opensips-solutions.com
> >>>>>
> >>>>> On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> >>>>>> This is happening also on the latest 3.0.
> >>>>>> The weird thing is that opensips doesn't send anything to rtpengine.
> >>>>>> The first opensips/rtpengine exchange on the initial INVITE works
> ok,
> >>>>>> but the opensips/rtpengine exchange on the 200ok fails (no command
> is
> >>>>>> sent by opensips - confirmed by running ngrep on the loopback
> >>>>>> interface).
> >>>>>> On the next call, the initial offer works fine, but the answer fails
> >>>>>> due to no command issued by opensips.
> >>>>>>
> >>>>>> version: opensips 3.0.2 (x86_64/linux)
> >>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> >>>>>> Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
> >>>>>> main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> >>>>>>
> >>>>>> -ovidiu
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com>
> wrote:
> >>>>>>>
> >>>>>>> Hello all,
> >>>>>>>
> >>>>>>> I'm running opensips 3.1.0-beta (latest version) and experiencing
> >>>>>>> connectivity issues to the rtpengine daemon running on the same
> host:
> >>>>>>> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP
> proxy
> >>>>>>> (22:Invalid argument)
> >>>>>>> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a
> RTP proxy
> >>>>>>> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223>
> does not
> >>>>>>> respond, disable it
> >>>>>>> ERROR:rtpengine:rtpe_function_call: no available proxies
> >>>>>>>
> >>>>>>> After an opensips restart, everything comes to normal.
> >>>>>>> I was running previously opensips 3.1.0-dev and everything was
> working fine.
> >>>>>>>
> >>>>>>> The issue starts showing up after a few days with very little
> traffic.
> >>>>>>> Is there anyone experiencing this issue?
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Ovidiu
> >>>>>>>
> >>>>>>> --
> >>>>>>> VoIP Embedded, Inc.
> >>>>>>> http://www.voipembedded.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Users mailing list
> >>>>> Users at lists.opensips.org
> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> VoIP Embedded, Inc.
> >>>> http://www.voipembedded.com
> >>>
> >>>
> >>>
> >>> --
> >>> VoIP Embedded, Inc.
> >>> http://www.voipembedded.com
> >>
> >>
> >>
> >> --
> >> VoIP Embedded, Inc.
> >> http://www.voipembedded.com
> >
> >
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200626/113ec084/attachment-0001.html>

From adrian.fretwell at topgreen.co.uk  Fri Jun 26 14:30:44 2020
From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell)
Date: Fri, 26 Jun 2020 15:30:44 +0100
Subject: [OpenSIPS-Users] Resource List Server- Help with xcap table data
Message-ID: <a2cf8a0e-d4ed-cea2-da48-6d5cdeede007@topgreen.co.uk>

Hello All,

I think I am just missing a small amount of information here.   I am 
trying to get the resource list sever to work but I think my problem is 
not knowing what data to put into the xcap table.

I have a user 201 at mydomain.uk that wants to subscribe to 
my-list at mydomain.uk  So in the table I put:

username: 201

domain: mydomain.uk

doc: (an xml document see below)

doc_type: 4

etag: a.1234

source: 1

doc_uri: sip:my-list at mydomain.uk

port: 5060

Can anyone tell me what I am doing wrong please.  when I call 
rls_handle_subscribe() it return with $rc == 10.

XML doc:

<?xml version="1.0" encoding="UTF-8"?>
    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
       xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <service uri="sip:my-list at mydomain.uk">
        <list name="my-list">
           <rl:entry uri="202 at mydomain.uk"/>
           <rl:entry uri="203 at mydomain.uk"/>
            </list>
            <packages>
               <package>presence</package>
            </packages>
         </service>
    </rls-services>


-- 
Kind regards,

Adrian Fretwell

Sibthorpe
Nottinghamshire
UK.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200626/5628ce3d/attachment.html>

From osas at voipembedded.com  Sat Jun 27 18:35:42 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Sat, 27 Jun 2020 14:35:42 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0LksGYHaT0-Pu2KTQdJOpO7EPeAK0-nwLSdJy6J7h1do+hA@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
 <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
 <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>
 <ba59f732-2576-d1c9-09b6-2b5c9e16d1bd@opensips.org>
 <CAND0LksGYHaT0-Pu2KTQdJOpO7EPeAK0-nwLSdJy6J7h1do+hA@mail.gmail.com>
Message-ID: <CAND0Lkv2LCFYey0JqeXWKRt_qPdjaJmJToGvMgo89bsyDUeBeQ@mail.gmail.com>

Fix implemented on trunk, 3.1 and 3.0.
We should update the fix on rtpproxy to match rtpengine and move the
OSIP_IOV_MAX define somewhere upper in the code tree to be visible by
both rtpproxy and rtpengine modules.
For trunk, maybe we should add a new param.

Should we backport this fix to 2.4?

Thanks,
Ovidiu

On Fri, Jun 26, 2020 at 9:35 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>
> Hello Razvan,
>
> On ubuntu we have a failure for more then 1024 buffers. There is something defined in some experimental headers (as __IOV_MAX), but the IOV_MAX define is not visible in the rtpengine module.
>
> And yes, there is an extra buffer. I guess the length of that extra buffer was zero and that’s why it didn’t create issues. But as soon as I concatenated the buffer, the issue showed up and I had an extra trailing string at the end of the rtpengine command that was sent on the wire.
> After reducing  the number of buffers by one, all was good on both scenarios: sending with and without concatenated buffers.
> I will prepare a fix for it and push it.
>
> -ovidiu
>
> On Fri, Jun 26, 2020 at 03:55 Răzvan Crainea <razvan at opensips.org> wrote:
>>
>> Hi, Ovidiu!
>>
>> So you're saying that the IOV_MAX is not explicitly defined, but it does
>> fail after 1024 buffers, correct? If so, perhaps we should limit the
>> number of buffers to 1024, if not already defined.
>> I did notice the extra vcnt as well, but I though that was related to
>> the fact that it allocates one extra iovec (at the headr) for the
>> cookie, and sometime uses it, sometime doesn't. Nevertheless, it is
>> consistent on both cases, UNIX & UDP, both have that vcnt + 1. Now I
>> haven't checked whether this is correct or not, could you please confirm?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 6/26/20 2:29 AM, Ovidiu Sas wrote:
>> > It looks like the hidden IOV_MAX is set to 1024 in debian.
>> > I tested a patch and all looks good.
>> > It seems that there is an error in the code: writev has the wrong
>> > number of iovcnt (should be one less).
>> > I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).
>> >
>> > -ovidiu
>> >
>> > On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>> >>
>> >> We will need to add a param to control the max number of buffers.
>> >>
>> >> -ovidiu
>> >>
>> >> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>> >>>
>> >>> It seems that when we have more than roughly 1000 buffers, the send fails.
>> >>>
>> >>> -ovidiu
>> >>>
>> >>> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>> >>>>
>> >>>> Hello Razvan,
>> >>>>
>> >>>> The system is a debian buster one.
>> >>>> I patched the code:
>> >>>> #ifdef IOV_MAX
>> >>>>      LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
>> >>>> #else
>> >>>>      LM_NOTICE("no IOV_MAX\n");
>> >>>> #endif
>> >>>>
>> >>>> and I get:
>> >>>> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
>> >>>> in the logs.
>> >>>>
>> >>>> Then I patched the code again to check how many buffers are being used:
>> >>>> The max so far was 73:
>> >>>> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
>> >>>> got me:
>> >>>> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
>> >>>>
>> >>>> I will continue to monitor the system to see if there is a correlation
>> >>>> between the error and the number of buffers.
>> >>>>
>> >>>> Thanks,
>> >>>> Ovidiu
>> >>>>
>> >>>> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
>> >>>>>
>> >>>>> Hi, Ovidiu!
>> >>>>>
>> >>>>> I doubt this is a problem of OpenSIPS version, but rather of the OS you
>> >>>>> are running on. I suspect that error comes from the fact that the bson
>> >>>>> resulted has more than IOV_MAX elements, which if I recall correctly it
>> >>>>> was 15 on some OSes.
>> >>>>> We had a similar problem in rtpproy[1], where we had merged the buffers
>> >>>>> in a single one just to pass over this limitation. Could you check if
>> >>>>> you are facing a similar issue?
>> >>>>>
>> >>>>> [1]
>> >>>>> https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
>> >>>>>
>> >>>>> Răzvan Crainea
>> >>>>> OpenSIPS Core Developer
>> >>>>> http://www.opensips-solutions.com
>> >>>>>
>> >>>>> On 6/24/20 7:32 AM, Ovidiu Sas wrote:
>> >>>>>> This is happening also on the latest 3.0.
>> >>>>>> The weird thing is that opensips doesn't send anything to rtpengine.
>> >>>>>> The first opensips/rtpengine exchange on the initial INVITE works ok,
>> >>>>>> but the opensips/rtpengine exchange on the 200ok fails (no command is
>> >>>>>> sent by opensips - confirmed by running ngrep on the loopback
>> >>>>>> interface).
>> >>>>>> On the next call, the initial offer works fine, but the answer fails
>> >>>>>> due to no command issued by opensips.
>> >>>>>>
>> >>>>>> version: opensips 3.0.2 (x86_64/linux)
>> >>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>> >>>>>> Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
>> >>>>>> main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
>> >>>>>>
>> >>>>>> -ovidiu
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>> >>>>>>>
>> >>>>>>> Hello all,
>> >>>>>>>
>> >>>>>>> I'm running opensips 3.1.0-beta (latest version) and experiencing
>> >>>>>>> connectivity issues to the rtpengine daemon running on the same host:
>> >>>>>>> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
>> >>>>>>> (22:Invalid argument)
>> >>>>>>> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
>> >>>>>>> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
>> >>>>>>> respond, disable it
>> >>>>>>> ERROR:rtpengine:rtpe_function_call: no available proxies
>> >>>>>>>
>> >>>>>>> After an opensips restart, everything comes to normal.
>> >>>>>>> I was running previously opensips 3.1.0-dev and everything was working fine.
>> >>>>>>>
>> >>>>>>> The issue starts showing up after a few days with very little traffic.
>> >>>>>>> Is there anyone experiencing this issue?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Thanks,
>> >>>>>>> Ovidiu
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> VoIP Embedded, Inc.
>> >>>>>>> http://www.voipembedded.com
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Users mailing list
>> >>>>> Users at lists.opensips.org
>> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> VoIP Embedded, Inc.
>> >>>> http://www.voipembedded.com
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> VoIP Embedded, Inc.
>> >>> http://www.voipembedded.com
>> >>
>> >>
>> >>
>> >> --
>> >> VoIP Embedded, Inc.
>> >> http://www.voipembedded.com
>> >
>> >
>> >
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From igor.pavlov1987 at gmail.com  Sun Jun 28 10:32:34 2020
From: igor.pavlov1987 at gmail.com (Igor Pavlov)
Date: Sun, 28 Jun 2020 14:32:34 +0400
Subject: [OpenSIPS-Users] Dispatcher. Disable ping for particular entry/GW.
Message-ID: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>

Hi all,

Is it possible to disable ping for particular entry in set at all?

I have a set of GWs which has 3-4 entries and some of these entries
(vendors) don't answer to OPTIONS requests (they are like an persistent
active GWs). I know that there is an 'ds_probing_list' setting, but in my
case list can contain GWs that should not be pinged.

-- 

Best regards,
Igor Pavlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200628/273b75d8/attachment.html>

From arsperger at gmail.com  Mon Jun 29 03:37:30 2020
From: arsperger at gmail.com (Arsen Semenov)
Date: Mon, 29 Jun 2020 08:37:30 +0500
Subject: [OpenSIPS-Users] Dispatcher. Disable ping for particular
	entry/GW.
In-Reply-To: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>
References: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>
Message-ID: <CAC3hFApz-EUrY5cRZ-cRRiwVoBrnRby9SNDyvYnK5uvmHGTz=w@mail.gmail.com>

Hi Igor,

Check ds_probing_mode parameter and gw state options.



On Sun, Jun 28, 2020 at 3:34 PM Igor Pavlov <igor.pavlov1987 at gmail.com>
wrote:

> Hi all,
>
> Is it possible to disable ping for particular entry in set at all?
>
> I have a set of GWs which has 3-4 entries and some of these entries
> (vendors) don't answer to OPTIONS requests (they are like an persistent
> active GWs). I know that there is an 'ds_probing_list' setting, but in my
> case list can contain GWs that should not be pinged.
>
> --
>
> Best regards,
> Igor Pavlov
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Arsen Semenov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200629/2092b2ad/attachment.html>

From igor.pavlov1987 at gmail.com  Mon Jun 29 06:29:59 2020
From: igor.pavlov1987 at gmail.com (Igor Pavlov)
Date: Mon, 29 Jun 2020 10:29:59 +0400
Subject: [OpenSIPS-Users] Dispatcher. Disable ping for particular
	entry/GW.
In-Reply-To: <CAC3hFApz-EUrY5cRZ-cRRiwVoBrnRby9SNDyvYnK5uvmHGTz=w@mail.gmail.com>
References: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>
 <CAC3hFApz-EUrY5cRZ-cRRiwVoBrnRby9SNDyvYnK5uvmHGTz=w@mail.gmail.com>
Message-ID: <CAAgv6-p-S=oJstMax0C6apyo4zJVmWqudVEQDF3Ofa9cET5dcQ@mail.gmail.com>

Hi Arsen,

This parameter is not quite what I need. I need to always check GWs in set,
but some of them should not be pinged.
Something like this:

id: 0
sip:1.1.1.1:5060 -> pinging
sip:2.2.2.2:5060 -> pinging
sip:3.3.3.3:5060 -> ping disabled (always in 'active' state)

I think I need to modify the dispatcher's source code to get a custom build.

пн, 29 июн. 2020 г. в 07:40, Arsen Semenov <arsperger at gmail.com>:

> Hi Igor,
>
> Check ds_probing_mode parameter and gw state options.
>
>
>
> On Sun, Jun 28, 2020 at 3:34 PM Igor Pavlov <igor.pavlov1987 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> Is it possible to disable ping for particular entry in set at all?
>>
>> I have a set of GWs which has 3-4 entries and some of these entries
>> (vendors) don't answer to OPTIONS requests (they are like an persistent
>> active GWs). I know that there is an 'ds_probing_list' setting, but in my
>> case list can contain GWs that should not be pinged.
>>
>> --
>>
>> Best regards,
>> Igor Pavlov
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> Arsen Semenov
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

Best regards,
Igor Pavlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200629/2e0eb47d/attachment.html>

From solarmon at one-n.co.uk  Mon Jun 29 08:24:33 2020
From: solarmon at one-n.co.uk (solarmon)
Date: Mon, 29 Jun 2020 09:24:33 +0100
Subject: [OpenSIPS-Users] Dispatcher. Disable ping for particular
	entry/GW.
In-Reply-To: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>
References: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>
Message-ID: <CAOXfywO5pHkZsrA6o9ha=c+wc0b3ZeppwfbO9uFBFRDgAeO3mQ@mail.gmail.com>

Hi Igor,

Have you tried using the ds_set_state MI command?

(for 2.4.x)
https://opensips.org/html/docs/modules/2.4.x/dispatcher.html#mi_ds_set_state


On Sun, 28 Jun 2020 at 11:35, Igor Pavlov <igor.pavlov1987 at gmail.com> wrote:

> Hi all,
>
> Is it possible to disable ping for particular entry in set at all?
>
> I have a set of GWs which has 3-4 entries and some of these entries
> (vendors) don't answer to OPTIONS requests (they are like an persistent
> active GWs). I know that there is an 'ds_probing_list' setting, but in my
> case list can contain GWs that should not be pinged.
>
> --
>
> Best regards,
> Igor Pavlov
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200629/975fec33/attachment.html>

From igor.pavlov1987 at gmail.com  Mon Jun 29 10:15:46 2020
From: igor.pavlov1987 at gmail.com (Igor Pavlov)
Date: Mon, 29 Jun 2020 14:15:46 +0400
Subject: [OpenSIPS-Users] Dispatcher. Disable ping for particular
	entry/GW.
In-Reply-To: <CAOXfywO5pHkZsrA6o9ha=c+wc0b3ZeppwfbO9uFBFRDgAeO3mQ@mail.gmail.com>
References: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>
 <CAOXfywO5pHkZsrA6o9ha=c+wc0b3ZeppwfbO9uFBFRDgAeO3mQ@mail.gmail.com>
Message-ID: <CAAgv6-q+swZpwrjyyusvQO4oUAEzhga2vX9X=FmMN48FECpV4Q@mail.gmail.com>

Hi solarmon,

Yes, I have tried. It will not help, because when you set GW in 'active'
state and GW is not able to respond to OPTIONS (because GW is not supported
pinging) it will automatically switched to 'Probing\Inactive' state.

пн, 29 июн. 2020 г. в 12:27, solarmon <solarmon at one-n.co.uk>:

> Hi Igor,
>
> Have you tried using the ds_set_state MI command?
>
> (for 2.4.x)
>
> https://opensips.org/html/docs/modules/2.4.x/dispatcher.html#mi_ds_set_state
>
>
> On Sun, 28 Jun 2020 at 11:35, Igor Pavlov <igor.pavlov1987 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> Is it possible to disable ping for particular entry in set at all?
>>
>> I have a set of GWs which has 3-4 entries and some of these entries
>> (vendors) don't answer to OPTIONS requests (they are like an persistent
>> active GWs). I know that there is an 'ds_probing_list' setting, but in my
>> case list can contain GWs that should not be pinged.
>>
>> --
>>
>> Best regards,
>> Igor Pavlov
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

Best regards,
Igor Pavlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200629/29a3dce9/attachment-0001.html>

From arsperger at gmail.com  Mon Jun 29 10:39:39 2020
From: arsperger at gmail.com (Arsen Semenov)
Date: Mon, 29 Jun 2020 15:39:39 +0500
Subject: [OpenSIPS-Users] Dispatcher. Disable ping for particular
	entry/GW.
In-Reply-To: <CAAgv6-q+swZpwrjyyusvQO4oUAEzhga2vX9X=FmMN48FECpV4Q@mail.gmail.com>
References: <CAAgv6-qZQZP+uSLnKXz3MXCF7iq9ztmPfv8E3YscuRhG3DgTiQ@mail.gmail.com>
 <CAOXfywO5pHkZsrA6o9ha=c+wc0b3ZeppwfbO9uFBFRDgAeO3mQ@mail.gmail.com>
 <CAAgv6-q+swZpwrjyyusvQO4oUAEzhga2vX9X=FmMN48FECpV4Q@mail.gmail.com>
Message-ID: <CAC3hFAqcO6k9zOEZKowzCA2fz9u99YQypuG7dQUpJ8dVouoshg@mail.gmail.com>

Igor,
you are right it will switch to proing state
https://github.com/OpenSIPS/opensips/blob/master/modules/dispatcher/dispatch.c#L2489

If I got you right, here you should have a gw state which won't be selected
for probing.
https://github.com/OpenSIPS/opensips/blob/master/modules/dispatcher/dispatch.c#L2530

On Mon, Jun 29, 2020 at 3:18 PM Igor Pavlov <igor.pavlov1987 at gmail.com>
wrote:

> Hi solarmon,
>
> Yes, I have tried. It will not help, because when you set GW in 'active'
> state and GW is not able to respond to OPTIONS (because GW is not supported
> pinging) it will automatically switched to 'Probing\Inactive' state.
>
> пн, 29 июн. 2020 г. в 12:27, solarmon <solarmon at one-n.co.uk>:
>
>> Hi Igor,
>>
>> Have you tried using the ds_set_state MI command?
>>
>> (for 2.4.x)
>>
>> https://opensips.org/html/docs/modules/2.4.x/dispatcher.html#mi_ds_set_state
>>
>>
>> On Sun, 28 Jun 2020 at 11:35, Igor Pavlov <igor.pavlov1987 at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> Is it possible to disable ping for particular entry in set at all?
>>>
>>> I have a set of GWs which has 3-4 entries and some of these entries
>>> (vendors) don't answer to OPTIONS requests (they are like an persistent
>>> active GWs). I know that there is an 'ds_probing_list' setting, but in my
>>> case list can contain GWs that should not be pinged.
>>>
>>> --
>>>
>>> Best regards,
>>> Igor Pavlov
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
>
> Best regards,
> Igor Pavlov
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Arsen Semenov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200629/b4f1c84a/attachment.html>

From razvan at opensips.org  Mon Jun 29 11:19:00 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Mon, 29 Jun 2020 14:19:00 +0300
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0Lkv2LCFYey0JqeXWKRt_qPdjaJmJToGvMgo89bsyDUeBeQ@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
 <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
 <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>
 <ba59f732-2576-d1c9-09b6-2b5c9e16d1bd@opensips.org>
 <CAND0LksGYHaT0-Pu2KTQdJOpO7EPeAK0-nwLSdJy6J7h1do+hA@mail.gmail.com>
 <CAND0Lkv2LCFYey0JqeXWKRt_qPdjaJmJToGvMgo89bsyDUeBeQ@mail.gmail.com>
Message-ID: <3254b1ff-81a2-4b69-7366-717fa21a92fc@opensips.org>

Hi, Ovidiu!

I agree we should match the two modules to use a common logic.
I believe we should backport this in 2.4 as well, since it doesn't work 
for all scenarios, therefore it is considered a bug.

I somehow doubt this should be a module's param, because it is only 
needed in certain circumstances, where IOV_MAX is not "visible" in the 
code. IMO, a decent, commonly accepted limit should be enough - so I 
believe the way you've done it for 3.0 and 3.1 is more than fine. Adding 
a parameter will only complicate provisioning and the gain of setting a 
custom value would be hard to quantify.

Probably a better approach would be to make sure the IOV_MAX is properly 
defined using something described here[1]. What do you think?

[1] 
https://stackoverflow.com/questions/27271801/c-the-permitted-maximum-of-the-iovcnt-argument-in-writev

Cheers,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 6/27/20 9:35 PM, Ovidiu Sas wrote:
> Fix implemented on trunk, 3.1 and 3.0.
> We should update the fix on rtpproxy to match rtpengine and move the
> OSIP_IOV_MAX define somewhere upper in the code tree to be visible by
> both rtpproxy and rtpengine modules.
> For trunk, maybe we should add a new param.
> 
> Should we backport this fix to 2.4?
> 
> Thanks,
> Ovidiu
> 
> On Fri, Jun 26, 2020 at 9:35 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>>
>> Hello Razvan,
>>
>> On ubuntu we have a failure for more then 1024 buffers. There is something defined in some experimental headers (as __IOV_MAX), but the IOV_MAX define is not visible in the rtpengine module.
>>
>> And yes, there is an extra buffer. I guess the length of that extra buffer was zero and that’s why it didn’t create issues. But as soon as I concatenated the buffer, the issue showed up and I had an extra trailing string at the end of the rtpengine command that was sent on the wire.
>> After reducing  the number of buffers by one, all was good on both scenarios: sending with and without concatenated buffers.
>> I will prepare a fix for it and push it.
>>
>> -ovidiu
>>
>> On Fri, Jun 26, 2020 at 03:55 Răzvan Crainea <razvan at opensips.org> wrote:
>>>
>>> Hi, Ovidiu!
>>>
>>> So you're saying that the IOV_MAX is not explicitly defined, but it does
>>> fail after 1024 buffers, correct? If so, perhaps we should limit the
>>> number of buffers to 1024, if not already defined.
>>> I did notice the extra vcnt as well, but I though that was related to
>>> the fact that it allocates one extra iovec (at the headr) for the
>>> cookie, and sometime uses it, sometime doesn't. Nevertheless, it is
>>> consistent on both cases, UNIX & UDP, both have that vcnt + 1. Now I
>>> haven't checked whether this is correct or not, could you please confirm?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 6/26/20 2:29 AM, Ovidiu Sas wrote:
>>>> It looks like the hidden IOV_MAX is set to 1024 in debian.
>>>> I tested a patch and all looks good.
>>>> It seems that there is an error in the code: writev has the wrong
>>>> number of iovcnt (should be one less).
>>>> I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).
>>>>
>>>> -ovidiu
>>>>
>>>> On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>
>>>>> We will need to add a param to control the max number of buffers.
>>>>>
>>>>> -ovidiu
>>>>>
>>>>> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>
>>>>>> It seems that when we have more than roughly 1000 buffers, the send fails.
>>>>>>
>>>>>> -ovidiu
>>>>>>
>>>>>> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>>
>>>>>>> Hello Razvan,
>>>>>>>
>>>>>>> The system is a debian buster one.
>>>>>>> I patched the code:
>>>>>>> #ifdef IOV_MAX
>>>>>>>       LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
>>>>>>> #else
>>>>>>>       LM_NOTICE("no IOV_MAX\n");
>>>>>>> #endif
>>>>>>>
>>>>>>> and I get:
>>>>>>> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
>>>>>>> in the logs.
>>>>>>>
>>>>>>> Then I patched the code again to check how many buffers are being used:
>>>>>>> The max so far was 73:
>>>>>>> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
>>>>>>> got me:
>>>>>>> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
>>>>>>>
>>>>>>> I will continue to monitor the system to see if there is a correlation
>>>>>>> between the error and the number of buffers.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ovidiu
>>>>>>>
>>>>>>> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
>>>>>>>>
>>>>>>>> Hi, Ovidiu!
>>>>>>>>
>>>>>>>> I doubt this is a problem of OpenSIPS version, but rather of the OS you
>>>>>>>> are running on. I suspect that error comes from the fact that the bson
>>>>>>>> resulted has more than IOV_MAX elements, which if I recall correctly it
>>>>>>>> was 15 on some OSes.
>>>>>>>> We had a similar problem in rtpproy[1], where we had merged the buffers
>>>>>>>> in a single one just to pass over this limitation. Could you check if
>>>>>>>> you are facing a similar issue?
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
>>>>>>>>
>>>>>>>> Răzvan Crainea
>>>>>>>> OpenSIPS Core Developer
>>>>>>>> http://www.opensips-solutions.com
>>>>>>>>
>>>>>>>> On 6/24/20 7:32 AM, Ovidiu Sas wrote:
>>>>>>>>> This is happening also on the latest 3.0.
>>>>>>>>> The weird thing is that opensips doesn't send anything to rtpengine.
>>>>>>>>> The first opensips/rtpengine exchange on the initial INVITE works ok,
>>>>>>>>> but the opensips/rtpengine exchange on the 200ok fails (no command is
>>>>>>>>> sent by opensips - confirmed by running ngrep on the loopback
>>>>>>>>> interface).
>>>>>>>>> On the next call, the initial offer works fine, but the answer fails
>>>>>>>>> due to no command issued by opensips.
>>>>>>>>>
>>>>>>>>> version: opensips 3.0.2 (x86_64/linux)
>>>>>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>>>>>>>>> Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
>>>>>>>>> main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
>>>>>>>>>
>>>>>>>>> -ovidiu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello all,
>>>>>>>>>>
>>>>>>>>>> I'm running opensips 3.1.0-beta (latest version) and experiencing
>>>>>>>>>> connectivity issues to the rtpengine daemon running on the same host:
>>>>>>>>>> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
>>>>>>>>>> (22:Invalid argument)
>>>>>>>>>> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
>>>>>>>>>> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
>>>>>>>>>> respond, disable it
>>>>>>>>>> ERROR:rtpengine:rtpe_function_call: no available proxies
>>>>>>>>>>
>>>>>>>>>> After an opensips restart, everything comes to normal.
>>>>>>>>>> I was running previously opensips 3.1.0-dev and everything was working fine.
>>>>>>>>>>
>>>>>>>>>> The issue starts showing up after a few days with very little traffic.
>>>>>>>>>> Is there anyone experiencing this issue?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Ovidiu
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>>> http://www.voipembedded.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> VoIP Embedded, Inc.
>>>>>>> http://www.voipembedded.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> VoIP Embedded, Inc.
>>>>>> http://www.voipembedded.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> VoIP Embedded, Inc.
>>>>> http://www.voipembedded.com
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
> 
> 
> 


From volga629 at networklab.ca  Mon Jun 29 15:14:29 2020
From: volga629 at networklab.ca (Slava Bendersky)
Date: Mon, 29 Jun 2020 11:14:29 -0400 (EDT)
Subject: [OpenSIPS-Users] dialog cluster
Message-ID: <1236127335.9909.1593443669329.JavaMail.zimbra@skillsearch.ca>

Hello Everyone, 
With PgSQL dialog module in cluster latest master 3.1-dev active/active setup tries insert duplicate data from each node. 
This setup contain 3 vips for each node on LAN and WAN sides. 

/usr/sbin/opensips[1727986]: ERROR:db_postgres:db_postgres_submit_query: 0x7f4eb5e95e28 PQsendQuery Error: ERROR: duplicate key value violates unique constraint "dialog_pkey"#012DETAIL: Key (dlg_id)=(7546448396242) already exists.#012 Query: 

Might be some miss configuration, but can find what the issue 

#### Dialog 
loadmodule "dialog.so" 
#modparam("dialog", "db_url", "postgres:///opensips") 
modparam("dialog", "db_mode", 2) 
modparam("dialog","profiles_with_value","outbound; inbound") 
modparam("dialog", "dlg_match_mode", 1) 
modparam("dialog", "default_timeout", 3600) 
modparam("dialog", "options_ping_interval", 900) 
modparam("dialog", "profiles_with_value", "caller ; domain") 
modparam("dialog", "dialog_replication_cluster", 1) 


if(!has_totag() && is_method("INVITE") && !has_body("application/csta+xml")) { 

create_dialog(); 
topology_hiding(); 

### Set profile ### 
### Set profile ### 
set_dlg_profile("caller",$fU@$fd); 
set_dlg_profile("domain",$fd); 

get_profile_size("caller",$fU@$fd,$var(ccaller)); 
get_profile_size("caller",$fd,$var(cdomain)); 
xlog("Number of calls from user $fU@$fd is $var(ccaller)"); 
xlog("Number of calls from domain $fd is $var(cdomain)"); 


xlog("Got request on ip addr [$socket_in(ip)] and call dir $avp(DLG_dir)\n"); 
# Wan route 
$var(ip_lst) = $shv(vip_wan_lst); 
route(SET_SOURCE_SOCKET); 
if($avp(DLG_dir)=="topbx") { 
switch($(avp(req_ip){s.select,3,.})) { 
case "38": 
set_dlg_sharing_tag("vip1"); 
xlog("[$rm] Set dialog tag vip1 ~> $(avp(req_ip){s.select,3,.})\n"); 
break; 
case "39": 
set_dlg_sharing_tag("vip2"); 
xlog("[$rm] Set dialog tag vip2 ~> $(avp(req_ip){s.select,3,.})\n"); 
break; 
case "40": 
set_dlg_sharing_tag("vip3"); 
xlog("[$rm] Set dialog tag vip3 ~> $(avp(req_ip){s.select,3,.})\n"); 
break; 
default: 
xlog("[$rm] Unknown last octet ~> $(avp(req_ip){s.select,3,.})\n"); 
} 
} 
} 

Any help thank you, volga629 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200629/52b6a358/attachment-0001.html>

From osas at voipembedded.com  Mon Jun 29 18:43:52 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 29 Jun 2020 14:43:52 -0400
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <3254b1ff-81a2-4b69-7366-717fa21a92fc@opensips.org>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
 <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
 <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>
 <ba59f732-2576-d1c9-09b6-2b5c9e16d1bd@opensips.org>
 <CAND0LksGYHaT0-Pu2KTQdJOpO7EPeAK0-nwLSdJy6J7h1do+hA@mail.gmail.com>
 <CAND0Lkv2LCFYey0JqeXWKRt_qPdjaJmJToGvMgo89bsyDUeBeQ@mail.gmail.com>
 <3254b1ff-81a2-4b69-7366-717fa21a92fc@opensips.org>
Message-ID: <CAND0Lkts0o6yYGt8OjOyyoE24ED+7CLx3s1PmpdVCjuvxK6sXg@mail.gmail.com>

Hi Razvan,

I have updated the rtpproxy module and everything is backported down to 2.4.

Detecting IOV_MAX would be kind of an overkill ...
The error logs were improved and the error is now searchable in the
mailing list. If everyone stumble across it, it should be easy to
troubleshoot.
It seems that IOV_MAX will be properly defined in the future (it is
defined in some experimental headers) and the detection of it will
become obsolete.
We could move the definition of OSIP_IOV_MAX into a common header file
for both rtpengine and rtpproxy module.

I'm still puzzled as to why this was not reported before for the
rtpengine module. It is quite easy to reproduce with very low traffic.

Thanks,
Ovidiu

On Mon, Jun 29, 2020 at 7:20 AM Răzvan Crainea <razvan at opensips.org> wrote:
>
> Hi, Ovidiu!
>
> I agree we should match the two modules to use a common logic.
> I believe we should backport this in 2.4 as well, since it doesn't work
> for all scenarios, therefore it is considered a bug.
>
> I somehow doubt this should be a module's param, because it is only
> needed in certain circumstances, where IOV_MAX is not "visible" in the
> code. IMO, a decent, commonly accepted limit should be enough - so I
> believe the way you've done it for 3.0 and 3.1 is more than fine. Adding
> a parameter will only complicate provisioning and the gain of setting a
> custom value would be hard to quantify.
>
> Probably a better approach would be to make sure the IOV_MAX is properly
> defined using something described here[1]. What do you think?
>
> [1]
> https://stackoverflow.com/questions/27271801/c-the-permitted-maximum-of-the-iovcnt-argument-in-writev
>
> Cheers,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 6/27/20 9:35 PM, Ovidiu Sas wrote:
> > Fix implemented on trunk, 3.1 and 3.0.
> > We should update the fix on rtpproxy to match rtpengine and move the
> > OSIP_IOV_MAX define somewhere upper in the code tree to be visible by
> > both rtpproxy and rtpengine modules.
> > For trunk, maybe we should add a new param.
> >
> > Should we backport this fix to 2.4?
> >
> > Thanks,
> > Ovidiu
> >
> > On Fri, Jun 26, 2020 at 9:35 AM Ovidiu Sas <osas at voipembedded.com> wrote:
> >>
> >> Hello Razvan,
> >>
> >> On ubuntu we have a failure for more then 1024 buffers. There is something defined in some experimental headers (as __IOV_MAX), but the IOV_MAX define is not visible in the rtpengine module.
> >>
> >> And yes, there is an extra buffer. I guess the length of that extra buffer was zero and that’s why it didn’t create issues. But as soon as I concatenated the buffer, the issue showed up and I had an extra trailing string at the end of the rtpengine command that was sent on the wire.
> >> After reducing  the number of buffers by one, all was good on both scenarios: sending with and without concatenated buffers.
> >> I will prepare a fix for it and push it.
> >>
> >> -ovidiu
> >>
> >> On Fri, Jun 26, 2020 at 03:55 Răzvan Crainea <razvan at opensips.org> wrote:
> >>>
> >>> Hi, Ovidiu!
> >>>
> >>> So you're saying that the IOV_MAX is not explicitly defined, but it does
> >>> fail after 1024 buffers, correct? If so, perhaps we should limit the
> >>> number of buffers to 1024, if not already defined.
> >>> I did notice the extra vcnt as well, but I though that was related to
> >>> the fact that it allocates one extra iovec (at the headr) for the
> >>> cookie, and sometime uses it, sometime doesn't. Nevertheless, it is
> >>> consistent on both cases, UNIX & UDP, both have that vcnt + 1. Now I
> >>> haven't checked whether this is correct or not, could you please confirm?
> >>>
> >>> Best regards,
> >>>
> >>> Răzvan Crainea
> >>> OpenSIPS Core Developer
> >>> http://www.opensips-solutions.com
> >>>
> >>> On 6/26/20 2:29 AM, Ovidiu Sas wrote:
> >>>> It looks like the hidden IOV_MAX is set to 1024 in debian.
> >>>> I tested a patch and all looks good.
> >>>> It seems that there is an error in the code: writev has the wrong
> >>>> number of iovcnt (should be one less).
> >>>> I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).
> >>>>
> >>>> -ovidiu
> >>>>
> >>>> On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> >>>>>
> >>>>> We will need to add a param to control the max number of buffers.
> >>>>>
> >>>>> -ovidiu
> >>>>>
> >>>>> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> >>>>>>
> >>>>>> It seems that when we have more than roughly 1000 buffers, the send fails.
> >>>>>>
> >>>>>> -ovidiu
> >>>>>>
> >>>>>> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
> >>>>>>>
> >>>>>>> Hello Razvan,
> >>>>>>>
> >>>>>>> The system is a debian buster one.
> >>>>>>> I patched the code:
> >>>>>>> #ifdef IOV_MAX
> >>>>>>>       LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> >>>>>>> #else
> >>>>>>>       LM_NOTICE("no IOV_MAX\n");
> >>>>>>> #endif
> >>>>>>>
> >>>>>>> and I get:
> >>>>>>> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> >>>>>>> in the logs.
> >>>>>>>
> >>>>>>> Then I patched the code again to check how many buffers are being used:
> >>>>>>> The max so far was 73:
> >>>>>>> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> >>>>>>> got me:
> >>>>>>> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
> >>>>>>>
> >>>>>>> I will continue to monitor the system to see if there is a correlation
> >>>>>>> between the error and the number of buffers.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Ovidiu
> >>>>>>>
> >>>>>>> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
> >>>>>>>>
> >>>>>>>> Hi, Ovidiu!
> >>>>>>>>
> >>>>>>>> I doubt this is a problem of OpenSIPS version, but rather of the OS you
> >>>>>>>> are running on. I suspect that error comes from the fact that the bson
> >>>>>>>> resulted has more than IOV_MAX elements, which if I recall correctly it
> >>>>>>>> was 15 on some OSes.
> >>>>>>>> We had a similar problem in rtpproy[1], where we had merged the buffers
> >>>>>>>> in a single one just to pass over this limitation. Could you check if
> >>>>>>>> you are facing a similar issue?
> >>>>>>>>
> >>>>>>>> [1]
> >>>>>>>> https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> >>>>>>>>
> >>>>>>>> Răzvan Crainea
> >>>>>>>> OpenSIPS Core Developer
> >>>>>>>> http://www.opensips-solutions.com
> >>>>>>>>
> >>>>>>>> On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> >>>>>>>>> This is happening also on the latest 3.0.
> >>>>>>>>> The weird thing is that opensips doesn't send anything to rtpengine.
> >>>>>>>>> The first opensips/rtpengine exchange on the initial INVITE works ok,
> >>>>>>>>> but the opensips/rtpengine exchange on the 200ok fails (no command is
> >>>>>>>>> sent by opensips - confirmed by running ngrep on the loopback
> >>>>>>>>> interface).
> >>>>>>>>> On the next call, the initial offer works fine, but the answer fails
> >>>>>>>>> due to no command issued by opensips.
> >>>>>>>>>
> >>>>>>>>> version: opensips 3.0.2 (x86_64/linux)
> >>>>>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> >>>>>>>>> Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
> >>>>>>>>> main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> >>>>>>>>>
> >>>>>>>>> -ovidiu
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hello all,
> >>>>>>>>>>
> >>>>>>>>>> I'm running opensips 3.1.0-beta (latest version) and experiencing
> >>>>>>>>>> connectivity issues to the rtpengine daemon running on the same host:
> >>>>>>>>>> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> >>>>>>>>>> (22:Invalid argument)
> >>>>>>>>>> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
> >>>>>>>>>> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
> >>>>>>>>>> respond, disable it
> >>>>>>>>>> ERROR:rtpengine:rtpe_function_call: no available proxies
> >>>>>>>>>>
> >>>>>>>>>> After an opensips restart, everything comes to normal.
> >>>>>>>>>> I was running previously opensips 3.1.0-dev and everything was working fine.
> >>>>>>>>>>
> >>>>>>>>>> The issue starts showing up after a few days with very little traffic.
> >>>>>>>>>> Is there anyone experiencing this issue?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Ovidiu
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> VoIP Embedded, Inc.
> >>>>>>>>>> http://www.voipembedded.com
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Users mailing list
> >>>>>>>> Users at lists.opensips.org
> >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> VoIP Embedded, Inc.
> >>>>>>> http://www.voipembedded.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> VoIP Embedded, Inc.
> >>>>>> http://www.voipembedded.com
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> VoIP Embedded, Inc.
> >>>>> http://www.voipembedded.com
> >>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at lists.opensips.org
> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >> --
> >> VoIP Embedded, Inc.
> >> http://www.voipembedded.com
> >
> >
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From adrian.fretwell at topgreen.co.uk  Tue Jun 30 05:56:54 2020
From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell)
Date: Tue, 30 Jun 2020 06:56:54 +0100
Subject: [OpenSIPS-Users] Resource List Server- Help with xcap table data
In-Reply-To: <a2cf8a0e-d4ed-cea2-da48-6d5cdeede007@topgreen.co.uk>
References: <a2cf8a0e-d4ed-cea2-da48-6d5cdeede007@topgreen.co.uk>
Message-ID: <642c6fc9-b3a3-6bae-17fc-929aea57828e@topgreen.co.uk>

Hello All,

An update,

I have got this working.  The clue was in the name space of the XML.  
The doc_type that I had thought was correct 4 (RESOURCE_LISTS) needed to 
be set to 8 (RLS_SERVICES).

A BLF List subscription from a Yealink phone always seems to generate an 
XCAP table database query looking for doc_type 8.  I clearly do not 
fully understand this process yet despite reading through two relevant 
RFCs 4662 and 4826.

It is still unclear to me what needs to be put in the doc_url or port 
columns of the xcap table, it is not mentioned in the documentation and 
there is no example in the tutorial on the OpenSIPS site.  If anyone has 
more information on this, please let me know.


Kind regards,

Adrian Fretwell

Sibthorpe
Nottinghamshire
UK.


On 26/06/2020 15:30, Adrian Fretwell wrote:
>
> Hello All,
>
> I think I am just missing a small amount of information here. I am 
> trying to get the resource list sever to work but I think my problem 
> is not knowing what data to put into the xcap table.
>
> I have a user 201 at mydomain.uk that wants to subscribe to 
> my-list at mydomain.uk So in the table I put:
>
> username: 201
>
> domain: mydomain.uk
>
> doc: (an xml document see below)
>
> doc_type: 4
>
> etag: a.1234
>
> source: 1
>
> doc_uri: sip:my-list at mydomain.uk
>
> port: 5060
>
> Can anyone tell me what I am doing wrong please.  when I call 
> rls_handle_subscribe() it return with $rc == 10.
>
> XML doc:
>
> <?xml version="1.0" encoding="UTF-8"?>
>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>       xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>     <service uri="sip:my-list at mydomain.uk">
>        <list name="my-list">
>           <rl:entry uri="202 at mydomain.uk"/>
>           <rl:entry uri="203 at mydomain.uk"/>
>            </list>
>            <packages>
>               <package>presence</package>
>            </packages>
>         </service>
>    </rls-services>
>
>
> -- 
> Kind regards,
>
> Adrian Fretwell
>
> Sibthorpe
> Nottinghamshire
> UK.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200630/b76bfdff/attachment.html>

From razvan at opensips.org  Tue Jun 30 07:07:28 2020
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 30 Jun 2020 10:07:28 +0300
Subject: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP
 proxy (22:Invalid argument)
In-Reply-To: <CAND0Lkts0o6yYGt8OjOyyoE24ED+7CLx3s1PmpdVCjuvxK6sXg@mail.gmail.com>
References: <CAND0Lks4BJ_HxWQwwXw-9-p6XV1GTqmbkvwig97RKD_TmmN2gA@mail.gmail.com>
 <CAND0LktESJSQgXyqvU-EaO=aZFpM04k7TPNenHZB_T7-CqEh-w@mail.gmail.com>
 <ba17ecbc-b77d-f8f2-ec4e-aefa71c1aa11@opensips.org>
 <CAND0LkttWKXsVMf4Tp_uiy-UCXYC=Udcw+uFHc47geTUOiqe5Q@mail.gmail.com>
 <CAND0LkthRtoPL+1jC4y3YCpsUxHGbTjnnHABsm-RF_92zUSL0g@mail.gmail.com>
 <CAND0LktJiK25hDX-9AfQPLrW_rmMrzmwXx34cFbBDa6BGGBP3w@mail.gmail.com>
 <CAND0Lkv__a_T7rkDvUGsCcAb930=dTk7A8qm7LnpL5rWg4tkDQ@mail.gmail.com>
 <ba59f732-2576-d1c9-09b6-2b5c9e16d1bd@opensips.org>
 <CAND0LksGYHaT0-Pu2KTQdJOpO7EPeAK0-nwLSdJy6J7h1do+hA@mail.gmail.com>
 <CAND0Lkv2LCFYey0JqeXWKRt_qPdjaJmJToGvMgo89bsyDUeBeQ@mail.gmail.com>
 <3254b1ff-81a2-4b69-7366-717fa21a92fc@opensips.org>
 <CAND0Lkts0o6yYGt8OjOyyoE24ED+7CLx3s1PmpdVCjuvxK6sXg@mail.gmail.com>
Message-ID: <89dcbad2-085d-9c13-d207-a6d74fcce23b@opensips.org>

Hi, Ovidiu!

I agree, the fact that no one reported it before is a bit interesting. 
On the other hand, not sure if >1000 buffers is expected, perhaps the 
flags you are using for rtpengine are increasing the number of buffers.

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 6/29/20 9:43 PM, Ovidiu Sas wrote:
> Hi Razvan,
> 
> I have updated the rtpproxy module and everything is backported down to 2.4.
> 
> Detecting IOV_MAX would be kind of an overkill ...
> The error logs were improved and the error is now searchable in the
> mailing list. If everyone stumble across it, it should be easy to
> troubleshoot.
> It seems that IOV_MAX will be properly defined in the future (it is
> defined in some experimental headers) and the detection of it will
> become obsolete.
> We could move the definition of OSIP_IOV_MAX into a common header file
> for both rtpengine and rtpproxy module.
> 
> I'm still puzzled as to why this was not reported before for the
> rtpengine module. It is quite easy to reproduce with very low traffic.
> 
> Thanks,
> Ovidiu
> 
> On Mon, Jun 29, 2020 at 7:20 AM Răzvan Crainea <razvan at opensips.org> wrote:
>>
>> Hi, Ovidiu!
>>
>> I agree we should match the two modules to use a common logic.
>> I believe we should backport this in 2.4 as well, since it doesn't work
>> for all scenarios, therefore it is considered a bug.
>>
>> I somehow doubt this should be a module's param, because it is only
>> needed in certain circumstances, where IOV_MAX is not "visible" in the
>> code. IMO, a decent, commonly accepted limit should be enough - so I
>> believe the way you've done it for 3.0 and 3.1 is more than fine. Adding
>> a parameter will only complicate provisioning and the gain of setting a
>> custom value would be hard to quantify.
>>
>> Probably a better approach would be to make sure the IOV_MAX is properly
>> defined using something described here[1]. What do you think?
>>
>> [1]
>> https://stackoverflow.com/questions/27271801/c-the-permitted-maximum-of-the-iovcnt-argument-in-writev
>>
>> Cheers,
>>
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 6/27/20 9:35 PM, Ovidiu Sas wrote:
>>> Fix implemented on trunk, 3.1 and 3.0.
>>> We should update the fix on rtpproxy to match rtpengine and move the
>>> OSIP_IOV_MAX define somewhere upper in the code tree to be visible by
>>> both rtpproxy and rtpengine modules.
>>> For trunk, maybe we should add a new param.
>>>
>>> Should we backport this fix to 2.4?
>>>
>>> Thanks,
>>> Ovidiu
>>>
>>> On Fri, Jun 26, 2020 at 9:35 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>
>>>> Hello Razvan,
>>>>
>>>> On ubuntu we have a failure for more then 1024 buffers. There is something defined in some experimental headers (as __IOV_MAX), but the IOV_MAX define is not visible in the rtpengine module.
>>>>
>>>> And yes, there is an extra buffer. I guess the length of that extra buffer was zero and that’s why it didn’t create issues. But as soon as I concatenated the buffer, the issue showed up and I had an extra trailing string at the end of the rtpengine command that was sent on the wire.
>>>> After reducing  the number of buffers by one, all was good on both scenarios: sending with and without concatenated buffers.
>>>> I will prepare a fix for it and push it.
>>>>
>>>> -ovidiu
>>>>
>>>> On Fri, Jun 26, 2020 at 03:55 Răzvan Crainea <razvan at opensips.org> wrote:
>>>>>
>>>>> Hi, Ovidiu!
>>>>>
>>>>> So you're saying that the IOV_MAX is not explicitly defined, but it does
>>>>> fail after 1024 buffers, correct? If so, perhaps we should limit the
>>>>> number of buffers to 1024, if not already defined.
>>>>> I did notice the extra vcnt as well, but I though that was related to
>>>>> the fact that it allocates one extra iovec (at the headr) for the
>>>>> cookie, and sometime uses it, sometime doesn't. Nevertheless, it is
>>>>> consistent on both cases, UNIX & UDP, both have that vcnt + 1. Now I
>>>>> haven't checked whether this is correct or not, could you please confirm?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Răzvan Crainea
>>>>> OpenSIPS Core Developer
>>>>> http://www.opensips-solutions.com
>>>>>
>>>>> On 6/26/20 2:29 AM, Ovidiu Sas wrote:
>>>>>> It looks like the hidden IOV_MAX is set to 1024 in debian.
>>>>>> I tested a patch and all looks good.
>>>>>> It seems that there is an error in the code: writev has the wrong
>>>>>> number of iovcnt (should be one less).
>>>>>> I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).
>>>>>>
>>>>>> -ovidiu
>>>>>>
>>>>>> On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>>
>>>>>>> We will need to add a param to control the max number of buffers.
>>>>>>>
>>>>>>> -ovidiu
>>>>>>>
>>>>>>> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>>>
>>>>>>>> It seems that when we have more than roughly 1000 buffers, the send fails.
>>>>>>>>
>>>>>>>> -ovidiu
>>>>>>>>
>>>>>>>> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>>>>
>>>>>>>>> Hello Razvan,
>>>>>>>>>
>>>>>>>>> The system is a debian buster one.
>>>>>>>>> I patched the code:
>>>>>>>>> #ifdef IOV_MAX
>>>>>>>>>        LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
>>>>>>>>> #else
>>>>>>>>>        LM_NOTICE("no IOV_MAX\n");
>>>>>>>>> #endif
>>>>>>>>>
>>>>>>>>> and I get:
>>>>>>>>> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
>>>>>>>>> in the logs.
>>>>>>>>>
>>>>>>>>> Then I patched the code again to check how many buffers are being used:
>>>>>>>>> The max so far was 73:
>>>>>>>>> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
>>>>>>>>> got me:
>>>>>>>>> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
>>>>>>>>>
>>>>>>>>> I will continue to monitor the system to see if there is a correlation
>>>>>>>>> between the error and the number of buffers.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Ovidiu
>>>>>>>>>
>>>>>>>>> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea <razvan at opensips.org> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi, Ovidiu!
>>>>>>>>>>
>>>>>>>>>> I doubt this is a problem of OpenSIPS version, but rather of the OS you
>>>>>>>>>> are running on. I suspect that error comes from the fact that the bson
>>>>>>>>>> resulted has more than IOV_MAX elements, which if I recall correctly it
>>>>>>>>>> was 15 on some OSes.
>>>>>>>>>> We had a similar problem in rtpproy[1], where we had merged the buffers
>>>>>>>>>> in a single one just to pass over this limitation. Could you check if
>>>>>>>>>> you are facing a similar issue?
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
>>>>>>>>>>
>>>>>>>>>> Răzvan Crainea
>>>>>>>>>> OpenSIPS Core Developer
>>>>>>>>>> http://www.opensips-solutions.com
>>>>>>>>>>
>>>>>>>>>> On 6/24/20 7:32 AM, Ovidiu Sas wrote:
>>>>>>>>>>> This is happening also on the latest 3.0.
>>>>>>>>>>> The weird thing is that opensips doesn't send anything to rtpengine.
>>>>>>>>>>> The first opensips/rtpengine exchange on the initial INVITE works ok,
>>>>>>>>>>> but the opensips/rtpengine exchange on the 200ok fails (no command is
>>>>>>>>>>> sent by opensips - confirmed by running ngrep on the loopback
>>>>>>>>>>> interface).
>>>>>>>>>>> On the next call, the initial offer works fine, but the answer fails
>>>>>>>>>>> due to no command issued by opensips.
>>>>>>>>>>>
>>>>>>>>>>> version: opensips 3.0.2 (x86_64/linux)
>>>>>>>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>>>>>>>>>>> Q_MALLOC, F_MALLOC, HP_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: 3a8f6f137
>>>>>>>>>>> main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
>>>>>>>>>>>
>>>>>>>>>>> -ovidiu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm running opensips 3.1.0-beta (latest version) and experiencing
>>>>>>>>>>>> connectivity issues to the rtpengine daemon running on the same host:
>>>>>>>>>>>> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
>>>>>>>>>>>> (22:Invalid argument)
>>>>>>>>>>>> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
>>>>>>>>>>>> ERROR:rtpengine:send_rtpe_command: proxy <udp:127.0.0.1:2223> does not
>>>>>>>>>>>> respond, disable it
>>>>>>>>>>>> ERROR:rtpengine:rtpe_function_call: no available proxies
>>>>>>>>>>>>
>>>>>>>>>>>> After an opensips restart, everything comes to normal.
>>>>>>>>>>>> I was running previously opensips 3.1.0-dev and everything was working fine.
>>>>>>>>>>>>
>>>>>>>>>>>> The issue starts showing up after a few days with very little traffic.
>>>>>>>>>>>> Is there anyone experiencing this issue?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ovidiu
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>>>>> http://www.voipembedded.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Users mailing list
>>>>>>>>>> Users at lists.opensips.org
>>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>> http://www.voipembedded.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> VoIP Embedded, Inc.
>>>>>>>> http://www.voipembedded.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> VoIP Embedded, Inc.
>>>>>>> http://www.voipembedded.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>> --
>>>> VoIP Embedded, Inc.
>>>> http://www.voipembedded.com
>>>
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> 


From bogdan at opensips.org  Tue Jun 30 12:02:42 2020
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 30 Jun 2020 15:02:42 +0300
Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.4.8 and 3.0.3
Message-ID: <5e4ca211-dbef-ada8-b19b-ce4bc56bd69c@opensips.org>


We are happy to announce a new set of OpenSIPS minor versions, namely 
2.4.8 and 3.0.3.

These releases incorporate all the testing and fixes done in the last 5 
months, fixes addressing various bugs or issues all across the code (see 
changelogs below)

Both releases are ready for production use and even more stable/accurate 
than before. Since they contain the latest bug fixes, we strongly 
recommend you to upgrade your current instances.

Thank you all for your reports, fixes, pull requests and all other 
contributions to this project!

The full ChangeLogs for the newly released versions are:
      https://opensips.org/pub/opensips/2.4.8/ChangeLog
      https://opensips.org/pub/opensips/3.0.3/ChangeLog

Get the latest versions from: http://opensips.org/pub/opensips/

Enjoy,

-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com



From wsimon at stratusvideo.com  Tue Jun 30 15:55:03 2020
From: wsimon at stratusvideo.com (William Simon)
Date: Tue, 30 Jun 2020 15:55:03 +0000
Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.4.8 and
 3.0.3
In-Reply-To: <5e4ca211-dbef-ada8-b19b-ce4bc56bd69c@opensips.org>
References: <5e4ca211-dbef-ada8-b19b-ce4bc56bd69c@opensips.org>
Message-ID: <51D0F438-1C61-4B0A-BCBD-56D31343C957@stratusvideo.com>

When will these releases reach the apt repository?


On 6/30/20, 8:04 AM, "Users on behalf of Bogdan-Andrei Iancu" <users-bounces at lists.opensips.org on behalf of bogdan at opensips.org> wrote:


    We are happy to announce a new set of OpenSIPS minor versions, namely
    2.4.8 and 3.0.3.

    These releases incorporate all the testing and fixes done in the last 5
    months, fixes addressing various bugs or issues all across the code (see
    changelogs below)

    Both releases are ready for production use and even more stable/accurate
    than before. Since they contain the latest bug fixes, we strongly
    recommend you to upgrade your current instances.

    Thank you all for your reports, fixes, pull requests and all other
    contributions to this project!

    The full ChangeLogs for the newly released versions are:
          https://opensips.org/pub/opensips/2.4.8/ChangeLog
          https://opensips.org/pub/opensips/3.0.3/ChangeLog

    Get the latest versions from: http://opensips.org/pub/opensips/

    Enjoy,

    --
    Bogdan-Andrei Iancu

    OpenSIPS Founder and Developer
       https://www.opensips-solutions.com


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



“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.”

From nick.altmann at voip.ninja  Tue Jun 30 19:13:05 2020
From: nick.altmann at voip.ninja (Nick Altmann)
Date: Tue, 30 Jun 2020 22:13:05 +0300
Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.4.8 and
	3.0.3
In-Reply-To: <51D0F438-1C61-4B0A-BCBD-56D31343C957@stratusvideo.com>
References: <5e4ca211-dbef-ada8-b19b-ce4bc56bd69c@opensips.org>
 <51D0F438-1C61-4B0A-BCBD-56D31343C957@stratusvideo.com>
Message-ID: <CAN=_5dviXBmwKinC4HeRJEqdpdc6Xp7C4-MSCQoLqN4cRue7ig@mail.gmail.com>

Depends on what distributive do you want. They're building at this moment
and appears there as soon as building process completed.

вт, 30 июн. 2020 г. в 18:56, William Simon <wsimon at stratusvideo.com>:

> When will these releases reach the apt repository?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200630/df65c22e/attachment.html>

From wsimon at stratusvideo.com  Tue Jun 30 19:27:18 2020
From: wsimon at stratusvideo.com (William Simon)
Date: Tue, 30 Jun 2020 19:27:18 +0000
Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.4.8 and
 3.0.3
In-Reply-To: <CAN=_5dviXBmwKinC4HeRJEqdpdc6Xp7C4-MSCQoLqN4cRue7ig@mail.gmail.com>
References: <5e4ca211-dbef-ada8-b19b-ce4bc56bd69c@opensips.org>
 <51D0F438-1C61-4B0A-BCBD-56D31343C957@stratusvideo.com>
 <CAN=_5dviXBmwKinC4HeRJEqdpdc6Xp7C4-MSCQoLqN4cRue7ig@mail.gmail.com>
Message-ID: <1AFBBDF5-6DCF-4EF4-984E-2348FBEEE1B6@stratusvideo.com>

OK, thank you, I will wait a short while longer.


From: Users <users-bounces at lists.opensips.org> on behalf of Nick Altmann <nick.altmann at voip.ninja>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Tuesday, June 30, 2020 at 3:15 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.4.8 and 3.0.3

Depends on what distributive do you want. They're building at this moment and appears there as soon as building process completed.

вт, 30 июн. 2020 г. в 18:56, William Simon <wsimon at stratusvideo.com<mailto:wsimon at stratusvideo.com>>:
When will these releases reach the apt repository?


“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200630/b4cb2d3c/attachment.html>