[SR-Users] RPM Repos Maintenance Needed

[tyler moore via sr-users]

Hi All,

I started a discussion on the matrix channel about some 404 RPM repos 
and wanted to bring it here to further discuss.
We typically configure our various RPM-based package managers to allow 
patch updates from the repos.

As an example, if trying to install 5.7.x, can be done as follows:

yum -y install yum-utils
yum-config-manager --add-repo https://rpm.kamailio.org/centos/kamailio.repo
yum-config-manager --disable \*
yum-config-manager --enable kamailio-5.7
yum install kamailio

This will fail though because 
https://rpm.kamailio.org/centos/7/5.7/5.7/x86_64/ does not exist.
Throughout the repos for centos/rhel/fedora I found the existence of 
packages is inconsistent.
We can tell the intention was to allow the above behavior as the 
kamailio.repo comes with the above configuration.

The above example will update /etc/yum.repos.d/kamailio.repo as follows:

[kamailio-5.7]
name=Kamailio - 5.7 - Packages for the latest Kamailio 5.7 release
baseurl=https://rpm.kamailio.org/centos/$releasever/5.7/5.7/$basearch/
enabled=1
metadata_expire=30d
repo_gpgcheck=0
gpgkey=https://rpm.kamailio.org/rpm-pub.key
type=rpm
skip_if_unavailable=True

That is for centos though, and I found that some of the other distros 
have incomplete kamailio.repo files as well.
In example, the rhel kamailio.repo is missing separate entries for 5.7, 
but it does exist in the centos version.


Looks like some small cleanup is in order to make the end user 
experience more consistent.
I believe sergey was maintaining those repos last, please chime in here 
if you can.

If needed I can pick up some of those responsibilities as well.

Regards,

Tyler Moore
Full Stack Software Engineer
Flyball Labs
Office: 888-907-2085, ext: 34
Cell: 248-909-2769
Email: tmo...@goflyball.com

__
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: Registrar / Path

[Alex Balashov via sr-users]

In thinking through it a bit more, I think I understand better now. You want to 
interrogate -- that is, to query -- the location service via redirect rather 
than by sending a request directly to it, and you want the returned coordinates 
for the AOR being interrogated to incorporate the path hop so that the querying 
entity can send requests to it through that adjacency (RS) rather than directly 
to it. 

It might have been easier if you explicitly stated that. :-) 

Contact addresses in 3xx replies generated by Kamailio come from the 
destination set of the branches resolved via a lookup(). By default, the 
Request URI of an incoming request is set to the resolved Contact in the 
registrar, but if you set a destination next-hop ($du) equal to the Path hop, 
which should happen automatically if this[1] and other Path-related parameters 
are set to enabled, that's what should be returned in a 3xx constructed by 
Kamailio from the preloaded branches.

At least, that is how I understand it. So, in fact, Kamailio does accommodate 
this use-case in a canned way, it's just not very obvious.

-- Alex

[1] 
https://kamailio.org/docs/modules/5.7.x/modules/registrar.html#registrar.p.use_path

> On 27 Oct 2023, at 10:59, Alex Balashov  wrote:
> 
> Yes, the remove_hf() et al. functions are designed to operate on requests. 
> Only a small subset of textops-family manipulation functions operate on 
> replies, and they should be explicitly labelled or named in a way that 
> reflects that.
> 
> I can't say I understand the scenario you've outlined, either, but prima 
> facie, it seems bizarre. Why would you put the Path value into a 302 
> redirect? The Path value simply provides a next-hop in a trapezoid where the 
> registrar is reached indirectly through an intermediate proxy. 
> 
> It may be the case that you're doing something in a roundabout way that 
> routes around the simpler, "baked in" scenarios Kamailio is prepared to 
> handle... 
> 
> -- Alex
> 
>> On 27 Oct 2023, at 10:23, Jawaid Bazyar via sr-users 
>>  wrote:
>> 
>> Hi Henning, thanks for your reply.
>> I have successfully used PATH before as you describe.
>> This model, however, I am having Kamailio issue a 302 Redirect, and, I need 
>> to take the recorded PATH information and put it into the 302 Redirect 
>> Contact field, to send back with sl_send_reply. Sl_send_reply does not seem 
>> to do that automatically even after a lookup() and reg_fetch.
>> I was able to figure out the textops transforms and get the data into a 
>> Contact header, though I’m not 100% confident I’m creating a correct 
>> Contact, as sometimes the PATH can be quite complex and I’m taking only the 
>> host part and reconstructing a contact from that. I guess I will have to 
>> scour the RFC and do some learning 
>> I was hoping this particular scenario had been baked into Kamailio 
>> previously and I just needed to find the right configuration options to 
>> exercise it.
>>  On my second issue:
>> I am left however with an inability to remove the existing Contact from the 
>> reply. I tried remove_hf before sl_send_reply, but either it doesn’t remove 
>> the Contact field, or, sl_send_reply adds the Contact field.
>>   From: Henning Westerholt 
>> Date: Friday, October 27, 2023 at 10:10 AM
>> To: "Kamailio (SER) - Users Mailing List" 
>> Cc: Jawaid Bazyar 
>> Subject: RE: Registrar / Path
>> Hello,
>> I probably failed to understand your scenario completely.
>> But basically, if you want to just forward REGISTER message from one 
>> Kamailio to the other, you can use “forward()” or “r_relay()” for stateless 
>> respectively stateful forwarding.  The path extension was designed to take 
>> the same way routing e.g. an INVITE to an user agent as it came through your 
>> infrastructure. It will work automatically by setting the destination URI if 
>> it path is set and you are using the “lookup(..)” function.
>> Cheers,
>> Henning
>>  -- Henning Westerholt – https://skalatan.de/blog/
>> Kamailio services – https://gilawa.com
>>   From: Jawaid Bazyar via sr-users  
>> Sent: Mittwoch, 25. Oktober 2023 21:54
>> To: sr-users@lists.kamailio.org
>> Cc: Jawaid Bazyar 
>> Subject: [SR-Users] Registrar / Path
>> Hi,
>> I have a scenario where I have an edge proxy (named RS), which locally 
>> stores registrations from Endpoints in its USRLOC, but which then also 
>> forward's REGISTER requests on to another proxy (named CN), which stores 
>> registrations in its USRLOC. (which then does DMQ with another CN like it).
>> Both RS and CN are storing Path information, for example:
>> kamctl ul show displays on both RS and CN:
>>  "Path": "sip:vs-rs01.blah.foo.bar;lr;received=sip:3.4.5.6:33577",
>> So I know the path info is in there.
>> I want CN , when presented with an INVITE, to reply with a 302 Redirect.
>> Right now I have this:
>> if (!lookup("location",sip:$tU@nodomain)) {
>> }
>> reg_fetch_contacts("location", "$tu", "called");
>> xlog("location info $ulc(called=>path)");
>> 

[SR-Users] Re: Registrar / Path

[Alex Balashov via sr-users]

Yes, the remove_hf() et al. functions are designed to operate on requests. Only 
a small subset of textops-family manipulation functions operate on replies, and 
they should be explicitly labelled or named in a way that reflects that.

I can't say I understand the scenario you've outlined, either, but prima facie, 
it seems bizarre. Why would you put the Path value into a 302 redirect? The 
Path value simply provides a next-hop in a trapezoid where the registrar is 
reached indirectly through an intermediate proxy. 

It may be the case that you're doing something in a roundabout way that routes 
around the simpler, "baked in" scenarios Kamailio is prepared to handle... 

-- Alex

> On 27 Oct 2023, at 10:23, Jawaid Bazyar via sr-users 
>  wrote:
> 
> Hi Henning, thanks for your reply.
>  I have successfully used PATH before as you describe.
>  This model, however, I am having Kamailio issue a 302 Redirect, and, I need 
> to take the recorded PATH information and put it into the 302 Redirect 
> Contact field, to send back with sl_send_reply. Sl_send_reply does not seem 
> to do that automatically even after a lookup() and reg_fetch.
>  I was able to figure out the textops transforms and get the data into a 
> Contact header, though I’m not 100% confident I’m creating a correct Contact, 
> as sometimes the PATH can be quite complex and I’m taking only the host part 
> and reconstructing a contact from that. I guess I will have to scour the RFC 
> and do some learning 
>  I was hoping this particular scenario had been baked into Kamailio 
> previously and I just needed to find the right configuration options to 
> exercise it.
>   On my second issue:
>  I am left however with an inability to remove the existing Contact from the 
> reply. I tried remove_hf before sl_send_reply, but either it doesn’t remove 
> the Contact field, or, sl_send_reply adds the Contact field.
>From: Henning Westerholt 
> Date: Friday, October 27, 2023 at 10:10 AM
> To: "Kamailio (SER) - Users Mailing List" 
> Cc: Jawaid Bazyar 
> Subject: RE: Registrar / Path
>  Hello,
>  I probably failed to understand your scenario completely.
>  But basically, if you want to just forward REGISTER message from one 
> Kamailio to the other, you can use “forward()” or “r_relay()” for stateless 
> respectively stateful forwarding.  The path extension was designed to take 
> the same way routing e.g. an INVITE to an user agent as it came through your 
> infrastructure. It will work automatically by setting the destination URI if 
> it path is set and you are using the “lookup(..)” function.
>  Cheers,
>  Henning
>   -- Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com
>From: Jawaid Bazyar via sr-users  
> Sent: Mittwoch, 25. Oktober 2023 21:54
> To: sr-users@lists.kamailio.org
> Cc: Jawaid Bazyar 
> Subject: [SR-Users] Registrar / Path
>  Hi,
>  I have a scenario where I have an edge proxy (named RS), which locally 
> stores registrations from Endpoints in its USRLOC, but which then also 
> forward's REGISTER requests on to another proxy (named CN), which stores 
> registrations in its USRLOC. (which then does DMQ with another CN like it).
>  Both RS and CN are storing Path information, for example:
>  kamctl ul show displays on both RS and CN:
>   "Path": "sip:vs-rs01.blah.foo.bar;lr;received=sip:3.4.5.6:33577",
>  So I know the path info is in there.
>  I want CN , when presented with an INVITE, to reply with a 302 Redirect.
>  Right now I have this:
>  if (!lookup("location",sip:$tU@nodomain)) {
> }
> reg_fetch_contacts("location", "$tu", "called");
> xlog("location info $ulc(called=>path)");
> sl_send_reply("302","Redirect");
>  and the xlog does display the path. Good, so I have it being sent all the 
> way through RS and CN and into CN’s USRLOC.
>  but this isn’t complete.
>  I am now faced with two issues.
>  One, I need to mangle the Path into a Contact header for the Redirect.
> Two, I need to delete the Contact header that sl_send_reply is putting on 
> there, which is the Contact as RS sees it from the endpoint. This needs to be 
> removed and replaced with a Contact of only the RS server.
>  It feels like there ought to be a simpler way to do this than parsing the 
> Path string and reassembling a Contact from it, but if there is it's not 
> readily apparent. Both Google and chatgpt have failed me :)
>  Thanks in advance,
>  Jawaid
>  __
> 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:


-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions
To 

[SR-Users] Re: Registrar / Path

[Jawaid Bazyar via sr-users]

Hi Henning, thanks for your reply.

 

I have successfully used PATH before as you describe.

 

This model, however, I am having Kamailio issue a 302 Redirect, and, I need to 
take the recorded PATH information and put it into the 302 Redirect Contact 
field, to send back with sl_send_reply. Sl_send_reply does not seem to do that 
automatically even after a lookup() and reg_fetch.

 

I was able to figure out the textops transforms and get the data into a Contact 
header, though I’m not 100% confident I’m creating a correct Contact, as 
sometimes the PATH can be quite complex and I’m taking only the host part and 
reconstructing a contact from that. I guess I will have to scour the RFC and do 
some learning 

 

I was hoping this particular scenario had been baked into Kamailio previously 
and I just needed to find the right configuration options to exercise it.

 

 

On my second issue:

 

I am left however with an inability to remove the existing Contact from the 
reply. I tried remove_hf before sl_send_reply, but either it doesn’t remove the 
Contact field, or, sl_send_reply adds the Contact field.

 

 

 

From: Henning Westerholt 
Date: Friday, October 27, 2023 at 10:10 AM
To: "Kamailio (SER) - Users Mailing List" 
Cc: Jawaid Bazyar 
Subject: RE: Registrar / Path

 

Hello,

 

I probably failed to understand your scenario completely.

 

But basically, if you want to just forward REGISTER message from one Kamailio 
to the other, you can use “forward()” or “r_relay()” for stateless respectively 
stateful forwarding. 

 

The path extension was designed to take the same way routing e.g. an INVITE to 
an user agent as it came through your infrastructure. It will work 
automatically by setting the destination URI if it path is set and you are 
using the “lookup(..)” function.

 

Cheers,

 

Henning

 

 

-- 

Henning Westerholt – https://skalatan.de/blog/

Kamailio services – https://gilawa.com

 

 

 

From: Jawaid Bazyar via sr-users  
Sent: Mittwoch, 25. Oktober 2023 21:54
To: sr-users@lists.kamailio.org
Cc: Jawaid Bazyar 
Subject: [SR-Users] Registrar / Path

 

Hi,

 

I have a scenario where I have an edge proxy (named RS), which locally stores 
registrations from Endpoints in its USRLOC, but which then also forward's 
REGISTER requests on to another proxy (named CN), which stores registrations in 
its USRLOC. (which then does DMQ with another CN like it).

 

Both RS and CN are storing Path information, for example:

 

kamctl ul show displays on both RS and CN:

  "Path": "sip:vs-rs01.blah.foo.bar;lr;received=sip:3.4.5.6:33577",

 

So I know the path info is in there.

 

I want CN , when presented with an INVITE, to reply with a 302 Redirect.

 

Right now I have this:

 

if (!lookup("location",sip:$tU@nodomain)) {

}

reg_fetch_contacts("location", "$tu", "called");

xlog("location info $ulc(called=>path)");

sl_send_reply("302","Redirect");

 

and the xlog does display the path. Good, so I have it being sent all the way 
through RS and CN and into CN’s USRLOC.

 

but this isn’t complete.

 

I am now faced with two issues.

 

One, I need to mangle the Path into a Contact header for the Redirect.

Two, I need to delete the Contact header that sl_send_reply is putting on 
there, which is the Contact as RS sees it from the endpoint. This needs to be 
removed and replaced with a Contact of only the RS server.

 

It feels like there ought to be a simpler way to do this than parsing the Path 
string and reassembling a Contact from it, but if there is it's not readily 
apparent. Both Google and chatgpt have failed me :)

 

Thanks in advance,

 

Jawaid

 

 

 

 

 

__
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: Registrar / Path

[Henning Westerholt via sr-users]

Hello,

I probably failed to understand your scenario completely.

But basically, if you want to just forward REGISTER message from one Kamailio 
to the other, you can use “forward()” or “r_relay()” for stateless respectively 
stateful forwarding.

The path extension was designed to take the same way routing e.g. an INVITE to 
an user agent as it came through your infrastructure. It will work 
automatically by setting the destination URI if it path is set and you are 
using the “lookup(..)” function.

Cheers,

Henning


--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com



From: Jawaid Bazyar via sr-users 
Sent: Mittwoch, 25. Oktober 2023 21:54
To: sr-users@lists.kamailio.org
Cc: Jawaid Bazyar 
Subject: [SR-Users] Registrar / Path

Hi,

I have a scenario where I have an edge proxy (named RS), which locally stores 
registrations from Endpoints in its USRLOC, but which then also forward's 
REGISTER requests on to another proxy (named CN), which stores registrations in 
its USRLOC. (which then does DMQ with another CN like it).

Both RS and CN are storing Path information, for example:

kamctl ul show displays on both RS and CN:
  "Path": "sip:vs-rs01.blah.foo.bar;lr;received=sip:3.4.5.6:33577",

So I know the path info is in there.

I want CN , when presented with an INVITE, to reply with a 302 Redirect.

Right now I have this:

if (!lookup("location",sip:$tU@nodomain)) {
}
reg_fetch_contacts("location", "$tu", "called");
xlog("location info $ulc(called=>path)");
sl_send_reply("302","Redirect");

and the xlog does display the path. Good, so I have it being sent all the way 
through RS and CN and into CN’s USRLOC.

but this isn’t complete.

I am now faced with two issues.

One, I need to mangle the Path into a Contact header for the Redirect.
Two, I need to delete the Contact header that sl_send_reply is putting on 
there, which is the Contact as RS sees it from the endpoint. This needs to be 
removed and replaced with a Contact of only the RS server.

It feels like there ought to be a simpler way to do this than parsing the Path 
string and reassembling a Contact from it, but if there is it's not readily 
apparent. Both Google and chatgpt have failed me :)

Thanks in advance,

Jawaid





__
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] Kamailio 5.4.3 Troubleshooting Traffic Blocking Issue After Docker and OpenSSL Update

[Pintu Lohar via sr-users]

Hi All,

We have recently encountered a challenging issue in our environment that I
wanted to bring to your attention. A few months ago, we performed updates
to our Docker and OpenSSL installations, upgrading OpenSSL to version
1.1.1u. Since then, we have been experiencing intermittent traffic blocking
(TLS and UDP both for around 10 minutes and getting recovered) on some of
our instances.

Prior to the OpenSSL upgrade, we had not observed any such issues. However,
the situation has become more complex due to a substantial increase in
traffic, with each instance now handling 4K-5K concurrent calls and a daily
total of approximately 200,000 calls per instance.

Our initial suspicion was related to a Docker iptable issue. To investigate
further, we conducted a GDB trace using "kamctl pstrap" and discovered
specific log entries indicating potential issues within the
"pthread_rwlock_wrlock" function. This has prompted us to explore whether
the problems are linked to the OpenSSL upgrade.

We are considering upgrading Kamailio to the latest version, although this
process typically requires a significant amount of time for proper planning
and testing. Given the high volume of calls we are currently handling, we
are also exploring the possibility of a temporary solution involving a
rollback of the OpenSSL version to see if it resolves the issue.

Curiously, during a recent load test using SIPP, which simulated 10,000
concurrent calls with a rate of 100 calls per second, we did not encounter
the same problem.

any hints or insights you may have that could help us pinpoint the root
cause of the problem .

We do have a complete GDB trace available, but its size necessitates
sharing a truncated version for now.

version: kamailio 5.4.3 (x86_64/linux) 0178a5

flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES

ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB

poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.

id: 0178a5

compiled on 12:36:56 Oct 22 2023 with gcc 4.8.5

Operating System Host :
LSB Version: :core-4.1-amd64:core-4.1-noarch

Distributor ID: Rocky

Description: Rocky Linux release 8.8 (Green Obsidian)

Release: 8.8

Codename: GreenObsidian

container os (Centos7)

Kamctl pstraip output (truncated to last few lines)


---start 154 -

kamailio: No such file or directory.

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

0x7fbf6f38a0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6

$1 = 82

$2 = {pid = 154, unix_sock = 182, idx = 27, status = 1, rank = 48, desc =
"tcp receiver (tcp:xxx.xxx.xxx.xx:5060 )
child=27", '\000' }

#0  0x7fbf6f38a0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6

No symbol table info available.

#1  0x00684858 in io_wait_loop_epoll (h=0xb41720 , t=2,
repeat=0) at core/io_wait.h:1039

n = 84

r = 0

fm = 0x2

revents = 8201656

__FUNCTION__ = "io_wait_loop_epoll"

#2  0x00699e7a in tcp_receive_loop (unix_sock=186) at
core/tcp_read.c:1997

__FUNCTION__ = "tcp_receive_loop"

#3  0x005279e7 in tcp_init_children () at core/tcp_main.c:5134

r = 27

i = -1

reader_fd_1 = 186

pid = 0

si_desc = "tcp receiver (tcp:xxx.xx.xxx.xxx:5060

)\000\000\000\355\217c\000\000\000\000\000\240\213{\001\001\000\000\000\017\000\000\000\000\000\000\000\250\a2o\276\177\000\000\200\b\231o\000\000\000\000\260\006\346\261\376\177\000\000\230\210w\000\000\000\000\000=\000\000\000>\000\000\000\270\016z\350\274\177\000\000\060;8o\002\000\000\000P\224\346\352\001\000\000"

si = 0x0

__FUNCTION__ = "tcp_init_children"

#4  0x0042ae66 in main_loop () at main.c:1771

i = 16

pid = 94

si = 0x0

si_desc = "udp receiver child=15
sock=.xxx.xxx.xx:5060\000\000\000\v\235\200", '\000' ,
"P\r\346\261\376\177\000\000\270%}\000\000\000\000\000T\000\000\000\000\000\000\000\060;8o\277\177\000\000\343\207\201\000\000\000\000\000\277;8o\277\177\000\000
\271A\000\000\000\000\000@\374Ko\276\177\000"

nrprocs = 16

woneinit = 1

__FUNCTION__ = "main_loop"

#5  0x00433ad6 in main (argc=9, argv=0x7ffeb1e60e38) at main.c:2856

cfg_stream = 0x16c9010

c = -1

r = 0

tmp = 0x7ffeb1e61f0c ""

tmp_len = 2496

port = 2496

proto = 1472

ahost = 0x0

aport = 0

options = 0x7d5238
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"

ret = -1

seed =