From prathibhab.tvm at gmail.com  Wed May  1 13:19:48 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Wed, 1 May 2024 13:19:48 +0000
Subject: [OpenSIPS-Users] Send failed
Message-ID: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>

How to solve this error- 477  send failed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240501/43e25e3b/attachment.html>

From denys.pozniak at gmail.com  Thu May  2 08:41:37 2024
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Thu, 2 May 2024 10:41:37 +0200
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200 tls/ssl
	certs
Message-ID: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>

Hello!

There is a task to divide a single tls/ssl letsencrypt certificate for
white labels into specific ones.
I entered about ~250 certificates into db_text, but as it turned out, for
OpenSIPS this is a rather complex operation to load them and takes about 1
minute and a heavy CPU load is noticeable.

I would appreciate any advice on how to avoid this.

# wc -l dbtext/tls_mgm
253 dbtext/tls_mgm

# time opensips-cli -x mi tls_reload
"OK"
real 0m52.034s
user 0m1.419s
sys 0m0.433s

# time systemctl restart opensips
real    0m58.198s
user    0m0.024s
sys     0m0.055s

# opensips -V
version: opensips 3.4.4 (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: 036d02961

-- 

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

From prathibhab.tvm at gmail.com  Thu May  2 12:54:39 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Thu, 2 May 2024 18:24:39 +0530
Subject: [OpenSIPS-Users] Send failed
In-Reply-To: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>
References: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>
Message-ID: <CAJh_-cDCEt4GSTuXrwGH99oZXorcsQHhKdAyCj+3R74_70Wtqg@mail.gmail.com>

Can someone point me on how to resolve this issue?

On Wed, 1 May 2024 at 18:49, Prathibha B <prathibhab.tvm at gmail.com> wrote:

> How to solve this error- 477  send failed.
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240502/9412da78/attachment.html>

From Ben.Newlin at genesys.com  Thu May  2 14:21:07 2024
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Thu, 2 May 2024 14:21:07 +0000
Subject: [OpenSIPS-Users] Send failed
In-Reply-To: <CAJh_-cDCEt4GSTuXrwGH99oZXorcsQHhKdAyCj+3R74_70Wtqg@mail.gmail.com>
References: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>
 <CAJh_-cDCEt4GSTuXrwGH99oZXorcsQHhKdAyCj+3R74_70Wtqg@mail.gmail.com>
Message-ID: <BN0PR10MB52081E849D28E15C3451D7CE95182@BN0PR10MB5208.namprd10.prod.outlook.com>

There are many different reasons for this error. With just this one line description and no more context it isn’t possible to say why it is occurring.

The most common cause of 477 errors is issues with the TCP/TLS connection to the far end. Have you tried capturing a trace of the call attempt? Have you verified your TCP/TLS settings are correct and are aligned with what the far end expects? Have you verified the message is being sent to the correct remote target to begin with?

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Prathibha B <prathibhab.tvm at gmail.com>
Date: Thursday, May 2, 2024 at 8:56 AM
To: users at lists.opensips.org <Users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Send failed
 EXTERNAL EMAIL - Please use caution with links and attachments

________________________________
Can someone point me on how to resolve this issue?

On Wed, 1 May 2024 at 18:49, Prathibha B <prathibhab.tvm at gmail.com<mailto:prathibhab.tvm at gmail.com>> wrote:
How to solve this error- 477  send failed.


--
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240502/8ad6afbf/attachment.html>

From olle at zaark.com  Thu May  2 17:17:23 2024
From: olle at zaark.com (olle at zaark.com)
Date: Thu, 2 May 2024 19:17:23 +0200
Subject: [OpenSIPS-Users] Send failed
In-Reply-To: <BN0PR10MB52081E849D28E15C3451D7CE95182@BN0PR10MB5208.namprd10.prod.outlook.com>
References: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>
 <CAJh_-cDCEt4GSTuXrwGH99oZXorcsQHhKdAyCj+3R74_70Wtqg@mail.gmail.com>
 <BN0PR10MB52081E849D28E15C3451D7CE95182@BN0PR10MB5208.namprd10.prod.outlook.com>
Message-ID: <00be01da9cb4$99713330$cc539990$@zaark.com>

Hi, I might add that it's worth checking TCP keep alive from both client and
server.

 

Olle Frimanson

 

From: Users <users-bounces at lists.opensips.org> On Behalf Of Ben Newlin
Sent: den 2 maj 2024 16:21
To: OpenSIPS users mailling list <Users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Send failed

 

There are many different reasons for this error. With just this one line
description and no more context it isn't possible to say why it is
occurring.

 

The most common cause of 477 errors is issues with the TCP/TLS connection to
the far end. Have you tried capturing a trace of the call attempt? Have you
verified your TCP/TLS settings are correct and are aligned with what the far
end expects? Have you verified the message is being sent to the correct
remote target to begin with?

 

Ben Newlin

 

From: Users <users-bounces at lists.opensips.org
<mailto:users-bounces at lists.opensips.org> > on behalf of Prathibha B
<prathibhab.tvm at gmail.com <mailto:prathibhab.tvm at gmail.com> >
Date: Thursday, May 2, 2024 at 8:56 AM
To: users at lists.opensips.org <mailto:users at lists.opensips.org>
<Users at lists.opensips.org <mailto:Users at lists.opensips.org> >
Subject: Re: [OpenSIPS-Users] Send failed


 EXTERNAL EMAIL - Please use caution with links and attachments 

 

  _____  

Can someone point me on how to resolve this issue?

 

On Wed, 1 May 2024 at 18:49, Prathibha B <prathibhab.tvm at gmail.com
<mailto:prathibhab.tvm at gmail.com> > wrote:

How to solve this error- 477  send failed.




 

-- 

Regards,

B.Prathibha

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

From prathibhab.tvm at gmail.com  Fri May  3 00:15:41 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Fri, 3 May 2024 00:15:41 +0000
Subject: [OpenSIPS-Users] Send failed
In-Reply-To: <00be01da9cb4$99713330$cc539990$@zaark.com>
References: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>
 <CAJh_-cDCEt4GSTuXrwGH99oZXorcsQHhKdAyCj+3R74_70Wtqg@mail.gmail.com>
 <BN0PR10MB52081E849D28E15C3451D7CE95182@BN0PR10MB5208.namprd10.prod.outlook.com>
 <00be01da9cb4$99713330$cc539990$@zaark.com>
Message-ID: <TYZPR06MB75250AC2D72D98650A57FA55FC1F2@TYZPR06MB7525.apcprd06.prod.outlook.com>

How to check TCP keepalive from client and server?

Sent from Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of olle at zaark.com <olle at zaark.com>
Sent: Thursday, May 2, 2024 10:47:23 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Send failed


Hi, I might add that it’s worth checking TCP keep alive from both client and server.



Olle Frimanson



From: Users <users-bounces at lists.opensips.org> On Behalf Of Ben Newlin
Sent: den 2 maj 2024 16:21
To: OpenSIPS users mailling list <Users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Send failed



There are many different reasons for this error. With just this one line description and no more context it isn’t possible to say why it is occurring.



The most common cause of 477 errors is issues with the TCP/TLS connection to the far end. Have you tried capturing a trace of the call attempt? Have you verified your TCP/TLS settings are correct and are aligned with what the far end expects? Have you verified the message is being sent to the correct remote target to begin with?



Ben Newlin



From: Users <users-bounces at lists.opensips.org<mailto:users-bounces at lists.opensips.org>> on behalf of Prathibha B <prathibhab.tvm at gmail.com<mailto:prathibhab.tvm at gmail.com>>
Date: Thursday, May 2, 2024 at 8:56 AM
To: users at lists.opensips.org<mailto:users at lists.opensips.org> <Users at lists.opensips.org<mailto:Users at lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] Send failed

 EXTERNAL EMAIL - Please use caution with links and attachments



________________________________

Can someone point me on how to resolve this issue?



On Wed, 1 May 2024 at 18:49, Prathibha B <prathibhab.tvm at gmail.com<mailto:prathibhab.tvm at gmail.com>> wrote:

How to solve this error- 477  send failed.




--

Regards,

B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240503/a2eff70e/attachment.html>

From prathibhab.tvm at gmail.com  Fri May  3 00:31:52 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Fri, 3 May 2024 06:01:52 +0530
Subject: [OpenSIPS-Users] Send failed
In-Reply-To: <TYZPR06MB75250AC2D72D98650A57FA55FC1F2@TYZPR06MB7525.apcprd06.prod.outlook.com>
References: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>
 <CAJh_-cDCEt4GSTuXrwGH99oZXorcsQHhKdAyCj+3R74_70Wtqg@mail.gmail.com>
 <BN0PR10MB52081E849D28E15C3451D7CE95182@BN0PR10MB5208.namprd10.prod.outlook.com>
 <00be01da9cb4$99713330$cc539990$@zaark.com>
 <TYZPR06MB75250AC2D72D98650A57FA55FC1F2@TYZPR06MB7525.apcprd06.prod.outlook.com>
Message-ID: <CAJh_-cDsB8BwA1_qK6kXgmLaewXZ9sr+mF9FSusN8Bxj75XcbA@mail.gmail.com>

# TCP Connection settings
tcp_connect_timeout = 200
tcp_connection_lifetime = 3600
tcp_max_connections = 4096
tcp_keepalive = 0
tcp_keepcount = 5
tcp_keepidle = 60
tcp_keepinterval = 0

On Fri, 3 May 2024 at 05:45, Prathibha B <prathibhab.tvm at gmail.com> wrote:

> How to check TCP keepalive from client and server?
>
> Sent from Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* Users <users-bounces at lists.opensips.org> on behalf of
> olle at zaark.com <olle at zaark.com>
> *Sent:* Thursday, May 2, 2024 10:47:23 PM
> *To:* 'OpenSIPS users mailling list' <users at lists.opensips.org>
> *Subject:* Re: [OpenSIPS-Users] Send failed
>
>
> Hi, I might add that it’s worth checking TCP keep alive from both client
> and server.
>
>
>
> Olle Frimanson
>
>
>
> *From:* Users <users-bounces at lists.opensips.org> *On Behalf Of *Ben Newlin
> *Sent:* den 2 maj 2024 16:21
> *To:* OpenSIPS users mailling list <Users at lists.opensips.org>
> *Subject:* Re: [OpenSIPS-Users] Send failed
>
>
>
> There are many different reasons for this error. With just this one line
> description and no more context it isn’t possible to say why it is
> occurring.
>
>
>
> The most common cause of 477 errors is issues with the TCP/TLS connection
> to the far end. Have you tried capturing a trace of the call attempt? Have
> you verified your TCP/TLS settings are correct and are aligned with what
> the far end expects? Have you verified the message is being sent to the
> correct remote target to begin with?
>
>
>
> Ben Newlin
>
>
>
> *From: *Users <users-bounces at lists.opensips.org> on behalf of Prathibha B
> <prathibhab.tvm at gmail.com>
> *Date: *Thursday, May 2, 2024 at 8:56 AM
> *To: *users at lists.opensips.org <Users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] Send failed
>
> * EXTERNAL EMAIL - Please use caution with links and attachments *
>
>
> ------------------------------
>
> Can someone point me on how to resolve this issue?
>
>
>
> On Wed, 1 May 2024 at 18:49, Prathibha B <prathibhab.tvm at gmail.com> wrote:
>
> How to solve this error- 477  send failed.
>
>
>
>
> --
>
> Regards,
>
> B.Prathibha
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240503/9ea2cc4b/attachment.html>

From prathibhab.tvm at gmail.com  Fri May  3 04:51:41 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Fri, 3 May 2024 10:21:41 +0530
Subject: [OpenSIPS-Users] Send failed
In-Reply-To: <CAJh_-cDsB8BwA1_qK6kXgmLaewXZ9sr+mF9FSusN8Bxj75XcbA@mail.gmail.com>
References: <TYZPR06MB7525630465AF14C4739AE120FC192@TYZPR06MB7525.apcprd06.prod.outlook.com>
 <CAJh_-cDCEt4GSTuXrwGH99oZXorcsQHhKdAyCj+3R74_70Wtqg@mail.gmail.com>
 <BN0PR10MB52081E849D28E15C3451D7CE95182@BN0PR10MB5208.namprd10.prod.outlook.com>
 <00be01da9cb4$99713330$cc539990$@zaark.com>
 <TYZPR06MB75250AC2D72D98650A57FA55FC1F2@TYZPR06MB7525.apcprd06.prod.outlook.com>
 <CAJh_-cDsB8BwA1_qK6kXgmLaewXZ9sr+mF9FSusN8Bxj75XcbA@mail.gmail.com>
Message-ID: <CAJh_-cBZ97cOb8YDYGC3X5Ps0=+sSE0=BHUSb4wUCEPzU-V52g@mail.gmail.com>

sip trace attached

On Fri, 3 May 2024 at 06:01, Prathibha B <prathibhab.tvm at gmail.com> wrote:

> # TCP Connection settings
> tcp_connect_timeout = 200
> tcp_connection_lifetime = 3600
> tcp_max_connections = 4096
> tcp_keepalive = 0
> tcp_keepcount = 5
> tcp_keepidle = 60
> tcp_keepinterval = 0
>
> On Fri, 3 May 2024 at 05:45, Prathibha B <prathibhab.tvm at gmail.com> wrote:
>
>> How to check TCP keepalive from client and server?
>>
>> Sent from Outlook for Android <https://aka.ms/AAb9ysg>
>> ------------------------------
>> *From:* Users <users-bounces at lists.opensips.org> on behalf of
>> olle at zaark.com <olle at zaark.com>
>> *Sent:* Thursday, May 2, 2024 10:47:23 PM
>> *To:* 'OpenSIPS users mailling list' <users at lists.opensips.org>
>> *Subject:* Re: [OpenSIPS-Users] Send failed
>>
>>
>> Hi, I might add that it’s worth checking TCP keep alive from both client
>> and server.
>>
>>
>>
>> Olle Frimanson
>>
>>
>>
>> *From:* Users <users-bounces at lists.opensips.org> *On Behalf Of *Ben
>> Newlin
>> *Sent:* den 2 maj 2024 16:21
>> *To:* OpenSIPS users mailling list <Users at lists.opensips.org>
>> *Subject:* Re: [OpenSIPS-Users] Send failed
>>
>>
>>
>> There are many different reasons for this error. With just this one line
>> description and no more context it isn’t possible to say why it is
>> occurring.
>>
>>
>>
>> The most common cause of 477 errors is issues with the TCP/TLS connection
>> to the far end. Have you tried capturing a trace of the call attempt? Have
>> you verified your TCP/TLS settings are correct and are aligned with what
>> the far end expects? Have you verified the message is being sent to the
>> correct remote target to begin with?
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users <users-bounces at lists.opensips.org> on behalf of Prathibha
>> B <prathibhab.tvm at gmail.com>
>> *Date: *Thursday, May 2, 2024 at 8:56 AM
>> *To: *users at lists.opensips.org <Users at lists.opensips.org>
>> *Subject: *Re: [OpenSIPS-Users] Send failed
>>
>> * EXTERNAL EMAIL - Please use caution with links and attachments *
>>
>>
>> ------------------------------
>>
>> Can someone point me on how to resolve this issue?
>>
>>
>>
>> On Wed, 1 May 2024 at 18:49, Prathibha B <prathibhab.tvm at gmail.com>
>> wrote:
>>
>> How to solve this error- 477  send failed.
>>
>>
>>
>>
>> --
>>
>> Regards,
>>
>> B.Prathibha
>>
>
>
> --
> Regards,
> B.Prathibha
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240503/e5941e62/attachment-0001.html>
-------------- next part --------------
1714711790.221264 ESP/SIP 10.176.16.131:60357 -> 10.213.0.18:443
INVITE sip:6238900031 at bptesting.erss.in SIP/2.0
Via: SIP/2.0/WSS 192.0.2.112;branch=z9hG4bK76528
To: <sip:6238900031 at bptesting.erss.in>
From: "bp" <sip:9 at bptesting.erss.in>;tag=4qnoq1o2sp
CSeq: 1 INVITE
Call-ID: g7aj6dn9cki17c962mhp
Max-Forwards: 70
Contact: <sip:8pitos0a at 192.0.2.112;transport=wss;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: Browser Phone 0.3.20 (SIPJS - 0.20.0) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Content-Type: application/sdp
Content-Length: 6961

v=0
o=- 5927092632460040994 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS 818b116b-9df1-4833-856f-0076eac66b71
m=audio 11576 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
c=IN IP4 13.235.157.188
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3889765687 1 udp 2122260223 192.168.56.1 49675 typ host generation 0 network-id 1
a=candidate:1166506088 1 udp 2122194687 10.176.16.131 49676 typ host generation 0 network-id 2
a=candidate:2219388706 1 udp 1685987071 14.139.183.221 49676 typ srflx raddr 10.176.16.131 rport 49676 generation 0 network-id 2
a=candidate:427018659 1 tcp 1518280447 192.168.56.1 9 typ host tcptype active generation 0 network-id 1
a=candidate:3140332796 1 tcp 1518214911 10.176.16.131 9 typ host tcptype active generation 0 network-id 2
a=candidate:2787732474 1 udp 25042943 13.235.157.188 11576 typ relay raddr 14.139.183.221 rport 60360 generation 0 network-id 2
a=ice-ufrag:5fWm
a=ice-pwd:tGwQL8VcBdlFSHM/Z0rxFTe8
a=ice-options:trickle
a=fingerprint:sha-256 91:1B:CF:3F:32:37:FA:84:72:83:10:38:86:80:B3:8B:94:6D:7E:10:3C:60:F7:A6:69:AC:34:62:99:18:52:43
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:818b116b-9df1-4833-856f-0076eac66b71 1fc1c374-2713-4807-81de-a725c54c1885
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
a=ssrc:3308415497 cname:614TApu7fEoTn997
a=ssrc:3308415497 msid:818b116b-9df1-4833-856f-0076eac66b71 1fc1c374-2713-4807-81de-a725c54c1885
m=video 11667 UDP/TLS/RTP/SAVPF 96 97 102 103 104 105 106 107 108 109 127 125 39 40 45 46 98 99 100 101 112 113 116 117 118
c=IN IP4 13.235.157.188
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3889765687 1 udp 2122260223 192.168.56.1 49677 typ host generation 0 network-id 1
a=candidate:1166506088 1 udp 2122194687 10.176.16.131 49678 typ host generation 0 network-id 2
a=candidate:2219388706 1 udp 1685987071 14.139.183.221 49678 typ srflx raddr 10.176.16.131 rport 49678 generation 0 network-id 2
a=candidate:427018659 1 tcp 1518280447 192.168.56.1 9 typ host tcptype active generation 0 network-id 1
a=candidate:3140332796 1 tcp 1518214911 10.176.16.131 9 typ host tcptype active generation 0 network-id 2
a=candidate:2787732474 1 udp 25042943 13.235.157.188 11667 typ relay raddr 14.139.183.221 rport 60362 generation 0 network-id 2
a=ice-ufrag:5fWm
a=ice-pwd:tGwQL8VcBdlFSHM/Z0rxFTe8
a=ice-options:trickle
a=fingerprint:sha-256 91:1B:CF:3F:32:37:FA:84:72:83:10:38:86:80:B3:8B:94:6D:7E:10:3C:60:F7:A6:69:AC:34:62:99:18:52:43
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:818b116b-9df1-4833-856f-0076eac66b71 10ea3a68-dae8-4739-9030-2540f94abccc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:103 rtx/90000
a=fmtp:103 apt=102
a=rtpmap:104 H264/90000
a=rtcp-fb:104 goog-remb
a=rtcp-fb:104 transport-cc
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli
a=fmtp:104 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:105 rtx/90000
a=fmtp:105 apt=104
a=rtpmap:106 H264/90000
a=rtcp-fb:106 goog-remb
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=106
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:125 rtx/90000
a=fmtp:125 apt=127
a=rtpmap:39 H264/90000
a=rtcp-fb:39 goog-remb
a=rtcp-fb:39 transport-cc
a=rtcp-fb:39 ccm fir
a=rtcp-fb:39 nack
a=rtcp-fb:39 nack pli
a=fmtp:39 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=4d001f
a=rtpmap:40 rtx/90000
a=fmtp:40 apt=39
a=rtpmap:45 AV1/90000
a=rtcp-fb:45 goog-remb
a=rtcp-fb:45 transport-cc
a=rtcp-fb:45 ccm fir
a=rtcp-fb:45 nack
a=rtcp-fb:45 nack pli
a=fmtp:45 level-idx=5;profile=0;tier=0
a=rtpmap:46 rtx/90000
a=fmtp:46 apt=45
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:112 H264/90000
a=rtcp-fb:112 goog-remb
a=rtcp-fb:112 transport-cc
a=rtcp-fb:112 ccm fir
a=rtcp-fb:112 nack
a=rtcp-fb:112 nack pli
a=fmtp:112 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f
a=rtpmap:113 rtx/90000
a=fmtp:113 apt=112
a=rtpmap:116 red/90000
a=rtpmap:117 rtx/90000
a=fmtp:117 apt=116
a=rtpmap:118 ulpfec/90000
a=ssrc-group:FID 3648400694 484736202
a=ssrc:3648400694 cname:614TApu7fEoTn997
a=ssrc:3648400694 msid:818b116b-9df1-4833-856f-0076eac66b71 10ea3a68-dae8-4739-9030-2540f94abccc
a=ssrc:484736202 cname:614TApu7fEoTn997
a=ssrc:484736202 msid:818b116b-9df1-4833-856f-0076eac66b71 10ea3a68-dae8-4739-9030-2540f94abccc

1714711790.222229 ESP/SIP 10.213.0.18:443 -> 10.176.16.131:60357
SIP/2.0 100 Giving it a try
Via: SIP/2.0/WSS 192.0.2.112;received=10.176.16.131;rport=60357;branch=z9hG4bK76528
To: <sip:6238900031 at bptesting.erss.in>
From: "bp" <sip:9 at bptesting.erss.in>;tag=4qnoq1o2sp
Call-ID: g7aj6dn9cki17c962mhp
CSeq: 1 INVITE
Server: OpenSIPS (3.4.5 (x86_64/linux))
Content-Length: 0


1714711790.222382 TCP/100

1714711790.222597 TCP/100

1714711790.222737 TCP/100

1714711790.222880 TCP/100

1714711790.223033 TCP/100

1714711790.236838 ESP/SIP 10.213.0.18:443 -> 10.176.16.131:60357
SIP/2.0 477 Send failed (477/TM)
Via: SIP/2.0/WSS 192.0.2.112;received=10.176.16.131;rport=60357;branch=z9hG4bK76528
To: <sip:6238900031 at bptesting.erss.in>;tag=e739-bef52aaa115178f0beeb72930121cfa7
From: "bp" <sip:9 at bptesting.erss.in>;tag=4qnoq1o2sp
Call-ID: g7aj6dn9cki17c962mhp
CSeq: 1 INVITE
Server: OpenSIPS (3.4.5 (x86_64/linux))
Content-Length: 0


1714711790.240678 ESP/SIP 10.176.16.131:60357 -> 10.213.0.18:443
ACK sip:6238900031 at bptesting.erss.in SIP/2.0
Via: SIP/2.0/WSS 192.0.2.112;branch=z9hG4bK76528
To: <sip:6238900031 at bptesting.erss.in>;tag=e739-bef52aaa115178f0beeb72930121cfa7
From: "bp" <sip:9 at bptesting.erss.in>;tag=4qnoq1o2sp
Call-ID: g7aj6dn9cki17c962mhp
CSeq: 1 ACK
Max-Forwards: 69
Content-Length: 0

From eranl at kayhut.com  Sun May  5 12:01:18 2024
From: eranl at kayhut.com (Eran Leshem)
Date: Sun, 5 May 2024 15:01:18 +0300
Subject: [OpenSIPS-Users] Increase OpenSips memory size
Message-ID: <CANuw4TF4gW9XPPP6YECnP0mmoxUfaxYp6z-NSyW7DOM_FXWuZg@mail.gmail.com>

Hi,
I'm trying to increase the size of the memory that OpenSips uses.
This is a bit strange to me, because when I run:
ps aux | grep -i opensips
I get:
/usr/sbin/opensips -P /run/opensips/opensips.pid -f
/etc/opensips/opensips.cfg -m 64 -M 4
but, when I look at:
/lib/systemd/system/opensips.service
I see:
Environment=P_MEMORY=32 S_MEMORY=32
ExecStart=/usr/sbin/opensips -P %t/opensips/opensips.pid -f
/etc/opensips/opensips.cfg -m $S_MEMORY -M $P_MEMORY $OPTIONS

So, from where does opensips get its memory parameters? (-m -M)
And, how much can I give it? Can I increase it to 320 and 320?
My machine:
- Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
- 16 GB memory,
- OpenSIPS version 3.4

Thanks,
Eran L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240505/c27ecdba/attachment.html>

From marcin at voipplus.net  Sun May  5 12:37:08 2024
From: marcin at voipplus.net (Marcin Groszek)
Date: Sun, 5 May 2024 07:37:08 -0500
Subject: [OpenSIPS-Users] Increase OpenSips memory size
In-Reply-To: <CANuw4TF4gW9XPPP6YECnP0mmoxUfaxYp6z-NSyW7DOM_FXWuZg@mail.gmail.com>
References: <CANuw4TF4gW9XPPP6YECnP0mmoxUfaxYp6z-NSyW7DOM_FXWuZg@mail.gmail.com>
Message-ID: <d48ac43f-8d0d-fdec-f57b-bf9ebd8a2cf3@voipplus.net>

I have edited  /etc/sysconfig/opensips to set memory parameters.


On 5/5/2024 7:01 AM, Eran Leshem wrote:
> Hi,
> I'm trying to increase the size of the memory that OpenSips uses.
> This is a bit strange to me, because when I run:
> ps aux | grep -i opensips
> I get:
> /usr/sbin/opensips -P /run/opensips/opensips.pid -f 
> /etc/opensips/opensips.cfg -m 64 -M 4
> but, when I look at:
> /lib/systemd/system/opensips.service
> I see:
> Environment=P_MEMORY=32 S_MEMORY=32
> ExecStart=/usr/sbin/opensips -P %t/opensips/opensips.pid -f 
> /etc/opensips/opensips.cfg -m $S_MEMORY -M $P_MEMORY $OPTIONS
>
> So, from where does opensips get its memory parameters? (-m -M)
> And, how much can I give it? Can I increase it to 320 and 320?
> My machine:
> - Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
> - 16 GB memory,
> - OpenSIPS version 3.4
>
> Thanks,
> Eran L.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-- 
Best Regards:
Marcin Groszek
Business Phone Service
https://www.voipplus.net

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

From eranl at kayhut.com  Sun May  5 12:52:39 2024
From: eranl at kayhut.com (Eran Leshem)
Date: Sun, 5 May 2024 15:52:39 +0300
Subject: [OpenSIPS-Users] Increase OpenSips memory size
In-Reply-To: <d48ac43f-8d0d-fdec-f57b-bf9ebd8a2cf3@voipplus.net>
References: <CANuw4TF4gW9XPPP6YECnP0mmoxUfaxYp6z-NSyW7DOM_FXWuZg@mail.gmail.com>
 <d48ac43f-8d0d-fdec-f57b-bf9ebd8a2cf3@voipplus.net>
Message-ID: <CANuw4THSSjra=2W5xys=jczOP2NdRLwHJ8YnNA27V9fqeKko1w@mail.gmail.com>

Unfortunately, I don't have the folder /etc/sysconfig/ in my system.
Any other folder to find that file?

On Sun, 5 May 2024, 15:39 Marcin Groszek, <marcin at voipplus.net> wrote:

> I have edited  /etc/sysconfig/opensips to set memory parameters.
>
>
> On 5/5/2024 7:01 AM, Eran Leshem wrote:
>
> Hi,
> I'm trying to increase the size of the memory that OpenSips uses.
> This is a bit strange to me, because when I run:
> ps aux | grep -i opensips
> I get:
> /usr/sbin/opensips -P /run/opensips/opensips.pid -f
> /etc/opensips/opensips.cfg -m 64 -M 4
> but, when I look at:
> /lib/systemd/system/opensips.service
> I see:
> Environment=P_MEMORY=32 S_MEMORY=32
> ExecStart=/usr/sbin/opensips -P %t/opensips/opensips.pid -f
> /etc/opensips/opensips.cfg -m $S_MEMORY -M $P_MEMORY $OPTIONS
>
> So, from where does opensips get its memory parameters? (-m -M)
> And, how much can I give it? Can I increase it to 320 and 320?
> My machine:
> - Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
> - 16 GB memory,
> - OpenSIPS version 3.4
>
> Thanks,
> Eran L.
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> --
> Best Regards:
> Marcin Groszek
> Business Phone Servicehttps://www.voipplus.net
>
> _______________________________________________
> 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/20240505/60d722f7/attachment.html>

From eranl at kayhut.com  Sun May  5 13:28:54 2024
From: eranl at kayhut.com (Eran Leshem)
Date: Sun, 5 May 2024 16:28:54 +0300
Subject: [OpenSIPS-Users] Increase OpenSips memory size
In-Reply-To: <CANuw4TH6aY04gWzp_-eHfvFU95ddETo3nTfLkzN8F1rF-j8Wpg@mail.gmail.com>
References: <CANuw4TF4gW9XPPP6YECnP0mmoxUfaxYp6z-NSyW7DOM_FXWuZg@mail.gmail.com>
 <d48ac43f-8d0d-fdec-f57b-bf9ebd8a2cf3@voipplus.net>
 <CANuw4THSSjra=2W5xys=jczOP2NdRLwHJ8YnNA27V9fqeKko1w@mail.gmail.com>
 <8ddd7561-991d-6930-0e75-4931d525d9a0@voipplus.net>
 <CANuw4TH6aY04gWzp_-eHfvFU95ddETo3nTfLkzN8F1rF-j8Wpg@mail.gmail.com>
Message-ID: <CANuw4TGeYPN6WjRULetYuJNxy=ObPfcm0OJMBor=e=kNm-RN+Q@mail.gmail.com>

On Sun, May 5, 2024 at 4:20 PM Eran Leshem <eranl at kayhut.com> wrote:

> O.K.
>
> I found the memory numbers in the file:
> /etc/default/opensips
> After changing the values (I multiplied it by 10 to: 640 and 40),
> I restarted opensips and saw that the changes were applied in the log.
>
> Thank you very much.
>
> On Sun, May 5, 2024 at 3:56 PM Marcin Groszek <marcin at voipplus.net> wrote:
>
>> try this
>>
>> cd /etc/
>>
>> grep -r "S_MEMORY" *
>>
>> or
>>
>> updatedb
>>
>> locate opensips
>>
>>
>> On 5/5/2024 7:52 AM, Eran Leshem wrote:
>>
>> Unfortunately, I don't have the folder /etc/sysconfig/ in my system.
>> Any other folder to find that file?
>>
>> On Sun, 5 May 2024, 15:39 Marcin Groszek, <marcin at voipplus.net> wrote:
>>
>>> I have edited  /etc/sysconfig/opensips to set memory parameters.
>>>
>>>
>>> On 5/5/2024 7:01 AM, Eran Leshem wrote:
>>>
>>> Hi,
>>> I'm trying to increase the size of the memory that OpenSips uses.
>>> This is a bit strange to me, because when I run:
>>> ps aux | grep -i opensips
>>> I get:
>>> /usr/sbin/opensips -P /run/opensips/opensips.pid -f
>>> /etc/opensips/opensips.cfg -m 64 -M 4
>>> but, when I look at:
>>> /lib/systemd/system/opensips.service
>>> I see:
>>> Environment=P_MEMORY=32 S_MEMORY=32
>>> ExecStart=/usr/sbin/opensips -P %t/opensips/opensips.pid -f
>>> /etc/opensips/opensips.cfg -m $S_MEMORY -M $P_MEMORY $OPTIONS
>>>
>>> So, from where does opensips get its memory parameters? (-m -M)
>>> And, how much can I give it? Can I increase it to 320 and 320?
>>> My machine:
>>> - Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
>>> - 16 GB memory,
>>> - OpenSIPS version 3.4
>>>
>>> Thanks,
>>> Eran L.
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> --
>>> Best Regards:
>>> Marcin Groszek
>>> Business Phone Servicehttps://www.voipplus.net
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> --
>> Best Regards:
>> Marcin Groszek
>> Business Phone Servicehttps://www.voipplus.net
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240505/f5cc4e48/attachment-0001.html>

From prathibhab.tvm at gmail.com  Mon May  6 12:40:04 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Mon, 6 May 2024 18:10:04 +0530
Subject: [OpenSIPS-Users] opensips call center module
Message-ID: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>

I'm able to hear the message given in the message queue but the call is not
getting transferred to the online agent,

-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240506/ea392bd1/attachment.html>

From eranl at kayhut.com  Mon May  6 14:09:54 2024
From: eranl at kayhut.com (Eran Leshem)
Date: Mon, 6 May 2024 17:09:54 +0300
Subject: [OpenSIPS-Users] How to answer a call with a wav file?
Message-ID: <CANuw4TFb+2QX2sKuUvfNNbiTNjyPDr-pnic_S1DjtQMCkNoF_A@mail.gmail.com>

Hi, I would like to create a special extension that will answer by playing
a wav file back to the caller.

The call will be as such:
1. The caller will call the special extension: "wav-call"
2. Instead of someone answering his call, the calling person will hear
a sound (a song, a wav file), being played back to him.
3. After that, the caller will hang-up.

I have tried to do it in several ways, but failed.
I looked at the documentation and I have tried using:

rtpengine_play_media("file=/path/to/ringback_tone_file.wav");

but, did not succeed.
I keep getting: "Unknown call-ID"

My machine:
- Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
- 16 GB memory,
- OpenSIPS version 3.4
- RTPEngine is installed.

Any ideas?
- Thanks, Eran L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240506/634d77bb/attachment.html>

From alexanderhenryperkins at gmail.com  Mon May  6 17:03:12 2024
From: alexanderhenryperkins at gmail.com (Alexander Perkins)
Date: Mon, 6 May 2024 13:03:12 -0400
Subject: [OpenSIPS-Users] Virtual Server Load Question
Message-ID: <CALLkTp0PS6Uhfs4KC6UQmv0qmYkFs15raKsX29RVw3P8H4Gi-A@mail.gmail.com>

Hello Everyone.  We are trying to figure out how much traffic we can pass
on an OpenSIPS server.  The only thing the server is doing is load
balancing.  And that it is it.  From our hosting provider, we are using the
following virtual server:

4 vCPUs and 8 GB of RAM.

Also, is there a limit to how many simultaneous calls it can process?
Also, how does udp_workers affect that?  What is a good value?

Thank you for reading my long-winded email :).

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

From alain.bieuzent at free.fr  Mon May  6 21:28:08 2024
From: alain.bieuzent at free.fr (Alain Bieuzent)
Date: Mon, 06 May 2024 23:28:08 +0200
Subject: [OpenSIPS-Users] Virtual Server Load Question
In-Reply-To: <CALLkTp0PS6Uhfs4KC6UQmv0qmYkFs15raKsX29RVw3P8H4Gi-A@mail.gmail.com>
References: <CALLkTp0PS6Uhfs4KC6UQmv0qmYkFs15raKsX29RVw3P8H4Gi-A@mail.gmail.com>
Message-ID: <15BFAAEB-5F8B-46FE-9F3F-A018C236D429@free.fr>

Hi Alex,

 

We manage 500 Call attempts per second on 6 vCPU server with less than 500MB of RAM.

CPU usage is less than 15% and load is around 0,2.

 

udp_worker is set to 8.

 

Hope it help.

 

Alain

 

De : Users <users-bounces at lists.opensips.org> au nom de Alexander Perkins <alexanderhenryperkins at gmail.com>
Répondre à : OpenSIPS users mailling list <users at lists.opensips.org>
Date : lundi 6 mai 2024 à 19:05
À : OpenSIPS users mailling list <users at lists.opensips.org>
Objet : [OpenSIPS-Users] Virtual Server Load Question

 

Hello Everyone.  We are trying to figure out how much traffic we can pass on an OpenSIPS server.  The only thing the server is doing is load balancing.  And that it is it.  From our hosting provider, we are using the following virtual server:

 

4 vCPUs and 8 GB of RAM.

 

Also, is there a limit to how many simultaneous calls it can process?  Also, how does udp_workers affect that?  What is a good value?

 

Thank you for reading my long-winded email :).

 

Alex

_______________________________________________ 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/20240506/58b97265/attachment.html>

From jehanzaib.kiani at gmail.com  Tue May  7 01:02:50 2024
From: jehanzaib.kiani at gmail.com (Jehanzaib Younis)
Date: Tue, 7 May 2024 13:02:50 +1200
Subject: [OpenSIPS-Users] opensips call center module
In-Reply-To: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
References: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
Message-ID: <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>

Hi Parathiba,

Could you capture the SIP packets? They'll provide insight into what's
going on.


Regards,
Jehanzaib


On Tue, May 7, 2024 at 12:40 AM Prathibha B <prathibhab.tvm at gmail.com>
wrote:

> I'm able to hear the message given in the message queue but the call is
> not getting transferred to the online agent,
>
> --
> Regards,
> B.Prathibha
> _______________________________________________
> 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/20240507/e50ef135/attachment-0001.html>

From jehanzaib.kiani at gmail.com  Tue May  7 01:13:40 2024
From: jehanzaib.kiani at gmail.com (Jehanzaib Younis)
Date: Tue, 7 May 2024 13:13:40 +1200
Subject: [OpenSIPS-Users] How to answer a call with a wav file?
In-Reply-To: <CANuw4TFb+2QX2sKuUvfNNbiTNjyPDr-pnic_S1DjtQMCkNoF_A@mail.gmail.com>
References: <CANuw4TFb+2QX2sKuUvfNNbiTNjyPDr-pnic_S1DjtQMCkNoF_A@mail.gmail.com>
Message-ID: <CAKrJzCxTxH=nT2Q1TAzSz30WQtcBm6GdHuwri4WA55vAb-uo6g@mail.gmail.com>

Hi Eran,

Have you tried rtpengine_manage() before playing the media ?

        rtpengine_manage();
        rtpengine_play_media("file=ringback_tone_file.wav");
        exit;


Regards,
Jehanzaib


On Tue, May 7, 2024 at 2:10 AM Eran Leshem <eranl at kayhut.com> wrote:

> Hi, I would like to create a special extension that will answer by playing
> a wav file back to the caller.
>
> The call will be as such:
> 1. The caller will call the special extension: "wav-call"
> 2. Instead of someone answering his call, the calling person will hear
> a sound (a song, a wav file), being played back to him.
> 3. After that, the caller will hang-up.
>
> I have tried to do it in several ways, but failed.
> I looked at the documentation and I have tried using:
>
> rtpengine_play_media("file=/path/to/ringback_tone_file.wav");
>
> but, did not succeed.
> I keep getting: "Unknown call-ID"
>
> My machine:
> - Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
> - 16 GB memory,
> - OpenSIPS version 3.4
> - RTPEngine is installed.
>
> Any ideas?
> - Thanks, Eran L.
> _______________________________________________
> 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/20240507/7e012afc/attachment.html>

From prathibhab.tvm at gmail.com  Tue May  7 06:02:31 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Tue, 7 May 2024 11:32:31 +0530
Subject: [OpenSIPS-Users] opensips call center module
In-Reply-To: <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>
References: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
 <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>
Message-ID: <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>

"Agents": [
        {
            "id": "101001",
            "Ref": 1,
            "Loged in": "YES",
            "State": "incall"
        },
        {
            "id": "101002",
            "Ref": 1,
            "Loged in": "YES",
            "State": "incall"
        }
    ]

The agent state shows status as incall.

On Tue, 7 May 2024 at 06:35, Jehanzaib Younis <jehanzaib.kiani at gmail.com>
wrote:

> Hi Parathiba,
>
> Could you capture the SIP packets? They'll provide insight into what's
> going on.
>
>
> Regards,
> Jehanzaib
>
>
> On Tue, May 7, 2024 at 12:40 AM Prathibha B <prathibhab.tvm at gmail.com>
> wrote:
>
>> I'm able to hear the message given in the message queue but the call is
>> not getting transferred to the online agent,
>>
>> --
>> Regards,
>> B.Prathibha
>> _______________________________________________
>> 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
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240507/bd89369f/attachment.html>

From prathibhab.tvm at gmail.com  Tue May  7 07:02:27 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Tue, 7 May 2024 12:32:27 +0530
Subject: [OpenSIPS-Users] opensips call center module
In-Reply-To: <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>
References: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
 <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>
 <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>
Message-ID: <CAJh_-cC=xUEBShwKNCu5b+=Yhuc46SqnDVabo1A6JXr-VMVkDw@mail.gmail.com>

I delete the records from cc_calls table and restart opensips. Then the
call is getting is transferred to one of the agents. What is the solution
to this? Everytime it is not possible to delete the records in cc_calls
table and restart opensips.

When I reject the call, the call is transferred to the same agent. The call
is not going to the next available agent.

On Tue, 7 May 2024 at 11:32, Prathibha B <prathibhab.tvm at gmail.com> wrote:

> "Agents": [
>         {
>             "id": "101001",
>             "Ref": 1,
>             "Loged in": "YES",
>             "State": "incall"
>         },
>         {
>             "id": "101002",
>             "Ref": 1,
>             "Loged in": "YES",
>             "State": "incall"
>         }
>     ]
>
> The agent state shows status as incall.
>
> On Tue, 7 May 2024 at 06:35, Jehanzaib Younis <jehanzaib.kiani at gmail.com>
> wrote:
>
>> Hi Parathiba,
>>
>> Could you capture the SIP packets? They'll provide insight into what's
>> going on.
>>
>>
>> Regards,
>> Jehanzaib
>>
>>
>> On Tue, May 7, 2024 at 12:40 AM Prathibha B <prathibhab.tvm at gmail.com>
>> wrote:
>>
>>> I'm able to hear the message given in the message queue but the call is
>>> not getting transferred to the online agent,
>>>
>>> --
>>> Regards,
>>> B.Prathibha
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Regards,
> B.Prathibha
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240507/b4014d43/attachment.html>

From prathibhab.tvm at gmail.com  Tue May  7 07:17:20 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Tue, 7 May 2024 12:47:20 +0530
Subject: [OpenSIPS-Users] opensips call center module
In-Reply-To: <CAJh_-cC=xUEBShwKNCu5b+=Yhuc46SqnDVabo1A6JXr-VMVkDw@mail.gmail.com>
References: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
 <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>
 <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>
 <CAJh_-cC=xUEBShwKNCu5b+=Yhuc46SqnDVabo1A6JXr-VMVkDw@mail.gmail.com>
Message-ID: <CAJh_-cC2Cfqn0xWZxCCC4N7Api6ByREmHrh=CiFGWzGxX7ZMaQ@mail.gmail.com>

After about 45 seconds, the screen on the receiver side becomes blank.

On Tue, 7 May 2024 at 12:32, Prathibha B <prathibhab.tvm at gmail.com> wrote:

> I delete the records from cc_calls table and restart opensips. Then the
> call is getting is transferred to one of the agents. What is the solution
> to this? Everytime it is not possible to delete the records in cc_calls
> table and restart opensips.
>
> When I reject the call, the call is transferred to the same agent. The
> call is not going to the next available agent.
>
> On Tue, 7 May 2024 at 11:32, Prathibha B <prathibhab.tvm at gmail.com> wrote:
>
>> "Agents": [
>>         {
>>             "id": "101001",
>>             "Ref": 1,
>>             "Loged in": "YES",
>>             "State": "incall"
>>         },
>>         {
>>             "id": "101002",
>>             "Ref": 1,
>>             "Loged in": "YES",
>>             "State": "incall"
>>         }
>>     ]
>>
>> The agent state shows status as incall.
>>
>> On Tue, 7 May 2024 at 06:35, Jehanzaib Younis <jehanzaib.kiani at gmail.com>
>> wrote:
>>
>>> Hi Parathiba,
>>>
>>> Could you capture the SIP packets? They'll provide insight into what's
>>> going on.
>>>
>>>
>>> Regards,
>>> Jehanzaib
>>>
>>>
>>> On Tue, May 7, 2024 at 12:40 AM Prathibha B <prathibhab.tvm at gmail.com>
>>> wrote:
>>>
>>>> I'm able to hear the message given in the message queue but the call is
>>>> not getting transferred to the online agent,
>>>>
>>>> --
>>>> Regards,
>>>> B.Prathibha
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> --
>> Regards,
>> B.Prathibha
>>
>
>
> --
> Regards,
> B.Prathibha
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240507/d67524bd/attachment-0001.html>

From jehanzaib.kiani at gmail.com  Tue May  7 07:40:51 2024
From: jehanzaib.kiani at gmail.com (Jehanzaib Younis)
Date: Tue, 7 May 2024 19:40:51 +1200
Subject: [OpenSIPS-Users] opensips call center module
In-Reply-To: <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>
References: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
 <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>
 <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>
Message-ID: <CAKrJzCz7Ead6ZYT+vZjND9wtJYduK1dLSnb87jBXT+1mFTJg=g@mail.gmail.com>

Does it always stay in the  incall State? If this is the case then you need
to check somehow BYE or CANCEL not working properly.

Regards,
Jehanzaib


On Tue, May 7, 2024 at 6:03 PM Prathibha B <prathibhab.tvm at gmail.com> wrote:

> "Agents": [
>         {
>             "id": "101001",
>             "Ref": 1,
>             "Loged in": "YES",
>             "State": "incall"
>         },
>         {
>             "id": "101002",
>             "Ref": 1,
>             "Loged in": "YES",
>             "State": "incall"
>         }
>     ]
>
> The agent state shows status as incall.
>
> On Tue, 7 May 2024 at 06:35, Jehanzaib Younis <jehanzaib.kiani at gmail.com>
> wrote:
>
>> Hi Parathiba,
>>
>> Could you capture the SIP packets? They'll provide insight into what's
>> going on.
>>
>>
>> Regards,
>> Jehanzaib
>>
>>
>> On Tue, May 7, 2024 at 12:40 AM Prathibha B <prathibhab.tvm at gmail.com>
>> wrote:
>>
>>> I'm able to hear the message given in the message queue but the call is
>>> not getting transferred to the online agent,
>>>
>>> --
>>> Regards,
>>> B.Prathibha
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Regards,
> B.Prathibha
> _______________________________________________
> 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/20240507/9ed0bdc6/attachment.html>

From prathibhab.tvm at gmail.com  Tue May  7 08:01:40 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Tue, 7 May 2024 13:31:40 +0530
Subject: [OpenSIPS-Users] opensips call center module
In-Reply-To: <CAKrJzCz7Ead6ZYT+vZjND9wtJYduK1dLSnb87jBXT+1mFTJg=g@mail.gmail.com>
References: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
 <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>
 <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>
 <CAKrJzCz7Ead6ZYT+vZjND9wtJYduK1dLSnb87jBXT+1mFTJg=g@mail.gmail.com>
Message-ID: <CAJh_-cBdUZR0wSQ9FzN7J0wW3NLsbap8W-f9v216wGmk-i_7mg@mail.gmail.com>

Yes. It always stay in incall state.

On Tue, 7 May 2024 at 13:14, Jehanzaib Younis <jehanzaib.kiani at gmail.com>
wrote:

> Does it always stay in the  incall State? If this is the case then you
> need to check somehow BYE or CANCEL not working properly.
>
> Regards,
> Jehanzaib
>
>
> On Tue, May 7, 2024 at 6:03 PM Prathibha B <prathibhab.tvm at gmail.com>
> wrote:
>
>> "Agents": [
>>         {
>>             "id": "101001",
>>             "Ref": 1,
>>             "Loged in": "YES",
>>             "State": "incall"
>>         },
>>         {
>>             "id": "101002",
>>             "Ref": 1,
>>             "Loged in": "YES",
>>             "State": "incall"
>>         }
>>     ]
>>
>> The agent state shows status as incall.
>>
>> On Tue, 7 May 2024 at 06:35, Jehanzaib Younis <jehanzaib.kiani at gmail.com>
>> wrote:
>>
>>> Hi Parathiba,
>>>
>>> Could you capture the SIP packets? They'll provide insight into what's
>>> going on.
>>>
>>>
>>> Regards,
>>> Jehanzaib
>>>
>>>
>>> On Tue, May 7, 2024 at 12:40 AM Prathibha B <prathibhab.tvm at gmail.com>
>>> wrote:
>>>
>>>> I'm able to hear the message given in the message queue but the call is
>>>> not getting transferred to the online agent,
>>>>
>>>> --
>>>> Regards,
>>>> B.Prathibha
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> --
>> Regards,
>> B.Prathibha
>> _______________________________________________
>> 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
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240507/862d6fd9/attachment.html>

From prathibhab.tvm at gmail.com  Wed May  8 04:17:41 2024
From: prathibhab.tvm at gmail.com (Prathibha B)
Date: Wed, 8 May 2024 09:47:41 +0530
Subject: [OpenSIPS-Users] opensips call center module
In-Reply-To: <CAJh_-cApN7Zuc8it1BszwiQnB_-mdvj-78sbZQpHekwk193rAg@mail.gmail.com>
References: <CAJh_-cBbpfS5Wbp2aKuJb5nFmcMF=rQiwpDkzaqp8v8yK2_QfQ@mail.gmail.com>
 <CAKrJzCzJQn1B_d5ZnoJjEoHjYJ0dRGfiauQE9an88_ZwdUS8jg@mail.gmail.com>
 <CAJh_-cDdxanF6M-r_BnThgyuYs9cfp_fpHAbiABD-2Uh0kiZqg@mail.gmail.com>
 <CAKrJzCz7Ead6ZYT+vZjND9wtJYduK1dLSnb87jBXT+1mFTJg=g@mail.gmail.com>
 <CAJh_-cBdUZR0wSQ9FzN7J0wW3NLsbap8W-f9v216wGmk-i_7mg@mail.gmail.com>
 <CAJh_-cApN7Zuc8it1BszwiQnB_-mdvj-78sbZQpHekwk193rAg@mail.gmail.com>
Message-ID: <CAJh_-cDah_K=GckBKs1=QVdUbMbYX5fMHoA4opiAxB+47wdStw@mail.gmail.com>

Exactly after 31 seconds, the video becomes blank. What could be the reason?

*Console Log:*
Wed May 08 2024 09:11:03 GMT+0530 (India Standard Time) | sip.invite-dialog
| No ACK for 2xx response received, attempting retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:05 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:09 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:13 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:17 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:21 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:25 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:29 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:33 GMT+0530 (India Standard Time)
| sip.invite-dialog | No ACK for 2xx response received, attempting
retransmission
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:33 GMT+0530 (India Standard Time)
| sip.Invitation | Invitation.onAckTimeout
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:33 GMT+0530 (India Standard Time)
| sip.Invitation | No ACK received for an extended period of time,
terminating session
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:33 GMT+0530 (India Standard Time)
| sip.invite-dialog | INVITE dialog
B2B.245.4610557.1715138504.19934727797hqeu982nm5b311b272f7dc2a4783f192166366d5a-4bdb
sending BYE request
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:33 GMT+0530 (India Standard Time)
| sip.invite-dialog | INVITE dialog
B2B.245.4610557.1715138504.19934727797hqeu982nm5b311b272f7dc2a4783f192166366d5a-4bdb
destroyed
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:33 GMT+0530 (India Standard Time)
| sip.Invitation | Session
B2B.245.4610557.1715138504.19934727795b311b272f7dc2a4783f192166366d5a-4bdb
transitioned to state Terminated
sip-0.20.0.min.js:2 Wed May 08 2024 09:11:33 GMT+0530 (India Standard Time)
| sip.Invitation | Session
B2B.245.4610557.1715138504.19934727795b311b272f7dc2a4783f192166366d5a-4bdb
in state Terminated is being disposed

On Tue, 7 May 2024 at 17:20, Prathibha B <prathibhab.tvm at gmail.com> wrote:

> Getting blank screen after 32 seconds.
>
> On Tue, 7 May 2024 at 13:31, Prathibha B <prathibhab.tvm at gmail.com> wrote:
>
>> Yes. It always stay in incall state.
>>
>> On Tue, 7 May 2024 at 13:14, Jehanzaib Younis <jehanzaib.kiani at gmail.com>
>> wrote:
>>
>>> Does it always stay in the  incall State? If this is the case then you
>>> need to check somehow BYE or CANCEL not working properly.
>>>
>>> Regards,
>>> Jehanzaib
>>>
>>>
>>> On Tue, May 7, 2024 at 6:03 PM Prathibha B <prathibhab.tvm at gmail.com>
>>> wrote:
>>>
>>>> "Agents": [
>>>>         {
>>>>             "id": "101001",
>>>>             "Ref": 1,
>>>>             "Loged in": "YES",
>>>>             "State": "incall"
>>>>         },
>>>>         {
>>>>             "id": "101002",
>>>>             "Ref": 1,
>>>>             "Loged in": "YES",
>>>>             "State": "incall"
>>>>         }
>>>>     ]
>>>>
>>>> The agent state shows status as incall.
>>>>
>>>> On Tue, 7 May 2024 at 06:35, Jehanzaib Younis <
>>>> jehanzaib.kiani at gmail.com> wrote:
>>>>
>>>>> Hi Parathiba,
>>>>>
>>>>> Could you capture the SIP packets? They'll provide insight into what's
>>>>> going on.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Jehanzaib
>>>>>
>>>>>
>>>>> On Tue, May 7, 2024 at 12:40 AM Prathibha B <prathibhab.tvm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I'm able to hear the message given in the message queue but the call
>>>>>> is not getting transferred to the online agent,
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> B.Prathibha
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> B.Prathibha
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> --
>> Regards,
>> B.Prathibha
>>
>
>
> --
> Regards,
> B.Prathibha
>


-- 
Regards,
B.Prathibha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240508/e839e023/attachment.html>

From bogdan at opensips.org  Wed May  8 06:55:29 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 8 May 2024 09:55:29 +0300
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200
 tls/ssl certs
In-Reply-To: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
References: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
Message-ID: <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>

Hi Denys.

That is rather weird, 250 certificates in 1 min. I assume it is not a DB 
issue (considering the db_text backend), so can you try to do multiple 
sequential "opensips-cli -x trap" to try to understand what is going on ?

Regards,

Bogdan-Andrei Iancu

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

On 02.05.2024 11:41, Denys Pozniak wrote:
> Hello!
>
> There is a task to divide a single tls/ssl letsencrypt certificate for 
> white labels into specific ones.
> I entered about ~250 certificates into db_text, but as it turned out, 
> for OpenSIPS this is a rather complex operation to load them and takes 
> about 1 minute and a heavy CPU load is noticeable.
>
> I would appreciate any advice on how to avoid this.
>
> # wc -l dbtext/tls_mgm
> 253 dbtext/tls_mgm
>
> # time opensips-cli -x mi tls_reload
> "OK"
> real 0m52.034s
> user 0m1.419s
> sys 0m0.433s
>
> # time systemctl restart opensips
> real    0m58.198s
> user    0m0.024s
> sys     0m0.055s
>
> # opensips -V
> version: opensips 3.4.4 (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: 036d02961
>
> -- 
>
> 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/20240508/d9a580a4/attachment.html>

From denys.pozniak at gmail.com  Wed May  8 11:10:14 2024
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Wed, 8 May 2024 13:10:14 +0200
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200
 tls/ssl certs
In-Reply-To: <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>
References: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
 <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>
Message-ID: <CA+x3AxoXfDkN3rVwXH3u5Rj7w8Nm6ULtwLb2=FKET=qOOuP9FQ@mail.gmail.com>

Hello!

If possible, please check log:
https://github.com/denyspozniak/opensips_tls_debug/blob/main/gdb_opensips_20240508_115956


ср, 8 мая 2024 г. в 08:55, Bogdan-Andrei Iancu <bogdan at opensips.org>:

> Hi Denys.
>
> That is rather weird, 250 certificates in 1 min. I assume it is not a DB
> issue (considering the db_text backend), so can you try to do multiple
> sequential "opensips-cli -x trap" to try to understand what is going on ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 02.05.2024 11:41, Denys Pozniak wrote:
>
> Hello!
>
> There is a task to divide a single tls/ssl letsencrypt certificate for
> white labels into specific ones.
> I entered about ~250 certificates into db_text, but as it turned out, for
> OpenSIPS this is a rather complex operation to load them and takes about 1
> minute and a heavy CPU load is noticeable.
>
> I would appreciate any advice on how to avoid this.
>
> # wc -l dbtext/tls_mgm
> 253 dbtext/tls_mgm
>
> # time opensips-cli -x mi tls_reload
> "OK"
> real 0m52.034s
> user 0m1.419s
> sys 0m0.433s
>
> # time systemctl restart opensips
> real    0m58.198s
> user    0m0.024s
> sys     0m0.055s
>
> # opensips -V
> version: opensips 3.4.4 (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: 036d02961
>
> --
>
> BR,
> Denys Pozniak
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://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/20240508/77073936/attachment-0001.html>

From eranl at kayhut.com  Wed May  8 12:07:08 2024
From: eranl at kayhut.com (Eran Leshem)
Date: Wed, 8 May 2024 15:07:08 +0300
Subject: [OpenSIPS-Users] How to answer a call with a wav file?
In-Reply-To: <CAKrJzCxTxH=nT2Q1TAzSz30WQtcBm6GdHuwri4WA55vAb-uo6g@mail.gmail.com>
References: <CANuw4TFb+2QX2sKuUvfNNbiTNjyPDr-pnic_S1DjtQMCkNoF_A@mail.gmail.com>
 <CAKrJzCxTxH=nT2Q1TAzSz30WQtcBm6GdHuwri4WA55vAb-uo6g@mail.gmail.com>
Message-ID: <CANuw4TGWmAXfEXqyovxk5EQpsdBDyzjDC0YXkLYG6Vn+wqo=Zw@mail.gmail.com>

Hi,

I tried adding the line that you suggested, but I still get an error
message.
The route that I wrote is:

```
route[play_audio] {
  rtpengine_offer("to-tag=$ft from-tag=$ft");
  append_to_reply("Content-Type: application/sdp\r\n");
  $var(body) = $(rb{re.subst,/(IP4.).*/\1$si/g});
  t_reply_with_body(183, "Session Progress", $var(body));
  rtpengine_manage();

  $var(play_duration) = 300;
  rtpengine_play_media("file=/path/to/music.wav to-tag=$ft", $var(
play_duration));
}
```

The error message that I'm getting is:

ERROR:rtpengine:rtpe_function_call: proxy replied with error: No
participant party specified
ERROR:rtpengine:rtpengine:rtpengine_playmedia_f: could not start media!

Any idea on what is wrong?

On Tue, May 7, 2024 at 4:15 AM Jehanzaib Younis <jehanzaib.kiani at gmail.com>
wrote:

> Hi Eran,
>
> Have you tried rtpengine_manage() before playing the media ?
>
>         rtpengine_manage();
>         rtpengine_play_media("file=ringback_tone_file.wav");
>         exit;
>
>
> Regards,
> Jehanzaib
>
>
> On Tue, May 7, 2024 at 2:10 AM Eran Leshem <eranl at kayhut.com> wrote:
>
>> Hi, I would like to create a special extension that will answer by
>> playing a wav file back to the caller.
>>
>> The call will be as such:
>> 1. The caller will call the special extension: "wav-call"
>> 2. Instead of someone answering his call, the calling person will hear
>> a sound (a song, a wav file), being played back to him.
>> 3. After that, the caller will hang-up.
>>
>> I have tried to do it in several ways, but failed.
>> I looked at the documentation and I have tried using:
>>
>> rtpengine_play_media("file=/path/to/ringback_tone_file.wav");
>>
>> but, did not succeed.
>> I keep getting: "Unknown call-ID"
>>
>> My machine:
>> - Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
>> - 16 GB memory,
>> - OpenSIPS version 3.4
>> - RTPEngine is installed.
>>
>> Any ideas?
>> - Thanks, Eran L.
>> _______________________________________________
>> 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/20240508/30bdaab4/attachment.html>

From bogdan at opensips.org  Wed May  8 12:15:32 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 8 May 2024 15:15:32 +0300
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200
 tls/ssl certs
In-Reply-To: <CA+x3AxoXfDkN3rVwXH3u5Rj7w8Nm6ULtwLb2=FKET=qOOuP9FQ@mail.gmail.com>
References: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
 <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>
 <CA+x3AxoXfDkN3rVwXH3u5Rj7w8Nm6ULtwLb2=FKET=qOOuP9FQ@mail.gmail.com>
Message-ID: <de9c24f9-8a4f-45f6-a534-55aea4dd1f0d@opensips.org>

Hi,

There is only one trap, ideally you should try to get several during the 
reload time.

Still, the trap you did shows opensips doing some logging (dumping to 
syslog) while reloading - could you check how intensive this logging is 
and eventually to try to disable it (increase the log level of opensips 
lower than INFO) to see if there is any impact?

Regards,

Bogdan-Andrei Iancu

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

On 08.05.2024 14:10, Denys Pozniak wrote:
> Hello!
>
> If possible, please check log:
> https://github.com/denyspozniak/opensips_tls_debug/blob/main/gdb_opensips_20240508_115956
>
>
> ср, 8 мая 2024 г. в 08:55, Bogdan-Andrei Iancu <bogdan at opensips.org>:
>
>     Hi Denys.
>
>     That is rather weird, 250 certificates in 1 min. I assume it is
>     not a DB issue (considering the db_text backend), so can you try
>     to do multiple sequential "opensips-cli -x trap" to try to
>     understand what is going on ?
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        https://www.opensips-solutions.com
>        https://www.siphub.com
>
>     On 02.05.2024 11:41, Denys Pozniak wrote:
>>     Hello!
>>
>>     There is a task to divide a single tls/ssl letsencrypt
>>     certificate for white labels into specific ones.
>>     I entered about ~250 certificates into db_text, but as it turned
>>     out, for OpenSIPS this is a rather complex operation to load them
>>     and takes about 1 minute and a heavy CPU load is noticeable.
>>
>>     I would appreciate any advice on how to avoid this.
>>
>>     # wc -l dbtext/tls_mgm
>>     253 dbtext/tls_mgm
>>
>>     # time opensips-cli -x mi tls_reload
>>     "OK"
>>     real 0m52.034s
>>     user 0m1.419s
>>     sys 0m0.433s
>>
>>     # time systemctl restart opensips
>>     real    0m58.198s
>>     user    0m0.024s
>>     sys     0m0.055s
>>
>>     # opensips -V
>>     version: opensips 3.4.4 (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: 036d02961
>>
>>     -- 
>>
>>     BR,
>>     Denys Pozniak
>>
>>
>>
>>     _______________________________________________
>>     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/20240508/fe3b6a9d/attachment.html>

From amel.guesmi at sofrecom.com  Wed May  8 14:53:17 2024
From: amel.guesmi at sofrecom.com (amel.guesmi at sofrecom.com)
Date: Wed, 8 May 2024 14:53:17 +0000
Subject: [OpenSIPS-Users] Tracer module integration with Opensips 3.4
In-Reply-To: <9aa3846765934357bfc70a8111dd2f8e@sofrecom.com>
References: <9aa3846765934357bfc70a8111dd2f8e@sofrecom.com>
Message-ID: <0f95840d3e6b4b39bb4b13c142340487@sofrecom.com>

Hello,

Any help please regarding my question ?

Thank  you

BR, Amel

De : GUESMI Amel SOFRECOM
Envoyé : lundi 29 avril 2024 10:57
À : OpenSIPS users mailling list <users at lists.opensips.org>
Cc : DL FT-FR Sbc TEAM <sbc.team at sofrecom.com>
Objet : Tracer module integration with Opensips 3.4

Hello Everyone,

I need your support to add tracer module in order to store incoming/outgoing SIP messages in database.
I already add some configs to my opensips.cfg file:

### Tracer ###
loadmodule "tracer.so"
modparam("tracer", "trace_on", 1)
modparam("tracer", "trace_local_ip", "opensips:5060")
modparam("tracer", "trace_id","[tid]uri=mysql://opensips:opensipsrw at ossdb/opensips;table=sip_trace;")
....
if ( is_method("INVITE")) {
                                  record_route();
                                  do_accounting("db|log", "cdr|missed", "acc");
                                  trace($var(trace_id), "d", "sip|xlog", $var(user));

                                  t_relay();
                                  exit;
                              }

The error in Opensips logs is:

ERROR:core:db_check_api: module db_mysql does not export db_use_table function
2024-04-25 09:29:10 Apr 25 10:29:10 [52] ERROR:tracer:get_db_struct: unable to bind database module
2024-04-25 09:29:10 Apr 25 10:29:10 [52] ERROR:tracer:parse_siptrace_id: Invalid parameters extracted!url <mysql://opensips:opensipsrw at ossdb/opensips>! table name <sip_trace>!
2024-04-25 09:29:10 Apr 25 10:29:10 [52] ERROR:tracer:parse_trace_id: failed to parse tracer uri []
2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:Traceback (last included file at the bottom):
2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL: 0. /etc/opensips/opensips.cfg
2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:53:19-20: Parameter <trace_id> not found in module <tracer> - can't set
2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", "trace_on", 1)
2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", "trace_local_ip", "opensips:5060")
2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", "trace_id","[tid]uri=mysql://opensips:opensipsrw at ossdb/opensips;table=sip_trace;")

I think that the module should store the messages in sip_trace table but I didn't understand how to configure properly the trace_id with mysql module.
Could you help me please ?


Thank you.
Best Regards,
Amel on behalf of my colleague Chaker

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

From eranl at kayhut.com  Wed May  8 17:27:16 2024
From: eranl at kayhut.com (Eran Leshem)
Date: Wed, 8 May 2024 20:27:16 +0300
Subject: [OpenSIPS-Users] The cause of 'max nr of branches exceeded'
Message-ID: <CANuw4TEK3nTesY+t3QE2WZJ_bzcEORJVGs00nig6nfwOd6v4xg@mail.gmail.com>

Hi,
After a few calls, I am getting in the log the following error message:
ERROR:core:append_branch: max nr of branches exceeded
ERROR:core:push_branch: failed to append a branch

What can I do to prevent this?

In opensips.cfg:
udp_workers=2
open_files_limit=600

In /etc/default/opensips:
S_MEMORY=3200
P_MEMORY=200

My machine:
- Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
- 16 GB memory,
- OpenSIPS version 3.4

Thanks,
Eran L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240508/29d40984/attachment.html>

From brett at nemeroff.com  Wed May  8 17:58:48 2024
From: brett at nemeroff.com (Brett Nemeroff)
Date: Wed, 8 May 2024 12:58:48 -0500
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200
 tls/ssl certs
In-Reply-To: <de9c24f9-8a4f-45f6-a534-55aea4dd1f0d@opensips.org>
References: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
 <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>
 <CA+x3AxoXfDkN3rVwXH3u5Rj7w8Nm6ULtwLb2=FKET=qOOuP9FQ@mail.gmail.com>
 <de9c24f9-8a4f-45f6-a534-55aea4dd1f0d@opensips.org>
Message-ID: <CAPwC5wyNDnvmXTE2F+7WdcSgzmPAtuw_uJu5ifYoygCHZQ=NiQ@mail.gmail.com>

Just offering my experience here. I have, without a doubt,
noticed intensive logging brings a highly performant server to its knees.

Disable ALL logging. Watch disk IO and confirm it's disabled. Try it again.
Just an easy thing to try.

-Brett


On Wed, May 8, 2024 at 7:17 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi,
>
> There is only one trap, ideally you should try to get several during the
> reload time.
>
> Still, the trap you did shows opensips doing some logging (dumping to
> syslog) while reloading - could you check how intensive this logging is and
> eventually to try to disable it (increase the log level of opensips lower
> than INFO) to see if there is any impact?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 08.05.2024 14:10, Denys Pozniak wrote:
>
> Hello!
>
> If possible, please check log:
>
> https://github.com/denyspozniak/opensips_tls_debug/blob/main/gdb_opensips_20240508_115956
>
>
> ср, 8 мая 2024 г. в 08:55, Bogdan-Andrei Iancu <bogdan at opensips.org>:
>
>> Hi Denys.
>>
>> That is rather weird, 250 certificates in 1 min. I assume it is not a DB
>> issue (considering the db_text backend), so can you try to do multiple
>> sequential "opensips-cli -x trap" to try to understand what is going on ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 02.05.2024 11:41, Denys Pozniak wrote:
>>
>> Hello!
>>
>> There is a task to divide a single tls/ssl letsencrypt certificate for
>> white labels into specific ones.
>> I entered about ~250 certificates into db_text, but as it turned out, for
>> OpenSIPS this is a rather complex operation to load them and takes about 1
>> minute and a heavy CPU load is noticeable.
>>
>> I would appreciate any advice on how to avoid this.
>>
>> # wc -l dbtext/tls_mgm
>> 253 dbtext/tls_mgm
>>
>> # time opensips-cli -x mi tls_reload
>> "OK"
>> real 0m52.034s
>> user 0m1.419s
>> sys 0m0.433s
>>
>> # time systemctl restart opensips
>> real    0m58.198s
>> user    0m0.024s
>> sys     0m0.055s
>>
>> # opensips -V
>> version: opensips 3.4.4 (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: 036d02961
>>
>> --
>>
>> BR,
>> Denys Pozniak
>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://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/20240508/80cf8824/attachment.html>

From bogdan at opensips.org  Thu May  9 16:45:52 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 9 May 2024 19:45:52 +0300
Subject: [OpenSIPS-Users] OpenSIPS 3.5.0 major release, beta version
Message-ID: <ca64308c-a97d-4421-8476-4e0f8ab5aa9b@opensips.org>

Hello there !!

It is that time of the year to do our iteration - one more year, one 
more evolution step, one more OpenSIPS major release.

So, we are all happy to announce the beta release of *OpenSIPS 3.5.0 
major version* - and this 3.5 version is all about IMS, about _AKA 
authentication_ support, about the _DIAMETER and HTTP/2 IMS interfaces_, 
about _IPSEC support_ and more. Besides IMS, the 3.5 comes with _Launch 
Darkly_ integration, with _Message Queue_ support, with advanced _SQL 
operations_ and many more.

But here is the shortest possible description 
<https://www.opensips.org/About/Version-Overview-3-5-0> of this release; 
and be aware that it's actually not so short as nothing is short about 
3.5 and IMS !

Please keep in mind that 3.5.0 is still a beta release, targeting mid 
July to become fully stable. So, we still have some testing ahead of us :)

Many thanks to our awesome community for contributing with ideas, code, 
patches, tests and reports!

Looking for downloading it? See the tarball 
<http://opensips.org/pub/opensips/3.5.0> or the GIT repo 
<https://github.com/OpenSIPS/opensips/tree/3.5>.

Enjoy it,

-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240509/891d67c1/attachment.html>

From denys.pozniak at gmail.com  Tue May 14 13:47:18 2024
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Tue, 14 May 2024 15:47:18 +0200
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200
 tls/ssl certs
In-Reply-To: <CAPwC5wyNDnvmXTE2F+7WdcSgzmPAtuw_uJu5ifYoygCHZQ=NiQ@mail.gmail.com>
References: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
 <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>
 <CA+x3AxoXfDkN3rVwXH3u5Rj7w8Nm6ULtwLb2=FKET=qOOuP9FQ@mail.gmail.com>
 <de9c24f9-8a4f-45f6-a534-55aea4dd1f0d@opensips.org>
 <CAPwC5wyNDnvmXTE2F+7WdcSgzmPAtuw_uJu5ifYoygCHZQ=NiQ@mail.gmail.com>
Message-ID: <CA+x3AxoSnbppn6Fg6X-j6XCS43aZLUjpiOG4=cmq=G5p1xaohw@mail.gmail.com>

Hello!

I disabled logging and added some resources to the virtual machine.
On a working OpenSIPS, I reloaded the tls several times and in parallel ran
a trap.
#opensips-cli -x mi tls_reload
#opensips-cli -x trap

If possible, please analyze it again, maybe you could find something
interesting:
https://github.com/denyspozniak/opensips_tls_debug/tree/main

Thanks in advance!



ср, 8 мая 2024 г. в 19:59, Brett Nemeroff <brett at nemeroff.com>:

> Just offering my experience here. I have, without a doubt,
> noticed intensive logging brings a highly performant server to its knees.
>
> Disable ALL logging. Watch disk IO and confirm it's disabled. Try it
> again. Just an easy thing to try.
>
> -Brett
>
>
> On Wed, May 8, 2024 at 7:17 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi,
>>
>> There is only one trap, ideally you should try to get several during the
>> reload time.
>>
>> Still, the trap you did shows opensips doing some logging (dumping to
>> syslog) while reloading - could you check how intensive this logging is and
>> eventually to try to disable it (increase the log level of opensips lower
>> than INFO) to see if there is any impact?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 08.05.2024 14:10, Denys Pozniak wrote:
>>
>> Hello!
>>
>> If possible, please check log:
>>
>> https://github.com/denyspozniak/opensips_tls_debug/blob/main/gdb_opensips_20240508_115956
>>
>>
>> ср, 8 мая 2024 г. в 08:55, Bogdan-Andrei Iancu <bogdan at opensips.org>:
>>
>>> Hi Denys.
>>>
>>> That is rather weird, 250 certificates in 1 min. I assume it is not a DB
>>> issue (considering the db_text backend), so can you try to do multiple
>>> sequential "opensips-cli -x trap" to try to understand what is going on ?
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>   https://www.opensips-solutions.com
>>>   https://www.siphub.com
>>>
>>> On 02.05.2024 11:41, Denys Pozniak wrote:
>>>
>>> Hello!
>>>
>>> There is a task to divide a single tls/ssl letsencrypt certificate for
>>> white labels into specific ones.
>>> I entered about ~250 certificates into db_text, but as it turned out,
>>> for OpenSIPS this is a rather complex operation to load them and takes
>>> about 1 minute and a heavy CPU load is noticeable.
>>>
>>> I would appreciate any advice on how to avoid this.
>>>
>>> # wc -l dbtext/tls_mgm
>>> 253 dbtext/tls_mgm
>>>
>>> # time opensips-cli -x mi tls_reload
>>> "OK"
>>> real 0m52.034s
>>> user 0m1.419s
>>> sys 0m0.433s
>>>
>>> # time systemctl restart opensips
>>> real    0m58.198s
>>> user    0m0.024s
>>> sys     0m0.055s
>>>
>>> # opensips -V
>>> version: opensips 3.4.4 (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: 036d02961
>>>
>>> --
>>>
>>> BR,
>>> Denys Pozniak
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://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
>>
>

-- 

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

From akogan at 5gfuture.com  Tue May 14 20:33:22 2024
From: akogan at 5gfuture.com (Alexander Kogan)
Date: Wed, 15 May 2024 00:33:22 +0400
Subject: [OpenSIPS-Users] call loop, dialog and topology_hiding.
Message-ID: <534270d6-2e3f-4556-a1fb-f566a05ad699@5gfuture.com>

Hello,

is it possible to return the call back to the same OpenSIPS instance 
when using topology hiding with Call-ID header encoding?

It doesn't work for me. The call flow is:

1. caller -> OpenSIPS, call_id_1 = 39e20b8211b311ef9f35a0369f28db67 at X.X.X.X
2. OpenSIPS -> the same OpenSIPS, call_id_2 = 
PNiupb663sWqpd38kW1sITWF4YSZ1cFgODEw1emUldnJfUgxHay0ycnEBUVpETGBnYnV.b1pc, 
encoded call_id of the first leg
3. OpenSIPS -> callee, call_id_3 = 
PNiupb663sWqpFAgoHBsIQ2V6IxM3MQ1YUh4EeCMNEhYvXzMmCXgzAiEOLS4dRDYkBSgiLyMNPxIrATE9djgKBS83Bh8gARIGKwUzGwVnMnU2Ig--, 
encoded call_id of the second leg

This scheme doesn't work for a subsequent requests from the first 
OpenSIPS to itself including ACK to the INVITE transaction. It doesn't 
work because OpenSIPS decodes call_id_2 when it receives the request and 
decoded call_id doesn't match with the call_id of appropriate dialog 
found by DID:

DBG:dialog:api_match_dialog: We found DID param in R-URI with value of 
f72.357c45e4
DBG:dialog:dlg_onroute: route param is 'f72.357c45e4' (len=12)
DBG:dialog:lookup_dlg: dialog id=1314178899 found on entry 639
DBG:core:parse_headers: flags=58
WARNING:dialog:dlg_onroute: tight matching failed for ACK with 
callid='39e20b8211b311ef9f35a0369f28db67 at X.X.X.X'/45, 
ftag='vQ5R9OFRXdslE8jhUV3bJRPFV8VLpAAq'/32, 
ttag='271887064-24388-26114'/21 and direction=0
WARNING:dialog:dlg_onroute: dialog identification elements are 
callid='PNiupb663sWqpd38kW1sITWF4YSZ1cFgODEw1emUldnJfUgxHay0ycnEBUVpETGBnYnV.b1pc'/73, 
caller tag='vQ5R9OFRXdslE8jhUV3bJRPFV8VLpAAq'/32, callee 
tag='271887064-24388-26114'/21
DBG:core:parse_headers: flags=200
DBG:core:grep_sock_info_ext: checking if host==us: 9==9 &&  [127.0.0.1] 
== [127.0.0.1]
DBG:core:grep_sock_info_ext: checking if port 5060 matches port 5060

Could you please explain, is it somehow possible to use call_id hiding 
with call loops?

-- 
Best regards,
Alexander Kogan,
Director of R&D
5g Future
http://5gfuture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240515/26a32b0c/attachment.html>

From denys.pozniak at gmail.com  Tue May 28 07:37:20 2024
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Tue, 28 May 2024 09:37:20 +0200
Subject: [OpenSIPS-Users] Manipulation with the received parameter in Via
	for force_rport()
Message-ID: <CA+x3AxqtWFmoVu+D-Ufq-gRQPTe8HOS0d=SbmocK1mfTao7Z7Q@mail.gmail.com>

Hello!

Is it possible to change where the received parameter is added to the Via
header using force_rport()?
I need to put it after the branch parameter, since this turned out to be
important for very ancient SIP terminals.

REGISTER sip:sip.local.net SIP/2.0
Via: SIP/2.0/UDP 192.168.1.216:5060
;branch=z9hG4bK59d0cba274f66fa62e82a5a7d383b461;rport

REGISTER sip:sip.local.net SIP/2.0
Via: SIP/2.0/UDP 185.99.99.99:5060;branch=z9hG4bK92e8.8d908052.0;cid=1
Via: SIP/2.0/UDP 192.168.1.216:5060;*received=185.44.44.44*
;branch=z9hG4bK59d0cba274f66fa62e82a5a7d383b461;rport=5060

Thanks in advance!


-- 

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

From Johan at democon.be  Wed May 29 07:54:49 2024
From: Johan at democon.be (Johan De Clercq)
Date: Wed, 29 May 2024 09:54:49 +0200
Subject: [OpenSIPS-Users] opensips not failing over on 500.
Message-ID: <CAEVWGm9e_N+xRPB8h=YcxacurK+nihB45p=EZSe1Dr6L3s293w@mail.gmail.com>

Hi,

I think that this is by design.
when you use load_balancer and you want to failover on receiving certain
cause codes, then you need to do that in failure_route, I believe.
Opensips will nto failover automatically to the next destination when
receiving 500.

Am I correct with my assumption ?

Br, Johan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240529/993c8f5a/attachment.html>

From inder.itpro at gmail.com  Wed May 29 14:16:21 2024
From: inder.itpro at gmail.com (inderjeet sharma)
Date: Wed, 29 May 2024 19:46:21 +0530
Subject: [OpenSIPS-Users] Webrtc LB Opensips 3.1
Message-ID: <CAOAEC9Ec9S2jpkkqkQbpFghAdF08m+8dwm=i4goJRydiwx19Ew@mail.gmail.com>

Hi Team,

I'm using OpenSIPS and RTPEngine for JSSIP/WebRTC, and it's working fine.
However, I plan to run the same setup in parallel and load balance the
traffic between these two deployments. Could you suggest a solution

                   [JSSIP Client]
                          / \ / \
[OpenSIPS + RTPEngine Deployment 1] [OpenSIPS + RTPEngine Deployment 2]
                          \ / \ /
                [Asterisk Server]


Thanks
Inderjeet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240529/0ea01476/attachment.html>

From Ben.Newlin at genesys.com  Wed May 29 14:30:14 2024
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Wed, 29 May 2024 14:30:14 +0000
Subject: [OpenSIPS-Users] opensips not failing over on 500.
In-Reply-To: <CAEVWGm9e_N+xRPB8h=YcxacurK+nihB45p=EZSe1Dr6L3s293w@mail.gmail.com>
References: <CAEVWGm9e_N+xRPB8h=YcxacurK+nihB45p=EZSe1Dr6L3s293w@mail.gmail.com>
Message-ID: <BN0PR10MB5208A56647EFFB46FC1FF49895F22@BN0PR10MB5208.namprd10.prod.outlook.com>

Yes, the default behavior of failure_route is to revert the received reply back upstream [1]. If failover is desired a new branch must be created by some action in the failure_route. I don’t use load_balancer but I believe for that module this would be the lb_next function [2].

[1] - https://www.opensips.org/Documentation/Script-Routes-3-5#toc3
[2] - https://opensips.org/docs/modules/3.5.x/load_balancer.html#func_lb_next

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Johan De Clercq <Johan at democon.be>
Date: Wednesday, May 29, 2024 at 3:56 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] opensips not failing over on 500.
 EXTERNAL EMAIL - Please use caution with links and attachments

________________________________
Hi,

I think that this is by design.
when you use load_balancer and you want to failover on receiving certain cause codes, then you need to do that in failure_route, I believe.  Opensips will nto failover automatically to the next destination when receiving 500.

Am I correct with my assumption ?

Br, Johan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240529/bfcef642/attachment.html>

From bogdan at opensips.org  Thu May 30 09:03:49 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 30 May 2024 12:03:49 +0300
Subject: [OpenSIPS-Users] The cause of 'max nr of branches exceeded'
In-Reply-To: <CANuw4TEK3nTesY+t3QE2WZJ_bzcEORJVGs00nig6nfwOd6v4xg@mail.gmail.com>
References: <CANuw4TEK3nTesY+t3QE2WZJ_bzcEORJVGs00nig6nfwOd6v4xg@mail.gmail.com>
Message-ID: <183b8581-c709-4971-96bc-a7fbf3f252a4@opensips.org>

Hi Eran,

The error you get means you reached the maximum number of branches per 
transactions. Branches are created during parallel or serial forking and 
there are max 12 configured in OpenSIPS.

So, check your script, maybe you have a run-away forking creating more 
than 12 branches.

Regards,

Bogdan-Andrei Iancu

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

On 08.05.2024 20:27, Eran Leshem wrote:
> Hi,
> After a few calls, I am getting in the log the following error message:
> ERROR:core:append_branch: max nr of branches exceeded
> ERROR:core:push_branch: failed to append a branch
>
> What can I do to prevent this?
>
> In opensips.cfg:
> udp_workers=2
> open_files_limit=600
>
> In /etc/default/opensips:
> S_MEMORY=3200
> P_MEMORY=200
>
> My machine:
> - Linux Mint 21.3 which is based on Ubuntu 22.04 LTS (Jammy Jellyfish),
> - 16 GB memory,
> - OpenSIPS version 3.4
>
> Thanks,
> Eran L.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Thu May 30 09:12:37 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 30 May 2024 12:12:37 +0300
Subject: [OpenSIPS-Users] Manipulation with the received parameter in
 Via for force_rport()
In-Reply-To: <CA+x3AxqtWFmoVu+D-Ufq-gRQPTe8HOS0d=SbmocK1mfTao7Z7Q@mail.gmail.com>
References: <CA+x3AxqtWFmoVu+D-Ufq-gRQPTe8HOS0d=SbmocK1mfTao7Z7Q@mail.gmail.com>
Message-ID: <7256ef84-d19f-46f5-81cd-29cede8bde9e@opensips.org>

Hi Denys,

Unfortunately this is not possible from script level - to pick the spot 
where the `received` will be inserted. Of course, there is all the time 
to options to put your fingers into the code :D .

Regards,

Bogdan-Andrei Iancu

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

On 28.05.2024 10:37, Denys Pozniak wrote:
> Hello!
>
> Is it possible to change where the received parameter is added to the 
> Via header using force_rport()?
> I need to put it after the branch parameter, since this turned out to 
> be important for very ancient SIP terminals.
>
> REGISTER sip:sip.local.net <http://sip.local.net> SIP/2.0
> Via: SIP/2.0/UDP 
> 192.168.1.216:5060;branch=z9hG4bK59d0cba274f66fa62e82a5a7d383b461;rport
>
> REGISTER sip:sip.local.net <http://sip.local.net> SIP/2.0
> Via: SIP/2.0/UDP 185.99.99.99:5060;branch=z9hG4bK92e8.8d908052.0;cid=1
> Via: SIP/2.0/UDP 192.168.1.216:5060 
> <http://192.168.1.216:5060>;*received=185.44.44.44*;branch=z9hG4bK59d0cba274f66fa62e82a5a7d383b461;rport=5060
>
> Thanks in advance!
>
>
> -- 
>
> 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/20240530/0d6a6049/attachment-0001.html>

From bogdan at opensips.org  Thu May 30 09:42:10 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 30 May 2024 12:42:10 +0300
Subject: [OpenSIPS-Users] OpenSIPS Summit 2024 - post facts
Message-ID: <d9e6e19e-a373-4b03-99fd-52be54e6dea8@opensips.org>

Hello all !!

I would like to thank you all for being part of the OpenSIPS Summit 2024 
in Valencia. It was an amazing set of speakers, sponsors and 
participants - I hope you all enjoyed the event, and even more, I hope 
you found it useful in terms of getting the updates and news from the 
VoIP and RTC words.

Now that the event is behind us, let me fill in here some post facts

  * the presentations and recordings were uploaded at attached to the
    schedule / linked to the web site
    <https://www.opensips.org/events/Summit-2024Valencia/#schedules>
  * the recordings are also available on the OpenSIPS YouTube channel
    <https://www.youtube.com/playlist?list=PLMMZA6ketvKqMJSM6XiaBzKRxualdj-gg>
  * photos from the event were uploaded on the OpenSIPS Summit 2024
    Album <https://photos.app.goo.gl/AA7PLMLmXvhSCEXr7>


Enjoy !

-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240530/33037e36/attachment.html>

From anmolp at cdot.in  Wed May  1 04:13:05 2024
From: anmolp at cdot.in (ANMOL PRAKASH)
Date: Wed, 01 May 2024 04:13:05 -0000
Subject: [OpenSIPS-Users] route handling of http protocol in opensips
Message-ID: <20240501040846.M90651@cdot.in>


Hi all,

Is there any module in opensips inline with xHTTP in kamailio.

In kamailio, xHTTP module offers a generic way of handling the HTTP protocol, by calling event_route[xhttp:request] in your config.

In opensips, httpd module is there to enable http server on opensips but I am looking for handling of HTTP protocol in opensips.


Any help will be highly appreciated.

Thanks & Regards

Anmol Prakash (5273)
C-DOT DELHI
INDIA

-------------------------------------------------------------------------------
::Disclaimer::
-------------------------------------------------------------------------------

The contents of this email and any attachment(s) are confidential and intended
for the named recipient(s) only. It shall not attach any liability on C-DOT.
Any views or opinions presented in this email are solely those of the author
and  may  not  necessarily  reflect  the  opinions  of  C-DOT.  Any  form of
reproduction, dissemination, copying, disclosure, modification, distribution
and / or publication of this message without the prior written consent of the
author of this e-mail is strictly prohibited. If you have received this email
in error please delete it and notify the sender immediately.

-------------------------------------------------------------------------------



From heuselr at gmail.com  Sun May 12 21:06:31 2024
From: heuselr at gmail.com (Ruben Heusel)
Date: Sun, 12 May 2024 21:06:31 -0000
Subject: [OpenSIPS-Users] Passing of PN params from Linphone to opensips
Message-ID: <CA+weG5XBp0b5GrTCe1JB0-Bww25vhTbUkoyZt7iLYuJxSky75g@mail.gmail.com>

Hey all,

i have an opensips running and followed
https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/
to enable Push Notification support.
I can connect to the opensips server with linphone, but the PN params i
pass are not recognized.

DBG:core:parse_params: Parsing params
for:[message-expires=2419200;+pn-provider="";+pn-prid="";+pn-param="";+sip.instance="<urn:uuid:ab1e22b7-3e88-00d8-a1b1-6812bf894285>";+org.linphone.specs="lime"]
DBG:core:pn_inspect_request: Contact URI has no PN params

I have no idea how to troubleshoot this and would appreciate any help.

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

From ksrigo at gmail.com  Tue May 21 08:48:54 2024
From: ksrigo at gmail.com (Srigo Kanapathipillai)
Date: Tue, 21 May 2024 10:48:54 +0200
Subject: [OpenSIPS-Users] Issue with stir and shaken crl_list
In-Reply-To: <34CF2799-B0A9-423E-9AFC-3034B6519B92@free.fr>
References: <CA+fRVSUKhhNAxzaCb_fuJfkrH6of-uwSoy84R11G40e2nKrQ8A@mail.gmail.com>
 <a49ec1ef-6b46-e812-a1ef-1f537296c8b7@opensips.org>
 <CA+fRVSVqVpJ1rCU1nEjpY_EfYLy6oqbfin0yUdpXL5p=BP4mhg@mail.gmail.com>
 <CA+fRVSVjstzd-GF+mwhx24m5E8W2NzrQf7mAWuvFoqGPL4C6sw@mail.gmail.com>
 <cdcdf5d1-1ea3-1824-b523-c4fcad261ab8@opensips.org>
 <657BF0AB-6533-4F70-A6D7-67A004437B6C@free.fr>
 <6B3CB7FE-F20C-431F-A14B-20838691A0FA@free.fr>
 <93268186-cfc5-090c-0b79-85311cff4b25@opensips.org>
 <34CF2799-B0A9-423E-9AFC-3034B6519B92@free.fr>
Message-ID: <CAAiAxuyGBmW3vO5uUXL=gQS=wqzvE2TTj6mn2yAVbk7CCMsyEA@mail.gmail.com>

Hi,

I'm currently working on the integration of MAN (French Stir/Shaken) on our
Opensips. I'm facing the same issue with Opensips
"stir_shaken:verify_callback: certificate validation failed: unable to get
certificate CRL" when calling stir_shaken_verify() function.

This is how I'm loading my CRL and CA:

modparam("stir_shaken", "crl_dir",
"/etc/opensips/stir_shaken_certificates/all_certifs/")
modparam("stir_shaken", "ca_dir",
"/etc/opensips/stir_shaken_certificates/all_certifs/")

and my contents directory:

[srigo at lab:/etc/opensips/stir_shaken_certificates/all_certifs]# ls -l
total 80
lrwxrwxrwx 1 opensips opensips    12 May 20 20:48 10f93d74.0 -> bpco_pa2.pem
lrwxrwxrwx 1 opensips opensips    12 May 20 20:48 155d6a90.0 -> bpco_pa1.pem
lrwxrwxrwx 1 opensips opensips    22 May 20 20:48 155d6a90.r0 ->
bpco_crl_operateur.pem
lrwxrwxrwx 1 opensips opensips    12 May 20 20:48 1df87289.0 -> bpco_ca1.pem
lrwxrwxrwx 1 opensips opensips     7 May 20 20:48 6c2f9df7.0 -> ipd.pem
lrwxrwxrwx 1 opensips opensips    11 May 20 20:48 b519955b.0 -> bpco_r1.pem
lrwxrwxrwx 1 opensips opensips    15 May 20 20:48 b519955b.r0 ->
bpco_crl_ca.pem
-rw-rw-r-- 1 opensips opensips  1180 May 20 19:24 bpco_ca1.pem
-rw-rw-r-- 1 opensips opensips  1180 May 20 20:23 bpco_ca2.pem
-rw-rw-r-- 1 opensips opensips   552 May 20 19:24 bpco_crl_ca.pem
-rw-rw-r-- 1 opensips opensips 87608 May 20 19:25 bpco_crl_operateur.pem
-rw-rw-r-- 1 opensips opensips  1135 May 20 19:23 bpco_pa1.pem
-rw-rw-r-- 1 opensips opensips  1135 May 20 20:22 bpco_pa2.pem
-rw-rw-r-- 1 opensips opensips   810 May 20 19:24 bpco_r1.pem
lrwxrwxrwx 1 opensips opensips    12 May 20 20:48 cbdd0bbc.0 -> bpco_ca2.pem
-rw-rw-r-- 1 opensips opensips  1281 May 20 20:48 ipd.pem

I have tried with crl_list and ca_list by concatening my CAs and my CRLs
but getting same errors.

If anyone faced the same issue and solved it or an idea how to solve it.
Please share it.

Thanks
Srigo

Le mar. 1 août 2023 à 16:08, Alain Bieuzent <alain.bieuzent at free.fr> a
écrit :

> Thaks Razvan, it's done
>
> Le 01/08/2023 15:35, « Users au nom de Răzvan Crainea » <
> users-bounces at lists.opensips.org <mailto:users-bounces at lists.opensips.org>
> au nom de razvan at opensips.org <mailto:razvan at opensips.org>> a écrit :
>
>
> Hi, Alain!
>
>
> You are actually right, it looks like the crl_list and ca_dir cannot be
> dynamic :(. Could you please open a feature request for this, so we can
> keep them right, perhaps change them to a tls_mgm domain?
>
>
> Best regards,
>
>
> Răzvan Crainea
> OpenSIPS Core Developer / SIPhub CTO
> http://www.opensips-solutions.com <http://www.opensips-solutions.com> /
> https://www.siphub.com <https://www.siphub.com>
>
>
> On 7/28/23 16:45, Alain Bieuzent wrote:
> > sorry I wrote nonsense (again...)
> > In the French implementation of STIR/SHAKEN we must download certificate
> updates every day (only for crl_list).
> > In stir_shaken module documentation , there is no explanation how to put
> crl_list in db.
> >
> > Regards
> >
> >
> > Le 28/07/2023 15:39, « Users au nom de Alain Bieuzent » <
> users-bounces at lists.opensips.org <mailto:users-bounces at lists.opensips.org>
> <mailto:users-bounces at lists.opensips.org <mailto:
> users-bounces at lists.opensips.org>> au nom de alain.bieuzent at free.fr
> <mailto:alain.bieuzent at free.fr> <mailto:alain.bieuzent at free.fr <mailto:
> alain.bieuzent at free.fr>>> a écrit :
> >
> >
> > Hi Razvan,
> >
> >
> > I work on the same project as Mickael and we don't understand how the
> tls_mgm can help us in this case.
> > In the French implementation of STIR/SHAKEN we must download certificate
> updates every day (ca_list and crl_list).
> > How can these updates be considered in real time?
> >
> >
> > Regards
> >
> >
> > Le 27/07/2023 12:38, « Users au nom de Răzvan Crainea » <
> users-bounces at lists.opensips.org <mailto:users-bounces at lists.opensips.org>
> <mailto:users-bounces at lists.opensips.org <mailto:
> users-bounces at lists.opensips.org>> <mailto:
> users-bounces at lists.opensips.org <mailto:users-bounces at lists.opensips.org>
> <mailto:users-bounces at lists.opensips.org <mailto:
> users-bounces at lists.opensips.org>>> au nom de razvan at opensips.org <mailto:
> razvan at opensips.org> <mailto:razvan at opensips.org <mailto:
> razvan at opensips.org>> <mailto:razvan at opensips.org <mailto:
> razvan at opensips.org> <mailto:razvan at opensips.org <mailto:
> razvan at opensips.org>>>> a écrit :
> >
> >
> >
> >
> > Hi, Mickael!
> >
> >
> >
> >
> > The only way is to store certificates in database and reload the tls_mgm
> > module (using tls_reload).
> >
> >
> >
> >
> > Best regards,
> >
> >
> >
> >
> > Răzvan Crainea
> > OpenSIPS Core Developer / SIPhub CTO
> > http://www.opensips-solutions.com <http://www.opensips-solutions.com> <
> http://www.opensips-solutions.com> <http://www.opensips-solutions.com&gt;>
> <http://www.opensips-solutions.com> <http://www.opensips-solutions.com&gt;>
> <http://www.opensips-solutions.com&gt;> <http://www.opensips-solutions.com&amp;gt;&gt;>
> / https://www.siphub.com <https://www.siphub.com> <https://www.siphub.com>
> <https://www.siphub.com&gt;> <https://www.siphub.com> <
> https://www.siphub.com&gt;> <https://www.siphub.com&gt;> <
> https://www.siphub.com&amp;gt;&gt;>
> >
> >
> >
> >
> > On 7/26/23 16:38, Mickael Hubert wrote:
> >> Hi Razvan,
> >> another question about crl_list, when crl list changed, what is the best
> >> way to reload this list in OpenSIPS memory ? restart it ? or another
> way ?
> >> I know the crl_list can change each day, so if I have to restart
> >> opensips each day, it's not very practical.
> >>
> >> thanks in advance
> >>
> >> Le mar. 25 juil. 2023 à 14:47, Mickael Hubert <mickael at winlux.fr
> <mailto:mickael at winlux.fr> <mailto:mickael at winlux.fr <mailto:
> mickael at winlux.fr>> <mailto:mickael at winlux.fr <mailto:mickael at winlux.fr>
> <mailto:mickael at winlux.fr <mailto:mickael at winlux.fr>>>
> >> <mailto:mickael at winlux.fr <mailto:mickael at winlux.fr> <mailto:
> mickael at winlux.fr <mailto:mickael at winlux.fr>> <mailto:mickael at winlux.fr
> <mailto:mickael at winlux.fr> <mailto:mickael at winlux.fr <mailto:
> mickael at winlux.fr>>>>> a écrit :
> >>
> >> Hi Razvan,
> >> Thanks a lot.
> >> I loaded the CRL for CA and certs and opensips start correctly ;)
> >>
> >> Have a good day !
> >>
> >> Le lun. 24 juil. 2023 à 16:07, Răzvan Crainea <razvan at opensips.org
> <mailto:razvan at opensips.org> <mailto:razvan at opensips.org <mailto:
> razvan at opensips.org>> <mailto:razvan at opensips.org <mailto:
> razvan at opensips.org> <mailto:razvan at opensips.org <mailto:
> razvan at opensips.org>>>
> >> <mailto:razvan at opensips.org <mailto:razvan at opensips.org> <mailto:
> razvan at opensips.org <mailto:razvan at opensips.org>> <mailto:
> razvan at opensips.org <mailto:razvan at opensips.org> <mailto:
> razvan at opensips.org <mailto:razvan at opensips.org>>>>> a écrit :
> >>
> >> Hi, Mickael!
> >>
> >> I don't have much experience with this, but a first search would
> >> point
> >> to this [1] answer, which seems reasonable to me: you need to
> >> provide
> >> the CRL of the entire path, not only of your intermediate cert.
> >> Did you
> >> try that?
> >>
> >> [1] https://stackoverflow.com/a/47398918 <
> https://stackoverflow.com/a/47398918> <
> https://stackoverflow.com/a/47398918> <
> https://stackoverflow.com/a/47398918&gt;> <
> https://stackoverflow.com/a/47398918> <
> https://stackoverflow.com/a/47398918&gt;> <
> https://stackoverflow.com/a/47398918&gt;> <
> https://stackoverflow.com/a/47398918&amp;gt;&gt;>
> >> <https://stackoverflow.com/a/47398918> <
> https://stackoverflow.com/a/47398918&gt;> <
> https://stackoverflow.com/a/47398918&gt;> <
> https://stackoverflow.com/a/47398918&amp;gt;&gt;> <
> https://stackoverflow.com/a/47398918&gt;> <
> https://stackoverflow.com/a/47398918&amp;gt;&gt;> <
> https://stackoverflow.com/a/47398918&amp;gt;&gt;> <
> https://stackoverflow.com/a/47398918&amp;amp;gt;&amp;gt;&gt;>
> >>
> >> Best regards,
> >>
> >> Răzvan Crainea
> >> OpenSIPS Core Developer
> >> http://www.opensips-solutions.com <http://www.opensips-solutions.com> <
> http://www.opensips-solutions.com> <http://www.opensips-solutions.com&gt;>
> <http://www.opensips-solutions.com> <http://www.opensips-solutions.com&gt;>
> <http://www.opensips-solutions.com&gt;> <http://www.opensips-solutions.com
> &amp;gt;&gt;>
> >> <http://www.opensips-solutions.com> <http://www.opensips-solutions.com&gt;>
> <http://www.opensips-solutions.com&gt;> <http://www.opensips-solutions.com&amp;gt;&gt;>
> <http://www.opensips-solutions.com&gt;> <http://www.opensips-solutions.com&amp;gt;&gt;>
> <http://www.opensips-solutions.com&amp;gt;&gt;> <
> http://www.opensips-solutions.com&amp;amp;gt;&amp;gt;&gt;>
> >>
> >> On 7/19/23 15:47, Mickael Hubert wrote:
> >>> Hi all,
> >>> I'm working on stir and shaken, and I want to include all
> >> revoked
> >>> certificates.
> >>> I my list in DER format, I use this command to transform it
> >> to PEM format:
> >>> openssl crl -in man_crl.der -inform DER -outform PEM -out crl.pem
> >>>
> >>> there is no erreur, I can read pem format (crl.pem):
> >>> -----BEGIN X509 CRL-----
> >>> ....
> >>> -----END X509 CRL-----
> >>>
> >>> I configured opensips with this:
> >>> modparam("stir_shaken", "crl_list",
> >> "/etc/opensips/stir-shaken-ca/crl.pem")
> >>>
> >>> but I have an error:
> >>> ul 19 12:39:07 [12] INFO:stir_shaken:verify_callback:
> >> certificate
> >>> validation failed: unable to get certificate CRL
> >>> Jul 19 12:39:07 [12] INFO:stir_shaken:w_stir_verify: Invalid
> >> certificate
> >>>
> >>> Can you tell me, what is exactly the correct format please ?
> >>>
> >>> Thanks in advance !
> >>> ++
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> 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> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;>
> >> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;amp;gt;&amp;gt;&gt
> ;>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> 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> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;>
> >> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;amp;gt;&amp;gt;&gt
> ;>
> >>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> 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> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;>
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>> <mailto:
> Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> 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> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&amp;gt;&gt;>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org <mailto:Users at lists.opensips.org> <mailto:
> 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> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users> <
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;>
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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>
>
>
>
>
>
> _______________________________________________
> 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/20240521/37362438/attachment-0001.html>

From yxrmail at 163.com  Mon May 27 09:18:10 2024
From: yxrmail at 163.com (suifeng)
Date: Mon, 27 May 2024 17:18:10 +0800 (CST)
Subject: [OpenSIPS-Users] opensips nat question
Message-ID: <68924de6.a1c1.18fb957ce58.Coremail.yxrmail@163.com>

HI,I has an NAT question;
img one:
img two:  Use fix_nated_sdp(10) processing：
opensips version OpenSIPS (3.2.17 (x86_64/linux))
opensips.cfg  part context:
 
route{
       if (nat_uac_test(23)) {
            if (is_method("REGISTER")) {
                setbflag("NAT");
                fix_nated_register();  
                xlog("request nat: $fd, rd: $rd, ru: $ru");
                xlog("request -1................");
            }
            if (is_method("INVITE")){
                xlog("request invite: $fd, rd: $rd, ru: $ru");
                fix_nated_contact();
                add_rr_param(";nat=yes"); 
                xlog("request -2................");
            }
        }


        if (is_method("INVITE") && has_body("application/sdp")) {
                xlog("request 13-1................si:[$si],cs:[$cs],uri:[uri]");
                fix_nated_sdp(10);
        }
}



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240527/bdabf4e1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 企业微信截图_37451ff5-4b77-45a5-89c0-1c0759c23e62.png
Type: image/png
Size: 374682 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20240527/bdabf4e1/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 企业微信截图_6a497ec5-96b6-46d8-95f2-dc038a3182fd.png
Type: image/png
Size: 413601 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20240527/bdabf4e1/attachment-0003.png>

From spanda at 3clogic.com  Mon May 27 09:46:19 2024
From: spanda at 3clogic.com (Sasmita Panda)
Date: Mon, 27 May 2024 15:16:19 +0530
Subject: [OpenSIPS-Users] utimer_ticker warning in opensips 3.2
In-Reply-To: <d3ed4465-f669-4517-a4c0-32347ea696da@opensips.org>
References: <CALf-Q442AqxhLDxKt6_psUWUzcC1aGfZ9CrHvYXH_BU5GFGL2w@mail.gmail.com>
 <CALf-Q45dJ=hVdJPxsB7dU1PhER4VYBnHSU+3Jn9RwrvnZ1a=Hg@mail.gmail.com>
 <CALf-Q45xVfjagrctOVtAqEkEhPzeVNWK9Zj7Kfh4_Xow1QjOUQ@mail.gmail.com>
 <2e986980-6548-4cd8-b1e5-cbbc65f60fe3@opensips.org>
 <CALf-Q46ceCOvwVf8gNKcdbkAaD99+k-rESkdGAoSrCno+jMf2w@mail.gmail.com>
 <d3ed4465-f669-4517-a4c0-32347ea696da@opensips.org>
Message-ID: <CALf-Q46uCnqeCpXAcbkhwN3vR1Ztwyv8dnMy2H=OU1+2-YeiPA@mail.gmail.com>

Hi ,

I am just facing the same issue again .

/usr/local/sbin/opensips[3443]: CRITICAL:core:fm_free: freeing already
freed shm pointer (0x7f3a59ddb4a0), first free: (null): (null)(0) -
aborting!

whenever I am starting opensips this is the last line I am getting in the
logs and it wont listen on the specified port .


As earlier suggested I was trying to run a trap with opensips-cli , but I
am facing an issue with that . It says the trap module is not loaded .
How do I load the trap module of opesnips-cli specifically ?

Please help . This is a kind of blocker for me .





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


On Thu, Mar 21, 2024 at 10:01 PM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> IF
>
> (a) it crashes, try to get a backtrace
>
> (b) it block on starting, try to do a "trap" via opensips-cli
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 21.03.2024 08:24, Sasmita Panda wrote:
>
> Sometimes it crashes and sometimes while starting I get the warings of the
> timer .  Same config  shows different issues .
>
>
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Wed, Mar 20, 2024 at 6:45 PM Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi,
>>
>> How the two reports fit together here ? there are completely separate
>> experiences on different runs?? or if you start opensips first you get the
>> warnings and later it crashes ??
>> For the crash part, I see a core file was generated - could you extract
>> the backtrace and post here ? (see
>> https://opensips.org/Documentation/TroubleShooting-Crash)
>>
>> Regards
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 11.03.2024 15:04, Sasmita Panda wrote:
>>
>> Any update on this ?
>>
>>
>> *Thanks & Regards*
>> *Sasmita Panda*
>> *Senior Network Testing and Software Engineer*
>> *3CLogic , ph:07827611765*
>>
>>
>> On Mon, Mar 11, 2024 at 12:03 PM Sasmita Panda <spanda at 3clogic.com>
>> wrote:
>>
>>> With the same server configuration and opensips version I am getting
>>> below error as well .
>>>
>>> CRITICAL:core:fm_free: freeing already freed shm pointer
>>> (0x7fc110e0b408), first free: (null): (null)(0) - aborting!
>>>
>>>  /usr/local/sbin/opensips[215171]: INFO:core:handle_sigs: child process
>>> 215185 exited by a signal 6
>>>  /usr/local/sbin/opensips[215171]: INFO:core:handle_sigs: core was
>>> generated
>>>  /usr/local/sbin/opensips[215171]: INFO:core:handle_sigs: terminating
>>> due to SIGCHLD
>>>  /usr/local/sbin/opensips[215172]: Memory status (pkg):
>>>  /usr/local/sbin/opensips[215172]: fm_status (0x7fc2907ff010):
>>>  /usr/local/sbin/opensips[215174]: INFO:core:sig_usr: signal 15 received
>>>  /usr/local/sbin/opensips[215172]: heap size= 33554432
>>>  /usr/local/sbin/opensips[215174]: Memory status (pkg):
>>>  /usr/local/sbin/opensips[215172]: used= 3710048, used+overhead=3801344,
>>> free=29844384
>>>  /usr/local/sbin/opensips[215174]: fm_status (0x7fc2907ff010):
>>>  /usr/local/sbin/opensips[215172]: max used (+overhead)= 3801344
>>>  /usr/local/sbin/opensips[215174]: heap size= 33554432
>>>  /usr/local/sbin/opensips[215172]: dumping free list:
>>>  /usr/local/sbin/opensips[215174]: used= 229752, used+overhead=318936,
>>> free=33324680
>>>  /usr/local/sbin/opensips[215172]: hash =   1 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:         8 -         8 (first
>>> 8)
>>>  /usr/local/sbin/opensips[215174]: max used (+overhead)= 385792
>>>  /usr/local/sbin/opensips[215174]: dumping free list:
>>>  /usr/local/sbin/opensips[215172]: hash =  18 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:       144 -       144 (first
>>> 144)
>>>  /usr/local/sbin/opensips[215174]: hash =   7 fragments no.:   139,
>>> unused:     0#012#011#011 bucket size:        56 -        56 (first
>>>  56)
>>>  /usr/local/sbin/opensips[215172]: hash = 2059 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:  16777216 -  33554432 (first
>>>  29752936)
>>>  /usr/local/sbin/opensips[215174]: hash =  13 fragments no.:    37,
>>> unused:     0#012#011#011 bucket size:       104 -       104 (first
>>> 104)
>>>  /usr/local/sbin/opensips[215172]: TOTAL:      3 free fragments =
>>> 29753088 free bytes
>>>  /usr/local/sbin/opensips[215172]: TOTAL: 48 overhead
>>>  /usr/local/sbin/opensips[215174]: hash =  16 fragments no.:    61,
>>> unused:     0#012#011#011 bucket size:       128 -       128 (first
>>> 128)
>>>  /usr/local/sbin/opensips[215172]: -----------------------------
>>>  /usr/local/sbin/opensips[215174]: hash =  31 fragments no.:   152,
>>> unused:     0#012#011#011 bucket size:       248 -       248 (first
>>> 248)
>>>  /usr/local/sbin/opensips[215174]: hash =  68 fragments no.:    16,
>>> unused:     0#012#011#011 bucket size:       544 -       544 (first
>>> 544)
>>>  /usr/local/sbin/opensips[215174]: hash = 105 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:       840 -       840 (first
>>> 840)
>>>  /usr/local/sbin/opensips[215174]: hash = 2059 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:  16777216 -  33554432 (first
>>>  33168816)
>>>  /usr/local/sbin/opensips[215174]: TOTAL:    407 free fragments =
>>> 33235496 free bytes
>>>  /usr/local/sbin/opensips[215174]: TOTAL: 48 overhead
>>>  /usr/local/sbin/opensips[215174]: -----------------------------
>>>  /usr/local/sbin/opensips[215176]: Memory status (pkg):
>>>  /usr/local/sbin/opensips[215176]: fm_status (0x7fc2907ff010):
>>>  /usr/local/sbin/opensips[215176]: heap size= 33554432
>>>  /usr/local/sbin/opensips[215176]: used= 3705480, used+overhead=3796584,
>>> free=29848952
>>>  /usr/local/sbin/opensips[215176]: max used (+overhead)= 3798064
>>>  /usr/local/sbin/opensips[215176]: dumping free list:
>>>  /usr/local/sbin/opensips[215176]: hash =   2 fragments no.:     2,
>>> unused:     0#012#011#011 bucket size:        16 -        16 (first
>>>  16)
>>>  /usr/local/sbin/opensips[215176]: hash =   3 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:        24 -        24 (first
>>>  24)
>>>  /usr/local/sbin/opensips[215176]: hash =  16 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:       128 -       128 (first
>>> 128)
>>>  /usr/local/sbin/opensips[215175]: Memory status (pkg):
>>>  /usr/local/sbin/opensips[215175]: fm_status (0x7fc2907ff010):
>>>  /usr/local/sbin/opensips[215175]: heap size= 33554432
>>>  /usr/local/sbin/opensips[215176]: hash = 2059 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:  16777216 -  33554432 (first
>>>  29757664)
>>>  /usr/local/sbin/opensips[215175]: used= 3705480, used+overhead=3796584,
>>> free=29848952
>>>  /usr/local/sbin/opensips[215176]: TOTAL:      5 free fragments =
>>> 29757848 free bytes
>>>  /usr/local/sbin/opensips[215175]: max used (+overhead)= 3798064
>>>  /usr/local/sbin/opensips[215176]: TOTAL: 48 overhead
>>>  /usr/local/sbin/opensips[215176]: -----------------------------
>>>  /usr/local/sbin/opensips[215175]: dumping free list:
>>>  /usr/local/sbin/opensips[215175]: hash =   2 fragments no.:     2,
>>> unused:     0#012#011#011 bucket size:        16 -        16 (first
>>>  16)
>>>  /usr/local/sbin/opensips[215175]: hash =   3 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:        24 -        24 (first
>>>  24)
>>>  /usr/local/sbin/opensips[215175]: hash =  16 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:       128 -       128 (first
>>> 128)
>>>  /usr/local/sbin/opensips[215175]: hash = 2059 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:  16777216 -  33554432 (first
>>>  29757664)
>>>  /usr/local/sbin/opensips[215175]: TOTAL:      5 free fragments =
>>> 29757848 free bytes
>>>  /usr/local/sbin/opensips[215175]: TOTAL: 48 overhead
>>>  /usr/local/sbin/opensips[215175]: -----------------------------
>>>  /usr/local/sbin/opensips[215171]: INFO:core:shutdown_opensips: process
>>> 3(215174) [timer] terminated, still waiting for 13 more
>>>  /usr/local/sbin/opensips[215171]: INFO:core:shutdown_opensips: process
>>> 4(215175) [SIP receiver udp:192.168.33.171:5060] terminated, still
>>> waiting for 12 more
>>>  /usr/local/sbin/opensips[215171]: INFO:core:shutdown_opensips: process
>>> 5(215176) [SIP receiver udp:192.168.33.171:5060] terminated, still
>>> waiting for 11 more
>>>  /usr/local/sbin/opensips[215171]: INFO:core:shutdown_opensips: process
>>> 1(215172) [MI FIFO] terminated, still waiting for 10 more
>>>  /usr/local/sbin/opensips[215173]: INFO:core:sig_usr: signal 15 received
>>>  /usr/local/sbin/opensips[215173]: Memory status (pkg):
>>>  /usr/local/sbin/opensips[215173]: fm_status (0x7fc2907ff010):
>>>  /usr/local/sbin/opensips[215173]: heap size= 33554432
>>>  /usr/local/sbin/opensips[215173]: used= 229752, used+overhead=318936,
>>> free=33324680
>>>  /usr/local/sbin/opensips[215173]: max used (+overhead)= 385792
>>>  /usr/local/sbin/opensips[215173]: dumping free list:
>>>  /usr/local/sbin/opensips[215173]: hash =   7 fragments no.:   139,
>>> unused:     0#012#011#011 bucket size:        56 -        56 (first
>>>  56)
>>>  /usr/local/sbin/opensips[215173]: hash =  13 fragments no.:    37,
>>> unused:     0#012#011#011 bucket size:       104 -       104 (first
>>> 104)
>>>  /usr/local/sbin/opensips[215173]: hash =  16 fragments no.:    61,
>>> unused:     0#012#011#011 bucket size:       128 -       128 (first
>>> 128)
>>>  /usr/local/sbin/opensips[215173]: hash =  31 fragments no.:   152,
>>> unused:     0#012#011#011 bucket size:       248 -       248 (first
>>> 248)
>>>  /usr/local/sbin/opensips[215173]: hash =  68 fragments no.:    16,
>>> unused:     0#012#011#011 bucket size:       544 -       544 (first
>>> 544)
>>>  /usr/local/sbin/opensips[215173]: hash = 105 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:       840 -       840 (first
>>> 840)
>>>  /usr/local/sbin/opensips[215173]: hash = 2059 fragments no.:     1,
>>> unused:     0#012#011#011 bucket size:  16777216 -  33554432 (first
>>>  33168816)
>>>  /usr/local/sbin/opensips[215173]: TOTAL:    407 free fragments =
>>> 33235496 free bytes
>>>  /usr/local/sbin/opensips[215173]: TOTAL: 48 overhead
>>>  /usr/local/sbin/opensips[215173]: -----------------------------
>>>  /usr/local/sbin/opensips[215171]: INFO:core:shutdown_opensips: process
>>> 2(215173) [time_keeper] terminated, still waiting for 9 more
>>>  /usr/local/sbin/opensips[215171]: INFO:core:cleanup: cleanup
>>>  /usr/local/sbin/opensips[215171]: CRITICAL:core:sig_alarm_abort: BUG -
>>> shutdown timeout triggered, dying...
>>>
>>> *Why is the service crashing ? *
>>>
>>> *Thanks & Regards*
>>> *Sasmita Panda*
>>> *Senior Network Testing and Software Engineer*
>>> *3CLogic , ph:07827611765*
>>>
>>>
>>> On Mon, Mar 11, 2024 at 11:52 AM Sasmita Panda <spanda at 3clogic.com>
>>> wrote:
>>>
>>>> Hi All ,
>>>>
>>>> Mar 11 05:57:02 ip-192-168-33-171 /usr/local/sbin/opensips[213843]:
>>>> INFO:proto_ws:mod_init: initializing WebSocket protocol
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 100
>>>> ms ago (now 290 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200
>>>> ms ago (now 390 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300
>>>> ms ago (now 490 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400
>>>> ms ago (now 590 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500
>>>> ms ago (now 690 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600
>>>> ms ago (now 790 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700
>>>> ms ago (now 890 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800
>>>> ms ago (now 990 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900
>>>> ms ago (now 1090 ms), delaying execution
>>>> Mar 11 05:57:03 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1000
>>>> ms ago (now 1190 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1100
>>>> ms ago (now 1290 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1200
>>>> ms ago (now 1390 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1300
>>>> ms ago (now 1490 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1400
>>>> ms ago (now 1590 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1500
>>>> ms ago (now 1690 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1600
>>>> ms ago (now 1790 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1700
>>>> ms ago (now 1890 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1790
>>>> ms ago (now 1980 ms), delaying execution
>>>> Mar 11 05:57:04 ip-192-168-33-171 /usr/local/sbin/opensips[213846]:
>>>> WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 990 ms
>>>> ago (now 1980 ms), delaying execution
>>>>
>>>> *What is this warning for? Whenever I am starting my openisps service
>>>> this warning comes . Although the service seems like it's running but it's
>>>> not listening on the socket exposed .  How to resolve this ?*
>>>>
>>>> */usr/local/sbin/opensips  -V*
>>>> version: opensips 3.2.3 (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.
>>>> svn revision: 3831:3878
>>>> main.c compiled on 07:52:40 Mar 29 2023 with gcc 11
>>>>
>>>> *cat /etc/*release*
>>>> Amazon Linux release 2023 (Amazon Linux)
>>>> NAME="Amazon Linux"
>>>> VERSION="2023"
>>>> ID="amzn"
>>>> ID_LIKE="fedora"
>>>> VERSION_ID="2023"
>>>> PLATFORM_ID="platform:al2023"
>>>> PRETTY_NAME="Amazon Linux 2023"
>>>> ANSI_COLOR="0;33"
>>>> CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023"
>>>> HOME_URL="https://aws.amazon.com/linux/"
>>>> BUG_REPORT_URL="https://github.com/amazonlinux/amazon-linux-2023"
>>>> SUPPORT_END="2028-03-01"
>>>> Amazon Linux release 2023 (Amazon Linux)
>>>>
>>>>
>>>> *Thanks & Regards*
>>>> *Sasmita Panda*
>>>> *Senior Network Testing and Software Engineer*
>>>> *3CLogic , ph:07827611765*
>>>>
>>>
>> _______________________________________________
>> 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/20240527/1d89cb31/attachment-0001.html>

From bogdan at opensips.org  Thu May 30 15:50:58 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 30 May 2024 18:50:58 +0300
Subject: [OpenSIPS-Users] utimer_ticker warning in opensips 3.2
In-Reply-To: <CALf-Q46uCnqeCpXAcbkhwN3vR1Ztwyv8dnMy2H=OU1+2-YeiPA@mail.gmail.com>
References: <CALf-Q442AqxhLDxKt6_psUWUzcC1aGfZ9CrHvYXH_BU5GFGL2w@mail.gmail.com>
 <CALf-Q45dJ=hVdJPxsB7dU1PhER4VYBnHSU+3Jn9RwrvnZ1a=Hg@mail.gmail.com>
 <CALf-Q45xVfjagrctOVtAqEkEhPzeVNWK9Zj7Kfh4_Xow1QjOUQ@mail.gmail.com>
 <2e986980-6548-4cd8-b1e5-cbbc65f60fe3@opensips.org>
 <CALf-Q46ceCOvwVf8gNKcdbkAaD99+k-rESkdGAoSrCno+jMf2w@mail.gmail.com>
 <d3ed4465-f669-4517-a4c0-32347ea696da@opensips.org>
 <CALf-Q46uCnqeCpXAcbkhwN3vR1Ztwyv8dnMy2H=OU1+2-YeiPA@mail.gmail.com>
Message-ID: <f91e90b8-1481-4732-9d74-60989d0ad424@opensips.org>

Hi,

Try to start opensips is mem debugging support - add "|-a Q_MALLOC_DBG" 
to the startup cmd line of OpenSIPS - this will give more hints on that 
crashing point.

Regards,
|

Bogdan-Andrei Iancu

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

On 27.05.2024 12:46, Sasmita Panda wrote:
> Hi ,
>
> I am just facing the same issue again .
>
> /usr/local/sbin/opensips[3443]: CRITICAL:core:fm_free: freeing already 
> freed shm pointer (0x7f3a59ddb4a0), first free: (null): (null)(0) - 
> aborting!
>
> whenever I am starting opensips this is the last line I am getting in 
> the logs and it wont listen on the specified port .
>
>
> As earlier suggested I was trying to run a trap with opensips-cli , 
> but I am facing an issue with that . It says the trap module is not 
> loaded .
> How do I load the trap module of opesnips-cli specifically ?
>
> Please help . This is a kind of blocker for me .
>
>
>
>
>
> */Thanks & Regards/*
> /Sasmita Panda/
> /Senior Network Testing and Software Engineer/
> /3CLogic , ph:07827611765/
>
>
> On Thu, Mar 21, 2024 at 10:01 PM Bogdan-Andrei Iancu 
> <bogdan at opensips.org> wrote:
>
>     IF
>
>     (a) it crashes, try to get a backtrace
>
>     (b) it block on starting, try to do a "trap" via opensips-cli
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        https://www.opensips-solutions.com
>        https://www.siphub.com
>
>     On 21.03.2024 08:24, Sasmita Panda wrote:
>>     Sometimes it crashes and sometimes while starting I get the
>>     warings of the timer .  Same config  shows different issues .
>>
>>
>>
>>     */Thanks & Regards/*
>>     /Sasmita Panda/
>>     /Senior Network Testing and Software Engineer/
>>     /3CLogic , ph:07827611765/
>>
>>
>>     On Wed, Mar 20, 2024 at 6:45 PM Bogdan-Andrei Iancu
>>     <bogdan at opensips.org> wrote:
>>
>>         Hi,
>>
>>         How the two reports fit together here ? there are completely
>>         separate experiences on different runs?? or if you start
>>         opensips first you get the warnings and later it crashes ??
>>         For the crash part, I see a core file was generated - could
>>         you extract the backtrace and post here ? (see
>>         https://opensips.org/Documentation/TroubleShooting-Crash)
>>
>>         Regards
>>
>>         Bogdan-Andrei Iancu
>>
>>         OpenSIPS Founder and Developer
>>            https://www.opensips-solutions.com
>>            https://www.siphub.com
>>
>>         On 11.03.2024 15:04, Sasmita Panda wrote:
>>>         Any update on this ?
>>>
>>>
>>>         */Thanks & Regards/*
>>>         /Sasmita Panda/
>>>         /Senior Network Testing and Software Engineer/
>>>         /3CLogic , ph:07827611765/
>>>
>>>
>>>         On Mon, Mar 11, 2024 at 12:03 PM Sasmita Panda
>>>         <spanda at 3clogic.com> wrote:
>>>
>>>             With the same server configuration and opensips version
>>>             I am getting below error as well .
>>>
>>>             CRITICAL:core:fm_free: freeing already freed shm pointer
>>>             (0x7fc110e0b408), first free: (null): (null)(0) - aborting!
>>>
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:handle_sigs: child process 215185 exited by a
>>>             signal 6
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:handle_sigs: core was generated
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:handle_sigs: terminating due to SIGCHLD
>>>              /usr/local/sbin/opensips[215172]: Memory status (pkg):
>>>              /usr/local/sbin/opensips[215172]: fm_status
>>>             (0x7fc2907ff010):
>>>              /usr/local/sbin/opensips[215174]: INFO:core:sig_usr:
>>>             signal 15 received
>>>              /usr/local/sbin/opensips[215172]: heap size= 33554432
>>>              /usr/local/sbin/opensips[215174]: Memory status (pkg):
>>>              /usr/local/sbin/opensips[215172]: used= 3710048,
>>>             used+overhead=3801344, free=29844384
>>>              /usr/local/sbin/opensips[215174]: fm_status
>>>             (0x7fc2907ff010):
>>>              /usr/local/sbin/opensips[215172]: max used (+overhead)=
>>>             3801344
>>>              /usr/local/sbin/opensips[215174]: heap size= 33554432
>>>              /usr/local/sbin/opensips[215172]: dumping free list:
>>>              /usr/local/sbin/opensips[215174]: used= 229752,
>>>             used+overhead=318936, free=33324680
>>>              /usr/local/sbin/opensips[215172]: hash =   1 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:         8
>>>             -     8 (first         8)
>>>              /usr/local/sbin/opensips[215174]: max used (+overhead)=
>>>             385792
>>>              /usr/local/sbin/opensips[215174]: dumping free list:
>>>              /usr/local/sbin/opensips[215172]: hash =  18 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:       144
>>>             -   144 (first       144)
>>>              /usr/local/sbin/opensips[215174]: hash =   7 fragments
>>>             no.:   139, unused: 0#012#011#011 bucket size:        56
>>>             -    56 (first        56)
>>>              /usr/local/sbin/opensips[215172]: hash = 2059 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:  16777216
>>>             -  33554432 (first  29752936)
>>>              /usr/local/sbin/opensips[215174]: hash =  13 fragments
>>>             no.:    37, unused: 0#012#011#011 bucket size:       104
>>>             -   104 (first       104)
>>>              /usr/local/sbin/opensips[215172]: TOTAL:      3 free
>>>             fragments = 29753088 free bytes
>>>              /usr/local/sbin/opensips[215172]: TOTAL: 48 overhead
>>>              /usr/local/sbin/opensips[215174]: hash =  16 fragments
>>>             no.:    61, unused: 0#012#011#011 bucket size:       128
>>>             -   128 (first       128)
>>>              /usr/local/sbin/opensips[215172]:
>>>             -----------------------------
>>>              /usr/local/sbin/opensips[215174]: hash =  31 fragments
>>>             no.:   152, unused: 0#012#011#011 bucket size:       248
>>>             -   248 (first       248)
>>>              /usr/local/sbin/opensips[215174]: hash =  68 fragments
>>>             no.:    16, unused: 0#012#011#011 bucket size:       544
>>>             -   544 (first       544)
>>>              /usr/local/sbin/opensips[215174]: hash = 105 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:       840
>>>             -   840 (first       840)
>>>              /usr/local/sbin/opensips[215174]: hash = 2059 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:  16777216
>>>             -  33554432 (first  33168816)
>>>              /usr/local/sbin/opensips[215174]: TOTAL:    407 free
>>>             fragments = 33235496 free bytes
>>>              /usr/local/sbin/opensips[215174]: TOTAL: 48 overhead
>>>              /usr/local/sbin/opensips[215174]:
>>>             -----------------------------
>>>              /usr/local/sbin/opensips[215176]: Memory status (pkg):
>>>              /usr/local/sbin/opensips[215176]: fm_status
>>>             (0x7fc2907ff010):
>>>              /usr/local/sbin/opensips[215176]: heap size= 33554432
>>>              /usr/local/sbin/opensips[215176]: used= 3705480,
>>>             used+overhead=3796584, free=29848952
>>>              /usr/local/sbin/opensips[215176]: max used (+overhead)=
>>>             3798064
>>>              /usr/local/sbin/opensips[215176]: dumping free list:
>>>              /usr/local/sbin/opensips[215176]: hash =   2 fragments
>>>             no.:     2, unused: 0#012#011#011 bucket size:        16
>>>             -    16 (first        16)
>>>              /usr/local/sbin/opensips[215176]: hash =   3 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:        24
>>>             -    24 (first        24)
>>>              /usr/local/sbin/opensips[215176]: hash =  16 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:       128
>>>             -   128 (first       128)
>>>              /usr/local/sbin/opensips[215175]: Memory status (pkg):
>>>              /usr/local/sbin/opensips[215175]: fm_status
>>>             (0x7fc2907ff010):
>>>              /usr/local/sbin/opensips[215175]: heap size= 33554432
>>>              /usr/local/sbin/opensips[215176]: hash = 2059 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:  16777216
>>>             -  33554432 (first  29757664)
>>>              /usr/local/sbin/opensips[215175]: used= 3705480,
>>>             used+overhead=3796584, free=29848952
>>>              /usr/local/sbin/opensips[215176]: TOTAL:      5 free
>>>             fragments = 29757848 free bytes
>>>              /usr/local/sbin/opensips[215175]: max used (+overhead)=
>>>             3798064
>>>              /usr/local/sbin/opensips[215176]: TOTAL: 48 overhead
>>>              /usr/local/sbin/opensips[215176]:
>>>             -----------------------------
>>>              /usr/local/sbin/opensips[215175]: dumping free list:
>>>              /usr/local/sbin/opensips[215175]: hash =   2 fragments
>>>             no.:     2, unused: 0#012#011#011 bucket size:        16
>>>             -    16 (first        16)
>>>              /usr/local/sbin/opensips[215175]: hash =   3 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:        24
>>>             -    24 (first        24)
>>>              /usr/local/sbin/opensips[215175]: hash =  16 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:       128
>>>             -   128 (first       128)
>>>              /usr/local/sbin/opensips[215175]: hash = 2059 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:  16777216
>>>             -  33554432 (first  29757664)
>>>              /usr/local/sbin/opensips[215175]: TOTAL:      5 free
>>>             fragments = 29757848 free bytes
>>>              /usr/local/sbin/opensips[215175]: TOTAL: 48 overhead
>>>              /usr/local/sbin/opensips[215175]:
>>>             -----------------------------
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:shutdown_opensips: process 3(215174) [timer]
>>>             terminated, still waiting for 13 more
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:shutdown_opensips: process 4(215175) [SIP
>>>             receiver udp:192.168.33.171:5060
>>>             <http://192.168.33.171:5060>] terminated, still waiting
>>>             for 12 more
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:shutdown_opensips: process 5(215176) [SIP
>>>             receiver udp:192.168.33.171:5060
>>>             <http://192.168.33.171:5060>] terminated, still waiting
>>>             for 11 more
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:shutdown_opensips: process 1(215172) [MI FIFO]
>>>             terminated, still waiting for 10 more
>>>              /usr/local/sbin/opensips[215173]: INFO:core:sig_usr:
>>>             signal 15 received
>>>              /usr/local/sbin/opensips[215173]: Memory status (pkg):
>>>              /usr/local/sbin/opensips[215173]: fm_status
>>>             (0x7fc2907ff010):
>>>              /usr/local/sbin/opensips[215173]: heap size= 33554432
>>>              /usr/local/sbin/opensips[215173]: used= 229752,
>>>             used+overhead=318936, free=33324680
>>>              /usr/local/sbin/opensips[215173]: max used (+overhead)=
>>>             385792
>>>              /usr/local/sbin/opensips[215173]: dumping free list:
>>>              /usr/local/sbin/opensips[215173]: hash =   7 fragments
>>>             no.:   139, unused: 0#012#011#011 bucket size:        56
>>>             -    56 (first        56)
>>>              /usr/local/sbin/opensips[215173]: hash =  13 fragments
>>>             no.:    37, unused: 0#012#011#011 bucket size:       104
>>>             -   104 (first       104)
>>>              /usr/local/sbin/opensips[215173]: hash =  16 fragments
>>>             no.:    61, unused: 0#012#011#011 bucket size:       128
>>>             -   128 (first       128)
>>>              /usr/local/sbin/opensips[215173]: hash =  31 fragments
>>>             no.:   152, unused: 0#012#011#011 bucket size:       248
>>>             -   248 (first       248)
>>>              /usr/local/sbin/opensips[215173]: hash =  68 fragments
>>>             no.:    16, unused: 0#012#011#011 bucket size:       544
>>>             -   544 (first       544)
>>>              /usr/local/sbin/opensips[215173]: hash = 105 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:       840
>>>             -   840 (first       840)
>>>              /usr/local/sbin/opensips[215173]: hash = 2059 fragments
>>>             no.:     1, unused: 0#012#011#011 bucket size:  16777216
>>>             -  33554432 (first  33168816)
>>>              /usr/local/sbin/opensips[215173]: TOTAL:    407 free
>>>             fragments = 33235496 free bytes
>>>              /usr/local/sbin/opensips[215173]: TOTAL: 48 overhead
>>>              /usr/local/sbin/opensips[215173]:
>>>             -----------------------------
>>>              /usr/local/sbin/opensips[215171]:
>>>             INFO:core:shutdown_opensips: process 2(215173)
>>>             [time_keeper] terminated, still waiting for 9 more
>>>              /usr/local/sbin/opensips[215171]: INFO:core:cleanup:
>>>             cleanup
>>>              /usr/local/sbin/opensips[215171]:
>>>             CRITICAL:core:sig_alarm_abort: BUG - shutdown timeout
>>>             triggered, dying...
>>>             */
>>>             /*
>>>             */Why is the service crashing ? /*
>>>             */
>>>             /*
>>>             */Thanks & Regards/*
>>>             /Sasmita Panda/
>>>             /Senior Network Testing and Software Engineer/
>>>             /3CLogic , ph:07827611765/
>>>
>>>
>>>             On Mon, Mar 11, 2024 at 11:52 AM Sasmita Panda
>>>             <spanda at 3clogic.com> wrote:
>>>
>>>                 Hi All ,
>>>
>>>                 Mar 11 05:57:02 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213843]:
>>>                 INFO:proto_ws:mod_init: initializing WebSocket protocol
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 100 ms ago (now 290 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 200 ms ago (now 390 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 300 ms ago (now 490 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 400 ms ago (now 590 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 500 ms ago (now 690 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 600 ms ago (now 790 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 700 ms ago (now 890 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 800 ms ago (now 990 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 900 ms ago (now 1090 ms), delaying
>>>                 execution
>>>                 Mar 11 05:57:03 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1000 ms ago (now 1190 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1100 ms ago (now 1290 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1200 ms ago (now 1390 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1300 ms ago (now 1490 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1400 ms ago (now 1590 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1500 ms ago (now 1690 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1600 ms ago (now 1790 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1700 ms ago (now 1890 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>>                 already scheduled 1790 ms ago (now 1980 ms),
>>>                 delaying execution
>>>                 Mar 11 05:57:04 ip-192-168-33-171
>>>                 /usr/local/sbin/opensips[213846]:
>>>                 WARNING:core:timer_ticker: timer task <tm-timer>
>>>                 already scheduled 990 ms ago (now 1980 ms), delaying
>>>                 execution
>>>                 */
>>>                 /*
>>>                 */What is this warning for? Whenever I am starting
>>>                 my openisps service this warning comes . Although
>>>                 the service seems like it's running but it's not
>>>                 listening on the socket exposed .  How to resolve
>>>                 this ?/*
>>>                 */
>>>                 /*
>>>                 */usr/local/sbin/opensips  -V*
>>>                 version: opensips 3.2.3 (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.
>>>                 svn revision: 3831:3878
>>>                 main.c compiled on 07:52:40 Mar 29 2023 with gcc 11
>>>
>>>                 *cat /etc/*release*
>>>                 Amazon Linux release 2023 (Amazon Linux)
>>>                 NAME="Amazon Linux"
>>>                 VERSION="2023"
>>>                 ID="amzn"
>>>                 ID_LIKE="fedora"
>>>                 VERSION_ID="2023"
>>>                 PLATFORM_ID="platform:al2023"
>>>                 PRETTY_NAME="Amazon Linux 2023"
>>>                 ANSI_COLOR="0;33"
>>>                 CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023"
>>>                 HOME_URL="https://aws.amazon.com/linux/"
>>>                 BUG_REPORT_URL="https://github.com/amazonlinux/amazon-linux-2023"
>>>                 SUPPORT_END="2028-03-01"
>>>                 Amazon Linux release 2023 (Amazon Linux)
>>>                 */
>>>                 /*
>>>                 */
>>>                 /*
>>>                 */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/20240530/869955b9/attachment-0001.html>

From bogdan at opensips.org  Thu May 30 16:03:58 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 30 May 2024 19:03:58 +0300
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200
 tls/ssl certs
In-Reply-To: <CA+x3AxoSnbppn6Fg6X-j6XCS43aZLUjpiOG4=cmq=G5p1xaohw@mail.gmail.com>
References: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
 <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>
 <CA+x3AxoXfDkN3rVwXH3u5Rj7w8Nm6ULtwLb2=FKET=qOOuP9FQ@mail.gmail.com>
 <de9c24f9-8a4f-45f6-a534-55aea4dd1f0d@opensips.org>
 <CAPwC5wyNDnvmXTE2F+7WdcSgzmPAtuw_uJu5ifYoygCHZQ=NiQ@mail.gmail.com>
 <CA+x3AxoSnbppn6Fg6X-j6XCS43aZLUjpiOG4=cmq=G5p1xaohw@mail.gmail.com>
Message-ID: <8cf0fd8e-6f79-4877-96ab-f9ef6605a992@opensips.org>

Hi Denys,

That is really weird, 4 out of 5 traps point to the shm_malloc() 
function, trying to get a free mem check. What is the usage of the shm 
mem (use the shmem: stats class to see) ? How many times you do this 
reload? does it get slow from the first?

Regards,

Bogdan-Andrei Iancu

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

On 14.05.2024 16:47, Denys Pozniak wrote:
> Hello!
>
> I disabled logging and added some resources to the virtual machine.
> On a working OpenSIPS, I reloaded the tls several times and in 
> parallel ran a trap.
> #opensips-cli -x mi tls_reload
> #opensips-cli -x trap
>
> If possible, please analyze it again, maybe you could find something 
> interesting:
> https://github.com/denyspozniak/opensips_tls_debug/tree/main
>
> Thanks in advance!
>
>
>
> ср, 8 мая 2024 г. в 19:59, Brett Nemeroff <brett at nemeroff.com>:
>
>     Just offering my experience here. I have, without a doubt,
>     noticed intensive logging brings a highly performant server to its
>     knees.
>
>     Disable ALL logging. Watch disk IO and confirm it's disabled. Try
>     it again. Just an easy thing to try.
>
>     -Brett
>
>
>     On Wed, May 8, 2024 at 7:17 AM Bogdan-Andrei Iancu
>     <bogdan at opensips.org> wrote:
>
>         Hi,
>
>         There is only one trap, ideally you should try to get several
>         during the reload time.
>
>         Still, the trap you did shows opensips doing some logging
>         (dumping to syslog) while reloading - could you check how
>         intensive this logging is and eventually to try to disable it
>         (increase the log level of opensips lower than INFO) to see if
>         there is any impact?
>
>         Regards,
>
>         Bogdan-Andrei Iancu
>
>         OpenSIPS Founder and Developer
>            https://www.opensips-solutions.com
>            https://www.siphub.com
>
>         On 08.05.2024 14:10, Denys Pozniak wrote:
>>         Hello!
>>
>>         If possible, please check log:
>>         https://github.com/denyspozniak/opensips_tls_debug/blob/main/gdb_opensips_20240508_115956
>>
>>
>>         ср, 8 мая 2024 г. в 08:55, Bogdan-Andrei Iancu
>>         <bogdan at opensips.org>:
>>
>>             Hi Denys.
>>
>>             That is rather weird, 250 certificates in 1 min. I assume
>>             it is not a DB issue (considering the db_text backend),
>>             so can you try to do multiple sequential "opensips-cli -x
>>             trap" to try to understand what is going on ?
>>
>>             Regards,
>>
>>             Bogdan-Andrei Iancu
>>
>>             OpenSIPS Founder and Developer
>>                https://www.opensips-solutions.com
>>                https://www.siphub.com
>>
>>             On 02.05.2024 11:41, Denys Pozniak wrote:
>>>             Hello!
>>>
>>>             There is a task to divide a single tls/ssl letsencrypt
>>>             certificate for white labels into specific ones.
>>>             I entered about ~250 certificates into db_text, but as
>>>             it turned out, for OpenSIPS this is a rather complex
>>>             operation to load them and takes about 1 minute and a
>>>             heavy CPU load is noticeable.
>>>
>>>             I would appreciate any advice on how to avoid this.
>>>
>>>             # wc -l dbtext/tls_mgm
>>>             253 dbtext/tls_mgm
>>>
>>>             # time opensips-cli -x mi tls_reload
>>>             "OK"
>>>             real 0m52.034s
>>>             user 0m1.419s
>>>             sys 0m0.433s
>>>
>>>             # time systemctl restart opensips
>>>             real    0m58.198s
>>>             user    0m0.024s
>>>             sys     0m0.055s
>>>
>>>             # opensips -V
>>>             version: opensips 3.4.4 (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: 036d02961
>>>
>>>             -- 
>>>
>>>             BR,
>>>             Denys Pozniak
>>>
>>>
>>>
>>>             _______________________________________________
>>>             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
>
>
>
> -- 
>
> BR,
> Denys Pozniak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240530/f0692b45/attachment.html>

From alberto.rinaudo at gmail.com  Thu May 30 21:15:05 2024
From: alberto.rinaudo at gmail.com (Alberto)
Date: Thu, 30 May 2024 22:15:05 +0100
Subject: [OpenSIPS-Users] re-homing calls
Message-ID: <CANoA6_LFtTufLWaRjQu-Sq4b8U_nXsDNCnm1+0ST206jkYsMow@mail.gmail.com>

Hi,

I'm testing
https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/
and I have a problem with re-homing calls from the backup server back to
the primary server.

My configuration is as follows:
shared mongodb : 172.20.2.19
opensips virtual floating ip : 172.20.2.20
opensips-0 : 172.20.2.21
opensips-1 : 172.20.2.22

to float the ip, i'm using keepalived monitoring both the network and the
opensips process.
When it detects the virtual ip has become available locally, keepalived
does this:

opensips-cli -x mi clusterer_shtag_set_active testtag/1
opensips-cli -x mi dlg_list | jq -r '.Dialogs[] | .callid' | while IFS=''
read -r callid; do
  opensips-cli -x mi dlg_send_sequential callid=${callid} mode=challenge
body=inbound
done

Now I'm testing 2 scenarios, in the first one the opensips process on the
primary server terminates, in the second scenario the network to the
primary server is interrupted.
In both cases I expect calls to be re-homed to the backup server (which
always happens) and to come back to the primary server when the problem has
been resolved (which doesn't always happen).

Here's the breakdown of the 2 tests.

So, when I start a call through opensips-0 and then kill the opensips
process, the virtual ip floats to the secondary server, and all calls are
migrated to the backup server.
When the opensips process is restarted, the ip floats back to the primary
server and all calls are migrated back.
All good here.

However, when I start a call through opensips-0 and pull the network cable,
the virtual ip floats to the secondary server and all calls are migrated.
But, when the network is restored and the ip floats back to the primary
server, calls fail to migrate back.
In the screenshot attached here you can see the invite that should migrate
the calls back to the primary server.
https://ibb.co/m4trL1Y
Note that in this second scenario opensips loses connectivity, but it
doesn't restart.

I tried to do `opensips-cli -x mi dlg_cluster_sync` and/or `opensips-cli -x
mi dlg_restore_db` on the primary server before the tag is set to active
and calls are migrated back, but it didn't help.

I hope this makes some sense.
Is there any other info or test I can provide?
Thanks
AR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240530/dfc30e29/attachment-0001.html>

From liviu at opensips.org  Fri May 31 09:48:30 2024
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 31 May 2024 12:48:30 +0300
Subject: [OpenSIPS-Users] Long reload time for mi tls_reload for 200
 tls/ssl certs
In-Reply-To: <CA+x3AxoSnbppn6Fg6X-j6XCS43aZLUjpiOG4=cmq=G5p1xaohw@mail.gmail.com>
References: <CA+x3AxreQHiK6dG5HxCdYFTfAfsqMr92NzvXrRO2Ucf=fDm4KQ@mail.gmail.com>
 <898f3242-df61-4d6d-8f78-fb53286484b2@opensips.org>
 <CA+x3AxoXfDkN3rVwXH3u5Rj7w8Nm6ULtwLb2=FKET=qOOuP9FQ@mail.gmail.com>
 <de9c24f9-8a4f-45f6-a534-55aea4dd1f0d@opensips.org>
 <CAPwC5wyNDnvmXTE2F+7WdcSgzmPAtuw_uJu5ifYoygCHZQ=NiQ@mail.gmail.com>
 <CA+x3AxoSnbppn6Fg6X-j6XCS43aZLUjpiOG4=cmq=G5p1xaohw@mail.gmail.com>
Message-ID: <59c0fe19-387c-4e2c-819f-9446c9facf76@opensips.org>

Hi Denys,

The report shows OpenSSL library doing small SHM allocations (4, 10, 
608, 24... bytes), which seem to frequently take place inside the 
PEM_read_bio_X509() loop (as part of the load_certificate_db() 
function).  Such a sequence of allocations could be stress-testing the 
allocator in a way that could justify 250 ms per certificate in total, 
as it is fragmenting the memory.  The effect can be more pronounced the 
*less* stuff is going on in your OpenSIPS instance, as the process of 
breaking up the big memory chunk into smaller units may use up to 
hundreds of cycles on each allocation.  For example:  testing box with 
no SIP traffic, or 'tls_reload' after a fresh restart, etc.

Please try the following:

- still using F_MALLOC, try doing more 'tls_reload' operations in a 
row.  Does performance improve?

- try using the "-a HP_MALLOC" allocator when booting your OpenSIPS - 
that one favors memory fragmentation a bit more, so subsequent reloads 
should be faster

Best regards,

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

On 14.05.2024 16:47, Denys Pozniak wrote:
> I disabled logging and added some resources to the virtual machine.
> On a working OpenSIPS, I reloaded the tls several times and in 
> parallel ran a trap.
> #opensips-cli -x mi tls_reload
> #opensips-cli -x trap
>
> If possible, please analyze it again, maybe you could find something 
> interesting:
> https://github.com/denyspozniak/opensips_tls_debug/tree/main
>
> Thanks in advance!


From bogdan at opensips.org  Fri May 31 10:16:27 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 31 May 2024 13:16:27 +0300
Subject: [OpenSIPS-Users] Opensips as proxy for Asterisk
In-Reply-To: <CAHKhBXWc8Mya_yvAR3cRcYFKQszZTeAXozhymtOzB8MTA-r3NA@mail.gmail.com>
References: <CAHKhBXWc8Mya_yvAR3cRcYFKQszZTeAXozhymtOzB8MTA-r3NA@mail.gmail.com>
Message-ID: <bd38cedc-7213-4677-b619-899193db8f71@opensips.org>

Hi,

What exact part is not working for you? The REGISTERs? or the INVITEs?

Regards,

Bogdan-Andrei Iancu

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

On 11.04.2024 13:58, Sterlin Devanish wrote:
> Hi friends,
>
> I am new to opensips.
> I am working on handling Background calls for Flutter WebRTC clients 
> using Asterisk.
>
> Since Asterisk doesn't support RFC8599, I am trying to configure 
> opensips as a proxy server for Asterisk.
>
> I am using mid_registrar to forward the registration request from 
> opensips to asterisk.
> It is perfectly working for SIP signaling, whereas for WebSockets the 
> request is not reaching the asterisk from opensips.
>
> Kindly help me where I am going wrong, or help me handle this scenario.
>
> /Thanks,/
> /*Sterlin Devanish D*/
>
>
> _______________________________________________
> 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/20240531/f5119b52/attachment.html>

From bogdan at opensips.org  Fri May 31 10:17:56 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 31 May 2024 13:17:56 +0300
Subject: [OpenSIPS-Users] Tracer module integration with Opensips 3.4
In-Reply-To: <36e45252719644c2981f64eb6b7d2fbe@sofrecom.com>
References: <36e45252719644c2981f64eb6b7d2fbe@sofrecom.com>
Message-ID: <5e5e18af-7395-46b4-985b-e70ca3223039@opensips.org>

Hi,

Quick one: do you load the db_mysql.so module too ?

Regards,

Bogdan-Andrei Iancu

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

On 25.04.2024 11:31, chaker.barkaoui at sofrecom.com wrote:
>
> Hello Everyone,
>
> I need your support to add tracer module in order tostore 
> incoming/outgoing SIP messages in database.
> I already add some configs to my opensips.cfg file:
>
> *### Tracer ###*
>
> *loadmodule "tracer.so"*
>
> *modparam("tracer", "trace_on", 1)*
>
> *modparam("tracer", "trace_local_ip", "opensips:5060")*
>
> *modparam("tracer", 
> "trace_id","[tid]uri=mysql://opensips:opensipsrw at ossdb/opensips;table=sip_trace;")
> **….*
>
> *if ( is_method("INVITE")) {*
>
> *record_route();*
>
> *do_accounting("db|log", "cdr|missed", "acc");*
>
> *trace($var(trace_id), "d", "sip|xlog", $var(user));*
>
> **
>
> *                                  t_relay();*
>
> *exit;*
>
> *}*
>
> **
>
> The error in Opensips logs is:
>
> ERROR:core:db_check_api: module db_mysql does not export db_use_table 
> function
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] ERROR:tracer:get_db_struct: 
> *unable to bind database module*
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] 
> ERROR:tracer:parse_siptrace_id: Invalid parameters extracted!url 
> <mysql://opensips:opensipsrw at ossdb/opensips>! table name <sip_trace>!
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] ERROR:tracer:parse_trace_id: 
> *failed to parse tracer uri []*
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:Traceback (last 
> included file at the bottom):
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL: 0. 
> /etc/opensips/opensips.cfg
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:core:yyerror: parse 
> error in /etc/opensips/opensips.cfg:53:19-20: *Parameter <trace_id> 
> not found in module <tracer> - can't set*
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", 
> "trace_on", 1)
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", 
> "trace_local_ip", "opensips:5060")
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", 
> "trace_id","[tid]uri=mysql://opensips:opensipsrw at ossdb/opensips;table=sip_trace;")
>
> I think that the module should store the messages in sip_trace table 
> but I didn’t understand how to configure properly the trace_id with 
> mysql module.
> Could you help me please ?
>
>
> Thank you.
> Best Regards,
> Chaker BARKAOUI.
>
> Orange Restricted
>
>
> _______________________________________________
> 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/20240531/a90a6d1c/attachment.html>

From bogdan at opensips.org  Fri May 31 10:19:25 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 31 May 2024 13:19:25 +0300
Subject: [OpenSIPS-Users] route handling of http protocol in opensips
In-Reply-To: <20240501040846.M90651@cdot.in>
References: <20240501040846.M90651@cdot.in>
Message-ID: <8b4cdf61-d8dc-4422-a794-483909441800@opensips.org>

Hi Anmol,

May I ask why do you want to handle HTTP custom traffic in OpenSIPS, 
which is a SIP server?

Best regards,

Bogdan-Andrei Iancu

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

On 01.05.2024 07:12, ANMOL PRAKASH via Users wrote:
> Hi all,
>
> Is there any module in opensips inline with xHTTP in kamailio.
>
> In kamailio, xHTTP module offers a generic way of handling the HTTP protocol, by calling event_route[xhttp:request] in your config.
>
> In opensips, httpd module is there to enable http server on opensips but I am looking for handling of HTTP protocol in opensips.
>
>
> Any help will be highly appreciated.
>
> Thanks & Regards
>
> Anmol Prakash (5273)
> C-DOT DELHI
> INDIA
>
> -------------------------------------------------------------------------------
> ::Disclaimer::
> -------------------------------------------------------------------------------
>
> The contents of this email and any attachment(s) are confidential and intended
> for the named recipient(s) only. It shall not attach any liability on C-DOT.
> Any views or opinions presented in this email are solely those of the author
> and  may  not  necessarily  reflect  the  opinions  of  C-DOT.  Any  form of
> reproduction, dissemination, copying, disclosure, modification, distribution
> and / or publication of this message without the prior written consent of the
> author of this e-mail is strictly prohibited. If you have received this email
> in error please delete it and notify the sender immediately.
>
> -------------------------------------------------------------------------------
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Fri May 31 10:21:44 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 31 May 2024 13:21:44 +0300
Subject: [OpenSIPS-Users] Tracer module integration with Opensips 3.4
In-Reply-To: <0f95840d3e6b4b39bb4b13c142340487@sofrecom.com>
References: <9aa3846765934357bfc70a8111dd2f8e@sofrecom.com>
 <0f95840d3e6b4b39bb4b13c142340487@sofrecom.com>
Message-ID: <3827faed-3eda-461b-bb3b-649817b8f365@opensips.org>

Your college Chaker pushed the same question, just check my reply there ;)

Regards,

Bogdan-Andrei Iancu

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

On 08.05.2024 17:53, amel.guesmi at sofrecom.com wrote:
>
> Hello,
>
> Any help please regarding my question ?
>
> Thank  you
>
> BR, Amel
>
> *De :*GUESMI Amel SOFRECOM
> *Envoyé :* lundi 29 avril 2024 10:57
> *À :* OpenSIPS users mailling list <users at lists.opensips.org>
> *Cc :* DL FT-FR Sbc TEAM <sbc.team at sofrecom.com>
> *Objet :* Tracer module integration with Opensips 3.4
>
> Hello Everyone,
>
> I need your support to add tracer module in order tostore 
> incoming/outgoing SIP messages in database.
> I already add some configs to my opensips.cfg file:
>
> *### Tracer ###*
>
> *loadmodule "tracer.so"*
>
> *modparam("tracer", "trace_on", 1)*
>
> *modparam("tracer", "trace_local_ip", "opensips:5060")*
>
> *modparam("tracer", 
> "trace_id","[tid]uri=mysql://opensips:opensipsrw at ossdb/opensips;table=sip_trace;")
> **….*
>
> *if ( is_method("INVITE")) {*
>
> *record_route();*
>
> *do_accounting("db|log", "cdr|missed", "acc");*
>
> *trace($var(trace_id), "d", "sip|xlog", $var(user));*
>
> **
>
> *                                  t_relay();*
>
> *exit;*
>
> *}*
>
> **
>
> The error in Opensips logs is:
>
> ERROR:core:db_check_api: module db_mysql does not export db_use_table 
> function
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] ERROR:tracer:get_db_struct: 
> *unable to bind database module*
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] 
> ERROR:tracer:parse_siptrace_id: Invalid parameters extracted!url 
> <mysql://opensips:opensipsrw at ossdb/opensips>! table name <sip_trace>!
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] ERROR:tracer:parse_trace_id: 
> *failed to parse tracer uri []*
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:Traceback (last 
> included file at the bottom):
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL: 0. 
> /etc/opensips/opensips.cfg
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:core:yyerror: parse 
> error in /etc/opensips/opensips.cfg:53:19-20: *Parameter <trace_id> 
> not found in module <tracer> - can't set*
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", 
> "trace_on", 1)
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", 
> "trace_local_ip", "opensips:5060")
>
> 2024-04-25 09:29:10 Apr 25 10:29:10 [52] CRITICAL:modparam("tracer", 
> "trace_id","[tid]uri=mysql://opensips:opensipsrw at ossdb/opensips;table=sip_trace;")
>
> I think that the module should store the messages in sip_trace table 
> but I didn’t understand how to configure properly the trace_id with 
> mysql module.
> Could you help me please ?
>
>
> Thank you.
> Best Regards,
> Amel on behalf of my colleague Chaker
>
>
> _______________________________________________
> 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/20240531/1b04e2ad/attachment.html>

From bogdan at opensips.org  Fri May 31 10:24:43 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 31 May 2024 13:24:43 +0300
Subject: [OpenSIPS-Users] Passing of PN params from Linphone to opensips
In-Reply-To: <CA+weG5XBp0b5GrTCe1JB0-Bww25vhTbUkoyZt7iLYuJxSky75g@mail.gmail.com>
References: <CA+weG5XBp0b5GrTCe1JB0-Bww25vhTbUkoyZt7iLYuJxSky75g@mail.gmail.com>
Message-ID: <db3d49b9-38a2-4dcb-b6a1-c5aac9224456@opensips.org>

Hi Ruben,

Could you post the at least the full Contact hdr you have?

Regards,

Bogdan-Andrei Iancu

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

On 13.05.2024 00:06, Ruben Heusel wrote:
> Hey all,
>
> i have an opensips running and followed 
> https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/ 
> to enable Push Notification support.
> I can connect to the opensips server with linphone, but the PN params 
> i pass are not recognized.
>
> DBG:core:parse_params: Parsing params 
> for:[message-expires=2419200;+pn-provider="";+pn-prid="";+pn-param="";+sip.instance="<urn:uuid:ab1e22b7-3e88-00d8-a1b1-6812bf894285>";+org.linphone.specs="lime"]
> DBG:core:pn_inspect_request: Contact URI has no PN params
>
> I have no idea how to troubleshoot this and would appreciate any help.
>
> Regards
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Fri May 31 10:26:58 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 31 May 2024 13:26:58 +0300
Subject: [OpenSIPS-Users] opensips nat question
In-Reply-To: <68924de6.a1c1.18fb957ce58.Coremail.yxrmail@163.com>
References: <68924de6.a1c1.18fb957ce58.Coremail.yxrmail@163.com>
Message-ID: <25615083-82d3-4dc2-84a9-2da4441e5e5a@opensips.org>

Hi,

And what's the actual question ?

Regards,

Bogdan-Andrei Iancu

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

On 27.05.2024 12:18, suifeng wrote:
> HI,I has an NAT question;
> img one:
> [...]
> img two:  Use fix_nated_sdp(10) processing：
> [....]
> opensips version OpenSIPS (3.2.17 (x86_64/linux))
> opensips.cfg  part context:
> route{
>        if (nat_uac_test(23)) {
>             if (is_method("REGISTER")) {
>                 setbflag("NAT");
>                 fix_nated_register();
>                 xlog("request nat: $fd, rd: $rd, ru: $ru");
>                 xlog("request -1................");
>             }
>             if (is_method("INVITE")){
>                 xlog("request invite: $fd, rd: $rd, ru: $ru");
>                 fix_nated_contact();
> add_rr_param(";nat=yes");
>                 xlog("request -2................");
>             }
>         }
>
>         if (is_method("INVITE") && has_body("application/sdp")) {
>                 xlog("request 
> 13-1................si:[$si],cs:[$cs],uri:[uri]");
>                 fix_nated_sdp(10);
>         }
> }
>
>
>
> _______________________________________________
> 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/20240531/de21497b/attachment.html>

From bogdan at opensips.org  Fri May 31 10:28:28 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 31 May 2024 13:28:28 +0300
Subject: [OpenSIPS-Users] Webrtc LB Opensips 3.1
In-Reply-To: <CAOAEC9Ec9S2jpkkqkQbpFghAdF08m+8dwm=i4goJRydiwx19Ew@mail.gmail.com>
References: <CAOAEC9Ec9S2jpkkqkQbpFghAdF08m+8dwm=i4goJRydiwx19Ew@mail.gmail.com>
Message-ID: <ada8c877-e113-4b75-a46f-aa5c8cabc2d5@opensips.org>

Hi,

I guess something based on DNS, considering the fact that there is 
nothing between the clients and the deployments.

Regards,

Bogdan-Andrei Iancu

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

On 29.05.2024 17:16, inderjeet sharma wrote:
> Hi Team,
>
> I'm using OpenSIPS and RTPEngine for JSSIP/WebRTC, and it's working 
> fine. However, I plan to run the same setup in parallel and load 
> balance the traffic between these two deployments. Could you suggest a 
> solution
>
>                    [JSSIP Client]
>                           / \ / \
> [OpenSIPS + RTPEngine Deployment 1] [OpenSIPS + RTPEngine Deployment 2]
>                           \ / \ /
>                 [Asterisk Server]
>
>
> Thanks
> Inderjeet
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From rvg at rvgeerligs.nl  Fri May 31 12:22:16 2024
From: rvg at rvgeerligs.nl (rvg at rvgeerligs.nl)
Date: Fri, 31 May 2024 12:22:16 +0000
Subject: [OpenSIPS-Users] Passing of PN params from Linphone to opensips
In-Reply-To: <db3d49b9-38a2-4dcb-b6a1-c5aac9224456@opensips.org>
References: <db3d49b9-38a2-4dcb-b6a1-c5aac9224456@opensips.org>
 <CA+weG5XBp0b5GrTCe1JB0-Bww25vhTbUkoyZt7iLYuJxSky75g@mail.gmail.com>
Message-ID: <7d9c4ec18876f369f234bd82dc389e9033fef512@rvgeerligs.nl>

Hi Ruben,

I am also working with Linphone on IOS, Mac and Windows.
I also followed the stepes in https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/ and part ii
 
I have actually succeeded to pass the credentials for the Linphone Callkit Tutorial.

For the pushnotifications to work must pass them to the provider.
In your example all these are empty:
"+pn-provider="";+pn-prid="";+pn-param=""".

 

I have not been able to pass the params for Linphone IOS. They get rejected by apns apple push notification service as: {"reason":"BadDeviceToken"}

In Linphone IOS you have to turn on Push Notifications



my logs for show the:
 The first new argument, pn_provider is: apns
 The second new argument, pn_prid is: DAAEB86C0B1AA01477835A95B1180551AD9698923AE63CFAF68DDA5C7F5F9A49:voip&A91E8154F72AF48CF443FDA5C924238588DC253D54BADA2C9B49E53C9FE569BF:remote
The third new argument, pn_param is: ABCD1234.org.linphone.phone.voip&remote
The third new argument, pn_param is new2: org.linphone.phone.voip&remote


Regards,

Ronald Geerligs



May 31, 2024 at 1:24 PM, "Bogdan-Andrei Iancu" <bogdan at opensips.org> wrote:


> 
> Hi Ruben,
> 
> Could you post the at least the full Contact hdr you have?
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  https://www.opensips-solutions.com/
>  https://www.siphub.com/
> 
> On 13.05.2024 00:06, Ruben Heusel wrote:
> 
> > 
> > Hey all,
> > 
> >  i have an opensips running and followed 
> >  https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/ 
> >  to enable Push Notification support.
> >  I can connect to the opensips server with linphone, but the PN params 
> >  i pass are not recognized.
> > 
> >  DBG:core:parse_params: Parsing params 
> >  for:[message-expires=2419200;+pn-provider="";+pn-prid="";+pn-param="";+sip.instance="<urn:uuid:ab1e22b7-3e88-00d8-a1b1-6812bf894285>";+org.linphone.specs="lime"]
> >  DBG:core:pn_inspect_request: Contact URI has no PN params
> > 
> >  I have no idea how to troubleshoot this and would appreciate any help.
> > 
> >  Regards
> > 
> >  _______________________________________________
> >  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/20240531/0fa19910/attachment.html>