Hi,
Is there any good solution for the scenario of an auth_challenge() with two separate transaction suspensions?
To clarify (simplified):
request_route {
...
t_newtran();
if(!is_present_hf("Authorization") && !is_present_hf("Proxy-Authorization")) {
auth_challenge("$fd", "1");
exit;
}
# TM suspend/continue
t_newtran();
async credentials query("RESUME_AUTH");
}
route[RESUME_AUTH] {
# Credentials received into PVs.
if(!pv_auth_check("...")) {
auth_challenge("$fd", "1");
exit;
}
# Create transaction shell if not exists already from auth query.
if(!t_lookup_request())
t_newtran();
# TM suspend/continue
async route query("RESUME_ROUTING");
}
route[RESUME_ROUTING] {
# Unmarshal etc.
t_relay(); # etc.
}
What happens here is that the first auth_challenge() results in a retransmission of its 407 challenge without absorbing the negative ACK. This is despite the ostensibly stateful behaviour of auth_challenge() without "force_stateless_reply" enabled.
In this case, it eclipses the second, unrelated 407 challenge from the subsequent routing query (407 challenge with +1 CSeq):

-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hi,
we have some Kamailios working as outboundproxy. So they get requests from internal systems and send them to different providers. From time to time, one provider returns a server as primary resource which is currently unavailable.
I guess if the internal systems connected directly to the target, they would remember the failed server and remember to always use the server with second priority at least until DNS refresh time. In our setup, since every request is "new" for Kamailio, it doesn't remember, which host is reachable or not.
Example:
target: example.com_sip._udp.example.com SRV resolves to:
10 192.0.2.42 5060
20 198.51.100.42 5060
30 203.0.113.42 5060
192.0.2.42 is unavailable. Still, Kamailio uses it for every new request and failover to 198.51.100.42 occurs only after timeouts hit.
Is there a best practice for solving this? I have played around with the dst_blocklist settings, but that caused even more trouble because Kamailio started blocking requests to peers that have only one server in the record having a short hickup.
Thanks in advance for every input, as this is causing trouble every time we run into such a situation.
Regards,
Sebastian
Hi,
I am exploring different redundancy / load-balancing models for a Kamailio cluster.
When I say cluster, I mean, a number (N) of Kamailio nodes acting as stateful proxies.
Each node is configured the same as the others, and all have access to the same lookup data to make routing decisions.
I would appreciate any advice or experience any of you can share on these different models.
Overall model:
Direct to proxies
Redirect servers first, which redirect to proxies
Selecting the first node to talk to. Each model could use either type of selection.
DNS-based (SRV or NAPTR, client makes call to dns name)
Anycast with ECMP (equal-cost multi-path routing)
Cluster with a mobile IP and service-down detection (this would just provide 1:1 protection)
Have clients make calls through the proxy using a DNS record containing an SRV record for each node (or, alternatively, done with NAPTR). Would rely on the client to switch nodes in the event of a node failure mid-call. (Is that even possible?)
Anycast would only work with UDP signaling. Use Anycast to find the first proxy, then use stateful responses to direct client back to same node for subsequent messages in a dialog.
So for anyone who has tried any of these methods, I would love to hear the pros and cons..
Thanks in advance!
Jawaid
Hello,
The documentation on using openssl_mutex_shared.so is contradicting.
https://github.com/kamailio/kamailio/blob/master/src/modules/tls/README#L293 says:
> For OpenSSL (libssl) v1.1.x, it is required to preload 'openssl_mutex_shared' library shipped by Kamailio. For more details see
'src/modules/tls/openssl_mutex_shared/README.md'.
https://github.com/kamailio/kamailio/blob/master/src/modules/tls/utils/open… says:
> IMPORTANT: the workaround of using this preloaded shared library is no longer needed starting with Kamailio v5.3.0-pre1 (git master branch after
September 14, 2019). The code of this shared library has been included in the core of Kamailio and the same behaviour is now achieved by default.
It is unclear, if openssl_mutex_shared.so must be preloaded.
In case the library is not needed anymore, it shall not be compiled and installed.
Kind regards
Дилян
Hello all,
I'm testing out release 5.6.2 on one production kamailio instance, and
today our monitoring system triggered an alarm for lack of disk space on /.
Indeed, kamailio.log started growing at an alarming rate at some point.
At about the same time disk space started being depleted, the following
line was frequently logged in the logs (no instances of it before that
time):
qm_malloc(): qm_malloc(0x7f5ade9c0010, 536) called from rtpengine:
bencode.c: __bencode_piece_new(79), module: rtpengine; Free fragment not
found!
They don't only concern rtpengine, core has produced similar "free fragment
not found" errors as well. There's additional multiple "had header field",
"bad header" and "invalid header name" errors appearing after that too, but
I'm guessing that's only a symptom of the qm_malloc issue?
kamailio is started with -m 2048 -M 16 and there's another instance with
almost identical traffic and configuration, but running on 5.6.1, which has
never exhibited such failures in several months uptime. So I'm wondering,
is there anything in 5.6.2 that could explain this? Thanks!
Best regards,
George
Hi all!
Got a random issue with NAT which I really have no clue how to solve.
Setup is as follows:
- Client A sends SIP INVITE through Public IP 1.2.3.4, where a Cisco
Firewall forwards NATed data to a Kamailio instance (acting as a SIPProxy
with dispatcher) listening with internal address 192.168.0.1 on port 5060.
RTPEngine is in the same server and address too.
- Kamailio will forward the invite to Asterisk NIC 1 (192.168.0.2) which
will do some provisioning and accounting stuff and redirect the call (if
authorized) to Client B's public IP address (all clients are outside the
network, reachable via WWW) using NIC 2 (192.168.1.2) and public address
4.3.2.1.
The issue is that from time to time, calls will not have audio.
Here is what I have found:
- when Client A sends INVITE, Asterisk NIC 1 will reply SIP 183 with SDP IP
Address set to the internal IP of NIC 1 (192.168.0.2)
- when Asterisk forwards call to Client B public IP address the SDP IP
address is 192.168.1.2 (NIC 2)
And I think the issue is the SDP address is wrong: when Asterisk forwards
call to Client B, the SDP address should be the public IP 4.3.2.1 but it
sends 192.168.1.2.
And when Asterisk replies to Kamailio the SDP is 192.168.0.1.
Correct me if I am wrong but i think the solution should be:
- when Kamailio receives a reply from Asterisk to be forwarded to Client A,
it should modify the SDP address to public IP 1.2.3.4
- when Asterisk forwards call to Client B, the sip.conf should have the
parameter externip set to the public IP 4.3.2.1
Questions:
- are my analysis & solution correct?
- is there an example of the above setup where I could get some ideas?
- how do I set Kamailio to modify the SDP address for me? Any examples?
Thanks in advance.
*Sérgio Charrua*
Hello,
not that tomorrow, Dec 14, 2022 starting after 09:00UTC (10:00Berlin),
is planned some maintenance work on kamailio.org server. It will be
unavailable from time to time, hopefully not for long time.
Affected services:
- web site
- mailing lists
- wiki site (alternative use the github repo:
https://github.com/kamailio/kamailio-wiki)
- html version of modules' documentation (text variant README is every
module folder of git clones or on github.org repository)
Short notifications will be sent when it starts and ends.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
I have the following basic script:
request_route{
record_route();
$var(enumres) = enum_query();
switch( $var(enumres) ) {
case -1:
xlog("enum_query lookup failure - To URI $tU");
sl_reply("503", "Temporary lookup failure");
return(0);
case 1:
break; # uri replaced
}
xlog("INVITE ENUM query - To URI $tU");
t_relay();
I have the following ENUM records for a test setup:
;; ANSWER SECTION:
x.x.x.1.5.1.8.3.0.3.1.e164.arpa. 60 IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:+13038151xxx@10.20.20.198!" .
x.x.x.1.5.1.8.3.0.3.1.e164.arpa. 60 IN NAPTR 110 10 "U" "E2U+sip" "!^.*$!sip:+13038151xxx@10.20.20.75!" .
What happens is the following:
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
17:57:19.961041 IP (tos 0x10, ttl 64, id 59648, offset 0, flags [none], proto UDP (17), length 1481)
10.20.20.40.5060 > 10.20.20.198.5060: SIP, length: 1453
INVITE sip:+13038151xxx@10.20.20.198 SIP/2.0
…
17:57:19.961058 IP (tos 0x10, ttl 64, id 24143, offset 0, flags [none], proto UDP (17), length 1480)
10.20.20.40.5060 > 10.20.20.75.5060: SIP, length: 1452
INVITE sip:+13038151xxx@10.20.20.75 SIP/2.0
…
These basically go out at the same time.
Eventually I get a ICMP Port Unreachable on the .198 one because that’s a dummy I just set up for testing.
My question is, with this kind of setup, is there a way to tell Kamailio to respect the NAPTR order value (note, 100, 110 above) and only try the 2nd route if the first fails?
Thanks,
Jawaid