Re: [OpenSIPS-Users] mid_register and its possible bad actions with De-REGISTER

2024-01-08 Thread Dmitry Ponomaryov 
Hello Liviu, In my case, AoR throttling was used, before issue (1), do 
you also think that this is how it should work? (looks like a CRITICAL) 
> On the other hand, AoR throttling goes beyond this and just makes 
sure there is always 1 AoR registered downstream. So on a "contact 
replace" operation, no SIP signaling should reach the Asterisk in that 
case. the point is that if different devices are registered under the 
same AoR, one such De-REGISTER, on the final Asterisk completely deletes 
the peer, although in some of the locations there is still data and if 
not for the De-REGISTER, Asterisk would have sent its INVITE, we would 
go through lookup and call all the devices we need from location via 
some route, this is the problem that we don’t always need De-REGISTER if 
there is more than one device under the same AoR(when we don't just 
reduce REGISTER to the main registrar, but use them as REGISTER from 
diff devices), which breaks peers on Asterisk with De-REGISTER.


but in total, it might be worth making such modparam module 
mid_registrar to disable De-REGISTER from the OpenSIPS itself, let the 
registrations themselves expire on the main registrar, and if there is a 
new registration with a new ctid with ct-throttling schema, then we will 
simply update peer again... or if someone needs this feature, then let 
it be possible to choose an interface and not just, for example: 
socket=1.1.1.1:5060 socket=2.2.2.2:5060 in this case De-REGISTER will go 
with 1.1.1.1:5060 on main registrar, because it is simply the first one 
listed socket in cfg. off course, your opinion is needed here, you are 
developer of this module since 2016 ;) Best regards!


(1): https://github.com/OpenSIPS/opensips/issues/3193



On 1/8/24 14:40, Liviu Chircu wrote:

On 27.12.2023 11:38, Dmitry Ponomaryov wrote:


All this to say, it might make sense to add the ability to disable 
this De-REGISTER, because with a new registration, we will still send 
it a registration with an updated contact before the main registrar 
times out, and there will be no problems, that is, for example, the 
following settings:


modparam("mid_registrar", "outgoing_expires", 600) 
modparam("mid_registrar", "default_expires", 300) 


Hello Dmitry,

From your scenario, it sounds like maybe you should enable AoR 
throttling, not just Ct throttling? Because in Ct throttling, each 
outgoing contact has a unique "ctid=" parameter, so it must be 
de-registered from the main registrar on each contact replace, since 
the replacement Contact has a new "ctid=", making it an entirely 
different SIP URI.


On the other hand, AoR throttling goes beyond this and just makes sure 
there is always 1 AoR registered downstream.  So on a "contact 
replace" operation,  no SIP signaling should reach the Asterisk in 
that case.


Best regards.


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

Re: [OpenSIPS-Users] uac_auth DB support

2024-01-08 Thread Schneur Rosenberg 
Thanks Liviu, BTW it's not Sebastian. it's Schneur AKA Scott :-)

On Mon, Jan 8, 2024 at 9:34 AM Liviu Chircu  wrote:
>
> On 06.12.2023 16:18, S.Rosenberg wrote:
>
>
> I would like to know if OpenSIPS has a way to pull the registrant info via 
> code without manually doing a DB query?
>
> Hi Sebastian,
>
> A bit late to the party here, but try giving the sql_cacher a spin.  It also 
> works on top of cachedb_local (or any other NoSQL, for that matter...), 
> however it will help you:
>
> - cut down on the amount of LoC in your script (just configure the cached 
> table properties in the "modparam" section and you're good to go)
>
> - solve the problem of reloading the data (you can configure it with 
> on_demand=300, for example, in order to cache a given row for a maximum of 5 
> minutes)
>
> Best regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
> OpenSIPS Summit 2024 Valencia, May 14-17 | www.opensips.org/events
>
> ___
> 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] uac_auth DB support

2024-01-08 Thread Liviu Chircu 

On 06.12.2023 16:18, S.Rosenberg wrote:


I would like to know if OpenSIPS has a way to pull the registrant info 
via code without manually doing a DB query?


Hi Sebastian,

A bit late to the party here, but try giving the sql_cacher 
 a spin.  It 
also works on top of cachedb_local (or any other NoSQL, for that 
matter...), however it will help you:


- cut down on the amount of LoC in your script (just configure the 
cached table properties in the "modparam" section and you're good to go)


- solve the problem of reloading the data (you can configure it with 
on_demand=300, for example, in order to cache a given row for a maximum 
of 5 minutes)


Best regards,

--
Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
OpenSIPS Summit 2024 Valencia, May 14-17 |www.opensips.org/events
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] replicate to HEP using the advertised address - OPENSIPS 3.3.9

2024-01-08 Thread James Seer 
Hi Liviu,

Thanks for the patch. However I can't apply it as my OpenSIPS is installed
as a binary package and not compiled from source.
I've also created an issue on GitHub to track this.
https://github.com/OpenSIPS/opensips/issues/3276

Le lun. 8 janv. 2024 à 11:13, Liviu Chircu  a écrit :

> On 26.12.2023 22:54, James Seer wrote:
>
> Aaaa the good old days before commit 4bd50335a (2023-12-12 by Vlad Paiu),
> life was simpler when my vip network interface and VIP itself were just one
> happy entity in HOMER's eyes :P
>
> This recent commit with its replication to HEP using the advertised
> address has complicated things in homer heplify by treating them as two
> different entities in the sip sequence (precisely during ACKs CANCEL and
> BYEs). Any chance we could make this an optional feature?
>
> Hi James,
>
> First of all, VIP issue aside, there seems to be a bug in that patch where
> the *sourceIP* and *sourcePort* are changed to *destinationIP *and
> *destinationPort* without a good reason (currently started a discussion
> with Vlad - we'll get to the bottom of it).  Maybe if this were tweaked,
> your SIP flows would return back to looking normal?!
>
> Nonetheless, if you have a 3.3 source tree to work with, try the following
> patch onto your root sources directory and see if the behavior improves by
> just fixing the bug instead of reverting the patch:
>
> git apply <(base64 -d <
> H4sIA91Ry26DMBA8w1fsqUoCJpCSZ9U0HxD11lMUWcYPZBUwsk3US/+9hiQNOQT13Is9
>
> Hs/ujsdMCgEI5dICmZaKNQU3U6sJ5fqyRRSyRze+rBj/goTN6ex5nq2iKF2ss3XGkiUkcbxIUx8h
>
> 9LizHwTBQPfdDtAsSVdhEkNwBY40llhJQVYWjKxxpx8Zqxt6JkqTw8QtIXRXWFZC4RraLeyqCp5j
>
> UZB87IP37YNbDbfYKPqJqSqasjIjYBk+kcIc0mP4i+c9vHBYaFW6eVkjROgjz3Mz0VbTU5S5YDBh
>
> THNj0Jaw07m58xgVvHq7mnW1rQgm46eB0sthc9MwY7GsQ4C/DhzQ1UrbzV3nlglvrWutrBq/+IHn
>
> 3RwYTTsHd8SDwuF8l71MVz28dtiqfrpD7x/2/a//pY33GloSHyMHIitL3jLwCi0cvX/s9530B7QY
> 9NXwAwAA
> EOF
> )
>
> Best regards,
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
> OpenSIPS Summit 2024 Valencia, May 14-17 | www.opensips.org/events
>
> ___
> 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] replicate to HEP using the advertised address - OPENSIPS 3.3.9

2024-01-08 Thread Liviu Chircu 

On 26.12.2023 22:54, James Seer wrote:
Aaaa the good old days before commit 4bd50335a (2023-12-12 by Vlad 
Paiu), life was simpler when my vip network interface and VIP itself 
were just one happy entity in HOMER's eyes :P


This recent commit with its replication to HEP using the advertised 
address has complicated things in homer heplify by treating them as 
two different entities in the sip sequence (precisely during ACKs 
CANCEL and BYEs). Any chance we could make this an optional feature?


Hi James,

First of all, VIP issue aside, there seems to be a bug in that patch 
where the /sourceIP/ and /sourcePort/ are changed to /destinationIP /and 
/destinationPort/ without a good reason (currently started a discussion 
with Vlad - we'll get to the bottom of it).  Maybe if this were tweaked, 
your SIP flows would return back to looking normal?!


Nonetheless, if you have a 3.3 source tree to work with, try the 
following patch onto your root sources directory and see if the behavior 
improves by just fixing the bug instead of reverting the patch:


git apply <(base64 -d <___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] mid_register and its possible bad actions with De-REGISTER

2024-01-08 Thread Liviu Chircu 

On 27.12.2023 11:38, Dmitry Ponomaryov wrote:


All this to say, it might make sense to add the ability to disable 
this De-REGISTER, because with a new registration, we will still send 
it a registration with an updated contact before the main registrar 
times out, and there will be no problems, that is, for example, the 
following settings:


modparam("mid_registrar", "outgoing_expires", 600) 
modparam("mid_registrar", "default_expires", 300) 


Hello Dmitry,

From your scenario, it sounds like maybe you should enable AoR 
throttling, not just Ct throttling? Because in Ct throttling, each 
outgoing contact has a unique "ctid=" parameter, so it must be 
de-registered from the main registrar on each contact replace, since the 
replacement Contact has a new "ctid=", making it an entirely different 
SIP URI.


On the other hand, AoR throttling goes beyond this and just makes sure 
there is always 1 AoR registered downstream.  So on a "contact replace" 
operation,  no SIP signaling should reach the Asterisk in that case.


Best regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit 2024 Valencia, May 14-17 | www.opensips.org/events


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