[SR-Users] Re: Sharing load between rtpengine servers

[Ben Kaufman via sr-users]

>From a strictly linguistic point of view the sentence, "This is supported by 
>all rtpengine commands except rtpengine_manage()" is at the end of the second 
>paragraph, which is in reference to the second argument.  I would take it to 
>mean that the second argument is not supported by rtpengine_manage() - not 
>that the entire function is not supported.  Does that seem correct?


As reference the full section:

---
5.1.  set_rtpengine_set(setid[, setid])

Sets the ID of the RTP proxy set to be used for the next rtpengine_delete(), 
rtpengine_offer(), rtpengine_answer() or rtpengine_manage() command. The 
parameter can be an integer or a config variable holding an integer.

A second set ID can be specified to daisy-chain two RTP proxies. The two set 
IDs must be distinct from each other and there must not be any overlap in the 
proxies present in both sets. In this use case, the request (offer, answer, 
etc) is first sent to an RTP proxy from the first set, which rewrites the SDP 
body and sends it back to the module. The rewritten SDP body is then used to 
make another request to an RTP proxy from the second set, which rewrites the 
SDP body another time and sends it back to the module to be placed back into 
the SIP message. This is useful if you have a set of RTP proxies that the 
caller must use, and another distinct set of RTP proxies that the callee must 
use. This is supported by all rtpengine commands except rtpengine_manage().
---



From: Daniel-Constantin Mierla via sr-users 
Sent: Thursday, November 9, 2023 2:25 AM
To: Kamailio (SER) - Users Mailing List 
Cc: Daniel-Constantin Mierla 
Subject: [SR-Users] Re: Sharing load between rtpengine servers


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Hello,

not sure why that remark is there, because contradicts with the first paragraph 
that has:

"Sets the ID of the RTP proxy set to be used for the next rtpengine_delete(), 
rtpengine_offer(), rtpengine_answer() or rtpengine_manage() command."

  - 
https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.f.set_rtpengine_set

I don't think that the last statement is good, maybe it propagated without 
notice from a very old version. From code point of view, there is no reason for 
set_rtpengine_set() not to work for rtpengine_manage(), this function is a 
pretty simple wrapper for rtpengine_offer()/_answer()/_delete().

I am going to remove that last statement from docs.

Cheers,
Daniel

On 09.11.23 01:06, David Cunningham via sr-users wrote:
Hi Alex,

It's on the page that you linked to: "This is supported by all rtpengine 
commands except rtpengine_manage()."

Thanks.


On Thu, 9 Nov 2023 at 12:55, Alex Balashov 
mailto:abalas...@evaristesys.com>> wrote:
Hi David,

Whence the impression that sets aren't compatible with rtpengine_manage()?

https://kamailio.org/docs/modules/5.7.x/modules/rtpengine.html#rtpengine.f.set_rtpengine_set

   "Sets the ID of the RTP proxy set to be used for the next rtpengine_delete(),
rtpengine_offer(), rtpengine_answer() or rtpengine_manage() command. The 
parameter
can be an integer or a config variable holding an integer."

Or are you using an earlier version of Kamailio in which this may not have been 
true?

-- Alex

> On 8 Nov 2023, at 18:52, David Cunningham 
> mailto:dcunning...@voisonics.com>> wrote:
>
> Hi Alex,
>
> Thank you for the reply. We use a large weight of  to send almost all 
> calls to the 22.x and 33.x servers without using sets. We avoided sets 
> because our Kamailio configuration uses rtpengine_manage(), which according 
> to the documentation is not compatible with set_rtpengine_set(). I'll try it 
> without the 11.x server and the large weights, and see if the calls are 
> evenly distributed between the 22.x and 33.x servers then.
>
> Thanks again.
>
>
> On Thu, 9 Nov 2023 at 10:25, Alex Balashov via sr-users 
> mailto:sr-users@lists.kamailio.org>> wrote:
> Hi,
>
> From the docs:
>
> "The balancing inside a set is done automatically by the module based on the 
> weight of each RTPEngine from the set. The default weight is 1, if another 
> RTPEngine should be used twice as often as the first one, one would specify 
> the weight 2 for this server, for example."
>
> I am unsure as to what effect such large values as  might have on 
> this arithmetic.
>
> It seems to me that if what you really want to accomplish is to evenly 
> distribute calls between 22.22.22.22 and 33.33.33.33, with 11.11.11.11 only 
> as a last-resort backup, then you should put the first two into one naive set 
> without any weights, e.g.
>
>modparam("rtpengine_sock", "1 == 
> udp:22.22.22.22:7724 
> udp:33.33.33.33:7724")
>
> Then put 11.11.11.11 into a set of its own:
>
>modparam("rtpengine_sock", "2 == 
> 

[SR-Users] dlg_req_within kamailio 5.7 CSeq values

[Jonathan Hunter via sr-users]

Hi All,

I am playing around with the dlg_req_within to send  a REINVITE to toggle some 
rtpengine parameters and this works fine.

The first time I use the command after tracking the dialog, it sends a REINVITE 
with an incremented CSEQ value.

However when I issue it again, it sends another REINVITE but with the same CSEQ 
value, so again 2 for example.

How can you ensure its incremented or can you set it somehow?

As would like to generate at least 2 reinvites per dialog.

Many thanks

Jon

Sent from Mail for Windows


__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Info: qm and fm memory managers aligning addresses to 16 bytes

[Daniel-Constantin Mierla via sr-users]

Hello,

following the Kamailio Developers Meeting discussions and provided that
GNU/Linux malloc() aligns allocated memory to 16 bytes on x86_64 (64b
CPUs), I just updated the native Kamailio qm (quick malloc - the default
one) and fm (fast malloc) memory managers to also align to 16 bytes:

  -
https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html

By default they do it to 16 also for 32b CPUs, the overhead at startup
with default config was rather insignificant (like 5000 bytes for
private memory set to 8MB), so I didn't want to bother that much (that's
also because some 32b CPUs could require larger alignment that the size
of the pointer address), but for flexibility I added the an option to
set the alignment size at compile time with KSR_MEMORY_ALIGN define
(e.g., -DKSR_MEMORY_ALIGN=8UL).

The main benefit at this moment is that Kamailio should be able to use
the OS distribution (e.g., Debian) packaged libwolfssl instead of
bundling and building the library inside it to compile with custom
flags, like it is done now. Also, it is safe for the future to use other
libraries that leverage internally the OS memory alignment size for
specific optimizations.

I also increased the optimize factor to 15, which should speed up a bit
dealing with larger chunks of memory (now up to 32KB, previously was up
to 16KB). Considering that it is more and more common to deal with
larger SIP messages (e.g., a webrtc invite can easily be like 20KB) as
well as tls/encryption needs addition space that the unencrypted udp/tcp.

Hopefully these updates don't have side effects, it was nothing
consistent changed, a few defines and fields to match the new alignment
constraints. But testing is important, try to play with the master and
your configs whenever you have any chance.

Unfortunately the tlsf memory manager seems to be specifically designed
for aligning to 8 bytes, a rather old related issue in that project is
not concluded:

  - https://github.com/mattconte/tlsf/issues/16

That means the tls_wolfssl module linked with the officially packaged
libwolfssl has to be used with qm or fm malloc from now on. Or it has to
be built like so far to use tlsf memory manager. The tls/tlsa module can
still be used with tlsf memory manager.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Dispatcher list reloading itself from file?!?

[Benoît Panizzon via sr-users]

Hi List

I wanted to take one of our cores down gracefully by not destroy
running dialogues to be able to implement a config change on Kamailio
5.5

For this I did:

kamctl dispatcher.remove ID SIP-URI, for every IC

This worked fine, Kamailio is instructed to reply 503 on out of
dialogue traffic from unknown endpoints causing the endpoints to
re-route traffic to the other core, eventually making it possible to
stop and restart Kamailio without harm.

dialog count was steadily decreasing, until after about 10 minutes
after removing the dispatcher URI's it started to increase again.

kamctl dispatcher.list shows me, all dispatcher URI I removed are back!

There is no ds_reload() being executed by calls.

In the module description, I find no hint, that the dispatcher config
is being reloaded from file in some interval or so.

What could be the cause of my removed dispatcher suddenly being back?

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Development environment for the pre-commit hooks and clang-format

[Daniel-Constantin Mierla via sr-users]

Hello,

during the Kamailio Developers Meeting 2023 in Dusseldorf early this
week, Victor Seva shared how one can setup own development environment
for facilitating the automatic checks for clang-format and few other
useful bits (e.g., training white spaces) using pre-commit tool. So I
thought it would be useful to shared further to both developers and
users communities (as the later can make patches and pull requests as well).

If I forgot something, Victor should amend me, but the main steps are:

- install pre-commit package (either via apt or via pip3)
- install clang-format (debian/ubuntu should have it as a package)
- go to the folder with git clone of Kamailio source and run:

   pre-commit install

The above command can take some time, but it is needed only once.

After that, on evey commit, the checks should be performed a summary
should be presented on screen, like:

$ git commit src/
check yaml...(no files to
check)Skipped
check xml(no files to
check)Skipped
fix end of
files.Passed
trim trailing
whitespace.Passed
check for merge
conflictsPassed
mixed line
endingPassed
clang-format.Passed

If the check of clang-format results in "Failed", like:

clang-format.Failed

the pre-commit hooks will correct it, so you can just run again the
commit command and the 2nd time should be good to go.

If for whatsoever reasons pre-commit is installed but you need to
ignore/skip the pre-commit hooks, just provide -n or --no-verify to the
commit command, like:

$ git commit -n src/

By using pre-commit hooks, one could easily avoid making pull requests
that are failing to meet the code formatting checks on github portal as
well as ensure that as developer one does no forget to run clang-format
before commit.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Issue with Dialog Handling in Kamailio Post 2-Minute Duration

[Aaron Soto via sr-users]

I have checked it but everything seems to be ok, I have noticed that 
kamailio is calling on a random port on each call, do you know if this 
could mean a problem?

Thanks for your help.

El 9/11/23 a las 12:58, Yuriy G escribió:
Check your firewall. According the screenshot and your description - 
it seems it is not delivered to kamailio service. So very possible 
blocked by firewall.


On Thu, 9 Nov 2023, 12:53 Aaron Soto,  wrote:

I enabled CFGTRACE, but the logs don't show this BYE; the only BYE
that appears is after 5 minutes, which is sent by Asterisk to
Kamailio. It's confusing because it seems like Kamailio isn't
processing the BYE when i make a hangup with my phone.

El 9/11/23 a las 11:46, Yuriy G escribió:

Screenshot doesn't help more than raw BYE request would.
But mostly you need to look into kamailio service logs. Better
with CFGTRACE debugger parameter enabled. It will show you on
which step BYE handling was dropped. Also it may show you some
meaningful output regarding the reason it wss dropped.




--
Aaron Soto
Departamento de telefonía - DA PROYECYO MANHATTAN
Facebook icon  LinkedIn icon 
 Twitter icon 
 Youtube icon 
 Instagram icon 

Logo T: (+34) 96 344 1038
E: aaron.s...@dialapplet.com
W: www.dialapplet.com España
46022 Valencia
C/ Duque de Gaeta, 44

AVISO DE CONFIDENCIALIDAD
Le informamos, como destinatario de este mensaje, que el correo 
electrónico vía Internet no permite asegurar la confidencialidad de los 
mensajes transmitidos ni su integridad o correcta recepción. Si no 
consintiera la utilización del correo electrónico vía Internet, rogamos 
nos lo comunique de forma inmediata. Este mensaje va dirigido de manera 
exclusiva a su destinatario y puede contener información confidencial 
cuya divulgación está prohibida por la ley. Si ha recibido este mensaje 
por error, le rogamos nos lo comunique de forma inmediata por esta misma 
vía y proceda a su eliminación, así como a la de cualquier documento 
adjunto al mismo. Asímismo, si no es el destinatario del mensaje, se le 
informa de que su lectura, copia, distribución y utilización, así como 
la de cualquier documento adjunto, sea cual sea su finalidad, están 
prohibidas.

CONFIDENTIALITY WARNING
We hereby inform you, as addressee of this message, that Internet e-mail 
neither guarantees the confidentiality nor the completeness or proper 
receipt of the messages sent. If you do not consent to the use of 
Internet e-mail, please notify us immediately. This message is intended 
exclusively for its addressee and may contain confidential information 
protected from disclosure by law. If you have received this message in 
error, please immediately notify us via e-mail and delete it and any 
attachment. If you are not the addressee indicated in this message, 
please be informed that any reading, copy, distribution or use of it or 
its attachments, for any purpose, is forbidden.
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe: