From slackway2me at gmail.com  Mon Sep  2 12:37:05 2024
From: slackway2me at gmail.com (Alexey)
Date: Mon, 2 Sep 2024 17:37:05 +0500
Subject: [OpenSIPS-Users] dr_reload via Control-Panel not working
Message-ID: <CAPc6LUEzM5iE_eR5i=_+G_dBfefDLi3jATZ8JpN+C9H34-xjaA@mail.gmail.com>

Hi all

Reload DR module rules via opensips-cli works:
------------------------------------------------------------------
voip-sipgw03 ~ # tail -f
/var/log/opensips/opensips/2024-09-02/opensips-voip-sipgw03-20240902.17.log
| grep reload
Sep  2 17:28:55 voip-sipgw03 [2366284] info
INFO:drouting:dr_reload_cmd: dr_reload MI command received!
Sep  2 17:28:55 voip-sipgw03 [2366284] info
INFO:drouting:dr_reload_data_head: loading drouting data!


Reload via Control-Panel does not work:
----------------------------------------------------------
Sep  2 17:29:26 voip-sipgw03 [2366283] info
INFO:drouting:dr_reload_cmd: dr_reload MI command received!
Sep  2 17:29:26 voip-sipgw03 [2366283] info
INFO:drouting:dr_reload_data_head: loading drouting data!
Sep  2 17:29:26 voip-sipgw03 [2366283] crit
CRITICAL:drouting:dr_reload_data_head: failed to load routing info
Sep  2 17:29:26 voip-sipgw03 [2366283] crit
CRITICAL:drouting:dr_reload_cmd: failed to load routing data

Restarting of nginx and php-fpm does not help either.
What may be the reason?

-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From julien at pwlk.fr  Mon Sep  2 13:00:11 2024
From: julien at pwlk.fr (Julien Pawlak)
Date: Mon, 02 Sep 2024 15:00:11 +0200
Subject: [OpenSIPS-Users] RTP Relay issue
In-Reply-To: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
References: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
Message-ID: <ba75b9a9270f61c511fbcd308be8f85b@pwlk.fr>

Hello,

Could I get some feedback please? I'm really stuck :(

---
J

Le 29/08/2024 17:25, Julien Pawlak a écrit :

> Hello
> 
> I have a problem with RTP Relay module in the initial invite request.
> 
> I have 2 rtpengine servers with both 2 interfaces, internal and 
> external.
> 
> When I add the lien below, there is no problem. Packets come and leave 
> through good interfaces.
> 
> $rtp_relay = "out-iface=internal in-iface=external"
> 
> But, when I execute the mi command to switch rtpengine server, packets 
> don't come and leave through good interfaces.
> 
> I see that I have to put this lines :
> 
> $rtp_relay(iface) = "external";
> 
> $rtp_relay_peer(iface) = "internal";
> 
> But, that doesn't work too, I have this in debug mode :
> 
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:parse_flags: in-iface value without out-iface
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:rtpe_function_call: could not parse flags
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
> 
> Please help.
> 
> Thank you
> 
> --
> J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240902/6c4fb8be/attachment.html>

From spanda at 3clogic.com  Tue Sep  3 05:28:10 2024
From: spanda at 3clogic.com (Sasmita Panda)
Date: Tue, 3 Sep 2024 10:58:10 +0530
Subject: [OpenSIPS-Users] Need some clarification on TLS configuration
	on opensips 3.2
In-Reply-To: <CALf-Q44OWvSic8vj+wRgUPaVAsTUjCf-gaNXCYJzY5oWEoL7nw@mail.gmail.com>
References: <CALf-Q45S5xL0E_D-5NOk-A_zf+RM-WFJvyBBcOpr0t4jWfi48g@mail.gmail.com>
 <CALf-Q44OWvSic8vj+wRgUPaVAsTUjCf-gaNXCYJzY5oWEoL7nw@mail.gmail.com>
Message-ID: <CALf-Q47Ejc+Smf77E44KMK71WAzvrPTYq41_wMcaimabTtuWeQ@mail.gmail.com>

Is there any update here ?


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


On Fri, Aug 30, 2024 at 5:27 PM Sasmita Panda <spanda at 3clogic.com> wrote:

> Hi ,
>
>
> for outbound call to a tls gateway I have below configuration for
> client_domain
>
>
> modparam("tls_mgm", "client_domain", "dom1")
> modparam("tls_mgm", "match_ip_address", "[dom1]*")
> modparam("tls_mgm", "tls_method", "[dom1]-TLSv1_2")
> modparam("tls_mgm", "certificate", "[dom1]/etc/opensips/tls/3cdomain.crt")
> modparam("tls_mgm", "private_key", "[dom1]/etc/opensips/tls/3cdomain.key")
> modparam("tls_mgm", "require_cert", "[dom1]0")
> modparam("tls_mgm", "verify_cert", "[dom1]0")
>
>          With this configuration when I place an outbound call I am
> getting below error in the logs  .  I don't have the certificate and key of
> the next party . How can I authorized this certificate the
> provide on opensips end ?
>
>
>
>
>
>
>
>
>
>
> *  NOTICE:tls_openssl:verify_callback: depth = 1, verify failure
> NOTICE:tls_openssl:verify_callback: subject =
> /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
> Inc./OU=http:\/\/certs.godaddy.com
> <http://certs.godaddy.com>\/repository\//CN=Go Daddy Secure Certificate
> Authority - G2  NOTICE:tls_openssl:verify_callback: issuer  =
> /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root
> Certificate Authority - G2  NOTICE:tls_openssl:verify_callback: verify
> error: unable to get local issuer certificate [error=20]
> INFO:tls_openssl:openssl_tls_connect: New TLS connection to 18.169.x.y:5065
> established  INFO:tls_openssl:tls_dump_cert_info: tls_connect: server TLS
> certificate subject: /CN=*.sftel.yyy.cloud, issuer:
> /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
> Inc./OU=http:\/\/certs.godaddy.com
> <http://certs.godaddy.com>\/repository\//CN=Go Daddy Secure Certificate
> Authority - G2  WARNING:tls_openssl:openssl_tls_connect: TLS server
> certificate verification failed
> ERROR:tls_openssl:tls_dump_verification_failure: unable to get local issuer
> certificate  INFO:tls_openssl:tls_dump_cert_info: tls_connect: local TLS
> client certificate subject: /CN=*.xxx.com <http://xxx.com>, issuer:
> /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=xyz RSA Domain
> Validation Secure Server CA*
>
> *What should I do here ? *
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Thu, Aug 29, 2024 at 12:52 PM Sasmita Panda <spanda at 3clogic.com> wrote:
>
>> Hi All ,
>>
>> I am using opensips 3.2 from very long time . For TLS connection I was
>> using our domain specific certificate and private key which was authorized
>> by some verified organization . With that my TLS connection with the server
>> is getting established and also I am able to get REGISTER and INVITE
>> request on the connection .
>>
>>
>> Rather than this , when I build opensips with TLS=1 opensips itself
>> creates its own rootCA . If I am using those crt and private key file for
>> TLS connection the connection get established but I am not getting any
>> request . What can be the reason .
>>
>> My configuration is like below .
>>
>> modparam("tls_mgm", "server_domain", "dom3")
>> modparam("tls_mgm", "match_ip_address", "[dom3]20.1.x.y:5061")
>> modparam("tls_mgm", "match_sip_domain", "[dom3]none")
>> # 20.1.x.y this is my servers private IP on which I have configured TLS
>> socket .
>> modparam("tls_mgm", "tls_method", "[dom3]-TLSv1_2")
>>
>> modparam("tls_mgm", "certificate",
>> "[dom3]/etc/opensips/tls/rootCA/cacert.pem")
>> modparam("tls_mgm", "private_key",
>> "[dom3]/etc/opensips/tls/rootCA/private/cakey.pem")
>> modparam("tls_mgm", "ca_list",
>> "[dom3]/etc/opensips/tls/rootCA/certs/01.pem")
>>
>> modparam("tls_mgm", "require_cert", "[dom3]0")
>> modparam("tls_mgm", "verify_cert", "[dom3]1")
>>
>> In the logs I am getting below message
>>
>>
>>
>> *2024-08-29T07:14:59.213460+00:00 ip-20-1-205-63 /sbin/opensips[22895]:
>> INFO:tls_openssl:openssl_tls_accept: New TLS connection from x.x.x.x:20219
>> accepted2024-08-29T07:14:59.213866+00:00 ip-20-1-205-63
>> /sbin/opensips[22895]: INFO:tls_openssl:openssl_tls_accept: Client did not
>> present a TLS certificate2024-08-29T07:14:59.214064+00:00 ip-20-1-205-63
>> /sbin/opensips[22895]: INFO:tls_openssl:tls_dump_cert_info: tls_accept:
>> local TLS server certificate subject:
>> /CN=OpenSIPS/ST=opensips.org/C=IP/emailAddress=team at opensips.org/O=opensips.org
>> <http://opensips.org/C=IP/emailAddress=team at opensips.org/O=opensips.org>,
>> issuer:
>> /CN=OpenSIPS/ST=opensips.org/C=IP/emailAddress=team at opensips.org/O=opensips.org
>> <http://opensips.org/C=IP/emailAddress=team at opensips.org/O=opensips.org>*
>>
>> I have added siptrace and tracing to the DB as well . I am not getting
>> any SIP messages on the 2nd case . What can be the reason for this ?  This
>> is quite critical to me . Please do help.
>>
>>
>> *Thanks & Regards*
>> *Sasmita Panda*
>> *Senior Network Testing and Software Engineer*
>> *3CLogic , ph:07827611765*
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240903/55488b02/attachment-0001.html>

From liviu at opensips.org  Thu Sep  5 07:50:10 2024
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 5 Sep 2024 10:50:10 +0300
Subject: [OpenSIPS-Users] Need some clarification on TLS configuration
 on opensips 3.2
In-Reply-To: <CALf-Q44OWvSic8vj+wRgUPaVAsTUjCf-gaNXCYJzY5oWEoL7nw@mail.gmail.com>
References: <CALf-Q45S5xL0E_D-5NOk-A_zf+RM-WFJvyBBcOpr0t4jWfi48g@mail.gmail.com>
 <CALf-Q44OWvSic8vj+wRgUPaVAsTUjCf-gaNXCYJzY5oWEoL7nw@mail.gmail.com>
Message-ID: <049f2d04-ff5f-8124-4dec-69cf92b640cd@opensips.org>

On 30.08.2024 14:57, Sasmita Panda wrote:
>
>          With this configuration when I place an outbound call I am 
> getting below error in the logs  .  I don't have the certificate and 
> key of the next party . How can I authorized this certificate the
> provide on opensips end ?

Hi Sasmita,

Try also setting the ca_list 
<https://opensips.org/docs/modules/3.6.x/tls_mgm.html#param_ca_list> and 
ca_dir 
<https://opensips.org/docs/modules/3.6.x/tls_mgm.html#param_ca_dir> 
modparams and see if the CA is finally located, because that seems to be 
the error here.

Moreover, if you are still stuck on this, why not start with the 
*basics*?  Forget about OpenSIPS and its TLS wrappers until you are 100% 
sure you have the right configuration files and try to establish the TLS 
connection / exchange a few packets *manually*, from command-line, using 
a tutorial such as this one 
<https://djangocas.dev/blog/test-tls-connectivity-with-openssl/>.

Hope this helps,

-- 
Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240905/ba7338e3/attachment.html>

From spanda at 3clogic.com  Thu Sep  5 10:46:07 2024
From: spanda at 3clogic.com (Sasmita Panda)
Date: Thu, 5 Sep 2024 16:16:07 +0530
Subject: [OpenSIPS-Users] Need some clarification on TLS configuration
 on opensips 3.2
In-Reply-To: <049f2d04-ff5f-8124-4dec-69cf92b640cd@opensips.org>
References: <CALf-Q45S5xL0E_D-5NOk-A_zf+RM-WFJvyBBcOpr0t4jWfi48g@mail.gmail.com>
 <CALf-Q44OWvSic8vj+wRgUPaVAsTUjCf-gaNXCYJzY5oWEoL7nw@mail.gmail.com>
 <049f2d04-ff5f-8124-4dec-69cf92b640cd@opensips.org>
Message-ID: <CALf-Q44Y7jWvd5mT+Ax9+f6apct+0akNWLE6J=z3CFU8sEZONA@mail.gmail.com>

Hi Liviu ,

Yesterday we tried the same thing . I have added ca_list in the opensips
config which resolved the tls error . Corresponding to ca_list I have added
/etc/ssl/certs/ca_certificates.crt (This file is present in the linux
server . I have not created this one . )

Before 5year I have tried the same kind of TLS connection with opensips 2.4
and that was working fine without adding the ca_list in the config file .
Hence I was expecting the same here with 3.2 as well . But that didn't work
here  .  What can be the reason for this ?


You are right , with basic openssl commands also I am able to establish a
TLS connection which I was not verified earlier .

Thank you once again .

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


On Thu, Sep 5, 2024 at 1:20 PM Liviu Chircu <liviu at opensips.org> wrote:

> On 30.08.2024 14:57, Sasmita Panda wrote:
>
>
>          With this configuration when I place an outbound call I am
> getting below error in the logs  .  I don't have the certificate and key of
> the next party . How can I authorized this certificate the
> provide on opensips end ?
>
> Hi Sasmita,
>
> Try also setting the ca_list
> <https://opensips.org/docs/modules/3.6.x/tls_mgm.html#param_ca_list> and
> ca_dir <https://opensips.org/docs/modules/3.6.x/tls_mgm.html#param_ca_dir>
> modparams and see if the CA is finally located, because that seems to be
> the error here.
>
> Moreover, if you are still stuck on this, why not start with the *basics*?
> Forget about OpenSIPS and its TLS wrappers until you are 100% sure you have
> the right configuration files and try to establish the TLS connection /
> exchange a few packets *manually*, from command-line, using a tutorial such
> as this one
> <https://djangocas.dev/blog/test-tls-connectivity-with-openssl/>.
>
> Hope this helps,
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240905/bf1f658d/attachment.html>

From julien at pwlk.fr  Thu Sep  5 11:47:42 2024
From: julien at pwlk.fr (Julien Pawlak)
Date: Thu, 05 Sep 2024 13:47:42 +0200
Subject: [OpenSIPS-Users] RTP Relay issue
In-Reply-To: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
References: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
Message-ID: <3c2e2bf8fa1691566afecad6fa8cce19@pwlk.fr>

Hello,

Could I get some feedback please? I'm really stuck :(

---
J

Le 29/08/2024 17:25, Julien Pawlak a écrit :

> Hello
> 
> I have a problem with RTP Relay module in the initial invite request.
> 
> I have 2 rtpengine servers with both 2 interfaces, internal and 
> external.
> 
> When I add the lien below, there is no problem. Packets come and leave 
> through good interfaces.
> 
> $rtp_relay = "out-iface=internal in-iface=external"
> 
> But, when I execute the mi command to switch rtpengine server, packets 
> don't come and leave through good interfaces.
> 
> I see that I have to put this lines :
> 
> $rtp_relay(iface) = "external";
> 
> $rtp_relay_peer(iface) = "internal";
> 
> But, that doesn't work too, I have this in debug mode :
> 
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:parse_flags: in-iface value without out-iface
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:rtpe_function_call: could not parse flags
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
> 
> Please help.
> 
> Thank you
> 
> --
> J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240905/8eec4c30/attachment.html>

From daniel.zanutti at gmail.com  Thu Sep  5 13:46:06 2024
From: daniel.zanutti at gmail.com (Daniel Zanutti)
Date: Thu, 5 Sep 2024 10:46:06 -0300
Subject: [OpenSIPS-Users] RTP Relay issue
In-Reply-To: <3c2e2bf8fa1691566afecad6fa8cce19@pwlk.fr>
References: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
 <3c2e2bf8fa1691566afecad6fa8cce19@pwlk.fr>
Message-ID: <CAN0jgiNb++e=tBJC8EejFfaRa5D94AB+MBoi=P2XsQGLsa9gQQ@mail.gmail.com>

Julien

Since the problem is on RTP, it's related to the rtpengine you're using.
Maybe you could ask for help on rtpengine forum.

On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users <
users at lists.opensips.org> wrote:

> Hello,
>
> Could I get some feedback please? I'm really stuck :(
>
> ---
> J
>
>
> Le 29/08/2024 17:25, Julien Pawlak a écrit :
>
> Hello
>
>
> I have a problem with RTP Relay module in the initial invite request.
>
> I have 2 rtpengine servers with both 2 interfaces, internal and external.
>
>
> When I add the lien below, there is no problem. Packets come and leave
> through good interfaces.
>
> $rtp_relay = "out-iface=internal in-iface=external"
>
> But, when I execute the mi command to switch rtpengine server, packets
> don't come and leave through good interfaces.
>
>
> I see that I have to put this lines :
>
> $rtp_relay(iface) = "external";
>
> $rtp_relay_peer(iface) = "internal";
>
>
> But, that doesn't work too, I have this in debug mode :
>
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] *in-iface=[internal]
> out-iface=[]* ctx-flags=[] flags=[] peer-flags=[]
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
> ERROR:rtpengine:parse_flags: in-iface value without out-iface
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
> ERROR:rtpengine:rtpe_function_call: could not parse flags
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
>
>
> Please help.
>
>
> Thank you
>
>
> --
> J.
>
> _______________________________________________
> 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/20240905/eeca146e/attachment.html>

From julien at pwlk.fr  Thu Sep  5 14:29:29 2024
From: julien at pwlk.fr (Julien Pawlak)
Date: Thu, 05 Sep 2024 16:29:29 +0200
Subject: [OpenSIPS-Users] RTP Relay issue
In-Reply-To: <CAN0jgiNb++e=tBJC8EejFfaRa5D94AB+MBoi=P2XsQGLsa9gQQ@mail.gmail.com>
References: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
 <3c2e2bf8fa1691566afecad6fa8cce19@pwlk.fr>
 <CAN0jgiNb++e=tBJC8EejFfaRa5D94AB+MBoi=P2XsQGLsa9gQQ@mail.gmail.com>
Message-ID: <f6622b08a54e1e9f449d49d7ab4cdef9@pwlk.fr>

Hello Daniel,

Thank you for your reply !

I don't think this problem is du to rtpengine. When i use commands 
rtpengine_offer, rtpengine_answer etc. all work fine. So, rtpengine side 
is ok. I want to use opensips rtp_relay module to simplify configuration 
because I have multiple rtpengine servers.

As I wrote, when I set this in opensips configuration file :

$rtp_relay(iface) = "internal";

$rtp_relay_peer(iface) = "external";

We see in opensips logs that the parameter $rtp_relay_peer(iface) = 
"external" does not appairs :

=> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]

$rtp_relay(iface) = "internal"; => in-iface=[internal] => OK

$rtp_relay_peer(iface) = "external"; => out-iface=[] => KO

So, this error appairs : ERROR:rtpengine:parse_flags: in-iface value 
without out-iface :(

---
J

Le 05/09/2024 15:46, Daniel Zanutti a écrit :

> Julien
> 
> Since the problem is on RTP, it's related to the rtpengine you're 
> using. Maybe you could ask for help on rtpengine forum.
> 
> On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users 
> <users at lists.opensips.org> wrote:
> 
> Hello,
> 
> Could I get some feedback please? I'm really stuck :(
> 
> ---
> J
> 
> Le 29/08/2024 17:25, Julien Pawlak a écrit :
> 
> Hello
> 
> I have a problem with RTP Relay module in the initial invite request.
> 
> I have 2 rtpengine servers with both 2 interfaces, internal and 
> external.
> 
> When I add the lien below, there is no problem. Packets come and leave 
> through good interfaces.
> 
> $rtp_relay = "out-iface=internal in-iface=external"
> 
> But, when I execute the mi command to switch rtpengine server, packets 
> don't come and leave through good interfaces.
> 
> I see that I have to put this lines :
> 
> $rtp_relay(iface) = "external";
> 
> $rtp_relay_peer(iface) = "internal";
> 
> But, that doesn't work too, I have this in debug mode :
> 
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:parse_flags: in-iface value without out-iface
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:rtpe_function_call: could not parse flags
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
> 
> Please help.
> 
> Thank you
> 
> --
> J. _______________________________________________
> 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/20240905/9e49ec6b/attachment.html>

From razvan at opensips.org  Fri Sep  6 08:57:50 2024
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Fri, 6 Sep 2024 11:57:50 +0300
Subject: [OpenSIPS-Users] dr_reload via Control-Panel not working
In-Reply-To: <CAPc6LUEzM5iE_eR5i=_+G_dBfefDLi3jATZ8JpN+C9H34-xjaA@mail.gmail.com>
References: <CAPc6LUEzM5iE_eR5i=_+G_dBfefDLi3jATZ8JpN+C9H34-xjaA@mail.gmail.com>
Message-ID: <f8751e2a-c9cf-41a6-b897-c50fc9aa5dd9@opensips.org>

What is the OpenSIPS version you are using?

Best regards,

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

On 9/2/24 3:37 PM, Alexey wrote:
> Hi all
> 
> Reload DR module rules via opensips-cli works:
> ------------------------------------------------------------------
> voip-sipgw03 ~ # tail -f
> /var/log/opensips/opensips/2024-09-02/opensips-voip-sipgw03-20240902.17.log
> | grep reload
> Sep  2 17:28:55 voip-sipgw03 [2366284] info
> INFO:drouting:dr_reload_cmd: dr_reload MI command received!
> Sep  2 17:28:55 voip-sipgw03 [2366284] info
> INFO:drouting:dr_reload_data_head: loading drouting data!
> 
> 
> Reload via Control-Panel does not work:
> ----------------------------------------------------------
> Sep  2 17:29:26 voip-sipgw03 [2366283] info
> INFO:drouting:dr_reload_cmd: dr_reload MI command received!
> Sep  2 17:29:26 voip-sipgw03 [2366283] info
> INFO:drouting:dr_reload_data_head: loading drouting data!
> Sep  2 17:29:26 voip-sipgw03 [2366283] crit
> CRITICAL:drouting:dr_reload_data_head: failed to load routing info
> Sep  2 17:29:26 voip-sipgw03 [2366283] crit
> CRITICAL:drouting:dr_reload_cmd: failed to load routing data
> 
> Restarting of nginx and php-fpm does not help either.
> What may be the reason?
> 


From razvan at opensips.org  Fri Sep  6 09:01:27 2024
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Fri, 6 Sep 2024 12:01:27 +0300
Subject: [OpenSIPS-Users] RTP Relay issue
In-Reply-To: <f6622b08a54e1e9f449d49d7ab4cdef9@pwlk.fr>
References: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
 <3c2e2bf8fa1691566afecad6fa8cce19@pwlk.fr>
 <CAN0jgiNb++e=tBJC8EejFfaRa5D94AB+MBoi=P2XsQGLsa9gQQ@mail.gmail.com>
 <f6622b08a54e1e9f449d49d7ab4cdef9@pwlk.fr>
Message-ID: <c071dca5-a2e7-4983-9a8c-5797b7395718@opensips.org>

Hi, Julien!

What version of opensips are you using? Send us the output of `opensips -V`.
Also, try to update to your latest commits for the branch you are using, 
and try again.

Best regards,

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

On 9/5/24 5:29 PM, Julien Pawlak via Users wrote:
> Hello Daniel,
> 
> Thank you for your reply !
> 
> I don't think this problem is du to rtpengine. When i use commands 
> rtpengine_offer, rtpengine_answer etc. all work fine. So, rtpengine side 
> is ok. I want to use opensips rtp_relay module to simplify configuration 
> because I have multiple rtpengine servers.
> 
> As I wrote, when I set this in opensips configuration file :
> 
> $rtp_relay(iface) = "internal";
> 
> $rtp_relay_peer(iface) = "external";
> 
> We see in opensips logs that the parameter $rtp_relay_peer(iface) = 
> "external" does not appairs :
> 
> => DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> 
> $rtp_relay(iface) = "internal"; => in-iface=[internal] => OK
> 
> $rtp_relay_peer(iface) = "external"; => out-iface=[] => KO
> 
> So, this error appairs : ERROR:rtpengine:parse_flags: in-iface value 
> without out-iface :(
> 
> ---
> J
> 
> Le 05/09/2024 15:46, Daniel Zanutti a écrit :
> 
>> Julien
>>
>> Since the problem is on RTP, it's related to the rtpengine you're 
>> using. Maybe you could ask for help on rtpengine forum.
>>
>> On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users 
>> <users at lists.opensips.org> wrote:
>>
>> Hello,
>>
>> Could I get some feedback please? I'm really stuck :(
>>
>> ---
>> J
>>
>> Le 29/08/2024 17:25, Julien Pawlak a écrit :
>>
>> Hello
>>
>> I have a problem with RTP Relay module in the initial invite request.
>>
>> I have 2 rtpengine servers with both 2 interfaces, internal and external.
>>
>> When I add the lien below, there is no problem. Packets come and leave 
>> through good interfaces.
>>
>> $rtp_relay = "out-iface=internal in-iface=external"
>>
>> But, when I execute the mi command to switch rtpengine server, packets 
>> don't come and leave through good interfaces.
>>
>> I see that I have to put this lines :
>>
>> $rtp_relay(iface) = "external";
>>
>> $rtp_relay_peer(iface) = "internal";
>>
>> But, that doesn't work too, I have this in debug mode :
>>
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
>> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> ERROR:rtpengine:parse_flags: in-iface value without out-iface
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> ERROR:rtpengine:rtpe_function_call: could not parse flags
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
>>
>> Please help.
>>
>> Thank you
>>
>> -- 
>> J. _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> Hello Daniel,
> 
> 
> Thank you for your reply !
> 
> 
> I don't think this problem is du to rtpengine. When i use commands 
> rtpengine_offer, rtpengine_answer etc. all work fine. So, rtpengine side 
> is ok. I want to use opensips rtp_relay module to simplify configuration 
> because I have multiple rtpengine servers.
> 
> 
> As I wrote, when I set this in opensips configuration file :
> 
> $rtp_relay(iface) = "internal";
> 
> $rtp_relay_peer(iface) = "external";
> 
> 
> We see in opensips logs that the parameter $rtp_relay_peer(iface) = 
> "external" does not appairs :
> 
> => DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> 
> 
> $rtp_relay(iface) = "internal"; => in-iface=[internal] => OK
> 
> $rtp_relay_peer(iface) = "external"; => out-iface=[] => KO
> 
> 
> So, this error appairs : ERROR:rtpengine:parse_flags: in-iface value 
> without out-iface :(
> 
> ---
> J
> 
> Le 05/09/2024 15:46, Daniel Zanutti a écrit :
> 
>> Julien
>> Since the problem is on RTP, it's related to the rtpengine you're 
>> using. Maybe you could ask for help on rtpengine forum.
>>
>> On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users 
>> <users at lists.opensips.org <mailto:users at lists.opensips.org>> wrote:
>>
>>     Hello,
>>
>>     Could I get some feedback please? I'm really stuck :(
>>
>>     ---
>>     J
>>
>>
>>     Le 29/08/2024 17:25, Julien Pawlak a écrit :
>>
>>         Hello
>>
>>
>>         I have a problem with RTP Relay module in the initial invite
>>         request.
>>
>>         I have 2 rtpengine servers with both 2 interfaces, internal
>>         and external.
>>
>>
>>         When I add the lien below, there is no problem. Packets come
>>         and leave through good interfaces.
>>
>>         $rtp_relay = "out-iface=internal in-iface=external"
>>
>>         But, when I execute the mi command to switch rtpengine server,
>>         packets don't come and leave through good interfaces.
>>
>>
>>         I see that I have to put this lines :
>>
>>         $rtp_relay(iface) = "external";
>>
>>         $rtp_relay_peer(iface) = "internal";
>>
>>
>>         But, that doesn't work too, I have this in debug mode :
>>
>>         août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
>>         DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[]
>>         type=[] *in-iface=[internal] out-iface=[]* ctx-flags=[]
>>         flags=[] peer-flags=[]
>>         août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
>>         ERROR:rtpengine:parse_flags: in-iface value without out-iface
>>         août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
>>         ERROR:rtpengine:rtpe_function_call: could not parse flags
>>         août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]:
>>         ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
>>
>>
>>         Please help.
>>
>>
>>         Thank you
>>
>>
>>         -- 
>>         J.
>>
>>     _______________________________________________
>>     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


From slackway2me at gmail.com  Fri Sep  6 10:41:19 2024
From: slackway2me at gmail.com (Alexey)
Date: Fri, 6 Sep 2024 15:41:19 +0500
Subject: [OpenSIPS-Users] dr_reload via Control-Panel not working
In-Reply-To: <f8751e2a-c9cf-41a6-b897-c50fc9aa5dd9@opensips.org>
References: <CAPc6LUEzM5iE_eR5i=_+G_dBfefDLi3jATZ8JpN+C9H34-xjaA@mail.gmail.com>
 <f8751e2a-c9cf-41a6-b897-c50fc9aa5dd9@opensips.org>
Message-ID: <CAPc6LUGwcsX38gTjK_FMi-x9r40Y4tdRmZNc45=ZE7SPiStiwQ@mail.gmail.com>

OpenSIPS 3.2.17

-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From santi.anton at quarea.com  Fri Sep  6 12:22:10 2024
From: santi.anton at quarea.com (=?iso-8859-1?Q?Santi_Ant=F3n?=)
Date: Fri, 6 Sep 2024 12:22:10 +0000
Subject: [OpenSIPS-Users] remove_latency value in pike module is not
	respected
Message-ID: <AS8PR08MB73726C3AC49A5A3F14BDD765939E2@AS8PR08MB7372.eurprd08.prod.outlook.com>

Hello,

I'm using pike module with this module configuration.

loadmodule "pike.so"
modparam("pike", "sampling_time_unit", 5)
modparam("pike", "reqs_density_per_unit", 10)
modparam("pike", "remove_latency", 3600)

The module detects the DoS, but 6-8 seconds later unblock the source IP when it is set to last 1h, where I'm going wrong?
I've tried different "remove_latency" values with the same results.
The log shows it.

Sep  5 18:30:32 voiptfm /usr/sbin/opensips[660915]: INFO:PIKE - BLOCKing ip 172.16.53.12, node=0x7f93ec486bc8
Sep  5 18:30:38 voiptfm /usr/sbin/opensips[660934]: INFO:PIKE - UNBLOCKing node 0x7f93ec486bc8

Sep  5 18:30:55 voiptfm /usr/sbin/opensips[660916]: INFO:PIKE - BLOCKing ip 172.16.53.12, node=0x7f93ec486bc8
Sep  5 18:31:03 voiptfm /usr/sbin/opensips[660934]: INFO:PIKE - UNBLOCKing node 0x7f93ec486bc8

Sep  6 13:36:08 voiptfm /usr/sbin/opensips[669077]: INFO:PIKE - BLOCKing ip 172.16.53.12, node=0x7f2727f97448
Sep  6 13:36:13 voiptfm /usr/sbin/opensips[669092]: INFO:PIKE - UNBLOCKing node 0x7f2727f97448


Salutacions/Saludos,

[cid:image001.jpg at 01DB0067.82501740]





Santi Antón
Responsable de operaciones
Tel. 902 520 520 - Ext. 106
santi.anton at quarea.com<mailto:santi.anton at quarea.com>






902 520 520
www.quarea.com<http://www.quarea.com/>
Quarea ITC Management & Consulting
Su experto en Redes Voz-Datos IP:
Asterisk, Cisco, Polycom, Sangoma












En compliment del que es disposa en l'article 13 del Reglament (UE) 2016/679, relatiu a la Protecció de Dades de Caràcter Personal, QUAREA ITC MANAGEMENT & CONSULTING, SL garanteix la confidencialitat de les dades personals dels seus clients. Li comuniquem que la seva adreça de correu electrònic forma part d'una base de dades gestionada sota la responsabilitat de QUAREA ITC MANAGEMENT & CONSULTING, SL, amb l'única finalitat de prestar-li els serveis per vostè sol·licitats, per la seva condició de client, proveïdor, o perquè ens hagi sol·licitat informació en algun moment. Les dades seran conservades durant el temps necessari per poder prestar-li els nostres serveis i complir amb les nostres obligacions legals. És voluntat de QUAREA ITC MANAGEMENT & CONSULTING, SL, evitar l'enviament deliberat de correu no sol·licitat, per la qual cosa podrà a tot moment, exercitar els seus drets d'accés, rectificació, supressió, limitació del seu tractament, oposició i portabilitat de les seves dades de caràcter personal mitjançant el correu electrònic infodat at quarea.com<mailto:infodat at quarea.com>

En cumplimiento de lo dispuesto en el artículo 13 del Reglamento (UE) 2016/679, relativo a la Protección de Datos de Carácter Personal, QUAREA ITC MANAGEMENT & CONSULTING, SL garantiza la confidencialidad de los datos personales de sus clientes. Le comunicamos que su dirección de correo electrónico forma parte de una base de datos gestionada bajo la responsabilidad de QUAREA ITC MANAGEMENT & CONSULTING, SL, con la única finalidad de prestarle los servicios por usted solicitados, por su condición de cliente, proveedor, o porque nos haya solicitado información en algún momento. Los datos serán conservados durante el tiempo necesario para poder prestarle nuestros servicios y cumplir con nuestras obligaciones legales. Es voluntad de QUAREA ITC MANAGEMENT & CONSULTING, SL, evitar el envío deliberado de correo no solicitado, por lo cual podrá en todo momento, ejercitar sus derechos de acceso, rectificación, supresión, limitación de su tratamiento, oposición y portabilidad de sus datos de carácter personal mediante el correo electrónico infodat at quarea.com<mailto:infodat at quarea.com>

In compliance with the provisions of Article 13 of Regulation (EU) 2016/679, regarding the Protection of Personal Data, QUAREA ITC MANAGEMENT & CONSULTING, SL guarantees the confidentiality of the personal data of his customers. We inform you that your email address is part of a managed database under the responsibility of QUAREA ITC MANAGEMENT & CONSULTING, SL, for the sole purpose of providing the services requested by you, as a client, supplier, or because we have requested information at some time. The data will be kept for the time necessary to provide our services and comply with our legal obligations. It is the will of QUAREA ITC MANAGEMENT & CONSULTING, SL, to avoid the deliberate sending of unsolicited mail, so that it may, at any time, exercise your rights of access, rectification, removal, limitation of his treatment, opposition and portability of his personal data through the email infodat at quarea.com<mailto:infodat at quarea.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240906/adc00d7a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7811 bytes
Desc: image001.jpg
URL: <http://lists.opensips.org/pipermail/users/attachments/20240906/adc00d7a/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 166 bytes
Desc: image002.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20240906/adc00d7a/attachment-0001.png>

From julien at pwlk.fr  Fri Sep  6 13:57:18 2024
From: julien at pwlk.fr (Julien Pawlak)
Date: Fri, 06 Sep 2024 15:57:18 +0200
Subject: [OpenSIPS-Users]  RTP Relay issue
In-Reply-To: <tencent_38A407285B178216DAEA9062CBF0787E6106@qq.com>
References: <tencent_38A407285B178216DAEA9062CBF0787E6106@qq.com>
Message-ID: <4e68c8f555a6edfacf31e424b6e0f26b@pwlk.fr>

Hi Răzvan !

Thank you for your reply !

Below the result of opensips -V command:

version: opensips 3.4.6 (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: ab10b6892
main.c compiled on 13:42:08 Jul 30 2024 with gcc 12

I'll try opensips version 3.4.8 (the latest) and come back to you.

Rgds

---
J

Le 06/09/2024 05:55, 老李-FSGUI,电话机器人 a écrit :

> Is it configured like this
> 
> $var(rtpengine_flags) = "RTP/AVP replace-session-connection 
> replace-origin ICE=remove address-family=IP4 out-iface=pub 
> in-iface=pub";
> or
> $var(rtpengine_flags) = "RTP/AVP replace-session-connection 
> replace-origin ICE=remove address-family=IP4 in-iface=priv 
> out-iface=priv";
> 
> rtpengine_offer("$var(rtpengine_flags)");
> 
> and rtpengine param for this
> 
> ./rtpengine -p /var/run/rtpengine.pid -i priv/172.33.1.xx -i 
> pub/12.xx.xxx.1 -n 172.33.1.xx:60000 -c 172.33.1.xx:60001 -m 50000 -M 
> 55000 -f -E -L 7
> 
> -------------------------
> 
> 老李-FSGUI,电话机器人
> nway at foxmail.com
> 
> ------------------ 原始邮件 ------------------
> 
> 发件人: "Julien Pawlak" <users at lists.opensips.org>;
> 发送时间: 2024年9月5日(星期四) 晚上10:29
> 收件人: "Daniel Zanutti"<daniel.zanutti at gmail.com>;
> 抄送: "OpenSIPS users mailling list"<users at lists.opensips.org>;
> 主题: Re: [OpenSIPS-Users] RTP Relay issue
> 
> Hello Daniel,
> 
> Thank you for your reply !
> 
> I don't think this problem is du to rtpengine. When i use commands 
> rtpengine_offer, rtpengine_answer etc. all work fine. So, rtpengine 
> side is ok. I want to use opensips rtp_relay module to simplify 
> configuration because I have multiple rtpengine servers.
> 
> As I wrote, when I set this in opensips configuration file :
> 
> $rtp_relay(iface) = "internal";
> 
> $rtp_relay_peer(iface) = "external";
> 
> We see in opensips logs that the parameter $rtp_relay_peer(iface) = 
> "external" does not appairs :
> 
> => DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> 
> $rtp_relay(iface) = "internal"; => in-iface=[internal] => OK
> 
> $rtp_relay_peer(iface) = "external"; => out-iface=[] => KO
> 
> So, this error appairs : ERROR:rtpengine:parse_flags: in-iface value 
> without out-iface :(
> 
> ---
> J
> 
> Le 05/09/2024 15:46, Daniel Zanutti a écrit :
> 
> Julien
> 
> Since the problem is on RTP, it's related to the rtpengine you're 
> using. Maybe you could ask for help on rtpengine forum.
> 
> On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users 
> <users at lists.opensips.org> wrote:
> 
> Hello,
> 
> Could I get some feedback please? I'm really stuck :(
> 
> ---
> J
> 
> Le 29/08/2024 17:25, Julien Pawlak a écrit :
> 
> Hello
> 
> I have a problem with RTP Relay module in the initial invite request.
> 
> I have 2 rtpengine servers with both 2 interfaces, internal and 
> external.
> 
> When I add the lien below, there is no problem. Packets come and leave 
> through good interfaces.
> 
> $rtp_relay = "out-iface=internal in-iface=external"
> 
> But, when I execute the mi command to switch rtpengine server, packets 
> don't come and leave through good interfaces.
> 
> I see that I have to put this lines :
> 
> $rtp_relay(iface) = "external";
> 
> $rtp_relay_peer(iface) = "internal";
> 
> But, that doesn't work too, I have this in debug mode :
> 
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:parse_flags: in-iface value without out-iface
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:rtpe_function_call: could not parse flags
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
> 
> Please help.
> 
> Thank you
> 
> --
> J. _______________________________________________
> 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/20240906/1636f321/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20240906/1636f321/attachment.gif>

From julien at pwlk.fr  Fri Sep  6 14:46:25 2024
From: julien at pwlk.fr (Julien Pawlak)
Date: Fri, 06 Sep 2024 16:46:25 +0200
Subject: [OpenSIPS-Users]  RTP Relay issue
In-Reply-To: <4e68c8f555a6edfacf31e424b6e0f26b@pwlk.fr>
References: <tencent_38A407285B178216DAEA9062CBF0787E6106@qq.com>
 <4e68c8f555a6edfacf31e424b6e0f26b@pwlk.fr>
Message-ID: <7c7129a7bc81972f5f1759b279e12b18@pwlk.fr>

Hi Răzvan,

I've just tested with version 3.4.8 and the situation has evolved.

This is what I have with a call of one side :

opensips conf:

$rtp_relay(iface) = "external";
$rtp_relay_peer(iface) = "internal";
rtp_relay_engage("rtpengine");

Debug result:

DBG:rtp_relay:rtp_relay_answer: leg=callee callid=[] ftag=[] ttag=[] 
type=[] in-iface=[external] out-iface=[external] ctx-flags=[] flags=[] 
peer-flags=[]

rtp_relay_list mi command:

[
{
"callid": "57c017bc5c8ccc3c5c29b2d57f6f0722 at x.x.x.x:5060",
"caller": {
"tag": "as2d4f2687",
"interface": "external"
},
"callee": {
"tag": "as2d4f2687",
"interface": "external"
},
"relay": "rtpengine",
"node": "udp:y.y.y.y:2223",
"set": 0,
"ctx": {
"from-tag": "as2d4f2687",
"to-tag": "DC09BE8B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_401C"
}
}
]

And for a call from the other side:

opensips conf:

$rtp_relay(iface) = "internal";
$rtp_relay_peer(iface) = "external";
rtp_relay_engage("rtpengine");

Debug result:

DBG:rtp_relay:rtp_relay_answer: leg=callee callid=[] ftag=[] ttag=[] 
type=[] in-iface=[internal] out-iface=[internal] ctx-flags=[] flags=[] 
peer-flags=[]

rtp_relay_list mi command:

[
{
"callid": "0201FFFFF1F526A9",
"caller": {
"tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
"interface": "internal"
},
"callee": {
"tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
"interface": "internal"
},
"relay": "rtpengine",
"node": "udp:y.y.y.y:2223",
"set": 0,
"ctx": {
"from-tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
"to-tag": "as36a555a0"
}
}
]

It seems that with this version the code just take $rtp_relay(iface) 
value, put it into $rtp_relay_peer and ignore $rtp_relay_peer value.

Have you any other idea ?

---
J.

Le 06/09/2024 15:57, Julien Pawlak a écrit :

> Hi Răzvan !
> 
> Thank you for your reply !
> 
> Below the result of opensips -V command:
> 
> version: opensips 3.4.6 (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: ab10b6892
> main.c compiled on 13:42:08 Jul 30 2024 with gcc 12
> 
> I'll try opensips version 3.4.8 (the latest) and come back to you.
> 
> Rgds
> 
> ---
> J
> 
> Le 06/09/2024 05:55, 老李-FSGUI,电话机器人 a écrit :
> 
> Is it configured like this
> 
> $var(rtpengine_flags) = "RTP/AVP replace-session-connection 
> replace-origin ICE=remove address-family=IP4 out-iface=pub 
> in-iface=pub";
> or
> $var(rtpengine_flags) = "RTP/AVP replace-session-connection 
> replace-origin ICE=remove address-family=IP4 in-iface=priv 
> out-iface=priv";
> 
> rtpengine_offer("$var(rtpengine_flags)");
> 
> and rtpengine param for this
> 
> ./rtpengine -p /var/run/rtpengine.pid -i priv/172.33.1.xx -i 
> pub/12.xx.xxx.1 -n 172.33.1.xx:60000 -c 172.33.1.xx:60001 -m 50000 -M 
> 55000 -f -E -L 7
> 
> -------------------------
> 
> 老李-FSGUI,电话机器人
> nway at foxmail.com
> 
> ------------------ 原始邮件 ------------------
> 
> 发件人: "Julien Pawlak" <users at lists.opensips.org>;
> 发送时间: 2024年9月5日(星期四) 晚上10:29
> 收件人: "Daniel Zanutti"<daniel.zanutti at gmail.com>;
> 抄送: "OpenSIPS users mailling list"<users at lists.opensips.org>;
> 主题: Re: [OpenSIPS-Users] RTP Relay issue
> 
> Hello Daniel,
> 
> Thank you for your reply !
> 
> I don't think this problem is du to rtpengine. When i use commands 
> rtpengine_offer, rtpengine_answer etc. all work fine. So, rtpengine 
> side is ok. I want to use opensips rtp_relay module to simplify 
> configuration because I have multiple rtpengine servers.
> 
> As I wrote, when I set this in opensips configuration file :
> 
> $rtp_relay(iface) = "internal";
> 
> $rtp_relay_peer(iface) = "external";
> 
> We see in opensips logs that the parameter $rtp_relay_peer(iface) = 
> "external" does not appairs :
> 
> => DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> 
> $rtp_relay(iface) = "internal"; => in-iface=[internal] => OK
> 
> $rtp_relay_peer(iface) = "external"; => out-iface=[] => KO
> 
> So, this error appairs : ERROR:rtpengine:parse_flags: in-iface value 
> without out-iface :(
> 
> ---
> J
> 
> Le 05/09/2024 15:46, Daniel Zanutti a écrit :
> 
> Julien
> 
> Since the problem is on RTP, it's related to the rtpengine you're 
> using. Maybe you could ask for help on rtpengine forum.
> 
> On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users 
> <users at lists.opensips.org> wrote:
> 
> Hello,
> 
> Could I get some feedback please? I'm really stuck :(
> 
> ---
> J
> 
> Le 29/08/2024 17:25, Julien Pawlak a écrit :
> 
> Hello
> 
> I have a problem with RTP Relay module in the initial invite request.
> 
> I have 2 rtpengine servers with both 2 interfaces, internal and 
> external.
> 
> When I add the lien below, there is no problem. Packets come and leave 
> through good interfaces.
> 
> $rtp_relay = "out-iface=internal in-iface=external"
> 
> But, when I execute the mi command to switch rtpengine server, packets 
> don't come and leave through good interfaces.
> 
> I see that I have to put this lines :
> 
> $rtp_relay(iface) = "external";
> 
> $rtp_relay_peer(iface) = "internal";
> 
> But, that doesn't work too, I have this in debug mode :
> 
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:parse_flags: in-iface value without out-iface
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:rtpe_function_call: could not parse flags
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
> 
> Please help.
> 
> Thank you
> 
> --
> J. _______________________________________________
> 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/20240906/1794e36b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20240906/1794e36b/attachment-0001.gif>

From daniel.cogo at gmail.com  Fri Sep  6 22:39:33 2024
From: daniel.cogo at gmail.com (Daniel Cogo De Vargas)
Date: Fri, 6 Sep 2024 19:39:33 -0300
Subject: [OpenSIPS-Users] Problem with TLS and Mid Registrar
Message-ID: <CANBmQegSCUthpUWeLL_6zC9CbUFJBcRAtx+5FvTtoXkonc45HA@mail.gmail.com>

I need a help.

I´m using the TLS and MID_REGISTRAR, my intention is translate TLS to UDP
and send the REGISTER and INVITE to a Asterisk.

When I use the extension TLS, REGISTER work  normally. It  send a call to
other extension (UDP  or TCP), but when the TLS extension receive a
call not work.

The error log message is:


Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112945]: new branch at
sip:1014 at voip.simple.com.br:5060
Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112944]: incoming reply
Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112945]: new branch at
sip:1014 at voip.simple.com.br:5060
Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112945]: incoming reply
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: looking up
sip:1014 at 132.226.249.251:5060;ctid=3384597829537881314!
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112945]: incoming reply
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]:
ERROR:core:tcp_connect_blocking_timeout: connect timed out, 99172 us
elapsed out of 100000 us
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]:
ERROR:core:tcp_sync_connect_fd: tcp_blocking_connect failed
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]:
ERROR:proto_tls:proto_tls_send: connect failed
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: ERROR:tm:msg_send: send()
to 10.252.252.25:58949 for proto tls/3 failed
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]:
ERROR:tm:t_forward_nonack: sending request failed
Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112945]: incoming reply


I´m using the MicrosSIP softphone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240906/47141168/attachment.html>

From vinayak.makwana at ecosmob.com  Sat Sep  7 06:46:21 2024
From: vinayak.makwana at ecosmob.com (Vinayak Makwana)
Date: Sat, 7 Sep 2024 12:16:21 +0530
Subject: [OpenSIPS-Users] Transcode DTMF specific telephone-event
Message-ID: <CAPHmyfxrUYS_VEmqvUCmkQ=mPbrGjuRahSqfo5kt4u0ChLfk2g@mail.gmail.com>

Hi all,

           I am trying to transcoding for a specific DTMF telephone-event
from opensips +rtpengine. I am using opensips 3.2.12.

Here's Call scenario :
Initial INVITE SDP ---> OpenSIPS

*       a=rtpmap:105 telephone-event/16000       a=rtpmap:100
telephone-event/8000*

>From opensips i want to add below DTMF payload 101 because B party is
accepting this DTMF payload type.
* a=rtpmap:101 telephone-event/8000 *i am using below code.
*       rtpengine_offer("transcode-telephone-event/8000");*

By using this function opensips does not transcode specific DTMF payload
101.

Is there any way to achieve this transcoding ?
Please let me know.


Regards,
Vinayak Makwana

-- 
* <https://www.ecosmob.com/ucx-expo/>
*
*Disclaimer*

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



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


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

From razvan at opensips.org  Mon Sep  9 08:29:23 2024
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Mon, 9 Sep 2024 11:29:23 +0300
Subject: [OpenSIPS-Users] RTP Relay issue
In-Reply-To: <7c7129a7bc81972f5f1759b279e12b18@pwlk.fr>
References: <tencent_38A407285B178216DAEA9062CBF0787E6106@qq.com>
 <4e68c8f555a6edfacf31e424b6e0f26b@pwlk.fr>
 <7c7129a7bc81972f5f1759b279e12b18@pwlk.fr>
Message-ID: <c430a239-449b-4306-aa9e-6c83d0d89cf8@opensips.org>

Hi, Julien!

Can you please run a test with debug logs (log_level 5) and post 
somewhere the logs?

Best regards,

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

On 9/6/24 5:46 PM, Julien Pawlak via Users wrote:
> Hi Răzvan,
> 
> I've just tested with version 3.4.8 and the situation has evolved.
> 
> This is what I have with a call of one side :
> 
> opensips conf:
> 
> $rtp_relay(iface) = "external";
> $rtp_relay_peer(iface) = "internal";
> rtp_relay_engage("rtpengine");
> 
> Debug result:
> 
> DBG:rtp_relay:rtp_relay_answer: leg=callee callid=[] ftag=[] ttag=[] 
> type=[] in-iface=[external] out-iface=[external] ctx-flags=[] flags=[] 
> peer-flags=[]
> 
> rtp_relay_list mi command:
> 
> [
> {
> "callid": "57c017bc5c8ccc3c5c29b2d57f6f0722 at x.x.x.x:5060",
> "caller": {
> "tag": "as2d4f2687",
> "interface": "external"
> },
> "callee": {
> "tag": "as2d4f2687",
> "interface": "external"
> },
> "relay": "rtpengine",
> "node": "udp:y.y.y.y:2223",
> "set": 0,
> "ctx": {
> "from-tag": "as2d4f2687",
> "to-tag": "DC09BE8B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_401C"
> }
> }
> ]
> 
> And for a call from the other side:
> 
> opensips conf:
> 
> $rtp_relay(iface) = "internal";
> $rtp_relay_peer(iface) = "external";
> rtp_relay_engage("rtpengine");
> 
> Debug result:
> 
> DBG:rtp_relay:rtp_relay_answer: leg=callee callid=[] ftag=[] ttag=[] 
> type=[] in-iface=[internal] out-iface=[internal] ctx-flags=[] flags=[] 
> peer-flags=[]
> 
> rtp_relay_list mi command:
> 
> [
> {
> "callid": "0201FFFFF1F526A9",
> "caller": {
> "tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
> "interface": "internal"
> },
> "callee": {
> "tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
> "interface": "internal"
> },
> "relay": "rtpengine",
> "node": "udp:y.y.y.y:2223",
> "set": 0,
> "ctx": {
> "from-tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
> "to-tag": "as36a555a0"
> }
> }
> ]
> 
> It seems that with this version the code just take $rtp_relay(iface) 
> value, put it into $rtp_relay_peer and ignore $rtp_relay_peer value.
> 
> Have you any other idea ?
> 
> ---
> J.
> 
> Le 06/09/2024 15:57, Julien Pawlak a écrit :
> 
>> Hi Răzvan !
>>
>> Thank you for your reply !
>>
>> Below the result of opensips -V command:
>>
>> version: opensips 3.4.6 (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: ab10b6892
>> main.c compiled on 13:42:08 Jul 30 2024 with gcc 12
>>
>> I'll try opensips version 3.4.8 (the latest) and come back to you.
>>
>> Rgds
>>
>> ---
>> J
>>
>> Le 06/09/2024 05:55, 老李-FSGUI,电话机器人 a écrit :
>>
>> Is it configured like this
>>
>> $var(rtpengine_flags) = "RTP/AVP replace-session-connection 
>> replace-origin ICE=remove address-family=IP4 out-iface=pub in-iface=pub";
>> or
>> $var(rtpengine_flags) = "RTP/AVP replace-session-connection 
>> replace-origin ICE=remove address-family=IP4 in-iface=priv 
>> out-iface=priv";
>>
>> rtpengine_offer("$var(rtpengine_flags)");
>>
>> and rtpengine param for this
>>
>> ./rtpengine -p /var/run/rtpengine.pid -i priv/172.33.1.xx -i 
>> pub/12.xx.xxx.1 -n 172.33.1.xx:60000 -c 172.33.1.xx:60001 -m 50000 -M 
>> 55000 -f -E -L 7
>>
>> -------------------------
>>
>> 老李-FSGUI,电话机器人
>> nway at foxmail.com
>>
>> ------------------ 原始邮件 ------------------
>>
>> 发件人: "Julien Pawlak" <users at lists.opensips.org>;
>> 发送时间: 2024年9月5日(星期四) 晚上10:29
>> 收件人: "Daniel Zanutti"<daniel.zanutti at gmail.com>;
>> 抄送: "OpenSIPS users mailling list"<users at lists.opensips.org>;
>> 主题: Re: [OpenSIPS-Users] RTP Relay issue
>>
>> Hello Daniel,
>>
>> Thank you for your reply !
>>
>> I don't think this problem is du to rtpengine. When i use commands 
>> rtpengine_offer, rtpengine_answer etc. all work fine. So, rtpengine 
>> side is ok. I want to use opensips rtp_relay module to simplify 
>> configuration because I have multiple rtpengine servers.
>>
>> As I wrote, when I set this in opensips configuration file :
>>
>> $rtp_relay(iface) = "internal";
>>
>> $rtp_relay_peer(iface) = "external";
>>
>> We see in opensips logs that the parameter $rtp_relay_peer(iface) = 
>> "external" does not appairs :
>>
>> => DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
>> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
>>
>> $rtp_relay(iface) = "internal"; => in-iface=[internal] => OK
>>
>> $rtp_relay_peer(iface) = "external"; => out-iface=[] => KO
>>
>> So, this error appairs : ERROR:rtpengine:parse_flags: in-iface value 
>> without out-iface :(
>>
>> ---
>> J
>>
>> Le 05/09/2024 15:46, Daniel Zanutti a écrit :
>>
>> Julien
>>
>> Since the problem is on RTP, it's related to the rtpengine you're 
>> using. Maybe you could ask for help on rtpengine forum.
>>
>> On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users 
>> <users at lists.opensips.org> wrote:
>>
>> Hello,
>>
>> Could I get some feedback please? I'm really stuck :(
>>
>> ---
>> J
>>
>> Le 29/08/2024 17:25, Julien Pawlak a écrit :
>>
>> Hello
>>
>> I have a problem with RTP Relay module in the initial invite request.
>>
>> I have 2 rtpengine servers with both 2 interfaces, internal and external.
>>
>> When I add the lien below, there is no problem. Packets come and leave 
>> through good interfaces.
>>
>> $rtp_relay = "out-iface=internal in-iface=external"
>>
>> But, when I execute the mi command to switch rtpengine server, packets 
>> don't come and leave through good interfaces.
>>
>> I see that I have to put this lines :
>>
>> $rtp_relay(iface) = "external";
>>
>> $rtp_relay_peer(iface) = "internal";
>>
>> But, that doesn't work too, I have this in debug mode :
>>
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
>> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> ERROR:rtpengine:parse_flags: in-iface value without out-iface
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> ERROR:rtpengine:rtpe_function_call: could not parse flags
>> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
>> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
>>
>> Please help.
>>
>> Thank you
>>
>> -- 
>> J. _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> Hi Răzvan,
> 
> 
> I've just tested with version 3.4.8 and the situation has evolved.
> 
> 
> This is what I have with a call of one side :
> 
> opensips conf:
> 
> $rtp_relay(iface) = "external";
> $rtp_relay_peer(iface) = "internal";
> rtp_relay_engage("rtpengine");
> 
> Debug result:
> 
> DBG:rtp_relay:rtp_relay_answer: leg=callee callid=[] ftag=[] ttag=[] 
> type=[] in-iface=[external] out-iface=[external] ctx-flags=[] flags=[] 
> peer-flags=[]
> 
> rtp_relay_list mi command:
> 
> [
> {
> "callid": "57c017bc5c8ccc3c5c29b2d57f6f0722 at x.x.x.x:5060",
> "caller": {
> "tag": "as2d4f2687",
> "interface": "external"
> },
> "callee": {
> "tag": "as2d4f2687",
> "interface": "external"
> },
> "relay": "rtpengine",
> "node": "udp:y.y.y.y:2223",
> "set": 0,
> "ctx": {
> "from-tag": "as2d4f2687",
> "to-tag": "DC09BE8B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_401C"
> }
> }
> ]
> 
> 
> And for a call from the other side:
> 
> opensips conf:
> 
> $rtp_relay(iface) = "internal";
> $rtp_relay_peer(iface) = "external";
> rtp_relay_engage("rtpengine");
> 
> Debug result:
> 
> DBG:rtp_relay:rtp_relay_answer: leg=callee callid=[] ftag=[] ttag=[] 
> type=[] in-iface=[internal] out-iface=[internal] ctx-flags=[] flags=[] 
> peer-flags=[]
> 
> rtp_relay_list mi command:
> 
> [
> {
> "callid": "0201FFFFF1F526A9",
> "caller": {
> "tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
> "interface": "internal"
> },
> "callee": {
> "tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
> "interface": "internal"
> },
> "relay": "rtpengine",
> "node": "udp:y.y.y.y:2223",
> "set": 0,
> "ctx": {
> "from-tag": "0E0AD956_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_4125",
> "to-tag": "as36a555a0"
> }
> }
> ]
> 
> 
> It seems that with this version the code just take $rtp_relay(iface) 
> value, put it into $rtp_relay_peer and ignore $rtp_relay_peer value.
> 
> 
> Have you any other idea ?
> 
> ---
> J.
> 
> 
> Le 06/09/2024 15:57, Julien Pawlak a écrit :
> 
>> Hi Răzvan !
>>
>>
>> Thank you for your reply !
>>
>>
>> Below the result of opensips -V command:
>>
>> version: opensips 3.4.6 (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: ab10b6892
>> main.c compiled on 13:42:08 Jul 30 2024 with gcc 12
>>
>>
>> I'll try opensips version 3.4.8 (the latest) and come back to you.
>>
>>
>> Rgds
>>
>> ---
>> J
>>
>>
>> Le 06/09/2024 05:55, 老李-FSGUI,电话机器人 a écrit :
>>
>>     Is it configured like this
>>     $var(rtpengine_flags) ="RTP/AVP replace-session-connection
>>     replace-origin ICE=remove address-family=IP4 out-iface=pub
>>     in-iface=pub";
>>     or
>>     $var(rtpengine_flags) ="RTP/AVP replace-session-connection
>>     replace-origin ICE=remove address-family=IP4 in-iface=priv
>>     out-iface=priv";
>>     rtpengine_offer("$var(rtpengine_flags)");
>>     and rtpengine param for this
>>     ./rtpengine -p /var/run/rtpengine.pid -i priv/172.33.1.xx -i
>>     pub/12.xx.xxx.1 -n 172.33.1.xx:60000 -c 172.33.1.xx:60001 -m 50000
>>     -M 55000 -f -E -L 7
>>     ------------------------------------------------------------------------
>>     	
>>     老李-FSGUI,电话机器人
>>     nway at foxmail.com
>>
>>     ------------------ 原始邮件 ------------------
>>     *发件人:* "Julien Pawlak" <users at lists.opensips.org>;
>>     *发送时间:* 2024年9月5日(星期四) 晚上10:29
>>     *收件人:* "Daniel Zanutti"<daniel.zanutti at gmail.com>;
>>     *抄送:* "OpenSIPS users mailling list"<users at lists.opensips.org>;
>>     *主题:* Re: [OpenSIPS-Users] RTP Relay issue
>>
>>     Hello Daniel,
>>
>>
>>     Thank you for your reply !
>>
>>
>>     I don't think this problem is du to rtpengine. When i use commands
>>     rtpengine_offer, rtpengine_answer etc. all work fine. So,
>>     rtpengine side is ok. I want to use opensips rtp_relay module to
>>     simplify configuration because I have multiple rtpengine servers.
>>
>>
>>     As I wrote, when I set this in opensips configuration file :
>>
>>     $rtp_relay(iface) = "internal";
>>
>>     $rtp_relay_peer(iface) = "external";
>>
>>
>>     We see in opensips logs that the parameter $rtp_relay_peer(iface)
>>     = "external" does not appairs :
>>
>>     => DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[]
>>     type=[] in-iface=[internal] out-iface=[] ctx-flags=[] flags=[]
>>     peer-flags=[]
>>
>>
>>     $rtp_relay(iface) = "internal"; => in-iface=[internal] => OK
>>
>>     $rtp_relay_peer(iface) = "external"; => out-iface=[] => KO
>>
>>
>>     So, this error appairs : ERROR:rtpengine:parse_flags: in-iface
>>     value without out-iface :(
>>
>>     ---
>>     J
>>
>>     Le 05/09/2024 15:46, Daniel Zanutti a écrit :
>>
>>         Julien
>>         Since the problem is on RTP, it's related to the rtpengine
>>         you're using. Maybe you could ask for help on rtpengine forum.
>>
>>         On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users
>>         <users at lists.opensips.org <mailto:users at lists.opensips.org>>
>>         wrote:
>>
>>             Hello,
>>
>>             Could I get some feedback please? I'm really stuck :(
>>
>>             ---
>>             J
>>
>>
>>             Le 29/08/2024 17:25, Julien Pawlak a écrit :
>>
>>                 Hello
>>
>>
>>                 I have a problem with RTP Relay module in the initial
>>                 invite request.
>>
>>                 I have 2 rtpengine servers with both 2 interfaces,
>>                 internal and external.
>>
>>
>>                 When I add the lien below, there is no problem.
>>                 Packets come and leave through good interfaces.
>>
>>                 $rtp_relay = "out-iface=internal in-iface=external"
>>
>>                 But, when I execute the mi command to switch rtpengine
>>                 server, packets don't come and leave through good
>>                 interfaces.
>>
>>
>>                 I see that I have to put this lines :
>>
>>                 $rtp_relay(iface) = "external";
>>
>>                 $rtp_relay_peer(iface) = "internal";
>>
>>
>>                 But, that doesn't work too, I have this in debug mode :
>>
>>                 août 29 17:04:44 opensips-1
>>                 /usr/local/sbin/opensips[844747]:
>>                 DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[]
>>                 ttag=[] type=[] *in-iface=[internal] out-iface=[]*
>>                 ctx-flags=[] flags=[] peer-flags=[]
>>                 août 29 17:04:44 opensips-1
>>                 /usr/local/sbin/opensips[844747]:
>>                 ERROR:rtpengine:parse_flags: in-iface value without
>>                 out-iface
>>                 août 29 17:04:44 opensips-1
>>                 /usr/local/sbin/opensips[844747]:
>>                 ERROR:rtpengine:rtpe_function_call: could not parse flags
>>                 août 29 17:04:44 opensips-1
>>                 /usr/local/sbin/opensips[844747]:
>>                 ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
>>
>>
>>                 Please help.
>>
>>
>>                 Thank you
>>
>>
>>                 -- 
>>                 J.
>>
>>             _______________________________________________
>>             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


From razvan at opensips.org  Mon Sep  9 08:34:59 2024
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Mon, 9 Sep 2024 11:34:59 +0300
Subject: [OpenSIPS-Users] dr_reload via Control-Panel not working
In-Reply-To: <CAPc6LUGwcsX38gTjK_FMi-x9r40Y4tdRmZNc45=ZE7SPiStiwQ@mail.gmail.com>
References: <CAPc6LUEzM5iE_eR5i=_+G_dBfefDLi3jATZ8JpN+C9H34-xjaA@mail.gmail.com>
 <f8751e2a-c9cf-41a6-b897-c50fc9aa5dd9@opensips.org>
 <CAPc6LUGwcsX38gTjK_FMi-x9r40Y4tdRmZNc45=ZE7SPiStiwQ@mail.gmail.com>
Message-ID: <25a8314f-8a19-4695-849c-dfba09fd5245@opensips.org>

Can you please post somewhere debug logs of the reload?

Best regards,

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

On 9/6/24 1:41 PM, Alexey wrote:
> OpenSIPS 3.2.17
> 


From julien at pwlk.fr  Mon Sep  9 12:39:41 2024
From: julien at pwlk.fr (Julien Pawlak)
Date: Mon, 09 Sep 2024 14:39:41 +0200
Subject: [OpenSIPS-Users]  RTP Relay issue
In-Reply-To: <CAN0jgiNb++e=tBJC8EejFfaRa5D94AB+MBoi=P2XsQGLsa9gQQ@mail.gmail.com>
References: <72632a7847a2864754bd7a847ad73834@pwlk.fr>
 <3c2e2bf8fa1691566afecad6fa8cce19@pwlk.fr>
 <CAN0jgiNb++e=tBJC8EejFfaRa5D94AB+MBoi=P2XsQGLsa9gQQ@mail.gmail.com>
Message-ID: <451b6fe4e77e4c2428c107c365f4c225@pwlk.fr>

Hi Răzvan,

You can see logs here : https://qtext.io/7i6d

Tell me if you need something else.

Thank you for your help!

---
Julien Pawlak

Le 05/09/2024 15:46, Daniel Zanutti a écrit :

> Julien
> 
> Since the problem is on RTP, it's related to the rtpengine you're 
> using. Maybe you could ask for help on rtpengine forum.
> 
> On Thu, Sep 5, 2024 at 8:50 AM Julien Pawlak via Users 
> <users at lists.opensips.org> wrote:
> 
> Hello,
> 
> Could I get some feedback please? I'm really stuck :(
> 
> ---
> J
> 
> Le 29/08/2024 17:25, Julien Pawlak a écrit :
> 
> Hello
> 
> I have a problem with RTP Relay module in the initial invite request.
> 
> I have 2 rtpengine servers with both 2 interfaces, internal and 
> external.
> 
> When I add the lien below, there is no problem. Packets come and leave 
> through good interfaces.
> 
> $rtp_relay = "out-iface=internal in-iface=external"
> 
> But, when I execute the mi command to switch rtpengine server, packets 
> don't come and leave through good interfaces.
> 
> I see that I have to put this lines :
> 
> $rtp_relay(iface) = "external";
> 
> $rtp_relay_peer(iface) = "internal";
> 
> But, that doesn't work too, I have this in debug mode :
> 
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> DBG:rtp_relay:rtp_relay_offer: callid=[] ftag=[] ttag=[] type=[] 
> in-iface=[internal] out-iface=[] ctx-flags=[] flags=[] peer-flags=[]
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:parse_flags: in-iface value without out-iface
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtpengine:rtpe_function_call: could not parse flags
> août 29 17:04:44 opensips-1 /usr/local/sbin/opensips[844747]: 
> ERROR:rtp_relay:rtp_relay_offer: could not engage offer!
> 
> Please help.
> 
> Thank you
> 
> --
> J. _______________________________________________
> 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/20240909/9aa65271/attachment.html>

From aronp at guaranteedplus.com  Mon Sep  9 18:58:33 2024
From: aronp at guaranteedplus.com (Podrigal, Aron)
Date: Mon, 9 Sep 2024 13:58:33 -0500
Subject: [OpenSIPS-Users] Issue with CRL Validation in French
	STIR/SHAKEN Implementation
In-Reply-To: <CA+fRVSUQ3b_QeSwLWT94bkTnXXFYFb279O0i0P3H6bWpEs8cYw@mail.gmail.com>
References: <MR1P264MB35855CB7BCE5F3CDA020C4C8CE0CA@MR1P264MB3585.FRAP264.PROD.OUTLOOK.COM>
 <CA+fRVSUQ3b_QeSwLWT94bkTnXXFYFb279O0i0P3H6bWpEs8cYw@mail.gmail.com>
Message-ID: <CANJp-yiephw4g7SUOwbLPS9cpBgx2XXEOKzntwy8OcWts=HMBQ@mail.gmail.com>

Hi

I think I am facing the same problem.


On Thu, Aug 10, 2023 at 4:46 AM Mickael Hubert <mickael at winlux.fr> wrote:

> Hi all,
> Thanks Wadii for your help (in private ;) )
> I developed a solution to check CRL in an external process (python script
> scheduled by AWX).
>
> My python script (download only in memory, not on disk)
> *For CA certificates:*
> - Download CA et intermediate certs
> - Download PA cert (pa cert is used to sign CRL)
> - Download CA CRL
> - Check if CA or intermediate cert are revoked
> - I use ansible (AWX) to write CA et intermediate certs into opensips disk
> - Ansible restart opensips only if CA or intermediate cert change
>
> *For provider certificate (BPCO):*
> - Download provider certificates that are in tar.gz (only in memory)
> - Uncompress tar.gz and create a dict with data (cert data, cert id,
> provider id)
> - Download CRL for provider certificates
> - Check all provider certificates signatures (not necessary, because
> opensips can do that for each call)
> - Check if cert is revoked
> - Extract metadata and add them to dict
> - Ansible parses this dict and push each line in mysql cache DB
> (sql_cacher module)
>
> Ex of dict:
> {
>   "126881e75888888": {
>     "provider_code": "PROV00",
>     "cert_data": "-----BEGIN CERTIFICATE-----.........\n-----END
> CERTIFICATE-----\n",
>     "not_before": "20230815220000Z",
>     "not_after": "20240814215959Z",
>     "has_expired": false,
>     "valid": false,
>     "revoked": true,
>     "revoked_date": "20230809151920Z"
>   }
> }
>
> Thanks to that, when call is processed by opensips, it gets in its cache
> the correct data, if revoked == true, force $rc = -7 (
> https://github.com/OpenSIPS/sipssert-opensips-tests/blob/1313d03b6ecd1972f9d2facf69116c418fb40399/stir-shaken/04.verify-200/stir_shaken_verify.cfg#L135)
> to send a correct error code 437 Unsupported Credential)
>
> Maybe that can help my french friends voip providers ;)
>
> Have a good day
>
>
> Le lun. 7 août 2023 à 09:29, Wadii ELMAJDI | Evenmedia <wadii at evenmedia.fr>
> a écrit :
>
>> Hello
>>
>>
>>
>> I have run into a problem with the STIR/SHAKEN verification process.
>>
>> In the French implementation of StirShaken, the CRL of the operator
>> certificates is signed with a certificate that is different from the one
>> used to sign providers certificates.
>> and in such case, OpenSSL does not allow in one command to validate the
>> entire certification chain.
>>
>> Also, OPENSIPS stirshaken module's stir_shaken_verify function fails to
>> validate providers certificate (with CRL Loaded)
>>
>>
>>
>> Error : certificate validation failed: unable to get certificate CRL
>>
>>
>>
>> For now, following the guidelines suggested by the French authority
>> handling STIR/SHAKEN, we are planning to implement a two-step approach to
>> check CRL before stir_shaken_verify kicks in (w/o CRL loaded)
>>
>> First, we verify the certification chain of the provider's certificate,
>> plus making sure CA’s certificates are not revoked. We do this using a
>> command like:
>>
>>
>>
>> openssl verify -CAfile /etc/opensips/example_certs/ca_list.pem -untrusted
>> /etc/opensips/example_certs/example_pa.pem -extended_crl -crl_check_all
>> -CRLfile /etc/opensips/example_certs/crl_list.pem
>> /etc/opensips/example_certs/ProviderCertificate.cer
>>
>>
>>
>> Where example_pa.pem is the certificate used to sign CRL of providers
>> certificates, and crl_list : the concatenation of both providers and CA’s
>> CRLs in PEM format.
>>
>> The second step involves a separate check to verify if the provider’s
>> certificate is revoked :
>>
>>
>>
>> openssl crl -in /etc/opensips/example_certs/crl_list.pem -noout -text |
>> grep $(openssl x509 -in /etc/opensips/example_certs/ProviderCertificate.cer
>> -noout -serial | cut -d '=' -f 2)
>>
>>
>>
>> This will add an extra processing time due to a double certification
>> validation (ran by both by openssl and stir_shaken_verify)  + reading crls
>> from disk.
>>
>>
>>
>> Given this situation, it would be highly beneficial if Opensips could
>> accommodate cases where revocation lists are signed with a different
>> certificate. This would not only simplify the verification process but also
>> improve compatibility for similar future scenarios (like a complex
>> certificate hierarchy)
>>
>>
>>
>> Suggestion :
>>
>>
>>
>> Consider adding an exported parameter, such as :
>>
>> modparam("stir_shaken", "crl_signing_certs",
>> "/stir_certs/crl_signing_certs.pem")
>>
>>
>>
>> This parameter would allow users to specify a list of separate
>> certificates used to sign the CRLs, in cases where the CRLs and the
>> provider certificates are not signed by the same certificate.
>> _______________________________________________
>> 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
>


-- 

-
Aron Podrigal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240909/da10d329/attachment-0001.html>

From slackway2me at gmail.com  Tue Sep 10 07:14:02 2024
From: slackway2me at gmail.com (Alexey)
Date: Tue, 10 Sep 2024 12:14:02 +0500
Subject: [OpenSIPS-Users] uac_registrant issue
Message-ID: <CAPc6LUEsOUHPfUAZPXpo0BBx4o=kGVH9wEOPVYMoiAJ1cpFgaA@mail.gmail.com>

Hi list,
we're using the 3.2.17 version.

I've noticed that sometimes (seems to be not always)
there's an error in OpenSIPS log after doing
'opensips-cli -x mi reg_reload':

ERROR:uac_registrant:reg_tm_cback: record [0x7fce2e313aa8] not found
on hash index [32]
ERROR:uac_registrant:reg_tm_cback: record [0x7fce2e314018] not found
on hash index [34]
ERROR:uac_registrant:reg_tm_cback: record [0x7fce2e313d60] not found
on hash index [35]

What may be the reason?

-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From slackway2me at gmail.com  Tue Sep 10 10:55:33 2024
From: slackway2me at gmail.com (Alexey)
Date: Tue, 10 Sep 2024 15:55:33 +0500
Subject: [OpenSIPS-Users] uac_registrant issue
Message-ID: <CAPc6LUHYmaYZCnE2vRx1DT3rpMhFvWjXwBDphmF--_5y8FZ+dg@mail.gmail.com>

Reloaded again, twice within 10 minutes,
now everything is OK, no errors in log.

Maybe it was some DB-related issue...

Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db
Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db
Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db
Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db
Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db
Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db
Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db
Sep 10 10:51:38 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [35] records from
db



-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From slackway2me at gmail.com  Tue Sep 10 11:58:54 2024
From: slackway2me at gmail.com (Alexey)
Date: Tue, 10 Sep 2024 16:58:54 +0500
Subject: [OpenSIPS-Users] uac_registrant issue
In-Reply-To: <CAPc6LUHYmaYZCnE2vRx1DT3rpMhFvWjXwBDphmF--_5y8FZ+dg@mail.gmail.com>
References: <CAPc6LUHYmaYZCnE2vRx1DT3rpMhFvWjXwBDphmF--_5y8FZ+dg@mail.gmail.com>
Message-ID: <CAPc6LUH=-Tsiju5y5FeyKpbwJ9WgqoaO_SQEo0-pYogtUu1yeA@mail.gmail.com>

but suddenly again such an error:


11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db

11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db

11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db

11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db

11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db

11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db

11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
db

11:49:37 sipgw [2348879] info
INFO:uac_registrant:load_reg_info_from_db: loading [33] records from
db

11:49:41 sipgw [2348899] err  ERROR:uac_registrant:reg_tm_cback:
record [0x7f0ccf957e60] not found on hash index [16]

11:49:43 sipgw [2348892] err  ERROR:uac_registrant:reg_tm_cback:
record [0x7f0ccfdffbd8] not found on hash index [18]



-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From slackway2me at gmail.com  Tue Sep 10 12:01:58 2024
From: slackway2me at gmail.com (Alexey)
Date: Tue, 10 Sep 2024 17:01:58 +0500
Subject: [OpenSIPS-Users] dr_reload via Control-Panel not working
In-Reply-To: <25a8314f-8a19-4695-849c-dfba09fd5245@opensips.org>
References: <CAPc6LUEzM5iE_eR5i=_+G_dBfefDLi3jATZ8JpN+C9H34-xjaA@mail.gmail.com>
 <f8751e2a-c9cf-41a6-b897-c50fc9aa5dd9@opensips.org>
 <CAPc6LUGwcsX38gTjK_FMi-x9r40Y4tdRmZNc45=ZE7SPiStiwQ@mail.gmail.com>
 <25a8314f-8a19-4695-849c-dfba09fd5245@opensips.org>
Message-ID: <CAPc6LUFHhQcCP+gNkuVBAfY+NOpA4SbPcuuM5sNEMzZ--r1bFg@mail.gmail.com>

Hi Răzvan,

sure, I'll try, if it will be possible to catch this moment,
as it is not always


-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From aronp at guaranteedplus.com  Wed Sep 11 19:52:16 2024
From: aronp at guaranteedplus.com (Podrigal, Aron)
Date: Wed, 11 Sep 2024 14:52:16 -0500
Subject: [OpenSIPS-Users] opensips CRASH in random locations - easily
	reproducible
Message-ID: <CANJp-yhOoh2qfU_tm7YUiiLve0ZOqoXehNvde8WggONwXchWJg@mail.gmail.com>

I have 2 opensips lets call them *SIPA * and *SIPB *

*Client ----> SIPA  ---> SIPB --->  SIPA |*

*                                         |                    |
                             ^                   |*
*                                         | _  403  _  <-*

Client sends a few sip messages and at some point *SIPA* crashes with

Below are relevant logs

Any idea where to start with? I think that this is somehow caused by
compression module.

Sep 11 19:20:44 [341893] DBG:core:dup_ref_script_route_in_shm: dupping
0x762ee3a559a8 [CACHE_FETCH_GEO_META], idx 17, ver/cnt 1, to new
0x762ee2549088 [CACHE_FETCH_GEO_META], idx 17, ver/cnt 1
Sep 11 19:20:44 [341893] DBG:tm:t_handle_async: placing async job into
reactor with timeouts 0/0
Sep 11 19:20:44 [341893] DBG:tm:io_watch_add: [UDP_worker] io_watch_add op
(52 on 48) (0x615232bc1cc0, 52, 16, 0x762ee2548ff8,1), fd_no=5/1024
Sep 11 19:20:44 [341893] CRITICAL:core:sig_usr: segfault in process pid:
341893, id: 6
Sep 11 19:20:44 [341893] DBG:core:restore_segv_handler: restoring SIGSEGV
handler...
Sep 11 19:20:44 [341893] DBG:core:restore_segv_handler: successfully
restored system SIGSEGV handler
Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
count: 0!=-1 for hash  33
Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
count: 0!=1 for hash  41
Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
count: 0!=-1 for hash  97
Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
count: 0!=1 for hash 105
Sep 11 19:20:44 [341895] DBG:core:db_init_async: >>    4/10 transfers: (54
- 0x762ee3ae9aa8)

-- 

-
Aron Podrigal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240911/de125f19/attachment.html>

From jehanzaib.kiani at gmail.com  Wed Sep 11 20:19:20 2024
From: jehanzaib.kiani at gmail.com (Jehanzaib Younis)
Date: Thu, 12 Sep 2024 08:19:20 +1200
Subject: [OpenSIPS-Users] opensips CRASH in random locations - easily
	reproducible
In-Reply-To: <CANJp-yhOoh2qfU_tm7YUiiLve0ZOqoXehNvde8WggONwXchWJg@mail.gmail.com>
References: <CANJp-yhOoh2qfU_tm7YUiiLve0ZOqoXehNvde8WggONwXchWJg@mail.gmail.com>
Message-ID: <CAKrJzCwESbaTe0FsueD6CHX=NuZAONjngV6+G_giF+xWELCdQA@mail.gmail.com>

Hi Aron,

What is your opensips version?
As this is a segmentation fault you will have the core dump file. it its
configured it will be good to analyze the core dump.

Regards,
Jehanzaib


On Thu, Sep 12, 2024 at 7:52 AM Podrigal, Aron <aronp at guaranteedplus.com>
wrote:

> I have 2 opensips lets call them *SIPA * and *SIPB *
>
> *Client ----> SIPA  ---> SIPB --->  SIPA |*
>
> *                                         |                    |
>                                ^                   |*
> *                                         | _  403  _  <-*
>
> Client sends a few sip messages and at some point *SIPA* crashes with
>
> Below are relevant logs
>
> Any idea where to start with? I think that this is somehow caused by
> compression module.
>
> Sep 11 19:20:44 [341893] DBG:core:dup_ref_script_route_in_shm: dupping
> 0x762ee3a559a8 [CACHE_FETCH_GEO_META], idx 17, ver/cnt 1, to new
> 0x762ee2549088 [CACHE_FETCH_GEO_META], idx 17, ver/cnt 1
> Sep 11 19:20:44 [341893] DBG:tm:t_handle_async: placing async job into
> reactor with timeouts 0/0
> Sep 11 19:20:44 [341893] DBG:tm:io_watch_add: [UDP_worker] io_watch_add op
> (52 on 48) (0x615232bc1cc0, 52, 16, 0x762ee2548ff8,1), fd_no=5/1024
> Sep 11 19:20:44 [341893] CRITICAL:core:sig_usr: segfault in process pid:
> 341893, id: 6
> Sep 11 19:20:44 [341893] DBG:core:restore_segv_handler: restoring SIGSEGV
> handler...
> Sep 11 19:20:44 [341893] DBG:core:restore_segv_handler: successfully
> restored system SIGSEGV handler
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
> count: 0!=-1 for hash  33
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
> count: 0!=1 for hash  41
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
> count: 0!=-1 for hash  97
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag.
> count: 0!=1 for hash 105
> Sep 11 19:20:44 [341895] DBG:core:db_init_async: >>    4/10 transfers: (54
> - 0x762ee3ae9aa8)
>
> --
>
> -
> Aron Podrigal
>
> _______________________________________________
> 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/20240912/d2d8f31f/attachment.html>

From pkelly at gmail.com  Thu Sep 12 15:06:09 2024
From: pkelly at gmail.com (Pete Kelly)
Date: Thu, 12 Sep 2024 17:06:09 +0200
Subject: [OpenSIPS-Users] Dropping all branches...
Message-ID: <CAEWH9M9mkHji4-HANf+PpNBxgkfF3_eY-uJ_yeL_Gt29hg0HmA@mail.gmail.com>

Good afternoon.

I have a situation where I have a number of branches for a call, within
each branch I am performing some checks and the result of those checks will
mean that the branch gets dropped (with drop()) or allowed to continue.

However if *all* branches are dropped, a standard "500 Server error
occurred (1/TM)” message is sent upstream.

Is there a way to customise this 500 error?

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

From bogdan at opensips.org  Fri Sep 13 06:04:38 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 13 Sep 2024 09:04:38 +0300
Subject: [OpenSIPS-Users] Dropping all branches...
In-Reply-To: <CAEWH9M9mkHji4-HANf+PpNBxgkfF3_eY-uJ_yeL_Gt29hg0HmA@mail.gmail.com>
References: <CAEWH9M9mkHji4-HANf+PpNBxgkfF3_eY-uJ_yeL_Gt29hg0HmA@mail.gmail.com>
Message-ID: <bc20fba0-6a65-47fc-9bb3-140cb8d8cf19@opensips.org>

Hi Pete,

The 500 reply is generated within the t_relay(), if no branches are sent 
out. A way to deal with this is to pass the 0x02 flag to t_relay(), to 
force it to report the error to the script, rather than automatically 
generated some err reply back. So t_relay() will fail and based on the 
retcode you can generate something else back to the caller.

Regards,

Bogdan-Andrei Iancu

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

On 12.09.2024 18:06, Pete Kelly wrote:
> Good afternoon.
>
> I have a situation where I have a number of branches for a call, 
> within each branch I am performing some checks and the result of those 
> checks will mean that the branch gets dropped (with drop()) or allowed 
> to continue.
>
> However if /all/ branches are dropped, a standard "500 Server error 
> occurred (1/TM)” message is sent upstream.
>
> Is there a way to customise this 500 error?
>
> Pete
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240913/341ba08c/attachment.html>

From bogdan at opensips.org  Fri Sep 13 06:06:38 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 13 Sep 2024 09:06:38 +0300
Subject: [OpenSIPS-Users] opensips CRASH in random locations - easily
 reproducible
In-Reply-To: <CANJp-yhOoh2qfU_tm7YUiiLve0ZOqoXehNvde8WggONwXchWJg@mail.gmail.com>
References: <CANJp-yhOoh2qfU_tm7YUiiLve0ZOqoXehNvde8WggONwXchWJg@mail.gmail.com>
Message-ID: <4a114163-718f-4213-90f1-3e09f979fa00@opensips.org>

Aron, try to follow this:
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.09.2024 22:52, Podrigal, Aron wrote:
> I have 2 opensips lets call them *SIPA * and *SIPB *
> *
> *
> *Client ----> SIPA  ---> SIPB --->  SIPA |*
> *                                         |       |
>                                          ^  |*
> *                                         | _  403  _ <-*
> *
> *
> Client sends a few sip messages and at some point *SIPA* crashes with
>
> Below are relevant logs
>
> Any idea where to start with? I think that this is somehow caused by 
> compression module.
>
> Sep 11 19:20:44 [341893] DBG:core:dup_ref_script_route_in_shm: dupping 
> 0x762ee3a559a8 [CACHE_FETCH_GEO_META], idx 17, ver/cnt 1, to new 
> 0x762ee2549088 [CACHE_FETCH_GEO_META], idx 17, ver/cnt 1
> Sep 11 19:20:44 [341893] DBG:tm:t_handle_async: placing async job into 
> reactor with timeouts 0/0
> Sep 11 19:20:44 [341893] DBG:tm:io_watch_add: [UDP_worker] 
> io_watch_add op (52 on 48) (0x615232bc1cc0, 52, 16, 0x762ee2548ff8,1), 
> fd_no=5/1024
> Sep 11 19:20:44 [341893] CRITICAL:core:sig_usr: segfault in process 
> pid: 341893, id: 6
> Sep 11 19:20:44 [341893] DBG:core:restore_segv_handler: restoring 
> SIGSEGV handler...
> Sep 11 19:20:44 [341893] DBG:core:restore_segv_handler: successfully 
> restored system SIGSEGV handler
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag. 
> count: 0!=-1 for hash  33
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag. 
> count: 0!=1 for hash  41
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag. 
> count: 0!=-1 for hash  97
> Sep 11 19:20:44 [341893] CRITICAL:core:fm_status: different free frag. 
> count: 0!=1 for hash 105
> Sep 11 19:20:44 [341895] DBG:core:db_init_async: >>  4/10 transfers: 
> (54 - 0x762ee3ae9aa8)
>
> -- 
>
> -
> Aron Podrigal
>
>
> _______________________________________________
> 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/20240913/8c719942/attachment.html>

From bogdan at opensips.org  Fri Sep 13 09:16:27 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 13 Sep 2024 12:16:27 +0300
Subject: [OpenSIPS-Users] uac_registrant issue
In-Reply-To: <CAPc6LUH=-Tsiju5y5FeyKpbwJ9WgqoaO_SQEo0-pYogtUu1yeA@mail.gmail.com>
References: <CAPc6LUHYmaYZCnE2vRx1DT3rpMhFvWjXwBDphmF--_5y8FZ+dg@mail.gmail.com>
 <CAPc6LUH=-Tsiju5y5FeyKpbwJ9WgqoaO_SQEo0-pYogtUu1yeA@mail.gmail.com>
Message-ID: <dcaa4f08-d988-45f6-9942-2d6961e839f1@opensips.org>

Hi Alexey,

What may happen is : the module fires some REGISTER requests and the 
replying is slow. While still waiting for the reply, you do a reload 
(pointers for structures do change), so the later incoming reply will 
not match the record that fired the request.

Regards,

Bogdan-Andrei Iancu

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

On 10.09.2024 14:58, Alexey wrote:
> but suddenly again such an error:
>
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
> db
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
> db
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
> db
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
> db
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
> db
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
> db
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [128] records from
> db
>
> 11:49:37 sipgw [2348879] info
> INFO:uac_registrant:load_reg_info_from_db: loading [33] records from
> db
>
> 11:49:41 sipgw [2348899] err  ERROR:uac_registrant:reg_tm_cback:
> record [0x7f0ccf957e60] not found on hash index [16]
>
> 11:49:43 sipgw [2348892] err  ERROR:uac_registrant:reg_tm_cback:
> record [0x7f0ccfdffbd8] not found on hash index [18]
>
>
>



From slackway2me at gmail.com  Fri Sep 13 11:58:25 2024
From: slackway2me at gmail.com (Alexey)
Date: Fri, 13 Sep 2024 16:58:25 +0500
Subject: [OpenSIPS-Users] uac_registrant issue
In-Reply-To: <dcaa4f08-d988-45f6-9942-2d6961e839f1@opensips.org>
References: <CAPc6LUHYmaYZCnE2vRx1DT3rpMhFvWjXwBDphmF--_5y8FZ+dg@mail.gmail.com>
 <CAPc6LUH=-Tsiju5y5FeyKpbwJ9WgqoaO_SQEo0-pYogtUu1yeA@mail.gmail.com>
 <dcaa4f08-d988-45f6-9942-2d6961e839f1@opensips.org>
Message-ID: <CAPc6LUFkjitUyfTeoUAKg58fh-m0xrKFDcgYTpM0sws4giZ+3w@mail.gmail.com>

Hi Bogdan,

Thank you for the comprehensive answer.


-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From alain.bieuzent at free.fr  Tue Sep 17 16:03:34 2024
From: alain.bieuzent at free.fr (Alain Bieuzent)
Date: Tue, 17 Sep 2024 18:03:34 +0200
Subject: [OpenSIPS-Users] RTPENGINE flag (substitute)
Message-ID: <46C71BFB-D9BF-485D-962F-B4DBBD2E6072@free.fr>

Hello all,

 

I know I'm not on an rtpengine support group, but the atmosphere is nicer here ;)

is that someone could give me the correct syntax of the flag to give to rtpengine to convert:

 

from : a=fmtp:96 0-16 to a=fmtp:96 0-15.

 

The rtpengine documentation is not clear about the substitute function

 

Thanks in advance

 

Alain

 

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

From aronp at guaranteedplus.com  Wed Sep 18 01:21:11 2024
From: aronp at guaranteedplus.com (Podrigal, Aron)
Date: Tue, 17 Sep 2024 20:21:11 -0500
Subject: [OpenSIPS-Users] rtp_relay_engage() Handling
Message-ID: <CANJp-yj4bKm6TDAaMpAfESxkb-isNVOv=kf7Ksw6QQDynpbfKA@mail.gmail.com>

Hi All,

I am trying to use rtp_relay_engage(). However, what happens when / if
there was a failure, since the internal method being used is by hooking
into TM with a callback on TMCB_REQUEST_FWDED, even though the offer /
rtpengine was down, the message is being relayed with the initial SDP.

Is there a way to stop / cancel the relay if there was an error?

-- 

-
Aron Podrigal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240917/c1f404a2/attachment.html>

From rob.dyck at telus.net  Wed Sep 18 17:24:11 2024
From: rob.dyck at telus.net (Robert Dyck)
Date: Wed, 18 Sep 2024 10:24:11 -0700
Subject: [OpenSIPS-Users] Nathelper vs Nat_traversal
Message-ID: <7597159.9J7NaK4W3v@leno.mylan>

I am reaching out to users and developers.

I read that nat_traversal was supposed to replace nathelper. It appears that 
they have co-existed for many versions now. Nat_traversal is supposed to 
overcome NAT issues in a multi proxy environment.

Looking at the functions provided by the two modules it doesn't look like 
nathelper's functionality has been completely replicated in nat_traversal.

Is anyone using nat_traversal, possibly with also nathelper?




From bogdan at opensips.org  Fri Sep 20 06:10:38 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 20 Sep 2024 09:10:38 +0300
Subject: [OpenSIPS-Users] OpenSIPS Bootcamp 2024 - Startup Special Discounts
Message-ID: <8d3a7cbd-6654-4a78-9c99-2a344bcf9962@opensips.org>

<https://opensips.org/training/OpenSIPS_eBootcamp_2024/>


      Startup Special Discounts


           Train Your Team on SIP with 50% Off



*Enroll _by September 30th_ and give your team the skills to enhance 
your SIP infrastructure.

*

Empower your startup’s team with essential SIP infrastructure skills 
through the OpenSIPS eBootcamp 
<https://opensips.org/training/OpenSIPS_eBootcamp_2024/>, now at *50% 
off for startups*. This *limited-time offer* is available to companies 
with *less than 3 years in operation*. To apply, simply provide your 
TechCrunch or Crunchbase  profile and proof of affiliation with an 
accelerator (e.g. YCombinator, Techstarts and many others). This is your 
chance to gain advanced VoIP knowledge and scale your business.
Hurry, the offer expires on September 30! Send an email with your info 
to bootcamp at opensips.org and we will return a promo code for this offer.

Register Now 
<https://opensips.org/training/OpenSIPS_eBootcamp_2024/#mu-pricing>

Any questions? do not hesitate to contact us <mailto:bootcamp at opensips.org>!

------------------------------------------------------------------------
You received this email as part of your relationship with the OpenSIPS 
Project.
If you do not want to receive any more news, please email to unsubscribe 
<mailto:news-leave at lists.opensips.org?Subject=Unsubscribe>.


-- 
   Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240920/f1454ded/attachment.html>

From alberto.rinaudo at gmail.com  Sun Sep 22 00:10:50 2024
From: alberto.rinaudo at gmail.com (Alberto)
Date: Sun, 22 Sep 2024 01:10:50 +0100
Subject: [OpenSIPS-Users] registrant example
Message-ID: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>

Hi,

I'm trying to put together a simple script to use uac_registrant
So I have:
LEFT SIP SERVERS <-[ip authentication]-> OPENSIPS <-[uac_registrant]->
REMOTE SIP PROVIDER

Here's the 2 problems I still have:
I have the users for the remote sip provider in the registrant table, and
opensips is already able to register to this remote sip provider,but:
- When an INVITE comes from the remote sip provider I register to, how do I
validate which user is it related to? Where should I store avp, and how
should I load them?
- When an INVITE comes from the left sip servers and I have to call the
remote sip provider, how do I load the credentials from the database to
authenticate the INVITE to the remote sip provider?

I'm using the address table for the left sip servers and check_address, but
I've stripped all that from my example below.
I hope this makes sense, thank you.

Here is a short example script I'm working with

#######
debug_mode=no

log_level=2
xlog_level=2
log_stdout=yes
stderror_enabled=yes
syslog_facility=LOG_LOCAL0

auto_aliases=no

server_signature=yes

socket=udp:0.0.0.0:5060

mpath="/usr/lib64/opensips/modules/"

loadmodule "db_mysql.so"

loadmodule "signaling.so"

loadmodule "sl.so"

loadmodule "tm.so"
modparam("tm", "auto_100trying", 0)
modparam("tm", "fr_inv_timeout", 120)
modparam("tm", "fr_timeout", 30)
modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "restart_fr_on_each_reply", 0)

loadmodule "rr.so"
modparam("rr", "append_fromtag", 1)

loadmodule "dialog.so"
modparam("dialog", "default_timeout", 14400)
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "enable_stats", 1)
modparam("dialog", "profiles_with_value", "caller")

loadmodule "sipmsgops.so"

loadmodule "usrloc.so"

loadmodule "registrar.so"

loadmodule "uac_auth.so"
modparam("uac_auth", "credential", "username:domain:password")

loadmodule "uac_registrant.so"
modparam("uac_registrant", "db_url", "mysql://opensips:opensipsrw at localhost
/opensips")

loadmodule "proto_udp.so"

route {
  if (has_totag()) {
    if (loose_route()) {
      if ($DLG_status != NULL && !validate_dialog()) {
        exit;
      }
    } else {
      if (is_method("ACK")) {
        if (t_check_trans()) {
          t_relay();
        }
        exit;
      }

      sl_send_reply(404, "Not Found");
      exit;
    }

    t_relay();

    exit;
  }

  if (is_method("CANCEL")) {
    if (t_check_trans()) {
      t_relay();
    }
    exit;
  }

  t_check_trans();

  if (is_method("INVITE")) {
    if (!create_dialog("B")) {
      sl_send_reply(500, "Internal Server Error");
      exit;
    }
  }

  route(relay);
}

route[relay] {
  if (is_method("INVITE")) {
    # VALIDATE THIS RELATES TO A USER IN THE UAC_REGISTRANT TABLE AND LOAD
AVPS
    # OR LOAD CREDENTIALS TO SEND INVITE ONWARD TO THE REMOTE SIP PROVIDER

    t_on_failure("invite_failure_route");
  }

  if (!t_relay()) {
    sl_send_reply(500, "Internal Error");
  }

  exit;
}

failure_route[invite_failure_route] {
  if (t_was_cancelled()) {
    exit;
  }

  if (t_check_status("3[0-9][0-9]")) {
    t_reply(404, "Not found");
    exit;
  }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240922/7f0e7c2e/attachment.html>

From bogdan at opensips.org  Mon Sep 23 06:41:38 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 23 Sep 2024 09:41:38 +0300
Subject: [OpenSIPS-Users] rtp_relay_engage() Handling
In-Reply-To: <CANJp-yj4bKm6TDAaMpAfESxkb-isNVOv=kf7Ksw6QQDynpbfKA@mail.gmail.com>
References: <CANJp-yj4bKm6TDAaMpAfESxkb-isNVOv=kf7Ksw6QQDynpbfKA@mail.gmail.com>
Message-ID: <cd5a3c16-6648-4aeb-8bc3-d04e073ab80b@opensips.org>

Hi Aron,

AFAIK, no, but I will let Razvan to update here next week - he knows 
better. Again, small chances to be able to stop (as everything is done 
via callbacks), but maybe to brain storm for some ideas.

Regards,

Bogdan-Andrei Iancu

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

On 18.09.2024 04:21, Podrigal, Aron wrote:
> Hi All,
>
> I am trying to use rtp_relay_engage(). However, what happens when / if 
> there was a failure, since the internal method being used is by 
> hooking into TM with a callback on TMCB_REQUEST_FWDED, even though the 
> offer / rtpengine was down, the message is being relayed with the 
> initial SDP.
>
> Is there a way to stop / cancel the relay if there was an error?
>
> -- 
>
> -
> Aron Podrigal
>
>
> _______________________________________________
> 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/20240923/36693983/attachment.html>

From bogdan at opensips.org  Mon Sep 23 06:46:47 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 23 Sep 2024 09:46:47 +0300
Subject: [OpenSIPS-Users] Nathelper vs Nat_traversal
In-Reply-To: <7597159.9J7NaK4W3v@leno.mylan>
References: <7597159.9J7NaK4W3v@leno.mylan>
Message-ID: <974965e4-0775-40b3-ab99-abc17dd5f8cd@opensips.org>

Hi,

Yes, the idea was to have them merged. The underlying concept in 
nat_traversal is more robust and complex, but it does not cover all the 
functionalities as provided by nathelper.

The big advantage of nat_traversal is that it is able to keep track of 
non-registering sessions (for NAT pining), like for calls or presence 
subscriptions. If you have a 100% registrations driven platform, it will 
not make too much of a difference for you.

Regards,

Bogdan-Andrei Iancu

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

On 18.09.2024 20:24, Robert Dyck wrote:
> I am reaching out to users and developers.
>
> I read that nat_traversal was supposed to replace nathelper. It appears that
> they have co-existed for many versions now. Nat_traversal is supposed to
> overcome NAT issues in a multi proxy environment.
>
> Looking at the functions provided by the two modules it doesn't look like
> nathelper's functionality has been completely replicated in nat_traversal.
>
> Is anyone using nat_traversal, possibly with also nathelper?
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Mon Sep 23 06:52:07 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 23 Sep 2024 09:52:07 +0300
Subject: [OpenSIPS-Users] registrant example
In-Reply-To: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
Message-ID: <99433521-4230-4685-b67a-a60868f7a023@opensips.org>

Hi,

1) The Registrant OpenSIPS should do an IP auth for the Remote SIP 
provider. OpenSIPS knows the server it registered with, so it should be 
able to do IP auth

2) there is notthing standard about loading the credentials, you can do 
it in any way that works for you, like having them hard coded in cfg (if 
the same credentials are to be used for the all calls), or loading them 
from DB (using sqlops module), or HTTP rest query.

Regards,

Bogdan-Andrei Iancu

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

On 22.09.2024 03:10, Alberto wrote:
> Hi,
>
> I'm trying to put together a simple script to use uac_registrant
> So I have:
> LEFT SIP SERVERS <-[ip authentication]-> OPENSIPS <-[uac_registrant]-> 
> REMOTE SIP PROVIDER
>
> Here's the 2 problems I still have:
> I have the users for the remote sip provider in the registrant table, 
> and opensips is already able to register to this remote sip provider,but:
> - When an INVITE comes from the remote sip provider I register to, how 
> do I validate which user is it related to? Where should I store avp, 
> and how should I load them?
> - When an INVITE comes from the left sip servers and I have to call 
> the remote sip provider, how do I load the credentials from the 
> database to authenticate the INVITE to the remote sip provider?
>
> I'm using the address table for the left sip servers and 
> check_address, but I've stripped all that from my example below.
> I hope this makes sense, thank you.
>
> Here is a short example script I'm working with
>
> #######
> debug_mode=no
>
> log_level=2
> xlog_level=2
> log_stdout=yes
> stderror_enabled=yes
> syslog_facility=LOG_LOCAL0
>
> auto_aliases=no
>
> server_signature=yes
>
> socket=udp:0.0.0.0:5060 <http://0.0.0.0:5060>
>
> mpath="/usr/lib64/opensips/modules/"
>
> loadmodule "db_mysql.so"
>
> loadmodule "signaling.so"
>
> loadmodule "sl.so"
>
> loadmodule "tm.so"
> modparam("tm", "auto_100trying", 0)
> modparam("tm", "fr_inv_timeout", 120)
> modparam("tm", "fr_timeout", 30)
> modparam("tm", "onreply_avp_mode", 1)
> modparam("tm", "restart_fr_on_each_reply", 0)
>
> loadmodule "rr.so"
> modparam("rr", "append_fromtag", 1)
>
> loadmodule "dialog.so"
> modparam("dialog", "default_timeout", 14400)
> modparam("dialog", "dlg_match_mode", 1)
> modparam("dialog", "enable_stats", 1)
> modparam("dialog", "profiles_with_value", "caller")
>
> loadmodule "sipmsgops.so"
>
> loadmodule "usrloc.so"
>
> loadmodule "registrar.so"
>
> loadmodule "uac_auth.so"
> modparam("uac_auth", "credential", "username:domain:password")
>
> loadmodule "uac_registrant.so"
> modparam("uac_registrant", "db_url", 
> "mysql://opensips:opensipsrw at localhost/opensips")
>
> loadmodule "proto_udp.so"
>
> route {
>   if (has_totag()) {
>     if (loose_route()) {
>       if ($DLG_status != NULL && !validate_dialog()) {
>         exit;
>       }
>     } else {
>       if (is_method("ACK")) {
>         if (t_check_trans()) {
>           t_relay();
>         }
>         exit;
>       }
>
>       sl_send_reply(404, "Not Found");
>       exit;
>     }
>
>     t_relay();
>
>     exit;
>   }
>
>   if (is_method("CANCEL")) {
>     if (t_check_trans()) {
>       t_relay();
>     }
>     exit;
>   }
>
>   t_check_trans();
>
>   if (is_method("INVITE")) {
>     if (!create_dialog("B")) {
>       sl_send_reply(500, "Internal Server Error");
>       exit;
>     }
>   }
>
>   route(relay);
> }
>
> route[relay] {
>   if (is_method("INVITE")) {
>     # VALIDATE THIS RELATES TO A USER IN THE UAC_REGISTRANT TABLE AND 
> LOAD AVPS
>     # OR LOAD CREDENTIALS TO SEND INVITE ONWARD TO THE REMOTE SIP PROVIDER
>
>     t_on_failure("invite_failure_route");
>   }
>
>   if (!t_relay()) {
>     sl_send_reply(500, "Internal Error");
>   }
>
>   exit;
> }
>
> failure_route[invite_failure_route] {
>   if (t_was_cancelled()) {
>     exit;
>   }
>
>   if (t_check_status("3[0-9][0-9]")) {
>     t_reply(404, "Not found");
>     exit;
>   }
> }
>
> _______________________________________________
> 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/20240923/067040a6/attachment.html>

From rob.dyck at telus.net  Mon Sep 23 14:36:33 2024
From: rob.dyck at telus.net (Robert Dyck)
Date: Mon, 23 Sep 2024 07:36:33 -0700
Subject: [OpenSIPS-Users] Nathelper vs Nat_traversal
In-Reply-To: <974965e4-0775-40b3-ab99-abc17dd5f8cd@opensips.org>
References: <7597159.9J7NaK4W3v@leno.mylan>
 <974965e4-0775-40b3-ab99-abc17dd5f8cd@opensips.org>
Message-ID: <6306004.DJkKcVGEfx@leno.mylan>

I thought perhaps nat_traversal had been abandoned. In nathelper the flags were 
changed to strings but not so in nat_traversal.

On Sunday, September 22, 2024 11:46:47 P.M. PDT Bogdan-Andrei Iancu wrote:
> Hi,
> 
> Yes, the idea was to have them merged. The underlying concept in
> nat_traversal is more robust and complex, but it does not cover all the
> functionalities as provided by nathelper.
> 
> The big advantage of nat_traversal is that it is able to keep track of
> non-registering sessions (for NAT pining), like for calls or presence
> subscriptions. If you have a 100% registrations driven platform, it will
> not make too much of a difference for you.
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
>    https://www.siphub.com
> 
> On 18.09.2024 20:24, Robert Dyck wrote:
> > I am reaching out to users and developers.
> > 
> > I read that nat_traversal was supposed to replace nathelper. It appears
> > that they have co-existed for many versions now. Nat_traversal is
> > supposed to overcome NAT issues in a multi proxy environment.
> > 
> > Looking at the functions provided by the two modules it doesn't look like
> > nathelper's functionality has been completely replicated in nat_traversal.
> > 
> > Is anyone using nat_traversal, possibly with also nathelper?
> > 
> > 
> > 
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users






From bogdan at opensips.org  Mon Sep 23 14:43:42 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 23 Sep 2024 17:43:42 +0300
Subject: [OpenSIPS-Users] Nathelper vs Nat_traversal
In-Reply-To: <6306004.DJkKcVGEfx@leno.mylan>
References: <7597159.9J7NaK4W3v@leno.mylan>
 <974965e4-0775-40b3-ab99-abc17dd5f8cd@opensips.org>
 <6306004.DJkKcVGEfx@leno.mylan>
Message-ID: <47fa07d6-2a84-41eb-a81a-3b5548e79d9f@opensips.org>

You mean the "flags" passed to client_nat_test() ?

Regards,

Bogdan-Andrei Iancu

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

On 23.09.2024 17:36, Robert Dyck wrote:
> I thought perhaps nat_traversal had been abandoned. In nathelper the flags were
> changed to strings but not so in nat_traversal.
>
> On Sunday, September 22, 2024 11:46:47 P.M. PDT Bogdan-Andrei Iancu wrote:
>> Hi,
>>
>> Yes, the idea was to have them merged. The underlying concept in
>> nat_traversal is more robust and complex, but it does not cover all the
>> functionalities as provided by nathelper.
>>
>> The big advantage of nat_traversal is that it is able to keep track of
>> non-registering sessions (for NAT pining), like for calls or presence
>> subscriptions. If you have a 100% registrations driven platform, it will
>> not make too much of a difference for you.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>     https://www.opensips-solutions.com
>>     https://www.siphub.com
>>
>> On 18.09.2024 20:24, Robert Dyck wrote:
>>> I am reaching out to users and developers.
>>>
>>> I read that nat_traversal was supposed to replace nathelper. It appears
>>> that they have co-existed for many versions now. Nat_traversal is
>>> supposed to overcome NAT issues in a multi proxy environment.
>>>
>>> Looking at the functions provided by the two modules it doesn't look like
>>> nathelper's functionality has been completely replicated in nat_traversal.
>>>
>>> Is anyone using nat_traversal, possibly with also nathelper?
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>



From rob.dyck at telus.net  Mon Sep 23 14:45:59 2024
From: rob.dyck at telus.net (Robert Dyck)
Date: Mon, 23 Sep 2024 07:45:59 -0700
Subject: [OpenSIPS-Users] Nathelper vs Nat_traversal
In-Reply-To: <47fa07d6-2a84-41eb-a81a-3b5548e79d9f@opensips.org>
References: <7597159.9J7NaK4W3v@leno.mylan> <6306004.DJkKcVGEfx@leno.mylan>
 <47fa07d6-2a84-41eb-a81a-3b5548e79d9f@opensips.org>
Message-ID: <5700336.hkbZ0PkbqX@leno.mylan>

Yes. Is that done to make reading the script easier?

On Monday, September 23, 2024 7:43:42 A.M. PDT Bogdan-Andrei Iancu wrote:
> You mean the "flags" passed to client_nat_test() ?
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
>    https://www.siphub.com
> 
> On 23.09.2024 17:36, Robert Dyck wrote:
> > I thought perhaps nat_traversal had been abandoned. In nathelper the flags
> > were changed to strings but not so in nat_traversal.
> > 
> > On Sunday, September 22, 2024 11:46:47 P.M. PDT Bogdan-Andrei Iancu wrote:
> >> Hi,
> >> 
> >> Yes, the idea was to have them merged. The underlying concept in
> >> nat_traversal is more robust and complex, but it does not cover all the
> >> functionalities as provided by nathelper.
> >> 
> >> The big advantage of nat_traversal is that it is able to keep track of
> >> non-registering sessions (for NAT pining), like for calls or presence
> >> subscriptions. If you have a 100% registrations driven platform, it will
> >> not make too much of a difference for you.
> >> 
> >> Regards,
> >> 
> >> Bogdan-Andrei Iancu
> >> 
> >> OpenSIPS Founder and Developer
> >> 
> >>     https://www.opensips-solutions.com
> >>     https://www.siphub.com
> >> 
> >> On 18.09.2024 20:24, Robert Dyck wrote:
> >>> I am reaching out to users and developers.
> >>> 
> >>> I read that nat_traversal was supposed to replace nathelper. It appears
> >>> that they have co-existed for many versions now. Nat_traversal is
> >>> supposed to overcome NAT issues in a multi proxy environment.
> >>> 
> >>> Looking at the functions provided by the two modules it doesn't look
> >>> like
> >>> nathelper's functionality has been completely replicated in
> >>> nat_traversal.
> >>> 
> >>> Is anyone using nat_traversal, possibly with also nathelper?
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at lists.opensips.org
> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users






From bogdan at opensips.org  Tue Sep 24 06:00:11 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 09:00:11 +0300
Subject: [OpenSIPS-Users] Transcode DTMF specific telephone-event
In-Reply-To: <CAPHmyfxrUYS_VEmqvUCmkQ=mPbrGjuRahSqfo5kt4u0ChLfk2g@mail.gmail.com>
References: <CAPHmyfxrUYS_VEmqvUCmkQ=mPbrGjuRahSqfo5kt4u0ChLfk2g@mail.gmail.com>
Message-ID: <93ccafb1-e1d8-43c8-8b22-fe9e5763e733@opensips.org>

Hi, This sounds more like an rtpengine question, rather than an opensips 
one :(. Hopefully someone here will be able to assist, you never know :)

Regards,

Bogdan-Andrei Iancu

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

On 07.09.2024 09:46, Vinayak Makwana via Users wrote:
> Hi all,
>
>            I am trying to transcoding for a specific 
> DTMF telephone-event from opensips +rtpengine. I am using opensips 
> 3.2.12.
>
> Here's Call scenario :
> Initial INVITE SDP ---> OpenSIPS
> *       a=rtpmap:105 telephone-event/16000
>        a=rtpmap:100 telephone-event/8000*
>
> From opensips i want to add below DTMF payload 101 because B party is 
> accepting this DTMF payload type.
> *a=rtpmap:101 telephone-event/8000 *i am using below code.
> *       rtpengine_offer("transcode-telephone-event/8000");*
>
> By using this function opensips does not transcode specific DTMF 
> payload 101.
>
> Is there any way to achieve this transcoding ?
> Please let me know.
>
>
> Regards,
> Vinayak Makwana
>
>
>
> *https://www.ecosmob.com/ucx-expo/ <https://www.ecosmob.com/ucx-expo/>
> *
> *Disclaimer*
> In addition to generic Disclaimer which you have agreed on our 
> website, any views or opinions presented in this email are solely 
> those of the originator and do not necessarily represent those of the 
> Company or its sister concerns. Any liability (in negligence, contract 
> or otherwise) arising from any third party taking any action, or 
> refraining from taking any action on the basis of any of the 
> information contained in this email is hereby excluded.
>
> *Confidentiality*
> This communication (including any attachment/s) is intended only for 
> the use of the addressee(s) and contains information that is 
> PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, 
> distribution, or copying of this communication is prohibited. Please 
> inform originator if you have received it in error.
>
> *Caution for viruses, malware etc.*
> This communication, including any attachments, may not be free of 
> viruses, trojans, similar or new contaminants/malware, interceptions 
> or interference, and may not be compatible with your systems. You 
> shall carry out virus/malware scanning on your own before opening any 
> attachment to this e-mail. The sender of this e-mail and Company 
> including its sister concerns shall not be liable for any damage that 
> may incur to you as a result of viruses, incompleteness of this 
> message, a delay in receipt of this message or any other computer 
> problems.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240924/6585580c/attachment.html>

From bogdan at opensips.org  Tue Sep 24 06:04:09 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 09:04:09 +0300
Subject: [OpenSIPS-Users] Problem with TLS and Mid Registrar
In-Reply-To: <CANBmQegSCUthpUWeLL_6zC9CbUFJBcRAtx+5FvTtoXkonc45HA@mail.gmail.com>
References: <CANBmQegSCUthpUWeLL_6zC9CbUFJBcRAtx+5FvTtoXkonc45HA@mail.gmail.com>
Message-ID: <a0279edb-9804-405a-9e95-12091284273a@opensips.org>

Hi Daniel,

As per logs, when routing the call to TLS, a private IP is used as 
destination (this 10.252.252.25) - I assume the registered information 
(at REGISTER time) is not correct, pointing to such a private IP, rather 
than to the public one - do you do any NAT fixing at REGISTER time ?

Regards,

Bogdan-Andrei Iancu

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

On 07.09.2024 01:39, Daniel Cogo De Vargas wrote:
> I need a help.
>
> I´m using the TLS and MID_REGISTRAR, my intention is translate TLS to 
> UDP and send the REGISTER and INVITE to a Asterisk.
>
> When I use the extension TLS, REGISTER work  normally. It  send a call 
> to other extension (UDP  or TCP), but when the TLS extension receive a 
> call not work.
>
> The error log message is:
>
>
> Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112945]: new branch at 
> sip:1014 at voip.simple.com.br:5060 <http://sip:1014 at voip.simple.com.br:5060>
> Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112944]: incoming reply
> Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112945]: new branch at 
> sip:1014 at voip.simple.com.br:5060 <http://sip:1014 at voip.simple.com.br:5060>
> Sep 06 22:33:10 sbc02 /usr/sbin/opensips[112945]: incoming reply
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: looking up 
> sip:1014 at 132.226.249.251:5060;ctid=3384597829537881314!
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112945]: incoming reply
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: 
> ERROR:core:tcp_connect_blocking_timeout: connect timed out, 99172 us 
> elapsed out of 100000 us
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: 
> ERROR:core:tcp_sync_connect_fd: tcp_blocking_connect failed
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: 
> ERROR:proto_tls:proto_tls_send: connect failed
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: ERROR:tm:msg_send: 
> send() to 10.252.252.25:58949 <http://10.252.252.25:58949> for proto 
> tls/3 failed
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112944]: 
> ERROR:tm:t_forward_nonack: sending request failed
> Sep 06 22:33:12 sbc02 /usr/sbin/opensips[112945]: incoming reply
>
>
> I´m using the MicrosSIP softphone.
>
> _______________________________________________
> 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/20240924/24181e7e/attachment-0001.html>

From bogdan at opensips.org  Tue Sep 24 06:09:58 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 09:09:58 +0300
Subject: [OpenSIPS-Users] clusterer compatibility between 2.4 and 3.4
In-Reply-To: <08BF7F86-F7E9-470C-ABBB-3DEE283FBE03@ag-projects.com>
References: <CH2PR12MB42628567B144A49C46D80AA9A9972@CH2PR12MB4262.namprd12.prod.outlook.com>
 <08BF7F86-F7E9-470C-ABBB-3DEE283FBE03@ag-projects.com>
Message-ID: <c602bd8b-9b3d-49e8-beb0-2fbdc2f37193@opensips.org>

Hi,

It is actually even more than the DB schema. The BIN protocol (used by 
the clustering module) is different in 2.4 and 3.4, so the two nodes 
will not  "understand" one each other :(

Regards,

Bogdan-Andrei Iancu

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

On 31.08.2024 01:05, Adrian Georgescu wrote:
> Because of the database schema differences between the two versions, 
> you will not be able to use the same database to run both.
>
> One migration strategy could be:
>
> 1. Convert the configuration and migrate the database structure to the 
> new version 3.4 on the current slave
> 2. Test the slave SIP logic using a separate IP address or port with a 
> SIP client that uses the slave server address as outbound SIP Proxy. 
> When everything works continue to the next step.
> 3. Switch over the cluster to the newly configured slave running the 
> new OpenSIPS version
> 4. Copy the configurations from the newly promoted slave to master to 
> the old master machine
> 5. Switch back to the old master
>
> Adrian
>
>
>> On 30. Aug 2024, at 16:54, Pyle, Jeff <JPyle at fusionconnect.com> wrote:
>>
>> Hello,
>>
>> I have an OpenSIPS 2.4 cluster I need to upgrade to 3.4. The cluster 
>> is configured as an HA pair, with one active and one standby where 
>> keepalived moves the IP between the two.
>>
>> Can instances on 2.4 and 3.4 participate in the same cluster? I'm 
>> hoping to update one "half" at a time while maintaining call 
>> processing on the side that isn't being upgraded.
>>
>>
>> Regards,
>> Jeff
>>
>> This message is subject to Fusion Connect, Inc.’s email communication 
>> policy:www.fusionconnect.com/email-policy 
>> <http://www.fusionconnect.com/email-policy>_______________________________________________
>> 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/20240924/9e13e610/attachment.html>

From bogdan at opensips.org  Tue Sep 24 06:16:11 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 09:16:11 +0300
Subject: [OpenSIPS-Users] Nathelper vs Nat_traversal
In-Reply-To: <5700336.hkbZ0PkbqX@leno.mylan>
References: <7597159.9J7NaK4W3v@leno.mylan> <6306004.DJkKcVGEfx@leno.mylan>
 <47fa07d6-2a84-41eb-a81a-3b5548e79d9f@opensips.org>
 <5700336.hkbZ0PkbqX@leno.mylan>
Message-ID: <ead64bbf-7eac-4b3f-8fa3-0d730da166ef@opensips.org>

Not much for now :). Unfortunately not all script functions were 
enhanced with the string flags (versus numerical ones)...still wip. But 
you can open a feature request on this.

Regards,

Bogdan-Andrei Iancu

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

On 23.09.2024 17:45, Robert Dyck wrote:
> Yes. Is that done to make reading the script easier?
>
> On Monday, September 23, 2024 7:43:42 A.M. PDT Bogdan-Andrei Iancu wrote:
>> You mean the "flags" passed to client_nat_test() ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>     https://www.opensips-solutions.com
>>     https://www.siphub.com
>>
>> On 23.09.2024 17:36, Robert Dyck wrote:
>>> I thought perhaps nat_traversal had been abandoned. In nathelper the flags
>>> were changed to strings but not so in nat_traversal.
>>>
>>> On Sunday, September 22, 2024 11:46:47 P.M. PDT Bogdan-Andrei Iancu wrote:
>>>> Hi,
>>>>
>>>> Yes, the idea was to have them merged. The underlying concept in
>>>> nat_traversal is more robust and complex, but it does not cover all the
>>>> functionalities as provided by nathelper.
>>>>
>>>> The big advantage of nat_traversal is that it is able to keep track of
>>>> non-registering sessions (for NAT pining), like for calls or presence
>>>> subscriptions. If you have a 100% registrations driven platform, it will
>>>> not make too much of a difference for you.
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>>
>>>> OpenSIPS Founder and Developer
>>>>
>>>>      https://www.opensips-solutions.com
>>>>      https://www.siphub.com
>>>>
>>>> On 18.09.2024 20:24, Robert Dyck wrote:
>>>>> I am reaching out to users and developers.
>>>>>
>>>>> I read that nat_traversal was supposed to replace nathelper. It appears
>>>>> that they have co-existed for many versions now. Nat_traversal is
>>>>> supposed to overcome NAT issues in a multi proxy environment.
>>>>>
>>>>> Looking at the functions provided by the two modules it doesn't look
>>>>> like
>>>>> nathelper's functionality has been completely replicated in
>>>>> nat_traversal.
>>>>>
>>>>> Is anyone using nat_traversal, possibly with also nathelper?
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>



From bogdan at opensips.org  Tue Sep 24 07:54:04 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 10:54:04 +0300
Subject: [OpenSIPS-Users] TCP keepalive problem.
In-Reply-To: <CAM_EGOGRgFHzWUH+3-+U3XGidSVaU3aLhmpKZZXYkpRL39-60A@mail.gmail.com>
References: <CAM_EGOGRgFHzWUH+3-+U3XGidSVaU3aLhmpKZZXYkpRL39-60A@mail.gmail.com>
Message-ID: <166f6eea-bd9e-4153-a881-8af2eaf0c974@opensips.org>

Hi Volkan,

The TCP persistent flag is a passive way to keep the connection open, 
meaning OpenSIPS will not close it during the registration time. But 
does not imply any kind of keep alive.

For some active ways of keeping the conn up, see
https://www.opensips.org/Documentation/Script-CoreParameters-3-4#tcp_keepalive
https://opensips.org/html/docs/modules/3.4.x/proto_tcp.html#idp156272

Otherwise try to lower the registration time (from OpenSIPS side) for 
that device to shorter value, below the device TCP timeout.

Regards,

Bogdan-Andrei Iancu

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

On 24.08.2024 14:06, Volkan Oransoy wrote:
> Hi all,
>
> I have an interesting issue that I am trying to identify the cause of. 
> I am trying to migrate a quite old Kamailio SIP proxy to OpenSIPS 3.4. 
> The new OpenSIPS proxy uses mid_registrar and replicates registrations 
> to the backend boxes.
> A specific type of UACs (Gigaset AS690) does not keep the TCP 
> connection alive. So on every registration refresh, the traffic comes 
> from another port and a new contact is created. Interestingly, there 
> are UACs from the very same network that have a healthy connection to 
> the OpenSIPS box.
> Since this is not an issue with the old box, I assume the issue is 
> related to my new setup.
>
> When sniffing the traffic, I see that the UAC ends the connection.
>
> 11 9.378043 UAC_IP SERVER_IP TCP 60 22719 → 5060 [SYN] Seq=0 Win=1608 
> Len=0 MSS=536
> 12 9.378148 SERVER_IP UAC_IP TCP 58 5060 → 22719 [SYN, ACK] Seq=0 
> Ack=1 Win=64240 Len=0 MSS=1460
> 13 9.401441 UAC_IP SERVER_IP TCP 60 22719 → 5060 [ACK] Seq=1 Ack=1 
> Win=1608 Len=0
> 14 9.405625 UAC_IP SERVER_IP SIP 560 Request: REGISTER 
> sip:c384.bulutfon.net <http://c384.bulutfon.net>  (1 binding) |
> 15 9.405731 SERVER_IP UAC_IP TCP 54 5060 → 22719 [ACK] Seq=1 Ack=507 
> Win=63784 Len=0
> 16 9.405863 SERVER_IP UAC_IP SIP 557 Status: 401 Unauthorized |
> 17 9.434851 UAC_IP SERVER_IP TCP 60 22719 → 5060 [ACK] Seq=507 Ack=504 
> Win=1608 Len=0
> 18 9.464046 UAC_IP SERVER_IP SIP 756 Request: REGISTER 
> sip:c384.bulutfon.net <http://c384.bulutfon.net>  (1 binding) |
> 19 9.470312 SERVER_IP UAC_IP TCP 590 5060 → 22719 [ACK] Seq=504 
> Ack=1209 Win=63784 Len=536 [TCP segment of a reassembled PDU]
> 20 9.470337 SERVER_IP UAC_IP SIP 125 Status: 200 OK (REGISTER)  (2 
> bindings) |
> 21 9.495625 UAC_IP SERVER_IP TCP 60 22719 → 5060 [ACK] Seq=1209 
> Ack=1040 Win=1608 Len=0
> 22 9.501248 UAC_IP SERVER_IP TCP 60 22719 → 5060 [ACK] Seq=1209 
> Ack=1111 Win=1608 Len=0
> 23 10.520457 UAC_IP SERVER_IP TCP 60 22719 → 5060 [FIN, ACK] Seq=1209 
> Ack=1111 Win=1608 Len=0
> 24 10.520701 SERVER_IP UAC_IP TCP 54 5060 → 22719 [FIN, ACK] Seq=1111 
> Ack=1210 Win=63784 Len=0
> 25 10.543913 UAC_IP SERVER_IP TCP 60 22719 → 5060 [ACK] Seq=1210 
> Ack=1112 Win=1608 Len=0
>
> I use tcp_persistent_flag to flag the TCP connections and I can see 
> the relevant flag on ul_dump output.
>
> modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSISTENT")
>
> if ($socket_in(proto) == "tcp" || $socket_in(proto) == "tls")
>     setbflag("TCP_PERSISTENT");
>
> mid_registrar_save("location");
>
> I have tried disabling the config above and giving a fixed TCP 
> lifetime value to the OpenSIPS box, but the issue remains the same.
>
> Do you have any hints that I can chase after?
>
> Best
>
> -- 
> Volkan Oransoy
>
> _______________________________________________
> 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/20240924/14f711a8/attachment-0001.html>

From alexandra.titoc at opensips.org  Tue Sep 10 09:15:10 2024
From: alexandra.titoc at opensips.org (Alexandra Titoc)
Date: Tue, 10 Sep 2024 12:15:10 +0300
Subject: [OpenSIPS-Users] =?utf-8?q?=5BBlog=5D_Amazon=E2=80=99s_SQS_Events?=
	=?utf-8?q?_in_OpenSIPS_3=2E6?=
Message-ID: <5e0c0db3-2b7a-4ed1-aba3-abcb7a0fc4dd@opensips.org>

Hello,

OpenSIPS 3.6 takes one more step when comes to integration with AWS 
Cloud. This is the support for Amazon Simple Queue Service (SQS), a 
fully managed message queuing for microservices, distributed systems, 
and serverless applications.

https://blog.opensips.org/2024/09/10/amazons-sqs-events-in-opensips-3-6/

Enjoy,

-- 
Alexandra Titoc

OpenSIPS Developer
   https://www.opensips.org



From bogdan at opensips.org  Tue Sep 24 08:40:54 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 11:40:54 +0300
Subject: [OpenSIPS-Users] remove_latency value in pike module is not
 respected
In-Reply-To: <AS8PR08MB73726C3AC49A5A3F14BDD765939E2@AS8PR08MB7372.eurprd08.prod.outlook.com>
References: <AS8PR08MB73726C3AC49A5A3F14BDD765939E2@AS8PR08MB7372.eurprd08.prod.outlook.com>
Message-ID: <f13ac8ae-6d37-4f02-a9d7-6d7f12ff9ff1@opensips.org>

Hi Santi,

The remove_latency is not about "unblocking" the node, but for how slow 
the nodes should be removed from IP tree, if there are not hits (this is 
something that controls the collapsing of the tree if there is no 
traffic/hits).

The node will stay BLOCK as time as there is traffic (as volume) to 
match the "blocking" condition. As soon as the traffic goes away and the 
condition fails, the node is unblocked.

I agree that the naming is not the best, neither the explanations in the 
docs :P...

The idea here is to have pike module as a way of detecting (the flooding 
srcs) and not as a tool to manage the blocking. For such purposes you 
can use dedicated tools like file2ban.

Best regards,

Bogdan-Andrei Iancu

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

On 06.09.2024 15:22, Santi Antón wrote:
>
> Hello,
>
> I’m using pike module with this module configuration.
>
> loadmodule "pike.so"
>
> modparam("pike", "sampling_time_unit", 5)
>
> modparam("pike", "reqs_density_per_unit", 10)
>
> modparam("pike", "remove_latency", 3600)
>
> The module detects the DoS, but 6-8 seconds later unblock the source 
> IP when it is set to last 1h, where I’m going wrong?
>
> I’ve tried different “remove_latency” values with the same results.
>
> The log shows it.
>
> Sep  5 18:30:32 voiptfm /usr/sbin/opensips[660915]: INFO:PIKE - 
> BLOCKing ip 172.16.53.12, node=0x7f93ec486bc8
>
> Sep  5 18:30:38 voiptfm /usr/sbin/opensips[660934]: INFO:PIKE - 
> UNBLOCKing node 0x7f93ec486bc8
>
> Sep  5 18:30:55 voiptfm /usr/sbin/opensips[660916]: INFO:PIKE - 
> BLOCKing ip 172.16.53.12, node=0x7f93ec486bc8
>
> Sep  5 18:31:03 voiptfm /usr/sbin/opensips[660934]: INFO:PIKE - 
> UNBLOCKing node 0x7f93ec486bc8
>
> Sep  6 13:36:08 voiptfm /usr/sbin/opensips[669077]: INFO:PIKE - 
> BLOCKing ip 172.16.53.12, node=0x7f2727f97448
>
> Sep  6 13:36:13 voiptfm /usr/sbin/opensips[669092]: INFO:PIKE - 
> UNBLOCKing node 0x7f2727f97448
>
> Salutacions/Saludos,
>
> 	
>
> 	
>
> 	
>
> 	
>
> 	
>
> *Santi Antón*
>
> *Responsable de operaciones***
>
> *Tel. 902 520 520 - Ext. 106*
> santi.anton at quarea.com <mailto:santi.anton at quarea.com>
>
> 	
>
> 	
>
> 	
>
> 	
>
> 	
>
> 	
>
> *902 520 520*
> www.quarea.com <http://www.quarea.com/>
>
> *Quarea ITC Management & Consulting*
> Su experto en Redes Voz-Datos IP:
> Asterisk, Cisco, Polycom, Sangoma
>
> 	
>
> //
>
> //
>
> //
>
> //
>
> //
>
> //
>
> //
>
> //
>
> //
>
> //
>
> /En compliment del que es disposa en l'article 13 del Reglament (UE) 
> 2016/679, relatiu a la Protecció de Dades de Caràcter Personal, QUAREA 
> ITC MANAGEMENT & CONSULTING, SL garanteix la confidencialitat de les 
> dades personals dels seus clients. Li comuniquem que la seva adreça de 
> correu electrònic forma part d'una base de dades gestionada sota la 
> responsabilitat de QUAREA ITC MANAGEMENT & CONSULTING, SL, amb l'única 
> finalitat de prestar-li els serveis per vostè sol·licitats, per la 
> seva condició de client, proveïdor, o perquè ens hagi sol·licitat 
> informació en algun moment. Les dades seran conservades durant el 
> temps necessari per poder prestar-li els nostres serveis i complir amb 
> les nostres obligacions legals. És voluntat de QUAREA ITC MANAGEMENT & 
> CONSULTING, SL, evitar l'enviament deliberat de correu no sol·licitat, 
> per la qual cosa podrà a tot moment, exercitar els seus drets d'accés, 
> rectificació, supressió, limitació del seu tractament, oposició i 
> portabilitat de les seves dades de caràcter personal mitjançant el 
> correu electrònic //infodat at quarea.com/ <mailto:infodat at quarea.com>
>
> /En cumplimiento de lo dispuesto en el artículo 13 del Reglamento (UE) 
> 2016/679, relativo a la Protección de Datos de Carácter Personal, 
> QUAREA ITC MANAGEMENT & CONSULTING, SL garantiza la confidencialidad 
> de los datos personales de sus clientes. Le comunicamos que su 
> dirección de correo electrónico forma parte de una base de datos 
> gestionada bajo la responsabilidad de QUAREA ITC MANAGEMENT & 
> CONSULTING, SL, con la única finalidad de prestarle los servicios por 
> usted solicitados, por su condición de cliente, proveedor, o porque 
> nos haya solicitado información en algún momento. Los datos serán 
> conservados durante el tiempo necesario para poder prestarle nuestros 
> servicios y cumplir con nuestras obligaciones legales. Es voluntad de 
> QUAREA ITC MANAGEMENT & CONSULTING, SL, evitar el envío deliberado de 
> correo no solicitado, por lo cual podrá en todo momento, ejercitar sus 
> derechos de acceso, rectificación, supresión, limitación de su 
> tratamiento, oposición y portabilidad de sus datos de carácter 
> personal mediante el correo electrónico //infodat at quarea.com/ 
> <mailto:infodat at quarea.com>
>
> /In compliance with the provisions of Article 13 of Regulation (EU) 
> 2016/679, regarding the Protection of Personal Data, QUAREA ITC 
> MANAGEMENT & CONSULTING, SL guarantees the confidentiality of the 
> personal data of his customers. We inform you that your email address 
> is part of a managed database under the responsibility of QUAREA ITC 
> MANAGEMENT & CONSULTING, SL, for the sole purpose of providing the 
> services requested by you, as a client, supplier, or because we have 
> requested information at some time. The data will be kept for the time 
> necessary to provide our services and comply with our legal 
> obligations. It is the will of QUAREA ITC MANAGEMENT & CONSULTING, SL, 
> to avoid the deliberate sending of unsolicited mail, so that it may, 
> at any time, exercise your rights of access, rectification, removal, 
> limitation of his treatment, opposition and portability of his 
> personal data through the email //infodat at quarea.com/ 
> <mailto:infodat at quarea.com>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240924/690ea036/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7811 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20240924/690ea036/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 166 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20240924/690ea036/attachment-0001.png>

From bogdan at opensips.org  Tue Sep 24 08:47:41 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 11:47:41 +0300
Subject: [OpenSIPS-Users] Combine topology hiding and uac modules.
In-Reply-To: <kuquANIKbcCq7Nr3LmuUNiCEexHUB1i2w0pHyvYYJm6zD9xNs9mwDKM8IYFjGbuoUb1pscx3Elzgjz6_q34KWVP4oS8qe8_U-2z8zqQvgA0=@proton.me>
References: <kuquANIKbcCq7Nr3LmuUNiCEexHUB1i2w0pHyvYYJm6zD9xNs9mwDKM8IYFjGbuoUb1pscx3Elzgjz6_q34KWVP4oS8qe8_U-2z8zqQvgA0=@proton.me>
Message-ID: <e75c471f-0a5f-4571-b9d3-d4cc0efd866e@opensips.org>

Hi Sylvain,

You want to use dialog module with TH , but the UAC module in the same 
time (to change the FROM hdr) ? If so, it should work IMHO.

Regards,

Bogdan-Andrei Iancu

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

On 27.08.2024 10:37, sylvain.daste--- via Users wrote:
> Hi,
>
> I have a simple question on the behavior of the UAC module when 
> topology hiding is also used. From the documentation of UAC the 
> automatic FROM restoration is working thanks to the parameter added to 
> the Record-Route header. However topology hiding will remove this 
> header. Therefore my question is : can you use this mode with topology 
> hiding ?
>
> Thanks,
> Sylvain
>
>
> _______________________________________________
> 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/20240924/09b0c62a/attachment.html>

From bogdan at opensips.org  Tue Sep 24 09:04:48 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 24 Sep 2024 12:04:48 +0300
Subject: [OpenSIPS-Users] Delay relay of 200 OK
In-Reply-To: <CAN0jgiPSraLf+pFXmOZ_L4YVbVwayZAZexh5_wUpMYSuBGoZ4Q@mail.gmail.com>
References: <CAN0jgiPSraLf+pFXmOZ_L4YVbVwayZAZexh5_wUpMYSuBGoZ4Q@mail.gmail.com>
Message-ID: <893b80a2-66a7-4d89-8fa0-721f909991d4@opensips.org>

Hi Daniel.

without a B2B (so in proxy mode), I wouldn't advice in delaying the 200 
OK at all . If the callee send the 200OK, it will expect a quick ACK 
back. If the ACK is not received, the callee will retransmit the 200 OK 
(at certain intervals) until either it gets an ACK, either gives up and 
generates a BYE.

So, this is risky stuff.... :)

Regards,

Bogdan-Andrei Iancu

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

On 19.08.2024 22:41, Daniel Zanutti wrote:
> Hi
>
> We need to delay the delivery of the 200 OK, and send it a few seconds 
> later, after an event is generated internally. If the call is marked 
> as suspicious, we will hangup the call and send 503 to the origin and 
> BYE to destination.
>
> Is it possible to do it? Can someone send some ideas?
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From alberto.rinaudo at gmail.com  Wed Sep 25 11:00:42 2024
From: alberto.rinaudo at gmail.com (Alberto)
Date: Wed, 25 Sep 2024 12:00:42 +0100
Subject: [OpenSIPS-Users] registrant example
In-Reply-To: <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
 <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
Message-ID: <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>

Thanks,

So, for n1, after ip auth I can validate the contact matches one of the
contacts used to register, but there's no function to do that automatically.
So in the case where opensips is keeping 2 registrations up to the same
server, it's up to me to validate which one was used.

n2, thanks again, I got it working by loading the credentials with
avp_db_query.

Regards
A

On Mon, 23 Sept 2024 at 07:52, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi,
>
> 1) The Registrant OpenSIPS should do an IP auth for the Remote SIP
> provider. OpenSIPS knows the server it registered with, so it should be
> able to do IP auth
>
> 2) there is notthing standard about loading the credentials, you can do it
> in any way that works for you, like having them hard coded in cfg (if the
> same credentials are to be used for the all calls), or loading them from DB
> (using sqlops module), or HTTP rest query.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 22.09.2024 03:10, Alberto wrote:
>
> Hi,
>
> I'm trying to put together a simple script to use uac_registrant
> So I have:
> LEFT SIP SERVERS <-[ip authentication]-> OPENSIPS <-[uac_registrant]->
> REMOTE SIP PROVIDER
>
> Here's the 2 problems I still have:
> I have the users for the remote sip provider in the registrant table, and
> opensips is already able to register to this remote sip provider,but:
> - When an INVITE comes from the remote sip provider I register to, how do
> I validate which user is it related to? Where should I store avp, and how
> should I load them?
> - When an INVITE comes from the left sip servers and I have to call the
> remote sip provider, how do I load the credentials from the database to
> authenticate the INVITE to the remote sip provider?
>
> I'm using the address table for the left sip servers and check_address,
> but I've stripped all that from my example below.
> I hope this makes sense, thank you.
>
> Here is a short example script I'm working with
>
> #######
> debug_mode=no
>
> log_level=2
> xlog_level=2
> log_stdout=yes
> stderror_enabled=yes
> syslog_facility=LOG_LOCAL0
>
> auto_aliases=no
>
> server_signature=yes
>
> socket=udp:0.0.0.0:5060
>
> mpath="/usr/lib64/opensips/modules/"
>
> loadmodule "db_mysql.so"
>
> loadmodule "signaling.so"
>
> loadmodule "sl.so"
>
> loadmodule "tm.so"
> modparam("tm", "auto_100trying", 0)
> modparam("tm", "fr_inv_timeout", 120)
> modparam("tm", "fr_timeout", 30)
> modparam("tm", "onreply_avp_mode", 1)
> modparam("tm", "restart_fr_on_each_reply", 0)
>
> loadmodule "rr.so"
> modparam("rr", "append_fromtag", 1)
>
> loadmodule "dialog.so"
> modparam("dialog", "default_timeout", 14400)
> modparam("dialog", "dlg_match_mode", 1)
> modparam("dialog", "enable_stats", 1)
> modparam("dialog", "profiles_with_value", "caller")
>
> loadmodule "sipmsgops.so"
>
> loadmodule "usrloc.so"
>
> loadmodule "registrar.so"
>
> loadmodule "uac_auth.so"
> modparam("uac_auth", "credential", "username:domain:password")
>
> loadmodule "uac_registrant.so"
> modparam("uac_registrant", "db_url", "mysql://opensips:opensipsrw at localhost
> /opensips")
>
> loadmodule "proto_udp.so"
>
> route {
>   if (has_totag()) {
>     if (loose_route()) {
>       if ($DLG_status != NULL && !validate_dialog()) {
>         exit;
>       }
>     } else {
>       if (is_method("ACK")) {
>         if (t_check_trans()) {
>           t_relay();
>         }
>         exit;
>       }
>
>       sl_send_reply(404, "Not Found");
>       exit;
>     }
>
>     t_relay();
>
>     exit;
>   }
>
>   if (is_method("CANCEL")) {
>     if (t_check_trans()) {
>       t_relay();
>     }
>     exit;
>   }
>
>   t_check_trans();
>
>   if (is_method("INVITE")) {
>     if (!create_dialog("B")) {
>       sl_send_reply(500, "Internal Server Error");
>       exit;
>     }
>   }
>
>   route(relay);
> }
>
> route[relay] {
>   if (is_method("INVITE")) {
>     # VALIDATE THIS RELATES TO A USER IN THE UAC_REGISTRANT TABLE AND LOAD
> AVPS
>     # OR LOAD CREDENTIALS TO SEND INVITE ONWARD TO THE REMOTE SIP PROVIDER
>
>     t_on_failure("invite_failure_route");
>   }
>
>   if (!t_relay()) {
>     sl_send_reply(500, "Internal Error");
>   }
>
>   exit;
> }
>
> failure_route[invite_failure_route] {
>   if (t_was_cancelled()) {
>     exit;
>   }
>
>   if (t_check_status("3[0-9][0-9]")) {
>     t_reply(404, "Not found");
>     exit;
>   }
> }
>
> _______________________________________________
> 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/20240925/7d9aa429/attachment.html>

From santi.anton at quarea.com  Wed Sep 25 07:31:59 2024
From: santi.anton at quarea.com (=?iso-8859-1?Q?Santi_Ant=F3n?=)
Date: Wed, 25 Sep 2024 07:31:59 +0000
Subject: [OpenSIPS-Users] remove_latency value in pike module is not
 respected
In-Reply-To: <f13ac8ae-6d37-4f02-a9d7-6d7f12ff9ff1@opensips.org>
References: <AS8PR08MB73726C3AC49A5A3F14BDD765939E2@AS8PR08MB7372.eurprd08.prod.outlook.com>
 <f13ac8ae-6d37-4f02-a9d7-6d7f12ff9ff1@opensips.org>
Message-ID: <DU2PR08MB73743E4C26B78AF67DF0149093692@DU2PR08MB7374.eurprd08.prod.outlook.com>

Hello Bogdan,

Thanks, the behavior is clear now.

Salutacions/Saludos,

Santi Antón Oñate
Quarea ITC Management & Consulting
902520520

De: Bogdan-Andrei Iancu <bogdan at opensips.org>
Enviat: martes, 24 de septiembre de 2024 10:41
Per a: OpenSIPS users mailling list <users at lists.opensips.org>; Santi Antón <santi.anton at quarea.com>
Tema: Re: [OpenSIPS-Users] remove_latency value in pike module is not respected

Hi Santi,

The remove_latency is not about "unblocking" the node, but for how slow the nodes should be removed from IP tree, if there are not hits (this is something that controls the collapsing of the tree if there is no traffic/hits).

The node will stay BLOCK as time as there is traffic (as volume) to match the "blocking" condition. As soon as the traffic goes away and the condition fails, the node is unblocked.

I agree that the naming is not the best, neither the explanations in the docs :P...

The idea here is to have pike module as a way of detecting (the flooding srcs) and not as a tool to manage the blocking. For such purposes you can use dedicated tools like file2ban.

Best regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  https://www.opensips-solutions.com

  https://www.siphub.com
On 06.09.2024 15:22, Santi Antón wrote:
Hello,

I'm using pike module with this module configuration.

loadmodule "pike.so"
modparam("pike", "sampling_time_unit", 5)
modparam("pike", "reqs_density_per_unit", 10)
modparam("pike", "remove_latency", 3600)

The module detects the DoS, but 6-8 seconds later unblock the source IP when it is set to last 1h, where I'm going wrong?
I've tried different "remove_latency" values with the same results.
The log shows it.

Sep  5 18:30:32 voiptfm /usr/sbin/opensips[660915]: INFO:PIKE - BLOCKing ip 172.16.53.12, node=0x7f93ec486bc8
Sep  5 18:30:38 voiptfm /usr/sbin/opensips[660934]: INFO:PIKE - UNBLOCKing node 0x7f93ec486bc8

Sep  5 18:30:55 voiptfm /usr/sbin/opensips[660916]: INFO:PIKE - BLOCKing ip 172.16.53.12, node=0x7f93ec486bc8
Sep  5 18:31:03 voiptfm /usr/sbin/opensips[660934]: INFO:PIKE - UNBLOCKing node 0x7f93ec486bc8

Sep  6 13:36:08 voiptfm /usr/sbin/opensips[669077]: INFO:PIKE - BLOCKing ip 172.16.53.12, node=0x7f2727f97448
Sep  6 13:36:13 voiptfm /usr/sbin/opensips[669092]: INFO:PIKE - UNBLOCKing node 0x7f2727f97448


Salutacions/Saludos,

[cid:image001.jpg at 01DB0F2D.A8415340]





Santi Antón
Responsable de operaciones
Tel. 902 520 520 - Ext. 106
santi.anton at quarea.com<mailto:santi.anton at quarea.com>






902 520 520
www.quarea.com<http://www.quarea.com/>
Quarea ITC Management & Consulting
Su experto en Redes Voz-Datos IP:
Asterisk, Cisco, Polycom, Sangoma












En compliment del que es disposa en l'article 13 del Reglament (UE) 2016/679, relatiu a la Protecció de Dades de Caràcter Personal, QUAREA ITC MANAGEMENT & CONSULTING, SL garanteix la confidencialitat de les dades personals dels seus clients. Li comuniquem que la seva adreça de correu electrònic forma part d'una base de dades gestionada sota la responsabilitat de QUAREA ITC MANAGEMENT & CONSULTING, SL, amb l'única finalitat de prestar-li els serveis per vostè sol·licitats, per la seva condició de client, proveïdor, o perquè ens hagi sol·licitat informació en algun moment. Les dades seran conservades durant el temps necessari per poder prestar-li els nostres serveis i complir amb les nostres obligacions legals. És voluntat de QUAREA ITC MANAGEMENT & CONSULTING, SL, evitar l'enviament deliberat de correu no sol·licitat, per la qual cosa podrà a tot moment, exercitar els seus drets d'accés, rectificació, supressió, limitació del seu tractament, oposició i portabilitat de les seves dades de caràcter personal mitjançant el correu electrònic infodat at quarea.com<mailto:infodat at quarea.com>

En cumplimiento de lo dispuesto en el artículo 13 del Reglamento (UE) 2016/679, relativo a la Protección de Datos de Carácter Personal, QUAREA ITC MANAGEMENT & CONSULTING, SL garantiza la confidencialidad de los datos personales de sus clientes. Le comunicamos que su dirección de correo electrónico forma parte de una base de datos gestionada bajo la responsabilidad de QUAREA ITC MANAGEMENT & CONSULTING, SL, con la única finalidad de prestarle los servicios por usted solicitados, por su condición de cliente, proveedor, o porque nos haya solicitado información en algún momento. Los datos serán conservados durante el tiempo necesario para poder prestarle nuestros servicios y cumplir con nuestras obligaciones legales. Es voluntad de QUAREA ITC MANAGEMENT & CONSULTING, SL, evitar el envío deliberado de correo no solicitado, por lo cual podrá en todo momento, ejercitar sus derechos de acceso, rectificación, supresión, limitación de su tratamiento, oposición y portabilidad de sus datos de carácter personal mediante el correo electrónico infodat at quarea.com<mailto:infodat at quarea.com>

In compliance with the provisions of Article 13 of Regulation (EU) 2016/679, regarding the Protection of Personal Data, QUAREA ITC MANAGEMENT & CONSULTING, SL guarantees the confidentiality of the personal data of his customers. We inform you that your email address is part of a managed database under the responsibility of QUAREA ITC MANAGEMENT & CONSULTING, SL, for the sole purpose of providing the services requested by you, as a client, supplier, or because we have requested information at some time. The data will be kept for the time necessary to provide our services and comply with our legal obligations. It is the will of QUAREA ITC MANAGEMENT & CONSULTING, SL, to avoid the deliberate sending of unsolicited mail, so that it may, at any time, exercise your rights of access, rectification, removal, limitation of his treatment, opposition and portability of his personal data through the email infodat at quarea.com<mailto:infodat at quarea.com>




_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240925/0921d79b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7811 bytes
Desc: image001.jpg
URL: <http://lists.opensips.org/pipermail/users/attachments/20240925/0921d79b/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 166 bytes
Desc: image002.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20240925/0921d79b/attachment-0001.png>

From 8968934 at gmail.com  Thu Sep 26 14:03:59 2024
From: 8968934 at gmail.com (Dmitry Gimalayskiy)
Date: Thu, 26 Sep 2024 17:03:59 +0300
Subject: [OpenSIPS-Users] db_text for drouting - column gwid has a bad type
	[4], accepting only [3]
Message-ID: <CAKOvPxtndsMOrzgH96WwUsR4WpbO1+v=ZtWEm4rATTVB3wPZUA@mail.gmail.com>

Hello everybody!

I am trying to use db_text for drouting, but I am getting an error when
loading the opensips:


# tail -f /var/log/opensips/opensips.log | egrep "ERR|CRIT|WAR"
ERROR:drouting:dr_load_routing_info: column gwid has a bad type [4],
accepting only [3]"
CRITICAL:drouting:dr_reload_data_head: failed to load routing info"

This is my db_text/dr_gateways:
# cat db_text/dr_gateways
id(int) gwid(str) type(int) address(str) strip(int) pri_prefix(str,null)
attrs(str,null) probe_mode(int) state(int) socket(str,null)
description(str,null)
1:asterisk:0:10.214.0.78:0:::0:0:udp\:10.214.0.77\:5081:test out provider
server\n

And opensips version:
# opensips-cli -x mi version
{
    "Server": "OpenSIPS (3.4.5 (x86_64/linux))"
}

How can I fix this error?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240926/a9c19cf9/attachment.html>

From bogdan at opensips.org  Fri Sep 27 06:32:00 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 27 Sep 2024 09:32:00 +0300
Subject: [OpenSIPS-Users] registrant example
In-Reply-To: <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
 <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
 <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>
Message-ID: <451c09b5-17d8-433b-8480-909955a59db5@opensips.org>

Hi Alberto,

There is no automatic way to do the inbound detection (via the registrar 
module). What you can do is to use the permissions module, with the 
address table as a view over the registrant table, so you do the inbound 
IP auth.

Regards,

Bogdan-Andrei Iancu

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

On 25.09.2024 14:00, Alberto wrote:
> Thanks,
>
> So, for n1, after ip auth I can validate the contact matches one of 
> the contacts used to register, but there's no function to do that 
> automatically.
> So in the case where opensips is keeping 2 registrations up to the 
> same server, it's up to me to validate which one was used.
>
> n2, thanks again, I got it working by loading the credentials with 
> avp_db_query.
>
> Regards
> A
>
> On Mon, 23 Sept 2024 at 07:52, Bogdan-Andrei Iancu 
> <bogdan at opensips.org> wrote:
>
>     Hi,
>
>     1) The Registrant OpenSIPS should do an IP auth for the Remote SIP
>     provider. OpenSIPS knows the server it registered with, so it
>     should be able to do IP auth
>
>     2) there is notthing standard about loading the credentials, you
>     can do it in any way that works for you, like having them hard
>     coded in cfg (if the same credentials are to be used for the all
>     calls), or loading them from DB (using sqlops module), or HTTP
>     rest query.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        https://www.opensips-solutions.com
>        https://www.siphub.com
>
>     On 22.09.2024 03:10, Alberto wrote:
>>     Hi,
>>
>>     I'm trying to put together a simple script to use uac_registrant
>>     So I have:
>>     LEFT SIP SERVERS <-[ip authentication]-> OPENSIPS
>>     <-[uac_registrant]-> REMOTE SIP PROVIDER
>>
>>     Here's the 2 problems I still have:
>>     I have the users for the remote sip provider in the registrant
>>     table, and opensips is already able to register to this remote
>>     sip provider,but:
>>     - When an INVITE comes from the remote sip provider I register
>>     to, how do I validate which user is it related to? Where should I
>>     store avp, and how should I load them?
>>     - When an INVITE comes from the left sip servers and I have to
>>     call the remote sip provider, how do I load the credentials from
>>     the database to authenticate the INVITE to the remote sip provider?
>>
>>     I'm using the address table for the left sip servers and
>>     check_address, but I've stripped all that from my example below.
>>     I hope this makes sense, thank you.
>>
>>     Here is a short example script I'm working with
>>
>>     #######
>>     debug_mode=no
>>
>>     log_level=2
>>     xlog_level=2
>>     log_stdout=yes
>>     stderror_enabled=yes
>>     syslog_facility=LOG_LOCAL0
>>
>>     auto_aliases=no
>>
>>     server_signature=yes
>>
>>     socket=udp:0.0.0.0:5060 <http://0.0.0.0:5060>
>>
>>     mpath="/usr/lib64/opensips/modules/"
>>
>>     loadmodule "db_mysql.so"
>>
>>     loadmodule "signaling.so"
>>
>>     loadmodule "sl.so"
>>
>>     loadmodule "tm.so"
>>     modparam("tm", "auto_100trying", 0)
>>     modparam("tm", "fr_inv_timeout", 120)
>>     modparam("tm", "fr_timeout", 30)
>>     modparam("tm", "onreply_avp_mode", 1)
>>     modparam("tm", "restart_fr_on_each_reply", 0)
>>
>>     loadmodule "rr.so"
>>     modparam("rr", "append_fromtag", 1)
>>
>>     loadmodule "dialog.so"
>>     modparam("dialog", "default_timeout", 14400)
>>     modparam("dialog", "dlg_match_mode", 1)
>>     modparam("dialog", "enable_stats", 1)
>>     modparam("dialog", "profiles_with_value", "caller")
>>
>>     loadmodule "sipmsgops.so"
>>
>>     loadmodule "usrloc.so"
>>
>>     loadmodule "registrar.so"
>>
>>     loadmodule "uac_auth.so"
>>     modparam("uac_auth", "credential", "username:domain:password")
>>
>>     loadmodule "uac_registrant.so"
>>     modparam("uac_registrant", "db_url",
>>     "mysql://opensips:opensipsrw at localhost/opensips")
>>
>>     loadmodule "proto_udp.so"
>>
>>     route {
>>       if (has_totag()) {
>>         if (loose_route()) {
>>           if ($DLG_status != NULL && !validate_dialog()) {
>>             exit;
>>           }
>>         } else {
>>           if (is_method("ACK")) {
>>             if (t_check_trans()) {
>>               t_relay();
>>             }
>>             exit;
>>           }
>>
>>           sl_send_reply(404, "Not Found");
>>           exit;
>>         }
>>
>>         t_relay();
>>
>>         exit;
>>       }
>>
>>       if (is_method("CANCEL")) {
>>         if (t_check_trans()) {
>>           t_relay();
>>         }
>>         exit;
>>       }
>>
>>       t_check_trans();
>>
>>       if (is_method("INVITE")) {
>>         if (!create_dialog("B")) {
>>           sl_send_reply(500, "Internal Server Error");
>>           exit;
>>         }
>>       }
>>
>>       route(relay);
>>     }
>>
>>     route[relay] {
>>       if (is_method("INVITE")) {
>>         # VALIDATE THIS RELATES TO A USER IN THE UAC_REGISTRANT TABLE
>>     AND LOAD AVPS
>>         # OR LOAD CREDENTIALS TO SEND INVITE ONWARD TO THE REMOTE SIP
>>     PROVIDER
>>
>>         t_on_failure("invite_failure_route");
>>       }
>>
>>       if (!t_relay()) {
>>         sl_send_reply(500, "Internal Error");
>>       }
>>
>>       exit;
>>     }
>>
>>     failure_route[invite_failure_route] {
>>       if (t_was_cancelled()) {
>>         exit;
>>       }
>>
>>       if (t_check_status("3[0-9][0-9]")) {
>>         t_reply(404, "Not found");
>>         exit;
>>       }
>>     }
>>
>>     _______________________________________________
>>     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/20240927/37aaeade/attachment.html>

From bogdan at opensips.org  Fri Sep 27 06:43:08 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 27 Sep 2024 09:43:08 +0300
Subject: [OpenSIPS-Users] db_text for drouting - column gwid has a bad
 type [4], accepting only [3]
In-Reply-To: <CAKOvPxtndsMOrzgH96WwUsR4WpbO1+v=ZtWEm4rATTVB3wPZUA@mail.gmail.com>
References: <CAKOvPxtndsMOrzgH96WwUsR4WpbO1+v=ZtWEm4rATTVB3wPZUA@mail.gmail.com>
Message-ID: <9f4422c3-2b66-4a59-8b2a-453510af025b@opensips.org>

Hi Dmitry,

Yeah, a bit of a know but ignored issue - most of the module in 
OpenSIPS, when loading data from DB, expect a DB_STRING (a NULL 
terminated string) to be returned. But the db_text driver is returning a 
DB_STR (string with len, not NULL terminated). And the drouting module 
is a bit more strict when comes to checking the returned data types.

Could you open please a bug report on github tracker, maybe it is time 
to get a proper fix for this.

Regards,

Bogdan-Andrei Iancu

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

On 26.09.2024 17:03, Dmitry Gimalayskiy wrote:
> Helloeverybody!
>
> I am trying to use db_text for drouting, but I am getting an error 
> when loading the opensips:
>
>
> # tail -f /var/log/opensips/opensips.log | egrep "ERR|CRIT|WAR"
> ERROR:drouting:dr_load_routing_info: column gwid has a bad type [4], 
> accepting only [3]"
> CRITICAL:drouting:dr_reload_data_head: failed to load routing info"
>
> This is my db_text/dr_gateways:
> # cat db_text/dr_gateways
> id(int) gwid(str) type(int) address(str) strip(int) 
> pri_prefix(str,null) attrs(str,null) probe_mode(int) state(int) 
> socket(str,null) description(str,null)
> 1:asterisk:0:10.214.0.78:0:::0:0:udp\:10.214.0.77\:5081:test out 
> provider server\n
>
> And opensips version:
> # opensips-cli -x mi version
> {
>     "Server": "OpenSIPS (3.4.5 (x86_64/linux))"
> }
>
> How can I fix this error?
>
> _______________________________________________
> 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/20240927/beaa2bed/attachment-0001.html>

From slackway2me at gmail.com  Fri Sep 27 08:52:38 2024
From: slackway2me at gmail.com (Alexey)
Date: Fri, 27 Sep 2024 13:52:38 +0500
Subject: [OpenSIPS-Users] registrant example
In-Reply-To: <451c09b5-17d8-433b-8480-909955a59db5@opensips.org>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
 <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
 <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>
 <451c09b5-17d8-433b-8480-909955a59db5@opensips.org>
Message-ID: <CAPc6LUHQT_9=eM+0uKF=X5M4Dq1GidnQx_-WxhLo=a-_rP5Jnw@mail.gmail.com>

Hi all,

I would also like to mention the correlation between OpenSIPS configuration
parameters and SIP headers in the SIP-registration process:

according to the SIP protocol implementation, you are able to form the
username in the Contact: header of your outgoing REGISTER-requests.
In OpenSIPS you have to fill it in the 'binding_uri' column of the
'registrant' table [1].

E.g. you want the remote server to send you INVITE with 'alice' in the
username of the SIP Request's URI (rU [2] ), and your server's IP is 1.2.3.4,
so you have to add 'sip:alice at 1.2.3.4' into this column.

During outbound registration, your OpenSIPS will form the Contact: header
in it's REGISTER request smth like:

    Contact: <sip:alice at 1.2.3.4>;expires=3600

So, after successful registration the remote server will send INVITEs to your
OpenSIPS like:

    INVITE sip:alice at 1.2.3.4:5060;user=phone SIP/2.0

After that you can catch such rU using different techniques, starting
from simple hard coding in the script:

    if ( $rU == "alice" )
        xlof(L_INFO, "[$ci] relaying to Asterisk PBX");
        t_relay(, "192.168.88.11:5060");

... or in case if there are many incoming extensions, you may also use
Dynamic Routing [3] module, to detect how to route inbound calls, according
to prefix, filling the 'prefix' column of 'dr_rules' table [4] with
the same username,
you populate the Contact: header in outbound REGISTER-requests
and respectively the same which will send the remote server in its INVITEs.


[1] https://www.opensips.org/Documentation/Install-DBSchema-3-5#GEN-DB-REGISTRANT
[2] https://www.opensips.org/Documentation/Script-CoreVar-3-5#toc77
[3] https://opensips.org/docs/modules/3.5.x/drouting.html
[4] https://www.opensips.org/Documentation/Install-DBSchema-3-5#GEN-DB-DR-RULES


-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From slackway2me at gmail.com  Fri Sep 27 09:03:24 2024
From: slackway2me at gmail.com (Alexey)
Date: Fri, 27 Sep 2024 14:03:24 +0500
Subject: [OpenSIPS-Users] db_text for drouting - column gwid has a bad
 type [4], accepting only [3]
In-Reply-To: <9f4422c3-2b66-4a59-8b2a-453510af025b@opensips.org>
References: <CAKOvPxtndsMOrzgH96WwUsR4WpbO1+v=ZtWEm4rATTVB3wPZUA@mail.gmail.com>
 <9f4422c3-2b66-4a59-8b2a-453510af025b@opensips.org>
Message-ID: <CAPc6LUHM4OtkApfL04kmmYo+rmHiwWj9n_A5EUbiN1rT5=Xzrg@mail.gmail.com>

Hi Dmitriy,

I would also recommend adding sip: to your gateway address,
I mean not just 10.214.0.78 , but sip:10.214.0.78 is correct.

If I'm not mistaken, some OpenSIPS versions returned errors,
when gateways' addresses did not have 'sip:' at the beginning.


-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From bogdan at opensips.org  Fri Sep 27 09:06:52 2024
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 27 Sep 2024 12:06:52 +0300
Subject: [OpenSIPS-Users] registrant example
In-Reply-To: <CAPc6LUHQT_9=eM+0uKF=X5M4Dq1GidnQx_-WxhLo=a-_rP5Jnw@mail.gmail.com>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
 <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
 <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>
 <451c09b5-17d8-433b-8480-909955a59db5@opensips.org>
 <CAPc6LUHQT_9=eM+0uKF=X5M4Dq1GidnQx_-WxhLo=a-_rP5Jnw@mail.gmail.com>
Message-ID: <bebfbe70-8d57-4eda-bc3e-00f622947881@opensips.org>

Authentication based on the content of the SIP message is weak, pron to 
easy attacks. Anyone can easily send you a call with "alice at 1.2.3.4" :P. 
Without a proper auth method (like digest or IP-auth), it totally 
unreliable.

Regards,

Bogdan-Andrei Iancu

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

On 27.09.2024 11:52, Alexey wrote:
> Hi all,
>
> I would also like to mention the correlation between OpenSIPS configuration
> parameters and SIP headers in the SIP-registration process:
>
> according to the SIP protocol implementation, you are able to form the
> username in the Contact: header of your outgoing REGISTER-requests.
> In OpenSIPS you have to fill it in the 'binding_uri' column of the
> 'registrant' table [1].
>
> E.g. you want the remote server to send you INVITE with 'alice' in the
> username of the SIP Request's URI (rU [2] ), and your server's IP is 1.2.3.4,
> so you have to add 'sip:alice at 1.2.3.4' into this column.
>
> During outbound registration, your OpenSIPS will form the Contact: header
> in it's REGISTER request smth like:
>
>      Contact: <sip:alice at 1.2.3.4>;expires=3600
>
> So, after successful registration the remote server will send INVITEs to your
> OpenSIPS like:
>
>      INVITE sip:alice at 1.2.3.4:5060;user=phone SIP/2.0
>
> After that you can catch such rU using different techniques, starting
> from simple hard coding in the script:
>
>      if ( $rU == "alice" )
>          xlof(L_INFO, "[$ci] relaying to Asterisk PBX");
>          t_relay(, "192.168.88.11:5060");
>
> ... or in case if there are many incoming extensions, you may also use
> Dynamic Routing [3] module, to detect how to route inbound calls, according
> to prefix, filling the 'prefix' column of 'dr_rules' table [4] with
> the same username,
> you populate the Contact: header in outbound REGISTER-requests
> and respectively the same which will send the remote server in its INVITEs.
>
>
> [1] https://www.opensips.org/Documentation/Install-DBSchema-3-5#GEN-DB-REGISTRANT
> [2] https://www.opensips.org/Documentation/Script-CoreVar-3-5#toc77
> [3] https://opensips.org/docs/modules/3.5.x/drouting.html
> [4] https://www.opensips.org/Documentation/Install-DBSchema-3-5#GEN-DB-DR-RULES
>
>



From slackway2me at gmail.com  Fri Sep 27 09:16:16 2024
From: slackway2me at gmail.com (Alexey)
Date: Fri, 27 Sep 2024 14:16:16 +0500
Subject: [OpenSIPS-Users] registrant example
In-Reply-To: <bebfbe70-8d57-4eda-bc3e-00f622947881@opensips.org>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
 <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
 <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>
 <451c09b5-17d8-433b-8480-909955a59db5@opensips.org>
 <CAPc6LUHQT_9=eM+0uKF=X5M4Dq1GidnQx_-WxhLo=a-_rP5Jnw@mail.gmail.com>
 <bebfbe70-8d57-4eda-bc3e-00f622947881@opensips.org>
Message-ID: <CAPc6LUE_hKxFpo=BNCFz+XnNzt_zQ_3xQPxNcMBvBctCWnavsQ@mail.gmail.com>

Hi Bogdan,

sure. My previous message was mostly intended to explain -
what username will contain the request-uri line of the incoming INVITE,
and how to catch such an invite in the script.

It was not about authentication.

Speaking about authentication I totally agree with your advice about
Permissions [1] module.
In my practice we also used Dynamic Routing module (with the logic
'accept invites from IP addresses which are added as gateways of some type'),
and some more complicated scripting with checking the $si [2] with the
logic 'allow incoming invite if the source IP address is among all those
towards which we are registering to using uac_registrant module'.


[1] https://opensips.org/docs/modules/3.5.x/permissions.html
[2] https://www.opensips.org/Documentation/Script-CoreVar-3-5#toc79


-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From inder.itpro at gmail.com  Sat Sep 28 10:56:55 2024
From: inder.itpro at gmail.com (inderjeet sharma)
Date: Sat, 28 Sep 2024 16:26:55 +0530
Subject: [OpenSIPS-Users] Segfault with Python Module
Message-ID: <CAOAEC9Eiopbcm+Tv0rGr5+wU+w2PNynhvh7n-Jm0Gk+Fq1x7SQ@mail.gmail.com>

Hi,
I'm experiencing a critical issue when trying to start OpenSIPS with the
Python module enabled. Upon starting the service, I encounter a
segmentation fault. Below are the relevant error logs:

└─# opensips -V
version: opensips 3.2.0 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: a9bd831a6
main.c compiled on 05:46:38 Jul 26 2021 with gcc 8


/usr/local/sbin/opensips[1168977]: DBG:core:init_mod: initializing module
python
CRITICAL:core:sig_usr: segfault in attendant (starter) process!
DBG:core:restore_segv_handler: restoring SIGSEGV handler...
opensips: DBG:core:wait_status_code: read code 0 (0 byte)
opensips: INFO:core:daemonize: pre-daemon process exiting with -1
systemd[1]: opensips.service: Control process exited, code=exited,
status=255/EXCEPTION
systemd[1]: opensips.service: Failed with result 'exit-code'.
systemd[1]: Failed to start opensips.service - OpenSIPS is a very fast and
flexible SIP (RFC3261) server.
systemd[1]: opensips.service: Scheduled restart job, restart counter is at
5.
systemd[1]: Stopped opensips.service - OpenSIPS is a very fast and flexible
SIP (RFC3261) server.

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

From stefano.pisani at omnianet.it  Sat Sep 28 15:55:01 2024
From: stefano.pisani at omnianet.it (Stefano Pisani)
Date: Sat, 28 Sep 2024 17:55:01 +0200
Subject: [OpenSIPS-Users] registrant example
In-Reply-To: <bebfbe70-8d57-4eda-bc3e-00f622947881@opensips.org>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
 <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
 <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>
 <451c09b5-17d8-433b-8480-909955a59db5@opensips.org>
 <CAPc6LUHQT_9=eM+0uKF=X5M4Dq1GidnQx_-WxhLo=a-_rP5Jnw@mail.gmail.com>
 <bebfbe70-8d57-4eda-bc3e-00f622947881@opensips.org>
Message-ID: <89fb2a73-32a8-4346-b88e-19416ac21274@omnianet.it>

Hello. I have a strange problem.

I'm using docker official image. It seems unable to load the 
configuration file for some reason.

opensips  | Sep 28 15:44:28 [1] WARNING:core:exec_preprocessor: no 
output from the preprocessor! Does it print to standard output?
opensips  | Sep 28 15:44:28 [1] CRITICAL:core:yyerror: parse error in 
default:1:1-1: syntax error
opensips  | Sep 28 15:44:28 [1] ERROR:core:parse_opensips_cfg: bad 
config file (1 errors)
opensips  | Sep 28 15:44:28 [1] ERROR:core:main: failed to parse config 
file (null)
opensips  | Sep 28 15:44:28 [1] NOTICE:core:main: Exiting....
opensips exited with code 255

The configuration file is in the right place. If I remove it I get the 
error "opensips.cfg missing".

Any idea?

Thanks

Stefano




From stefano.pisani at omnianet.it  Sat Sep 28 19:56:09 2024
From: stefano.pisani at omnianet.it (Stefano Pisani)
Date: Sat, 28 Sep 2024 21:56:09 +0200
Subject: [OpenSIPS-Users] error migrating database to 3.5
In-Reply-To: <89fb2a73-32a8-4346-b88e-19416ac21274@omnianet.it>
References: <CANoA6_J24cCQay4gHKLC=kA4XAU7L9PU5caLyQ+oTowf_0qCvw@mail.gmail.com>
 <99433521-4230-4685-b67a-a60868f7a023@opensips.org>
 <CANoA6_KGwsz2os3BVg3SngTHvESawmqxCLB6hF-mJUEWsXDc8g@mail.gmail.com>
 <451c09b5-17d8-433b-8480-909955a59db5@opensips.org>
 <CAPc6LUHQT_9=eM+0uKF=X5M4Dq1GidnQx_-WxhLo=a-_rP5Jnw@mail.gmail.com>
 <bebfbe70-8d57-4eda-bc3e-00f622947881@opensips.org>
 <89fb2a73-32a8-4346-b88e-19416ac21274@omnianet.it>
Message-ID: <0273e469-5c13-4fe3-9c3d-078e87dee04c@omnianet.it>

Hello,

I used opensips-cli to migrate database from 3.4 to 3.5 but I got an error:

ERROR: unsupported migration flavour: 3.4_to_3.5

I used opensips-cli from github https://github.com/OpenSIPS/opensips-cli

$ opensips-cli --version
OpenSIPS CLI 0.2.0

I checked modules/database.py and 3.4_to_3.5 is missing actually.

I followed this guide 
https://www.opensips.org/Documentation/Migration-3-4-0-to-3-5-0.

What I missed?

Thanks

Stefano



From daniel.cogo at gmail.com  Mon Sep 30 19:12:11 2024
From: daniel.cogo at gmail.com (Daniel Cogo De Vargas)
Date: Mon, 30 Sep 2024 16:12:11 -0300
Subject: [OpenSIPS-Users] Problem with TLS and MS Teams
Message-ID: <CANBmQejMVPszg02cr25EebEGqeF=EY9FA4vtSDewNnRhxQBRtA@mail.gmail.com>

Hi

I have problem with Opensips 3.2 and MS Teams.

I´m used the certify and private key generated from Go Daddy.

I´m check the files and are OK. The extensions SIP register with TLS mode
and make call. But when I try receive a call from MS Teams show the message
error:

NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify failure
NOTICE:tls_wolfssl:verify_callback: subject =
/C=US/ST=WA/L=Redmond/O=Microsoft Corporation/CN=sip.pstnhub.microsoft.com
NOTICE:tls_wolfssl:verify_callback: issuer  = /C=US/O=Microsoft
Corporation/CN=Microsoft Azure RSA TLS Issuing CA 03
NOTICE:tls_wolfssl:verify_callback: verify error: certificate verify failed
[error=-188]
ERROR:tls_wolfssl:_wolfssl_tls_accept: New TLS connection from
52.114.132.46:25236 failed to accept
ERROR:tls_wolfssl:_wolfssl_tls_accept: TLS accept error: -188, certificate
verify failed
ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake!

Best Regards,
Daniel Cogo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240930/2c5cebf4/attachment.html>

From nway at foxmail.com  Thu Sep 26 22:05:17 2024
From: nway at foxmail.com (=?utf-8?B?6ICB5p2OLUZTR1VJLOeUteivneacuuWZqOS6ug==?=)
Date: Fri, 27 Sep 2024 06:05:17 +0800
Subject: [OpenSIPS-Users] db_text for drouting - column gwid has a bad
	type[4], accepting only [3]
Message-ID: <tencent_92A2D83044BE612418685217B996F96A8706@qq.com>

you can change gwid type to int4 or int



---Original---
From: "Dmitry Gimalayskiy"<8968934 at gmail.com&gt;
Date: Thu, Sep 26, 2024 22:05 PM
To: "users"<users at lists.opensips.org&gt;;
Subject: [OpenSIPS-Users] db_text for drouting - column gwid has a bad type[4], accepting only [3]


Hello everybody!


I am trying to use&nbsp;db_text for drouting,&nbsp;but I am getting an error when loading the opensips:


# tail -f /var/log/opensips/opensips.log | egrep "ERR|CRIT|WAR"
ERROR:drouting:dr_load_routing_info: column gwid has a bad type [4], accepting only [3]"
CRITICAL:drouting:dr_reload_data_head: failed to load routing info"

This is my db_text/dr_gateways: 
# cat db_text/dr_gateways 
id(int)  gwid(str) type(int) address(str) strip(int) pri_prefix(str,null)  attrs(str,null) probe_mode(int) state(int) socket(str,null)  description(str,null)
1:asterisk:0:10.214.0.78:0:::0:0:udp\:10.214.0.77\:5081:test out provider server\n


And opensips version:
# opensips-cli -x mi version
{
&nbsp; &nbsp; "Server": "OpenSIPS (3.4.5 (x86_64/linux))"
}


How can I fix this error?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240927/8bc5c429/attachment-0001.html>