[SR-Users] nating private uas to public ip addr

[Jack Murphy]

I have a multi-homed kam with a uas behind one private interface and a
public interface for the uac+sip provider.

When the uac initiates a call, kam sends the invite to the private uas
which sets up a b-leg call back to kam with a Contact header that has the
uas' private ip address.  I want to change that private ip address to be
Kamailio's advertised/public ip address before it gets forwarded to the sip
provider.

I am rewriting Contact in a route from request_route like this:
> if ($rP != $null) {
>   $var(ct) = ";transport=" + $rP;
> }else{
>   $var(ct) = "";
> }
> $var(cr) = "";
>
> remove_hf("Contact");
> append_hf("Contact: $var(cr)\r\n");

This seems to work fine for the INVITE going to the provider.

There's also the 200 OK that the uas sends for the uac (a-leg) with a
private ip address in Contact -- I want to rewrite that before sending it
to the UAC, too.

Using the same method as above (but inside onreply_route), what happens is
the UAC receives the modified OK and sends back an ACK with the modified
Contact (kam's public ip addr) in the ACK r-uri, and kam gets in a loop of
sending an ACK from its private ip address to its public ip address and
replying to itself.

call flows: https://imgur.com/a/Yj2DJpn

Is there a right way to do this?
__
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: Drops on async_route with delay

[Henning Westerholt]

Hi Alex,

It seems that a part of your e-mail is missing.

Anything unusual regarding the system load? Any errors in the kamailio logs?

Cheers,

Henning

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

-Original Message-
From: Alex Balashov  
Sent: Tuesday, January 31, 2023 3:20 PM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Drops on async_route with delay

Hi,

Some percentage of requests processed with async_route("REQ_PROCESS", "5") seem 
to end up with a resumed transaction, though most do. Not sure what the exact 
percentage is. The ones that don't 

Is this due to excessive requests? Is there a limit on internal IPC queue 
depth? Is it conceptually similar to a generic shared blocking queue 
internally, along the lines of 'mqueue'? Is there any reasonable way to 
troubleshoot this? 

Thanks!

-- Alex

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

__
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:
__
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: Sip messages responses counters per interface

[Henning Westerholt]

Hello,

have a look here for two options:

https://www.kamailio.org/docs/modules/5.6.x/modules/counters.html
https://www.kamailio.org/docs/modules/5.6.x/modules/statistics.html

Cheers,

Henning

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

From: Patrick Karton 
Sent: Tuesday, January 31, 2023 10:59 PM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Sip messages responses counters per interface

Hello i see that kamailio provides counters for sip requests 
(INVITE,BYE,ACK,CANCEL,...) and the corresponding responses via core.but this 
seems to be a sum  from all kamailio interfaces.

Is there a way or module to have those counters per kamailio interface ?


Thanks.
__
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: Depending on topoh.mask_key Kamailio cannot parse RURIs or modifies magically the SIP uri by changing some bytes in it (2)

[Henning Westerholt]

Hello,

regarding shared memory, Kamailio uses usually shared memory, regardless of how 
many workers are configured.

About compiling Kamailio without its internal memory pool, its possible. This 
was discussed last month in a thread about memory performance, if I remember 
correctly, on the list.

Cheers,

Henning

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

-Original Message-
From: Дилян Палаузов  
Sent: Wednesday, February 1, 2023 4:11 PM
To: Kamailio - Users Mailing List 
Subject: [SR-Users] Depending on topoh.mask_key Kamailio cannot parse RURIs or 
modifies magically the SIP uri by changing some bytes in it (2)

Hello,

does somebody has success, when using websockets and topoh?

If I run a single Kamailio process, I guess I do not need real shared memory.  
Can I adjust Kamailio somehow to use just malloc()/free() in this case, so that 
debugging is easier?


As it turned out dns_cache_init=off leads to crashes - 
https://github.com/kamailio/kamailio/issues/3350 .  With dns_cache_init=on and 
use_dns_cache=on, does not lead to reading invalid data.

Running Kamailio under valgrind:

When I do not set topoh.mask_key (so the default is used), for the yesterday 
mentioned workflow, for incoming packet:

18(19) ERROR:  [core/kemi.c:96]: sr_kemi_core_err(): ksr_sipdump_event 
1- sipdump:msg src 144.76.142.78:48294 dst 144.76.142.78:5060 ACK 
sip:127.3.4.84;line=sr-n6iazhainwp1g6s5orj136tdouwy3etacsf73ejxgwvqp9e7zhkucrp-
gbeewrfl36313.0e3j4amxpworeiw.y1wlpagevs3eabw.3lz6tdcrtlh.cwobffzgzfwx37m.jlibmlzxczibv*
 SIP/2.0
Route: 

Route: 

Via: SIP/2.0/WSS lvqj9uhih64a.invalid;branch=z9hG4bK962314
Max-Forwards: 70
To: ;tag=5Ml7bJz
From: "Online https://sip.bapha.be"; ;tag=kab7lqjdgi
Call-ID: i7jjtim7h775c6vqqudg
CSeq: 9846 ACK
Supported: outbound
User-Agent: SIP.js/0.7.8
Content-Length: 0


it logs:
18(19) ERROR: kemix [kemix_mod.c:229]: ki_kx_get_ruri_attr(): failed to parse 
the R-URI
18(19) ERROR: rr [loose.c:1011]: loose_route_mode(): failed to parse Request URI

With topoh.mask_key "TEAI32l)- eauiDEUIA!?()" (in practice without the quotes) 
the same happens.

With topoh.mask_key "TEAI32l" (in practive without the quotes) for the same 
workflow: the above message does not appear, but KSR.tm.t_relay() produces


for this input

8(19) ERROR:  [core/kemi.c:96]: sr_kemi_core_err(): ksr_sipdump_event 
1- sipdump:msg src 144.76.142.78:52284 dst 144.76.142.78:5060
ACK sip:127.3.4.84;
line=sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-
1fzlsdzo25n3koik1vhkwxptc5woeoc-159seo9* SIP/2.0
Route: 

Route: 

Via: SIP/2.0/WSS do52j57mf93b.invalid;branch=z9hG4bK1262183
Max-Forwards: 70
To: ;tag=~QBNVNr
From: "Online https://sip.bapha.be"; ;tag=rfucq55gg3
Call-ID: 0up52op7q7ilpa4mrq7e
CSeq: 3376 ACK
Supported: outbound
User-Agent: SIP.js/0.7.8
Content-Length: 0


18(19) ERROR:  [core/forward.c:508]: forward_request(): resolving 
"testnimecallubp.b" failed: unresolvable A or  request [-7]

In the above string there are some invisible bytes.  When I pass it over 
hexdump -C the output is:

  31 38 28 31 39 29 20 45  52 52 4f 52 3a 20 3c 63  |18(19) ERROR:  [core/forwa|
0020  72 64 2e 63 3a 35 30 38  5d 3a 20 66 6f 72 77 61  |rd.c:508]: forwa|
0030  72 64 5f 72 65 71 75 65  73 74 28 29 3a 20 72 65  |rd_request(): re|
0040  73 6f 6c 76 69 6e 67 20  22 74 65 73 74 18 83 6e  |solving "test..n|
0050  69 6d 65 18 63 61 6c 6c  75 1f 62 c1 70 c1 17 2e  |ime.callu.b.p...|
0060  62 c5 22 20 66 61 69 6c  65 64 3a 20 75 6e 72 65  |b." failed: unre|
0070  73 6f 6c 76 61 62 6c 65  20 41 20 6f 72 20 41 41  |solvable A or AA|
0080  41 41 20 72 65 71 75 65  73 74 20 5b 2d 37 5d 0d  |AA request [-7].|
0090  0a|.|
0091


As you can see the strings test-gnome-ca...@bapha.be and test..nime.callu.b.p 
are similar: many octets are identacal.  I have stopped and started Kamailio 
several times, the results do repeat.

These are my topoh parameters

#modparam("topoh", "mask_key", "TEAI32l)- eauiDEUIA!?()")   

#modparam("topoh", "mask_key", "TEAI32l")   

modparam("topoh", "mask_ip", "127.3.4.84")  
   
modparam("topoh", "sanity_checks", 1)   
   
modparam("topoh", "event_mode", 1)  
   


When I do not load topoh for the otherwise same configuration, I guess this is 
the corresponding ACK (avoiding topoh):

ACK 
sip:test-gnome-ca...@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50-740fb9bd

[SR-Users] Re: topos breaking route set on hairpin calls?

[Henning Westerholt]

Hello,

you've seems to have already found a workaround, as posted later.

Generally, topos should work for PRACK, there were several enhancements/fixes 
committed in the last year.

Cheers,

Henning

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

-Original Message-
From: Benoît Panizzon  
Sent: Thursday, February 2, 2023 8:51 AM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] topos breaking route set on hairpin calls?

Hi

Having this situation while elaborating topos in lab.

* Kamailio Registration Instance with topos enabled where customers are
  registered.

* Kamailio Core Instance with Dialogue enabled and handling
  interconnections.

Calls in transit from customer to IC work flawlessly, topos does what it 
should, hides and restores headers needed on the core.

But I have run into an issue with customer calling another customer on same 
registrar instance. To generate a CDR with diaglogue and for decision where to 
route the calls to (registrar is kept simple and only handles registrations and 
locations), those calls are also routed via core.

This works as long as PRACK is disabled.

When PRACK is enabled and CPE B is requesting 100rel, the PRACK send from CPE A 
has no route set (it was removed by topos). Therefore the PRACK only makes it 
to the core who then does not know where to route that PRACK.
It looks like topos on the REG only restores ONE Route pointing to the core 
(maybe because the 2nd one pointed to itself?) header when restoring them.

I have attempted to spam more record_route() here and there in the config of 
the core and the registrar to try to force creation of route headers, but 
failed.

Is this a known limitation of using topos?

--
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:
__
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: topos breaking route set on hairpin calls?

[Benoît Panizzon]

Hi

I might have figured out how to do it... I have to suppress topoligy
hiding when not talking to a CPE.

branch_route[BR_TO_CORE]
{
$var(droptopos) = 1;
}

event_route[topos:msg-outgoing] {
if ($var(droptopos) == 1) {
drop;
}
}

Trace looks promising, now getting full route set being passed on.

-- 
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] topos breaking route set on hairpin calls?

[Benoît Panizzon]

Hi

Having this situation while elaborating topos in lab.

* Kamailio Registration Instance with topos enabled where customers are
  registered.

* Kamailio Core Instance with Dialogue enabled and handling
  interconnections.

Calls in transit from customer to IC work flawlessly, topos does what
it should, hides and restores headers needed on the core.

But I have run into an issue with customer calling another customer on
same registrar instance. To generate a CDR with diaglogue and for
decision where to route the calls to (registrar is kept simple and only
handles registrations and locations), those calls are also routed via
core.

This works as long as PRACK is disabled.

When PRACK is enabled and CPE B is requesting 100rel, the PRACK send
from CPE A has no route set (it was removed by topos). Therefore the
PRACK only makes it to the core who then does not know where to route
that PRACK.
It looks like topos on the REG only restores ONE Route pointing to the
core (maybe because the 2nd one pointed to itself?) header when
restoring them.

I have attempted to spam more record_route() here and there in the
config of the core and the registrar to try to force creation of route
headers, but failed.

Is this a known limitation of using topos?

-- 
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: