Re: [OpenSIPS-Users] opensipsctl ping sip:1234 at 1.2.3.4 ALWAYS returns “200 OK”

[Louis Rochon]

Bogdan-Andrei,



Thanks for your help. Now I can modify to make it fit my specific requirements.



Regards,



Louis

From: Bogdan-Andrei Iancu 
Sent: August 7, 2019 6:10 AM
To: OpenSIPS users mailling list ; Louis Rochon 

Subject: Re: [OpenSIPS-Users] opensipsctl ping sip:1234 at 1.2.3.4 ALWAYS 
returns “200 OK”


WARNING: External Email: Exercise Caution

Hi Louis,

The `opensipsctl ping` is actually triggering the `t_uac_dlg` MI command. The 
200 OK you see is actually from the MI level, saying that the MI cmd was 
successfully ran. It is not from the SIP level

Now, opensipsctl may not be the smartest tool, so it display only the ret code 
from MI level. IF you want to see the full MI response (with the SIP payload 
also), remove the "head" filter here 
https://github.com/OpenSIPS/opensips/blob/2.4/scripts/opensipsctl#L1895

Regards,



Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  
https://www.opensips-solutions.com

OpenSIPS Summit 2019

  
https://www.opensips.org/events/Summit-2019Amsterdam/
On 08/06/2019 11:35 PM, Louis Rochon wrote:
Just to add: I have completely reinstalled the OS and OpenSIPs 2.4.6.

Same problem….

Anybody?

Louis

From: Users 
 On 
Behalf Of Louis Rochon
Sent: August 5, 2019 9:08 AM
To: OpenSIPS users mailling list 

Subject: [OpenSIPS-Users] opensipsctl ping sip:1234 at 1.2.3.4 ALWAYS returns 
“200 OK”


WARNING: External Email: Exercise Caution


opensipsctl ping sip:1234 at 1.2.3.4 ALWAYS returns “200 OK”.
I could point it to a dead IP and it still returns 200 OK.
Opensips 2.4.6 installed on CentOS 7.
In 2.4.2 and in 1.8, this returned “200” (no ok) or whatever cause-code the UA 
returned, and “408” for a time out. Now it’s always “200 OK”
Wireshark indicates that it does send SIP Options and receives appropriate 
response (if any).
Of course, I have googled this ad nauseum
Help!

Thanks in advance,
Louis
NOTICE TO RECIPIENT: This email, including attachments, may contain information 
which is confidential, proprietary, attorney-client privileged and / or 
controlled under U.S. export laws and regulations and may be restricted from 
disclosure by applicable State and Federal law. Nothing in this email shall 
create any legal binding agreement between the parties unless expressly stated 
herein and provided by an authorized representative of Comtech 
Telecommunications Corp. or its subsidiaries. If you are not the intended 
recipient of this message, be advised that any dissemination, distribution, or 
use of the contents of this message is strictly prohibited. If you received 
this message in error, please notify us immediately by return email and 
permanently delete all copies of the original email and any attached 
documentation from any computer or other media.




___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

Re: [OpenSIPS-Users] UDP workers consume 100% CPU

[Vitalii Aleksandrov]

Hi,

I'm using libssl-1.1.1-1ubuntu2.1~18.04.4

Since I need SIP over TLS I can't just remove proto_tls. Will try to 
reproduce it again and collect more data.


On 07.08.19 13:18, Bogdan-Andrei Iancu wrote:

Hi Vitalii,

As the backtraces show, it is a deadlock in TLS - if you remove the 
proto_tls, you will not experience this issue anymore. The root 
problem is not in OpenSIPS itself but in the libssl/libcrypto - what 
versions are you using for these libs ?


Regards,

Bogdan-Andrei Iancu

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

On 08/05/2019 09:13 PM, Vitalii Aleksandrov wrote:

Hi,

I have a test opensips 2.4.6 (last week's checkout from 2.4 branch) 
and after short load testing it started to consume all CPU resources.


Here is what opensips floods to syslog:
Aug  3 13:25:01 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231430 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231530 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231630 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231730 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231830 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231930 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176232030 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:timer_ticker: timer 
task  already scheduled for 114023090 ms (now 176232030 
ms), it may overlap..


Where 4774 is: "Process::  ID=7 PID=4774 Type=timer"

Here is the TOP output for time consuming processes:
  PID USER PR  NI    VIRT    RES  SHR    S  %CPU %MEM 
TIME+ COMMAND
 4801 opensips  20   0  721040  28496  24240 R  52.9  0.7 1817:08 
opensips
 4802 opensips  20   0  721040  27724  23588 R  47.1  0.7 1813:06 
opensips
 4806 opensips  20   0  721040  27640  23532 R  47.1  0.7 1814:41 
opensips
 4833 opensips  20   0  721040  28848  24812 R  47.1  0.7 1815:16 
opensips
 4803 opensips  20   0  721044  27928  23732 R  41.2  0.7 1817:09 
opensips
 4804 opensips  20   0  721040  28188  23996 R  41.2  0.7 1816:05 
opensips
 4799 opensips  20   0  721040  28272  24172 R  35.3  0.7 1813:29 
opensips
 4800 opensips  20   0  721040  28340  24204 R  29.4  0.7 1816:52 
opensips
 4805 opensips  20   0  723256  29620  25300 R  29.4  0.8 1819:28 
opensips


And here is the "opensipsctl ps" for them:
Process::  ID=32 PID=4799 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=33 PID=4800 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=34 PID=4801 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=35 PID=4802 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=36 PID=4803 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=37 PID=4804 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=38 PID=4805 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=39 PID=4806 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=66 PID=4833 Type=TCP receiver

"strace" output for those burning processes just floods with:
11:07:04.042794 sched_yield()   = 0
11:07:04.042869 sched_yield()   = 0
11:07:04.042943 sched_yield()   = 0
11:07:04.043016 sched_yield()   = 0
11:07:04.043090 sched_yield()   = 0
11:07:04.043164 sched_yield()   = 0

Unfortunately this opensips is striped and gdb output is limited.
GDB bt of TCP receiver:
(gdb) bt
#0  0x7f939211fe57 in sched_yield () at 
../sysdeps/unix/syscall-template.S:78
#1  0x7f936fffc14d in ?? () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/proto_tls.so
#2  0x7f93791698d5 in send_pr_buffer () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so
#3  0x7f93791626b8 in relay_reply () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so
#4  0x7f937919fe2a in timer_routine () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so

#5  0x55e00034a58a in handle_timer_job ()
#6  0x55e00041ae2a in tcp_worker_proc_loop ()
#7  0x55e000427218 in tcp_start_processes ()
#8  0x55e0002e6837 in main ()

GDB bt of UDP receiver:
#0  0x7f939211fe57 in sched_yield () at 
../sysdeps/unix/syscall-template.S:78
#1  0x7f936fffc14d in ?? () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/proto_tls.so
#2  0x7f93791698d5 in send_pr_buffer () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so
#3  0x7f93791626b8 in relay_reply () from 

Re: [OpenSIPS-Users] CacheDB_Redis authentication

[Yury Kirsanov]

Hi Bogdan,
Thanks, I've just checked it and can confirm that using empty username
works!

modparam("cachedb_redis", "cachedb_url","redis:prod://:Password@10.x.x.x
:6379/")

Probably it would be good to update REDIS module article with this
information!

Thanks again and best regards,
Yury.

ср, 7 авг. 2019 г. в 20:43, Bogdan-Andrei Iancu :

> Have you checked this?
>
>
> https://stackoverflow.com/questions/44344628/how-to-create-a-redis-cloud-connection-url-with-an-auth-password
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS Summit 2019
>   https://www.opensips.org/events/Summit-2019Amsterdam/
>
> On 08/07/2019 01:38 PM, Yury Kirsanov wrote:
>
> Hi,
> Tried like this:
>
> modparam("cachedb_redis",
> "cachedb_url","redis:prod://10.x.x.x:6379/?password=Password")
>
> And like this:
>
> modparam("cachedb_redis", "cachedb_url",
> "redis:prod://Password@10.x.x.x:6379/"
> )
>
> And tried some other ways putting password in different places but in that
> cases OpenSIPS won't even start. In two examples above it starts but then
> I'm getting following error:
>
> Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: Redis operation failure -
> 0x1b19410 NOAUTH Authentication required.
> Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: giving up on query
>
> Thanks for your help,
> Yury.
>
> On Wed, 7 Aug. 2019, 20:33 Bogdan-Andrei Iancu, 
> wrote:
>
>> Hi,
>>
>> How exactly have you tried to build the URL ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>> OpenSIPS Summit 2019
>>   https://www.opensips.org/events/Summit-2019Amsterdam/
>>
>> On 07/31/2019 12:35 PM, Yury Kirsanov wrote:
>>
>> Hi,
>> Could you please let me know correct syntax of modparam for cachedb_redis
>> for password authentication? Or is it not supported at all? I've tried
>> different variants but can't get it to work, always getting an error:
>>
>> Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: Redis operation failure -
>> 0x1b19410 NOAUTH Authentication required.
>> Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: giving up on query
>>
>> Thanks!
>>
>> Regards,
>> Yury.
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Presence privacy rules question

[Bogdan-Andrei Iancu]

Hi Arsen,

In order to access presence information (of another user), the 
watcher/receiver needs to subscribe first. So what you need to do, is to 
deny subscription across different SIP domains. You can easily do this 
in script checking the RURI domain against FROM URI domain, for 
SUBSCRIBE requests.


Regards,

Bogdan-Andrei Iancu

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

On 07/27/2019 03:57 PM, Arsen wrote:

Hi guys,

I have a scenario where SIP users are grouped logically within a 
single domain.


I am looking for a way how to share presence status only within those 
particular logical groups of users. So that users from group 
Customer_A can see presence status only from this group and can't see 
status of users from Customer_B group.


As I know in basic presence config anybody can see status of anybody 
and enabling presence rules requires XCAP integation, but I am 
confused how to restrict presence by groups.


maybe someone have ideas and can point me in right direction, please 
advise :)


Best regards,
Arsen Semionov



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


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

Re: [OpenSIPS-Users] CacheDB_Redis authentication

[Bogdan-Andrei Iancu]

Have you checked this?

https://stackoverflow.com/questions/44344628/how-to-create-a-redis-cloud-connection-url-with-an-auth-password

Regards,

Bogdan-Andrei Iancu

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

On 08/07/2019 01:38 PM, Yury Kirsanov wrote:

Hi,
Tried like this:

modparam("cachedb_redis", 
"cachedb_url","redis:prod://10.x.x.x:6379/?password=Password")


And like this:

modparam("cachedb_redis", 
"cachedb_url","redis:prod://Password@10.x.x.x:6379/")


And tried some other ways putting password in different places but in 
that cases OpenSIPS won't even start. In two examples above it starts 
but then I'm getting following error:


Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: Redis operation failure 
- 0x1b19410 NOAUTH Authentication required.

Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: giving up on query

Thanks for your help,
Yury.

On Wed, 7 Aug. 2019, 20:33 Bogdan-Andrei Iancu, > wrote:


Hi,

How exactly have you tried to build the URL ?

Regards,

Bogdan-Andrei Iancu

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

On 07/31/2019 12:35 PM, Yury Kirsanov wrote:

Hi,
Could you please let me know correct syntax of modparam for
cachedb_redis for password authentication? Or is it not supported
at all? I've tried different variants but can't get it to work,
always getting an error:

Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: Redis operation
failure - 0x1b19410 NOAUTH Authentication required.
Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: giving up on query

Thanks!

Regards,
Yury.


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




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

Re: [OpenSIPS-Users] Loglevel priority prefix in /var/log/messages

[Bogdan-Andrei Iancu]

Hi Denys,

Check your syslog configuration and see to which log file the LOCAL0 
facility is diverted - maybe you are looking into the wrong file.


Regards,

Bogdan-Andrei Iancu

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

On 07/31/2019 11:57 AM, Denys Pozniak wrote:

Hello!

Please help me to configure loglevel prefix priority (like INFO, 
NOTICE, WARNING, ERROR) for /var/log/messages.
As you can see below OpenSIPS does not display it, but for example, 
Rtpengine does.


### Global Settings 
log_level=3
log_stderror=no
log_facility=LOG_LOCAL0
...

### Routing Logic 

route{
xlog("L_INFO","info_New message rm=$rm / si=$si / ru=$ru / 
ci=$ci \n");
xlog("L_NOTICE","notice_New message rm=$rm / si=$si / ru=$ru / 
ci=$ci \n");
xlog("L_WARN","warning_New message rm=$rm / si=$si / ru=$ru / 
ci=$ci \n");
xlog("L_ERR","error_New message rm=$rm / si=$si / ru=$ru / 
ci=$ci \n");

...

[root@localhost opensips]# tail -f /var/log/messages
Jul 27 15:28:31 localhost /usr/sbin/opensips[32644]: notice_New 
message rm=INVITE / si=192.168.56.1 / ru=sip:5@192.168.56.3 
 / 
ci=008BDC86-DDB1-E911-80AA-492E68E5C084@192.168.56.1 

Jul 27 15:28:31 localhost /usr/sbin/opensips[32644]: warning_New 
message rm=INVITE / si=192.168.56.1 / ru=sip:5@192.168.56.3 
 / 
ci=008BDC86-DDB1-E911-80AA-492E68E5C084@192.168.56.1 

Jul 27 15:28:31 localhost /usr/sbin/opensips[32644]: error_New message 
rm=INVITE / si=192.168.56.1 / ru=sip:5@192.168.56.3 
 / 
ci=008BDC86-DDB1-E911-80AA-492E68E5C084@192.168.56.1 

Jul 27 15:28:31 localhost rtpengine: [1564255711.862367] INFO: 
[008BDC86-DDB1-E911-80AA-492E68E5C084@192.168.56.1 
]: Received 
command 'offer' from 10.10.200.43:53649 
Jul 27 15:28:31 localhost rtpengine: [1564255711.862410] NOTICE: 
[008BDC86-DDB1-E911-80AA-492E68E5C084@192.168.56.1 
]: Creating 
new call
Jul 27 15:28:31 localhost rtpengine: [1564255711.862684] INFO: 
[008BDC86-DDB1-E911-80AA-492E68E5C084@192.168.56.1 
]: Replying 
to 'offer' from 10.10.200.43:53649  
(elapsed time 0.000304 sec)


[root@localhost opensips]# opensips -V
version: opensips 3.0.0 (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.
main.c compiled on 13:02:44 May 30 2019 with gcc 4.8.5

[root@localhost opensips]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)


--

BR,
Denys Pozniak




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


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

Re: [OpenSIPS-Users] CacheDB_Redis authentication

[Yury Kirsanov]

Hi,
Tried like this:

modparam("cachedb_redis",
"cachedb_url","redis:prod://10.x.x.x:6379/?password=Password")

And like this:

modparam("cachedb_redis", "cachedb_url","redis:prod://Password@10.x.x.x
:6379/")

And tried some other ways putting password in different places but in that
cases OpenSIPS won't even start. In two examples above it starts but then
I'm getting following error:

Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: Redis operation failure -
0x1b19410 NOAUTH Authentication required.
Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: giving up on query

Thanks for your help,
Yury.

On Wed, 7 Aug. 2019, 20:33 Bogdan-Andrei Iancu,  wrote:

> Hi,
>
> How exactly have you tried to build the URL ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS Summit 2019
>   https://www.opensips.org/events/Summit-2019Amsterdam/
>
> On 07/31/2019 12:35 PM, Yury Kirsanov wrote:
>
> Hi,
> Could you please let me know correct syntax of modparam for cachedb_redis
> for password authentication? Or is it not supported at all? I've tried
> different variants but can't get it to work, always getting an error:
>
> Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: Redis operation failure -
> 0x1b19410 NOAUTH Authentication required.
> Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: giving up on query
>
> Thanks!
>
> Regards,
> Yury.
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] mhomed=1 and force_send_socket()

[Bogdan-Andrei Iancu]

Vitalii,

I think this is what you are looking for 
https://github.com/OpenSIPS/opensips/issues/1671, right ?


Regards,

Bogdan-Andrei Iancu

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

On 07/31/2019 12:33 PM, Vitalii Aleksandrov wrote:
When user is registered everything is OK. The problem appears when I 
send a call to another proxy or carrier. With UDP transport opensips 
correctly detects an outgoing interface and forwards a call. With 
TCP/TLS transport opensips is not that smart. Found the place in code 
which detects an outgoing socket and it just takes the first interface 
for TCP with a comment that it's too complicated to detect it properly.
It means if you have a proxy with multiple LAN/WAN interfaces you 
can't just forward calls to different trunks and have to manually 
manage force_send_socket().
And unfortunately this trick with $fs doesn't work for BIN and I just 
can't have cluster neighbors in different segments of my network.


mhomed =1 will make sure that the outgoing interface towards user A 
is the interface on which user A has registered.

Hence you need to be very very careful with mhomed=1.
I use force_send_socket when I a have a mixed environment (e.g users 
that register, connection to provider without registration, etc).


these are my 2 drops of wisdom :-)

as for BIN, that I can't explain as I never used that type of interface.

.
Op di 30 jul. 2019 om 17:16 schreef Vitalii Aleksandrov 
mailto:vitalik.v...@gmail.com>>:


Hi,

Have a problem with a multihomed proxy which doesn't select outgoing
interface correctly. Found similar topics where people discussed
usage
of force_send_socket() when they want to force opensips to use some
interface.

As far as I understood "mhomed=1" is the option which forces
opensips to
select a proper outgoing interface in multihomed environment. This
options really works, but unfortunately only for UDP. When
opensips has
multiple TCP / TLS / BIN interfaces, opensips just takes the
first from
the list which is not always correct and fails to establish an
outgoing
connection.

Since I have a module that detects an outgoing interface I can
use this
info with $fs to force correct socket for SIP. Unfortunately this
trick
doesn't work for BIN and it's not possible to setup a multihomed
opensips with clustering neighbors in both internal and external
networks.

Is there any workaround for BIN?


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


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



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


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

Re: [OpenSIPS-Users] CacheDB_Redis authentication

[Bogdan-Andrei Iancu]

Hi,

How exactly have you tried to build the URL ?

Regards,

Bogdan-Andrei Iancu

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

On 07/31/2019 12:35 PM, Yury Kirsanov wrote:

Hi,
Could you please let me know correct syntax of modparam for 
cachedb_redis for password authentication? Or is it not supported at 
all? I've tried different variants but can't get it to work, always 
getting an error:


Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: Redis operation failure 
- 0x1b19410 NOAUTH Authentication required.

Jul 31 19:22:56 ERROR:cachedb_redis:redis_set: giving up on query

Thanks!

Regards,
Yury.


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


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

Re: [OpenSIPS-Users] UDP workers consume 100% CPU

[Bogdan-Andrei Iancu]

Hi Vitalii,

As the backtraces show, it is a deadlock in TLS - if you remove the 
proto_tls, you will not experience this issue anymore. The root problem 
is not in OpenSIPS itself but in the libssl/libcrypto - what versions 
are you using for these libs ?


Regards,

Bogdan-Andrei Iancu

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

On 08/05/2019 09:13 PM, Vitalii Aleksandrov wrote:

Hi,

I have a test opensips 2.4.6 (last week's checkout from 2.4 branch) 
and after short load testing it started to consume all CPU resources.


Here is what opensips floods to syslog:
Aug  3 13:25:01 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231430 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231530 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231630 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231730 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231830 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176231930 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:utimer_ticker: utimer 
task  already scheduled for 114023190 ms (now 176232030 
ms), it may overlap..
Aug  3 13:25:02 l /opensips[4774]: WARNING:core:timer_ticker: timer 
task  already scheduled for 114023090 ms (now 176232030 ms), 
it may overlap..


Where 4774 is: "Process::  ID=7 PID=4774 Type=timer"

Here is the TOP output for time consuming processes:
  PID USER PR  NIVIRTRES  SHRS  %CPU %MEM 
TIME+ COMMAND
 4801 opensips  20   0  721040  28496  24240 R  52.9  0.7 1817:08 
opensips
 4802 opensips  20   0  721040  27724  23588 R  47.1  0.7 1813:06 
opensips
 4806 opensips  20   0  721040  27640  23532 R  47.1  0.7 1814:41 
opensips
 4833 opensips  20   0  721040  28848  24812 R  47.1  0.7 1815:16 
opensips
 4803 opensips  20   0  721044  27928  23732 R  41.2  0.7 1817:09 
opensips
 4804 opensips  20   0  721040  28188  23996 R  41.2  0.7 1816:05 
opensips
 4799 opensips  20   0  721040  28272  24172 R  35.3  0.7 1813:29 
opensips
 4800 opensips  20   0  721040  28340  24204 R  29.4  0.7 1816:52 
opensips
 4805 opensips  20   0  723256  29620  25300 R  29.4  0.8 1819:28 
opensips


And here is the "opensipsctl ps" for them:
Process::  ID=32 PID=4799 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=33 PID=4800 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=34 PID=4801 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=35 PID=4802 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=36 PID=4803 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=37 PID=4804 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=38 PID=4805 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=39 PID=4806 Type=SIP receiver udp:127.0.0.1:5070
Process::  ID=66 PID=4833 Type=TCP receiver

"strace" output for those burning processes just floods with:
11:07:04.042794 sched_yield()   = 0
11:07:04.042869 sched_yield()   = 0
11:07:04.042943 sched_yield()   = 0
11:07:04.043016 sched_yield()   = 0
11:07:04.043090 sched_yield()   = 0
11:07:04.043164 sched_yield()   = 0

Unfortunately this opensips is striped and gdb output is limited.
GDB bt of TCP receiver:
(gdb) bt
#0  0x7f939211fe57 in sched_yield () at 
../sysdeps/unix/syscall-template.S:78
#1  0x7f936fffc14d in ?? () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/proto_tls.so
#2  0x7f93791698d5 in send_pr_buffer () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so
#3  0x7f93791626b8 in relay_reply () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so
#4  0x7f937919fe2a in timer_routine () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so

#5  0x55e00034a58a in handle_timer_job ()
#6  0x55e00041ae2a in tcp_worker_proc_loop ()
#7  0x55e000427218 in tcp_start_processes ()
#8  0x55e0002e6837 in main ()

GDB bt of UDP receiver:
#0  0x7f939211fe57 in sched_yield () at 
../sysdeps/unix/syscall-template.S:78
#1  0x7f936fffc14d in ?? () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/proto_tls.so
#2  0x7f93791698d5 in send_pr_buffer () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so
#3  0x7f93791626b8 in relay_reply () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so
#4  0x7f9379165015 in reply_received () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tm.so

#5  0x55e000322fed in forward_reply ()
#6  0x55e000309d1d in receive_msg 

Re: [OpenSIPS-Users] opensipsctl ping sip:1234 at 1.2.3.4 ALWAYS returns “200 OK”

[Bogdan-Andrei Iancu]

Hi Louis,

The `opensipsctl ping` is actually triggering the `t_uac_dlg` MI 
command. The 200 OK you see is actually from the MI level, saying that 
the MI cmd was successfully ran. It is not from the SIP level


Now, opensipsctl may not be the smartest tool, so it display only the 
ret code from MI level. IF you want to see the full MI response (with 
the SIP payload also), remove the "head" filter here 
https://github.com/OpenSIPS/opensips/blob/2.4/scripts/opensipsctl#L1895


Regards,

Bogdan-Andrei Iancu

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

On 08/06/2019 11:35 PM, Louis Rochon wrote:


Just to add: I have completely reinstalled the OS and OpenSIPs 2.4.6.

Same problem….

Anybody?

Louis

*From:*Users  *On Behalf Of *Louis 
Rochon

*Sent:* August 5, 2019 9:08 AM
*To:* OpenSIPS users mailling list 
*Subject:* [OpenSIPS-Users] opensipsctl ping sip:1234 at 1.2.3.4 
ALWAYS returns “200 OK”


*WARNING: External Email: Exercise Caution*

opensipsctl ping sip:1234 at 1.2.3.4 ALWAYS returns “200 OK”.

I could point it to a dead IP and it still returns 200 OK.

Opensips 2.4.6 installed on CentOS 7.

In 2.4.2 and in 1.8, this returned “200” (no ok) or whatever 
cause-code the UA returned, and “408” for a time out. Now it’s always 
“200 OK”


Wireshark indicates that it does send SIP Options and receives 
appropriate response (if any).


Of course, I have googled this ad nauseum

Help!

Thanks in advance,

Louis

NOTICE TO RECIPIENT: This email, including attachments, may contain 
information which is confidential, proprietary, attorney-client 
privileged and / or controlled under U.S. export laws and regulations 
and may be restricted from disclosure by applicable State and Federal 
law. Nothing in this email shall create any legal binding agreement 
between the parties unless expressly stated herein and provided by an 
authorized representative of Comtech Telecommunications Corp. or its 
subsidiaries. If you are not the intended recipient of this message, 
be advised that any dissemination, distribution, or use of the 
contents of this message is strictly prohibited. If you received this 
message in error, please notify us immediately by return email and 
permanently delete all copies of the original email and any attached 
documentation from any computer or other media.




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


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

Re: [OpenSIPS-Users] CANCEL & INVITE

[Bogdan-Andrei Iancu]

Some update here, to keep the list also informed.

I re-checked the code and I found some regression in CANCEL handling - 
this was added last year with commit 
4747da559f4df161441be8373488dee9fd16c282 when support for 
"Content-Disposition: no-cancel" was added.

https://github.com/OpenSIPS/opensips/commit/4747da559f4df161441be8373488dee9fd16c282

Also I just pushed a fix (on master) for this issue
https://github.com/OpenSIPS/opensips/commit/f1a6d0d8e46c4aff9f203f2eb7e85a2b1e40cf92

Richard, would you please test it also and confirm the fix, so I can do 
safe backport to 3.0 and 2.4 ?


Many thanks,

Bogdan-Andrei Iancu

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

On 06/21/2019 06:26 PM, Bogdan-Andrei Iancu wrote:
Ww - we have a record here :) - resuming a discussion over 8 years 
!


AFAIK, there was no intentional change (when comes to canceling 
branches with no reply) - do you have a pcap + logs to show such 
behavior ?


And in regards to the sequence of CANCEL (on timeout) + forking, I 
think this was fixed starting 1.7 - first the CANCEL is sent out and 
then the new potential branches.


Regards,
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 2019
   https://www.opensips.org/events/Summit-2019Amsterdam/
On 06/20/2019 01:06 AM, Richard Revels wrote:
I'm going to resurrect this as I've noticed that opensips 2.4.6 sends 
CANCEL for branches it never got a provisional response for.  Was 
this changed intentionally?


Also, it looks like the discussion I am responding on was about 
opensips 1.5 but if any testing is needed around fail-over scenarios 
I expect to be doing some of that over the next few days.  Just let 
me know what still needs to be looked at and I'll try to get it in.



BandwidthMaroon.png



Richard Revels•System Architect II

900 Main Campus Drive, Suite 100, Raleigh, NC 27606

m:919-578-3421 • o: 919-727-4614

e: rrev...@bandwidth.com 



On Tue, Apr 5, 2011 at 3:33 PM Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


Hi guys,

Actually it will be great to have that patch tested to know for
sure if
the problem is solved. I never got a 100% confirmation from
Andrew, but
maybe Piotr can test and confirm.

Thanks and regards,
Bogdan

On 04/05/2011 04:58 PM, Andrew Pogrebennyk wrote:
> Hi Piotr,
> This sounds familiar to the problem I experienced some time ago
- make
> sure to check comments here:
>

https://sourceforge.net/tracker/?func=detail=1086410=2940556_id=232389
>
> I haven't been able to replicate that setup to confirm that the
> attached patch works. You are welcome to try it though :) Note RFC
> states it clearly that if no response has been received from
the UAS
> at all, we should not attempt to send a CANCEL there.
>
> But it seems that in your case you received some provisional
response
> so the issue has to do with the order in which CANCEL is fired -
> exactly what the patch is intended to fix.
>
> On 05.04.2011 15:56, Piotr Sobolewski wrote:
>> I'm having problem with specific gateway to which OpenSIPS sends
>> INVITE and then another INVITE (CallForward on no Aswer).
>> The  problem is when after sending first INVITE to gateway
(without
>> getting final response), OpenSIPS hits failure route and then
sends
>> another INVITE (with different RURI) toward gateway before
CANCEL is
>> sent, so the gateway responds to second INVITE with "482 Request
>> merged" (and gateway does not attempt to make second connection).
>> Is there a way to send CANCEL before sending second INVITE ?
>


-- 
Bogdan-Andrei Iancu

OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"


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



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




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