Re: [OpenSIPS-Users] Help with rtpproxy on a multihomed host.

[Sharad Kumar via Users]

Hi Matt,


If you want to do topology hiding too in your setup, I would recommend 
you, to use topology hiding module instead of using B2B_LOGIC one.



Thanks and Regards

Sharad Kumar


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

Re: [OpenSIPS-Users] Help with rtpproxy on a multihomed host.

[SamyGo]

Hi,
if *a.a.a.a* is PublicIP and *b.b.b.b* is Private IP ; where c.c.c.c is
another Private IP address then you just need to enable multihome param "
*mhomed=1" *in your opensips.cfg script and OpenSIPS should take care of
relaying the packet our with proper SIP headers, the selection of the
interface to "c.c.c.c" will be done automatically if the Operating System's
IP routes are configured properly i.e b.b.b.b can reach c.c.c.c.

Next up is the rpproxy engagement, you'll need to do couple of things for
that.
1 - start RTPproxy in bridging mode i.e  -l a.a.a.a/b.b.b.b
2 - in your opensips.cfg you've to explicitly tell the rtpproxy which
direction this call is flowing by use of flags and other functions.

i.e
if(call-from-WAN->LAN)
* rtpproxy_engage("ei");*

if(call-from-LAN->WAN)
* rtpproxy_engage("ie");*

You might need additional flags in there as this is just an example. Hope
this helps.

Regards,
Sammy




On Tue, Jan 7, 2020 at 8:22 PM Matthew Schumacher  wrote:

> Hello all,
>
> I'm trying to setup an SBC of sorts so that I can have users
> authenticate to opensips using a public interface, then have opensips
> relay and rtpproxy that request to a private sip host.
>
> Something like this:
>
> public sip client ---(proxy authetication)--> aa.aa.aa.aa bb.bb.bb.bb
> (sip trunk auth by ip) --->  cc.cc.cc.cc (inside sip gateway)
>
> Where aa.aa.aa.aa and bb.bb.bb.bb live on the same host.
>
> I used osipsconfig with use_auth, use_dbacc, use_dbusrloc, use_dialog,
> use_multidomain, use_dialplan, have_inbound_pstn, have_outbound_pstn
>
> I then took the config it created and added rtpproxy module and config
> as well as force_send_socket() because when it sent sip to cc.cc.cc.c it
> was sourcing from aa.aa.aa.aa instead of bb.bb.bb.bb.
>
> It almost works, and actually works with one way audio from cc.cc.cc.cc
> through the proxy to the client, but opensips tells the client that the
> audio is at cc.cc.cc.cc which doesn't route.
>
> What's the best way to do multi homing?  opensips seems fairly straight
> forward with a single IP address, but things got complicated fast when I
> added a second IP.
>
> I would just use b2b_init_request("top hiding"); but I get lots of loops
> when I do that.
>
> Thanks,
> Matt
>
>
> ### Global Parameters #
>
> log_level=4
> log_stderror=yes
> log_facility=LOG_LOCAL0
>
> children=4
>
> /* uncomment the following lines to enable debugging */
> #debug_mode=yes
>
> /* uncomment the next line to enable the auto temporary blacklisting of
> not available destinations (default disabled) */
> #disable_dns_blacklist=no
>
> /* uncomment the next line to enable IPv6 lookup after IPv4 dns
> lookup failures (default disabled) */
> #dns_try_ipv6=yes
>
> /* comment the next line to enable the auto discovery of local aliases
> based on reverse DNS on IPs */
> auto_aliases=no
>
> listen=udp:bb.bb.bb.bb:5060   # CUSTOMIZE ME
> listen=udp:aa.aa.aa.aa:5060   # CUSTOMIZE ME
>
>
> ### Modules Section 
>
> #set module path
> mpath="/usr/lib64/opensips/modules/"
>
>  SIGNALING module
> loadmodule "signaling.so"
>
>  StateLess module
> loadmodule "sl.so"
>
>  Transaction Module
> loadmodule "tm.so"
> modparam("tm", "fr_timeout", 5)
> modparam("tm", "fr_inv_timeout", 30)
> modparam("tm", "restart_fr_on_each_reply", 0)
> modparam("tm", "onreply_avp_mode", 1)
>
>  Record Route Module
> loadmodule "rr.so"
> /* do not append from tag to the RR (no need for this script) */
> modparam("rr", "append_fromtag", 0)
>
>  MAX ForWarD module
> loadmodule "maxfwd.so"
>
>  SIP MSG OPerationS module
> loadmodule "sipmsgops.so"
>
>  FIFO Management Interface
> loadmodule "mi_fifo.so"
> modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
> modparam("mi_fifo", "fifo_mode", 0666)
>
>  PGSQL module
> loadmodule "db_postgres.so"
>
>  HTTPD module
> loadmodule "httpd.so"
> modparam("httpd", "port", )
>
>  USeR LOCation module
> loadmodule "usrloc.so"
> modparam("usrloc", "nat_bflag", "NAT")
> modparam("usrloc", "db_mode",   2)
> modparam("usrloc", "db_url",
>  "postgres://opensips:longpassword@localhost/opensips") # CUSTOMIZE ME
>
>
>  REGISTRAR module
> loadmodule "registrar.so"
> modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT")
> /* uncomment the next line not to allow more than 10 contacts per AOR */
> #modparam("registrar", "max_contacts", 10)
>
>  ACCounting module
> loadmodule "acc.so"
> /* what special events should be accounted ? */
> modparam("acc", "early_media", 0)
> modparam("acc", "report_cancels", 0)
> /* by default we do not adjust the direct of the sequential requests.
> if you enable this parameter, be sure the enable "append_fromtag"
> in "rr" module */
> modparam("acc", "detect_direction", 0)
> modparam("acc", "db_url",
>  "postgres://opensips:longpassword@localhost/opensips") # CUSTOMIZE ME
>
>  AUTHentication modules
> loadmodule "auth.so"
> loadmodule "auth_db.so"
> 

[OpenSIPS-Users] Help with rtpproxy on a multihomed host.

[Matthew Schumacher]

Hello all,

I'm trying to setup an SBC of sorts so that I can have users 
authenticate to opensips using a public interface, then have opensips 
relay and rtpproxy that request to a private sip host.


Something like this:

public sip client ---(proxy authetication)--> aa.aa.aa.aa bb.bb.bb.bb  
(sip trunk auth by ip) --->  cc.cc.cc.cc (inside sip gateway)


Where aa.aa.aa.aa and bb.bb.bb.bb live on the same host.

I used osipsconfig with use_auth, use_dbacc, use_dbusrloc, use_dialog, 
use_multidomain, use_dialplan, have_inbound_pstn, have_outbound_pstn


I then took the config it created and added rtpproxy module and config 
as well as force_send_socket() because when it sent sip to cc.cc.cc.c it 
was sourcing from aa.aa.aa.aa instead of bb.bb.bb.bb.


It almost works, and actually works with one way audio from cc.cc.cc.cc 
through the proxy to the client, but opensips tells the client that the 
audio is at cc.cc.cc.cc which doesn't route.


What's the best way to do multi homing?  opensips seems fairly straight 
forward with a single IP address, but things got complicated fast when I 
added a second IP.


I would just use b2b_init_request("top hiding"); but I get lots of loops 
when I do that.


Thanks,
Matt


### Global Parameters #

log_level=4
log_stderror=yes
log_facility=LOG_LOCAL0

children=4

/* uncomment the following lines to enable debugging */
#debug_mode=yes

/* uncomment the next line to enable the auto temporary blacklisting of
   not available destinations (default disabled) */
#disable_dns_blacklist=no

/* uncomment the next line to enable IPv6 lookup after IPv4 dns
   lookup failures (default disabled) */
#dns_try_ipv6=yes

/* comment the next line to enable the auto discovery of local aliases
   based on reverse DNS on IPs */
auto_aliases=no

listen=udp:bb.bb.bb.bb:5060   # CUSTOMIZE ME
listen=udp:aa.aa.aa.aa:5060   # CUSTOMIZE ME


### Modules Section 

#set module path
mpath="/usr/lib64/opensips/modules/"

 SIGNALING module
loadmodule "signaling.so"

 StateLess module
loadmodule "sl.so"

 Transaction Module
loadmodule "tm.so"
modparam("tm", "fr_timeout", 5)
modparam("tm", "fr_inv_timeout", 30)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "onreply_avp_mode", 1)

 Record Route Module
loadmodule "rr.so"
/* do not append from tag to the RR (no need for this script) */
modparam("rr", "append_fromtag", 0)

 MAX ForWarD module
loadmodule "maxfwd.so"

 SIP MSG OPerationS module
loadmodule "sipmsgops.so"

 FIFO Management Interface
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("mi_fifo", "fifo_mode", 0666)

 PGSQL module
loadmodule "db_postgres.so"

 HTTPD module
loadmodule "httpd.so"
modparam("httpd", "port", )

 USeR LOCation module
loadmodule "usrloc.so"
modparam("usrloc", "nat_bflag", "NAT")
modparam("usrloc", "db_mode",   2)
modparam("usrloc", "db_url",
    "postgres://opensips:longpassword@localhost/opensips") # CUSTOMIZE ME


 REGISTRAR module
loadmodule "registrar.so"
modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT")
/* uncomment the next line not to allow more than 10 contacts per AOR */
#modparam("registrar", "max_contacts", 10)

 ACCounting module
loadmodule "acc.so"
/* what special events should be accounted ? */
modparam("acc", "early_media", 0)
modparam("acc", "report_cancels", 0)
/* by default we do not adjust the direct of the sequential requests.
   if you enable this parameter, be sure the enable "append_fromtag"
   in "rr" module */
modparam("acc", "detect_direction", 0)
modparam("acc", "db_url",
    "postgres://opensips:longpassword@localhost/opensips") # CUSTOMIZE ME

 AUTHentication modules
loadmodule "auth.so"
loadmodule "auth_db.so"
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "db_url",
    "postgres://opensips:longpassword@localhost/opensips") # CUSTOMIZE ME
modparam("auth_db", "load_credentials", "")

 DOMAIN module
loadmodule "domain.so"
modparam("domain", "db_url",
    "postgres://opensips:longpassword@localhost/opensips") # 
CUSTOMIZE ME

modparam("domain", "db_mode", 1)   # Use caching
modparam("auth_db|usrloc", "use_domain", 1)

 DIALOG module
loadmodule "dialog.so"
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
modparam("dialog", "db_mode", 2)
modparam("dialog", "db_url",
    "postgres://opensips:longpassword@localhost/opensips") # CUSTOMIZE ME

  DIALPLAN module
loadmodule "dialplan.so"
modparam("dialplan", "db_url",
    "postgres://opensips:longpassword@localhost/opensips") # CUSTOMIZE ME

  MI_HTTP module
loadmodule "mi_http.so"
modparam("mi_http", "root", "json")

loadmodule "proto_udp.so"
loadmodule "proto_tcp.so"

loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # 
CUSTOMIZE ME


loadmodule "json.so"
loadmodule 

Re: [OpenSIPS-Users] Dialog profiles replication issues

[SamyGo]

Hi Vlad,
Update: it wasn't the issue with dialog module or bin_proto. When I used
avp_db_query() inside async() that led to script processing to halt, I've
removed the async() and its working fine now, however the crash for adding
a new profile variable is still there and needs resolution.

Best Regards,
Sammy


On Tue, Jan 7, 2020 at 11:38 AM SamyGo  wrote:

> Thanks Vald,
> The problem I'm facing with profile sharing is strange, when I make a call
> the whole flow freeze in that route with dialog profile operations i.e
> get/set. I can wait for as many as 15+ seconds and nothing happens. CANCEL
> the call and resend INVITE and it completes the route in normal way. Which
> is beyond my understanding as why each alternate call is able to process
> the route.
>
> Here is the core dump trace: https://pastebin.com/XqiaMWnV
>
> Best regards,
> Sammy
>
>
> On Tue, Jan 7, 2020 at 10:03 AM Vlad Patrascu  wrote:
>
>> Hi Sammy,
>>
>> The behavior you described when replicating profiles is not actually a
>> loop but instead the normal operation. Dialog profile counters are
>> periodically broadcasted by all nodes in the cluster to all other nodes.
>> Also, an update is also broadcasted when a counter decreases. As such there
>> indeed should not be any direct correlation between the number of SIP
>> invites and binary packets (containing profile counters) sent. But if the
>> SIP traffic contains BYEs or if you end dialogs you might see a surge of
>> binary packets.
>>
>> As for the crash, can you post a full backtrace from gdb?
>>
>> Regards,
>>
>> Vlad Patrascu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote:
>>
>> reposting
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>> OpenSIPS Summit, Amsterdam, May 2020
>>   https://www.opensips.org/events/Summit-2020Amsterdam/
>> OpenSIPS Bootcamp, Miami, March 2020
>>   https://opensips.org/training/OpenSIPS_Bootcamp_2020/
>>
>> On 1/6/20 4:21 AM, SamyGo wrote:
>>
>> Hi Bogdan,
>> Thanks for taking time out, here are the related config params.
>>
>> listen=bin:OPENSIPS_IP:6677
>>
>> ### dialog module for profiles/limits
>> loadmodule "dialog.so"
>> modparam("dialog", "db_mode", 0)
>> modparam("dialog", "profiles_with_value",
>> "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx
>> /b;countryPrefix/b")
>> modparam("dialog", "profile_replication_cluster", 1)
>> modparam("dialog", "replicate_profiles_timer", 3000)
>> modparam("dialog", "replicate_profiles_check", 10)
>>
>> ### Clustering Module
>> loadmodule "clusterer.so"
>> modparam("clusterer", "db_mode", 1)
>> modparam("clusterer", "my_node_id", 3)
>> modparam("clusterer", "sharing_tag", "gw1/1=active")
>> modparam("clusterer", "node_timeout", 20)
>> modparam("clusterer", "db_url","DB_MODULE://DB_USER:DB_PASS@DB_HOST
>> /DB_NAME")
>>
>> Routing logic:
>> https://pastebin.com/6whjkhCs
>>
>> Related Logs are here.
>> https://pastebin.com/a9a3iDQh
>>
>>  Wireshark graph showing storm of binary packets when SIP invite
>> initiates the related route.
>>
>> *BONUS CRASH: *When in a cluster I add a new profile_with_value , say
>> someVariable/b and restart the first box with this variable, the other
>> boxes in cluster crash by saying something along the lines of "unexpected
>> someVariable received"
>>
>> I'm trying to get hold of the core files and as soon as possible will
>> share that here.
>>
>>
>> Regards,.
>> Sammy.
>>
>>
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Freeswitch integration with Opensips

[John Tuxies]

I have opensips with cp. Users provisioned fine and users can call each
other. When i install freeswitch and try to integrate it with opensips then
i got no calls between the users. The registration of the users is done in
the opensips.
I could send the whole config files from both opensips and Freeswitch as
well if you would like.


John


On Tuesday, January 7, 2020, Bogdan-Andrei Iancu 
wrote:

> Hi John,
>
> It will be a good idea to bring the tutorial up2date, but not sure if
> Giovanni has the resources to do it.
>
> I'm not able to help with the FS part, but I can help with the OpenSIPS
> side - have you tried to migrate to 2.4 / 3.0 and faced some issues ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS Summit, Amsterdam, May 2020
>   https://www.opensips.org/events/Summit-2020Amsterdam/
> OpenSIPS Bootcamp, Miami, March 2020
>   https://opensips.org/training/OpenSIPS_Bootcamp_2020/
>
> On 1/7/20 2:08 PM, John Tuxies wrote:
>
> After many failed attempts to integrate Freeswitch with Opensips, i am
> asking for some help please.
> The guide i am trying to follow is quite old https://www.opensips.org/
> Documentation/Tutorials-OpenSIPSFreeSwitchIntegration but there is not
> any newer version.
> What i have done so far is to install Opensips (from deb repository) with
> Control Panel in a Debian system. I have created a domain (local IP) and a
> few users. Users registered to softphones and they can talk to each other.
> Then i installed Freeswitch (from deb repository) and altered the default
> ports from 506x to something 509x. Also i have changed the default 1234
> passwd for all extensions from Freeswitch.
> I am stuck in the rest of the config of Freeswitch and Opensips to
> integrate them.  Some help please?
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Freeswitch integration with Opensips

[Bogdan-Andrei Iancu]

Hi John,

It will be a good idea to bring the tutorial up2date, but not sure if 
Giovanni has the resources to do it.


I'm not able to help with the FS part, but I can help with the OpenSIPS 
side - have you tried to migrate to 2.4 / 3.0 and faced some issues ?


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
  https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
  https://opensips.org/training/OpenSIPS_Bootcamp_2020/

On 1/7/20 2:08 PM, John Tuxies wrote:
After many failed attempts to integrate Freeswitch with Opensips, i am 
asking for some help please.
The guide i am trying to follow is quite old 
https://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration 
but there is not any newer version.
What i have done so far is to install Opensips (from deb repository) 
with Control Panel in a Debian system. I have created a domain (local 
IP) and a few users. Users registered to softphones and they can talk 
to each other. Then i installed Freeswitch (from deb repository) and 
altered the default ports from 506x to something 509x. Also i have 
changed the default 1234 passwd for all extensions from Freeswitch.
I am stuck in the rest of the config of Freeswitch and Opensips to 
integrate them.  Some help please?



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


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

Re: [OpenSIPS-Users] Dialog profiles replication issues

[SamyGo]

Thanks Vald,
The problem I'm facing with profile sharing is strange, when I make a call
the whole flow freeze in that route with dialog profile operations i.e
get/set. I can wait for as many as 15+ seconds and nothing happens. CANCEL
the call and resend INVITE and it completes the route in normal way. Which
is beyond my understanding as why each alternate call is able to process
the route.

Here is the core dump trace: https://pastebin.com/XqiaMWnV

Best regards,
Sammy


On Tue, Jan 7, 2020 at 10:03 AM Vlad Patrascu  wrote:

> Hi Sammy,
>
> The behavior you described when replicating profiles is not actually a
> loop but instead the normal operation. Dialog profile counters are
> periodically broadcasted by all nodes in the cluster to all other nodes.
> Also, an update is also broadcasted when a counter decreases. As such there
> indeed should not be any direct correlation between the number of SIP
> invites and binary packets (containing profile counters) sent. But if the
> SIP traffic contains BYEs or if you end dialogs you might see a surge of
> binary packets.
>
> As for the crash, can you post a full backtrace from gdb?
>
> Regards,
>
> Vlad Patrascu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote:
>
> reposting
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS Summit, Amsterdam, May 2020
>   https://www.opensips.org/events/Summit-2020Amsterdam/
> OpenSIPS Bootcamp, Miami, March 2020
>   https://opensips.org/training/OpenSIPS_Bootcamp_2020/
>
> On 1/6/20 4:21 AM, SamyGo wrote:
>
> Hi Bogdan,
> Thanks for taking time out, here are the related config params.
>
> listen=bin:OPENSIPS_IP:6677
>
> ### dialog module for profiles/limits
> loadmodule "dialog.so"
> modparam("dialog", "db_mode", 0)
> modparam("dialog", "profiles_with_value",
> "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx
> /b;countryPrefix/b")
> modparam("dialog", "profile_replication_cluster", 1)
> modparam("dialog", "replicate_profiles_timer", 3000)
> modparam("dialog", "replicate_profiles_check", 10)
>
> ### Clustering Module
> loadmodule "clusterer.so"
> modparam("clusterer", "db_mode", 1)
> modparam("clusterer", "my_node_id", 3)
> modparam("clusterer", "sharing_tag", "gw1/1=active")
> modparam("clusterer", "node_timeout", 20)
> modparam("clusterer", "db_url","DB_MODULE://DB_USER:DB_PASS@DB_HOST
> /DB_NAME")
>
> Routing logic:
> https://pastebin.com/6whjkhCs
>
> Related Logs are here.
> https://pastebin.com/a9a3iDQh
>
>  Wireshark graph showing storm of binary packets when SIP invite initiates
> the related route.
>
> *BONUS CRASH: *When in a cluster I add a new profile_with_value , say
> someVariable/b and restart the first box with this variable, the other
> boxes in cluster crash by saying something along the lines of "unexpected
> someVariable received"
>
> I'm trying to get hold of the core files and as soon as possible will
> share that here.
>
>
> Regards,.
> Sammy.
>
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dialog profiles replication issues

[Vlad Patrascu]

Hi Sammy,

The behavior you described when replicating profiles is not actually a 
loop but instead the normal operation. Dialog profile counters are 
periodically broadcasted by all nodes in the cluster to all other nodes. 
Also, an update is also broadcasted when a counter decreases. As such 
there indeed should not be any direct correlation between the number of 
SIP invites and binary packets (containing profile counters) sent. But 
if the SIP traffic contains BYEs or if you end dialogs you might see a 
surge of binary packets.


As for the crash, can you post a full backtrace from gdb?

Regards,

Vlad Patrascu
OpenSIPS Developer
http://www.opensips-solutions.com

On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote:

reposting
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
   https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
   https://opensips.org/training/OpenSIPS_Bootcamp_2020/

On 1/6/20 4:21 AM, SamyGo wrote:

Hi Bogdan,
Thanks for taking time out, here are the related config params.

listen=bin:OPENSIPS_IP:6677

### dialog module for profiles/limits
loadmodule "dialog.so"
modparam("dialog", "db_mode", 0)
modparam("dialog", "profiles_with_value", 
"userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx

/b;countryPrefix/b")
modparam("dialog", "profile_replication_cluster", 1)
modparam("dialog", "replicate_profiles_timer", 3000)
modparam("dialog", "replicate_profiles_check", 10)

### Clustering Module
loadmodule "clusterer.so"
modparam("clusterer", "db_mode", 1)
modparam("clusterer", "my_node_id", 3)
modparam("clusterer", "sharing_tag", "gw1/1=active")
modparam("clusterer", "node_timeout", 20)
modparam("clusterer", 
"db_url","DB_MODULE://DB_USER:DB_PASS@DB_HOST/DB_NAME")


Routing logic:
https://pastebin.com/6whjkhCs

Related Logs are here.
https://pastebin.com/a9a3iDQh

 Wireshark graph showing storm of binary packets when SIP invite 
initiates the related route.


*BONUS CRASH: *When in a cluster I add a new profile_with_value , say 
someVariable/b and restart the first box with this variable, the 
other boxes in cluster crash by saying something along the lines of 
"unexpected someVariable received"


I'm trying to get hold of the core files and as soon as possible will 
share that here.



Regards,.
Sammy.





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

Re: [OpenSIPS-Users] INFO:db_mysql:switch_state_to_disconnected

[solarmon]

Hi Livui,

Thank you for your response.

I've checked wait_timeout and it is the default 28800 (8 hours).

Is this default not suitable?

Note that our SIP load balancers currently have little traffic going
through it, so is this default value not suitable? Should we be reducing
it? Or are these DB log message common/expected in this situation with
little traffic?

I'm still trying to correlate whether these database errors are related to
the dispatcher endpoints that are seemingly and randomly failing (when
using the opensipsctl dispatcher show or dump commands).

Thanks.

On Tue, 7 Jan 2020 at 11:55, Liviu Chircu  wrote:

> Hi solarmon,
>
> Please find an elaborate discussion on this topic here [1].  In short,
> MySQL's "wait_timeout" setting directly affects the number of such errors
> you are seeing in the logs, unless you are dealing with some other kind of
> a DB problem which causes new connections to be immediately dropped
> (e.g. deadlock, internal error, read-only state, etc.).
>
> Best regards,
>
> [1]: http://lists.opensips.org/pipermail/devel/2019-October/026171.html
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> OpenSIPS Summit, Amsterdam, May 2020
>   https://www.opensips.org/events/Summit-2020Amsterdam/
> OpenSIPS Bootcamp, Miami, March 2020
>   https://opensips.org/training/OpenSIPS_Bootcamp_2020/
>
> On 07.01.2020 13:45, solarmon wrote:
>
> Hi,
>
> I'm am still getting these database related messages on my opensips
> servers.
>
> /usr/local/sbin/opensips[29086]:
> INFO:db_mysql:switch_state_to_disconnected: disconnect event for
> 0x7fb482d108a8
> /usr/local/sbin/opensips[29086]: INFO:db_mysql:reset_all_statements:
> resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
> /usr/local/sbin/opensips[29086]: INFO:db_mysql:connect_with_retry:
> re-connected successful for 0x7fb482d108a8
>
> As per my last post on this subject, the database it is using is local to
> opensips - i.e. running on the same machine opensips. Thus, there should be
> no networking or routing or firewall that could be causing connectivity
> issues.
>
> Why is opensips generating such logs suggesting that it cannot connect to
> its local database? What could be causing this issue - opensips or the
> (MariaDB) database?
>
> Thank you.
>
> On Mon, 23 Dec 2019 at 14:49, solarmon  wrote:
>
>> Hi,
>>
>> Looking at the logs, these "INFO:db_mysql:switch_state_to_disconnected"
>> events do occur quite regularly.
>>
>> Also note that the database is local to the opensips node (part of a two
>> node cluster, with mariadb master/master syncing)).
>>
>> As per another post (that has not has a response) I'm using the
>> "opensipsctl dispatcher show" to monitor the endpoint status. I think this
>> is related as I've notice that the state shown by " "opensipsctl dispatcher
>> show"" and  "opensipsctl dispatcher dump" differ:
>>
>> When using "opensipsctl dispatcher show":
>>
>>
>> ++---++---+---++--+---+--+
>> | id | setid | destination| socket| state |
>> weight | priority | attrs | description  |
>>
>> ++---++---+---++--+---+--+
>> |  1 | 1 | sip:A.B.C.D:5060   | udp:W.X.Y.Z:5060 | 2 | 1  |
>>  0 |   | |
>>
>> When using "opensipsctl dispatcher dump":
>>
>> SET:: 1
>> URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0
>> socket:: udp:W.X.Y.Z:5060
>>
>> I might change my monitoring script to use  "opensipsctl dispatcher
>> dump", but it was easier for me to process the tabular format as it
>> contains the destination and state in the same line.
>>
>> Thanks.
>>
>> On Mon, 23 Dec 2019 at 14:37, Răzvan Crainea  wrote:
>>
>>> There are no errors - as the level indicates, there are some INFO
>>> messages indicating that a re-connection is done. Most likely the
>>> database connection was in a stale state, and the driver decided to
>>> reconnect. Nothing wrong about that.
>>>
>>> The reason for switching the endpoint in probing mode comes from the SIP
>>> signaling level - you should add more debugging in your script to
>>> understand this problem, or take a look at the signaling level.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 12/23/19 11:38 AM, solarmon wrote:
>>> > Hi,
>>> >
>>> > I'm investigating why there was a blip in the Dispatcher endpoint SIP
>>> > Options pings. The endpoint went in to "State=2 (Probing)" state and
>>> at
>>> > the same time the following was logged in opensips.log:
>>> >
>>> > /usr/local/sbin/opensips[29087]:
>>> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for
>>> > 0x7fb482d108a8
>>> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:reset_all_statements:
>>> > resetting all statements on 

Re: [OpenSIPS-Users] NAT for in-dialog requests

[Bogdan-Andrei Iancu]

Hi Callum,

I would say you are on the right tracks.

For detecting different NAT situation, there is no other way than to 
play with the flags of the `nat_uac_test()`.


For the in-dialog NAT handling, during the initial request you need to 
learn the NAT status of the parties involved (for the caller, based on 
the nat_uac_test(), for the callee, based on the data from lookup()).  
Once you learned the caller/callee 's NAT status, you should preserve 
this information across the whole dialog, so, when handling in-dialog 
requests, you already know the NAT status of each party.


And yes, when you receive traffic (requests or replies) for a party 
behind the NAT, you need to do the Contact fixing (and SDP if the case), 
in order to get rid of the private IPs.


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
  https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
  https://opensips.org/training/OpenSIPS_Bootcamp_2020/

On 12/13/19 2:12 PM, Callum Guy wrote:

Hi All,

I am operating a registrar which proxies calls to an internal network
of media servers.

Most of my subscribers are operating using RFC1918 addresses behind
NAT. We detect this configuration through nat_uac_test() and patch the
SIP using fix_nated_contact(). By rewriting the requests the media
servers will send in-dialog requests with request URI set to the NAT
address.

This works fine for the majority of my use cases however I am now
dealing with a UAC which has chosen to use public addresses on the
handsets but continues to run behind NAT. The effect here is that my
choice of flags for nat_uac_test() do not match the scenario and the
rewrites are not happening.

I can resolve this issue with some additional flags and logic however
I wonder if there is a "more correct" way to do this. In an ideal
world I would lookup the registration during INVITE processing, notice
that there is a different received address and use this for all future
communications for the rest of the dialog.

For example the initial requests out to these handsets are performing
a lookup() operation which will retrieve the original contact for use
as request URI and received address for use as destination URI
allowing the request to be properly formed and forwarded. The issue
arises when the dialog is started, the UAC responds to the well formed
INVITE with 200 OK and unless I patch the contact with the received IP
the subsequent ACK will end up routing back to the UAC contact rather
than the NAT device. What I am hoping is that there may be a correct
way for me to track the received IP against the dialog such that it
can be used in subsequent in-dialog requests, allowing the request URI
to correctly represent the UAC contact whilst still delivering
requests to the NAT address. I can probably achieve this by recording
the information using dialog variables however I imagine this is a
common scenario so I wouldn't want to add this logic in manually if
there was a proper way to do this natively in OpenSIPs.

Hopefully this isn't one of those questions that gets asked too
regularly however if it is please point me in the direction of an
article that might help, I've re-read the nathelper, nat_trasveral,
registrar and usrloc documentation today and haven't found what I'm
looking for. Any pointers would be appreciated before I embark on a
homegrown solution.

Thanks,

Callum




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

[OpenSIPS-Users] Freeswitch integration with Opensips

[John Tuxies]

 After many failed attempts to integrate Freeswitch with Opensips, i am
asking for some help please.
The guide i am trying to follow is quite old
https://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration
but there is not any newer version.
What i have done so far is to install Opensips (from deb repository) with
Control Panel in a Debian system. I have created a domain (local IP) and a
few users. Users registered to softphones and they can talk to each other.
Then i installed Freeswitch (from deb repository) and altered the default
ports from 506x to something 509x. Also i have changed the default 1234
passwd for all extensions from Freeswitch.
I am stuck in the rest of the config of Freeswitch and Opensips to
integrate them.  Some help please?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] INFO:db_mysql:switch_state_to_disconnected

[Liviu Chircu]

Hi solarmon,

Please find an elaborate discussion on this topic here [1]. In short,
MySQL's "wait_timeout" setting directly affects the number of such errors
you are seeing in the logs, unless you are dealing with some other kind of
a DB problem which causes new connections to be immediately dropped
(e.g. deadlock, internal error, read-only state, etc.).

Best regards,

[1]: http://lists.opensips.org/pipermail/devel/2019-October/026171.html

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

OpenSIPS Summit, Amsterdam, May 2020
  https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
  https://opensips.org/training/OpenSIPS_Bootcamp_2020/

On 07.01.2020 13:45, solarmon wrote:

Hi,

I'm am still getting these database related messages on my opensips 
servers.


/usr/local/sbin/opensips[29086]: 
INFO:db_mysql:switch_state_to_disconnected: disconnect event for 
0x7fb482d108a8
/usr/local/sbin/opensips[29086]: INFO:db_mysql:reset_all_statements: 
resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
/usr/local/sbin/opensips[29086]: INFO:db_mysql:connect_with_retry: 
re-connected successful for 0x7fb482d108a8


As per my last post on this subject, the database it is using is local 
to opensips - i.e. running on the same machine opensips. Thus, there 
should be no networking or routing or firewall that could be causing 
connectivity issues.


Why is opensips generating such logs suggesting that it cannot connect 
to its local database? What could be causing this issue - opensips or 
the (MariaDB) database?


Thank you.

On Mon, 23 Dec 2019 at 14:49, solarmon > wrote:


Hi,

Looking at the logs, these
"INFO:db_mysql:switch_state_to_disconnected" events do occur quite
regularly.

Also note that the database is local to the opensips node (part of
a two node cluster, with mariadb master/master syncing)).

As per another post (that has not has a response) I'm using the
"opensipsctl dispatcher show" to monitor the endpoint status. I
think this is related as I've notice that the state shown by "
"opensipsctl dispatcher show"" and "opensipsctl dispatcher dump"
differ:

When using "opensipsctl dispatcher show":


++---++---+---++--+---+--+
| id | setid | destination            | socket      | state |
weight | priority | attrs | description  |

++---++---+---++--+---+--+
|  1 |     1 | sip:A.B.C.D:5060   | udp:W.X.Y.Z:5060 |   2 | 1    
 |        0 |       | |

When using "opensipsctl dispatcher dump":

        SET:: 1
                URI:: sip:A.B.C.D:5060 state=Active
first_hit_counter=0
                        socket:: udp:W.X.Y.Z:5060

I might change my monitoring script to use "opensipsctl dispatcher
dump", but it was easier for me to process the tabular format as
it contains the destination and state in the same line.

Thanks.

On Mon, 23 Dec 2019 at 14:37, Răzvan Crainea mailto:raz...@opensips.org>> wrote:

There are no errors - as the level indicates, there are some INFO
messages indicating that a re-connection is done. Most likely the
database connection was in a stale state, and the driver
decided to
reconnect. Nothing wrong about that.

The reason for switching the endpoint in probing mode comes
from the SIP
signaling level - you should add more debugging in your script to
understand this problem, or take a look at the signaling level.

Best regards,

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

On 12/23/19 11:38 AM, solarmon wrote:
> Hi,
>
> I'm investigating why there was a blip in the Dispatcher
endpoint SIP
> Options pings. The endpoint went in to "State=2 (Probing)"
state and at
> the same time the following was logged in opensips.log:
>
> /usr/local/sbin/opensips[29087]:
> INFO:db_mysql:switch_state_to_disconnected: disconnect event
for
> 0x7fb482d108a8
> /usr/local/sbin/opensips[29087]:
INFO:db_mysql:reset_all_statements:
> resetting all statements on connection: (0x7fb482d11080)
0x7fb482d108a8
> /usr/local/sbin/opensips[29087]:
INFO:db_mysql:connect_with_retry:
> re-connected successful for 0x7fb482d108a8
> /usr/local/sbin/opensips[29077]:
> INFO:db_mysql:switch_state_to_disconnected: disconnect event
for
> 0x7fb482d108a8
> /usr/local/sbin/opensips[29077]:
INFO:db_mysql:reset_all_statements:
> resetting all statements on connection: (0x7fb482d11080)
0x7fb482d108a8

Re: [OpenSIPS-Users] INFO:db_mysql:switch_state_to_disconnected

[solarmon]

Hi,

I'm am still getting these database related messages on my opensips servers.

/usr/local/sbin/opensips[29086]:
INFO:db_mysql:switch_state_to_disconnected: disconnect event for
0x7fb482d108a8
/usr/local/sbin/opensips[29086]: INFO:db_mysql:reset_all_statements:
resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
/usr/local/sbin/opensips[29086]: INFO:db_mysql:connect_with_retry:
re-connected successful for 0x7fb482d108a8

As per my last post on this subject, the database it is using is local to
opensips - i.e. running on the same machine opensips. Thus, there should be
no networking or routing or firewall that could be causing connectivity
issues.

Why is opensips generating such logs suggesting that it cannot connect to
its local database? What could be causing this issue - opensips or the
(MariaDB) database?

Thank you.

On Mon, 23 Dec 2019 at 14:49, solarmon  wrote:

> Hi,
>
> Looking at the logs, these "INFO:db_mysql:switch_state_to_disconnected"
> events do occur quite regularly.
>
> Also note that the database is local to the opensips node (part of a two
> node cluster, with mariadb master/master syncing)).
>
> As per another post (that has not has a response) I'm using the
> "opensipsctl dispatcher show" to monitor the endpoint status. I think this
> is related as I've notice that the state shown by " "opensipsctl dispatcher
> show"" and  "opensipsctl dispatcher dump" differ:
>
> When using "opensipsctl dispatcher show":
>
>
> ++---++---+---++--+---+--+
> | id | setid | destination| socket| state |
> weight | priority | attrs | description  |
>
> ++---++---+---++--+---+--+
> |  1 | 1 | sip:A.B.C.D:5060   | udp:W.X.Y.Z:5060 | 2 | 1  |
>  0 |   | |
>
> When using "opensipsctl dispatcher dump":
>
> SET:: 1
> URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0
> socket:: udp:W.X.Y.Z:5060
>
> I might change my monitoring script to use  "opensipsctl dispatcher dump",
> but it was easier for me to process the tabular format as it contains the
> destination and state in the same line.
>
> Thanks.
>
> On Mon, 23 Dec 2019 at 14:37, Răzvan Crainea  wrote:
>
>> There are no errors - as the level indicates, there are some INFO
>> messages indicating that a re-connection is done. Most likely the
>> database connection was in a stale state, and the driver decided to
>> reconnect. Nothing wrong about that.
>>
>> The reason for switching the endpoint in probing mode comes from the SIP
>> signaling level - you should add more debugging in your script to
>> understand this problem, or take a look at the signaling level.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 12/23/19 11:38 AM, solarmon wrote:
>> > Hi,
>> >
>> > I'm investigating why there was a blip in the Dispatcher endpoint SIP
>> > Options pings. The endpoint went in to "State=2 (Probing)" state and at
>> > the same time the following was logged in opensips.log:
>> >
>> > /usr/local/sbin/opensips[29087]:
>> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for
>> > 0x7fb482d108a8
>> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:reset_all_statements:
>> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
>> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:connect_with_retry:
>> > re-connected successful for 0x7fb482d108a8
>> > /usr/local/sbin/opensips[29077]:
>> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for
>> > 0x7fb482d108a8
>> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:reset_all_statements:
>> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
>> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:connect_with_retry:
>> > re-connected successful for 0x7fb482d108a8
>> >
>> > Please can somebody advise what these error messages mean and how/what
>> > to investigate it further and resolve it.
>> >
>> > Thank you.
>> >
>> > ___
>> > Users mailing list
>> > Users@lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Question on route types and replies

[Bogdan-Andrei Iancu]

Hi Daren,

Yes, correct, all the onreply_route and failure_route are 100% stateful, 
provided by the tm module (transaction module). So, whenever you are in 
one of those routes, you should do (if permitted) only stateful 
signaling and not stateless, otherwise you will get unexpected behaviors 
from OpenSIPS and the TM engine is not aware of your stateless ops (from 
script).


In the stateful blocks, use t_reply() or send_reply() (which is actually 
a wrapper over t_relay() + sl_send_reply()). But going back to the 
failure of t_relay() - the function will automatically try to send back 
a stateful reply and it will report error to script only if even this 
replying failed - so makes no sense to try to send from script , again, 
a negative reply (the t_relay() already tried it and failed to do it).


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
  https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
  https://opensips.org/training/OpenSIPS_Bootcamp_2020/

On 1/7/20 1:27 AM, Daren FERREIRA wrote:

Hi Bogdan,

I have no idea on real changes between 2.3 and 3.0 but it seems that 
there is much more script sanity checks (and that’s great) that now 
blocks (erroneous) things that was not blocked before…
For example, that’s the reason why i had to replace sl_send_reply() by 
send_reply().

But in my case, i’m already in a failure_route.

failure_route[GW_FAILOVER]{
      route(CONTROLS);

      if (t_was_cancelled()) {
              exit;
      }
      do_accounting("db","failed");
      $acc_extra(identity)=$hdr(P-Asserted-Identity);
      $acc_extra(src)=$fU;
      $acc_extra(dst)=$tU;
      $acc_extra(src_ip) =$si; # source IP of the request

# failure detection with redirect to next available trunk
      if (t_check_status("(408)|([56][0-9][0-9])")) {
              xlog("L_INFO","Failed trunk $rd/$du detected \n");

              if ( ds_next_dst() ) {
t_on_branch("CLEANING");
                      t_on_failure("GW_FAILOVER");
                      route(RELAY);
#this block is not usable there
                      if (!t_relay()) {
sl_reply_error();
                      };
                      exit;
              }
              send_reply(500,"All GW are down");
      }
}
So do you think activating the failure_route inside the failure_route 
is enough to manage the eventual t_relay failures? (and by the way, is 
it safe to activate failure_routes inside failure_routes).


Reading your other posts (about 408 failover) makes me better 
understand the opensips internal (i think so).
If i well understand, a failure_route is forcibly stateful, so it is 
not logical to send stateless replies inside a stateful block.
On the opposite side i actually no idea how to send errors replies 
inside stateful blocks (maybe that’s internally managed - there is my 
limit).


I hope this is better now to understand my problem.

Thank you

Regards

Le 6 janv. 2020 à 18:41, Bogdan-Andrei Iancu > a écrit :


Hi Daren,

I do not remember to have any changes between 2.3 and 3.0 when comes 
to the sl_send_reply() usage - maybe you can be more explicit on the 
differences you see between the versions.


Now, one using handling the failure of `t_relay()` - if the function 
has some internal failure in sending out the request, it will 
automatically send back a negative reply and return success to 
script. The failure indication is returned to the script ONLY if the 
both sending the request AND the negative reply ops failed.
The sending of the negative reply is done in stateful mode, so this 
is the explanation of sl_reply_error() you see in examples - it will 
try to report back a reply in a stateless mode (in a lighter way, 
with a higher probability of success than the stateful attempt).
Why not doing this in failure route? as in failure route you are 
already in stateful mode, so there are almost 0 chances to get a 
failure indication from t_relay().


As a note, see the 0x02 flag for t_relay() - 
https://opensips.org/html/docs/modules/3.0.x/tm.html#func_t_relay


Best Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
https://opensips.org/training/OpenSIPS_Bootcamp_2020/

On 12/15/19 5:11 PM, Daren FERREIRA wrote:

Hello,

I’ve been using my configuration script for a while without problems 
on 2.3.x releases, but, with 3.0.x some errors are coming.
Syntax changes are not a problem, as fortunately changes are well 
documented on the wikis :)


My problem is relative to replies (sl_send_reply and sl_reply_error) 
and the places where we’re allowed to use them.
For sl_send_reply, send_reply alternative has solved my problem, but 
that’s not as easy for sl_reply_error.


In every documentation,