Hello,
I migrated from Kamailio 3.0.3 to Kamailio 5.1.4. and have two questions
about the execution sequence of the Request_Route.
The following condition trys to authenticate the first INVITE or REGISTER
request which normally does not have the Authorization Header:
route (auth)
..
..
..
route[auth]{
if ( !proxy_authorize("myrealm", "subscriber") ) {
proxy_challenge("myrealm", "0");
sl_reply_error();
exit;
};
return;
}
For sure the Return Code of "proxy_authorize" will not be one (1) at the
beginneing, so the proxy_challenge() will generate the "407 Proxy
Authentication Required" request and the agent will send the INVITE or the
REGISTER again with the Authorization-Header and the call or the
registration attempt succeeds. During my observation to the new returned
codes (values) of both proxy_authorize() and proxy_challenge() in Kamailio
5.1.4, I noticed the following differnet execution sequence of this
"Request_Route".
at Kamailio 3.0.3, and exactly after the proxy_challenge("myrealm", "0")
command was executed, no more commands were excuted as if it jumped out of
the if statement, and the proxy was wating for the new INVITE or REGISTER.
Hence the sl_reply_error() did not send any error reply. I wrote several
logging commad before and after the proxy_challenge("myrealm", "0"), so I
am pretty sure that the proxy_challenge("myrealm", "0") is last excuted
command to be excuted here.
at Kamailio 5.1.4, the behaviour was more logical and the proxy executes
commands which come under the proxy_challenge("myrealm", "0") like logging
commands or sl_reply_error() which generates usually the error reply " 500
I'm terribly sorry, server error occurred".
My first question is: May somebody explain this different behavior?
My second Question: assume that the agent will send a wrong credentials and
response, does the proxy_challenge("myrealm", "0") function terminate this
dialouge with 401 Unauthorized Error or I must add the following "if
condition" afterwards:
if ( !proxy_authorize("myrealm", "subscriber") ) {
proxy_challenge("myrealm", "0");
if (!$rc){
sl_reply_error(); '#### or I will be more
specific sl_send_reply (code, reason)
}
exit;
};
Thanks and best regards
Abdulaziz Alghosh
We have a situation where we get a redirect from a carrier with a list of carriers to send the transaction to in the contact header. None of the carriers in the contact header have q values assigned.
We have implemented our redirect handling logic using the UAC_REDIRECT module (get_redirects()) with help from TM module (t-load_contacts(), t_next_contact()). (failure_route code is at bottom of this note)
We find that when we receive a contact header with q values, we can launch requests serially using t_next_contact() and individually work through the contact list until we get a positive response. When we get a redirect with no q values in the contact header we find that all contacts get loaded and launched in parallel.
Although not stated in the documentation, it appears that in order to implement serial contact redirect handling, q values must be present in the contact header. Based on this assumption, and knowing that the redirecting carrier cannot include q values, we have attempted to modify the contact header and find that we are unable to add q values to the contact header.
We have attempted without success to use remove_hf("Contact”) followed by append_hf("Contact: $(avp(contact)) \r\n”); where $(avp(contact)) is the avp where we have rewritten the contact header to include q values.
Any guidance on how to handle this issue is appreciated.
_________________________________________________________-
Our failure route code:
if (t_check_status("3[0-9][0-9]")) {
xlog("L_INFO", "----> REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n");
get_redirects("*:*");
if (!t_load_contacts()) {
xlog("L_INFO", "-t_load_contacts() FAILED /n");
};
xlog("L_INFO", "####->LOAD CONTACT LIST $xavp(tm_contacts[0]=>uri) \n");
if (t_next_contacts()) {
xlog("L_INFO", "-t_next_contact() loaded successfully /n");
xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n");
};
t_on_failure("serial");
if(t_relay()){
xlog("L_INFO","----->Relayed in MANAGE_FAILURE --- Method $rm --- Contact Header $ct \n");
};
exit;
} else {
xlog("L_INFO","-----> NO REDIRECT --- Method $rm --- Contact Header $ct \n");
exit;
}
failure_route["serial"] {
xlog ("L_INFO", "Entered failure_route(serial) /n");
if (t_check_status("3[0-9][0-9]")) {
xlog("L_INFO", "----> DOUBLE REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n");
$xavp(tm_contacts[*]) = $null;
xlog("L_INFO", "XXX-> tm_contacts reset to Null $xavp(tm_contacts[0]=>uri)\n");
get_redirects("*:*");
if (!t_load_contacts()) {
xlog("L_INFO", "-t_load_contacts() FAILED /n");
};
xlog("L_INFO", "####-> LOAD 2 CONTACT LIST $xavp(tm_contacts[0]=>uri) \n");
}
if (!t_next_contacts()) {
exit;
}
xlog("L_INFO", "-t_next_contact() loaded successfully /n");
xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n");
t_on_failure("serial");
if(t_relay()){
xlog("L_INFO","----->Relayed in failure_route(serial) --- Method $rm --- Contact Header $ct \n");
};
}
Best Regards,
Mike Montgomery
Principal, Trusted Technical Services, Inc.
o - 919 924 4703 x3000
m - 919 539 6133
I am trying to install Perl module on Ubuntu 18.04 / Kamailio kamailio-5.1.6 and getting the following response:
$ sudo apt-get install kamailio-perl-modules
Reading package lists... Done
Building dependency tree
Reading state information... Done
kamailio-perl-modules is already the newest version (5.1.2-1ubuntu2).
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
kamailio-perl-modules : Depends: kamailio (= 5.1.2-1ubuntu2) but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
Is there a better way to add perl module?
PS: libperl-dev already installed.
Thanks,
AL
Hi,
it seems that siptrace module doesn’t close db connections.
I’m on Kamailio 5.1.4 from official debian stretch repository with postgresql db module enabled.
siptrace config:
modparam("siptrace", "db_url", DBURL)
modparam("siptrace", "duplicate_uri", "sip:193.32.51.189:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "hep_version", 3)
modparam("siptrace", "hep_capture_id", 1001)
modparam("siptrace", "trace_mode", 1)
Here you can see the open connections from the kamailio host:
# select client_addr, state, query from pg_stat_activity where client_addr = '10.23.101.61';
client_addr | state | query
--------------+-------+----------------------------------------------------------------
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
10.23.101.61 | idle | select table_version from version where table_name='sip_trace'
(31 Zeilen)
another example, other installation with same kamailio version 5.1.4:
# select client_addr, state, query from pg_stat_activity where client_addr = '10.23.102.1';
client_addr | state | query
-------------+-------+----------------------------------------------------------------
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
10.23.102.1 | idle | select table_version from version where table_name='sip_trace'
(39 Zeilen)
Thanks Roman
Hi, I would like to know if it is possible to make the last register of a
user the active register and if possible the only one.
I'm with an Android application and sometimes I can not deregister properly
before the new registration, for example when the network changes, so there
are times when the hanging signals do not work correctly when there is more
than one register for a user.
Is it possible to avoid that there is more than one register for a user? Is
it possible to configure the last register to delete the previous ones or
to be a single register?
Thanks in advance and I await your answers.
--
José Antonio Gutiérrez Delgado
Responsable técnico
Oficina: (+34) 923040031
<http://www.arsoft-company.com/>
*Este mensaje se dirige exclusivamente a su destinatario/s y puede contener
información privilegiada o confidencial. Si no es vd. el destinatario
indicado, queda notificado de que la utilización, divulgación y/o copia sin
autorización está prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.*
*Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es
tarea de todos.*
Hello!
I was reading the documentation of Kamailio, And, although there are some
authentication modules, I couldn't find a way to implement a custom
authentication for SIP Register. Something that allows me, for example, to
call a web server and returns if the user is authenticated, or the user
data.
Am I missing anything? Do you know if it's possible to do this using
another way?
Thanks
João
hello dears,
i'm using kamailio 5.1 as IMS , and i have the following servers:
* p-cscf
* i-cscf-1 ,icscf-2
* s-cscf-1,scscf-2
i need to do high availability and load balancing between my servers , but i have some questions like do i have to use keepalived or dispatcher module and what the benefits of each one of them ,and on load balancing method should i do it for the register requests or only for invite requests or just for every thing ??
if any one has an idea or any thing to guide me i will be thankful
thanks in advance and regards
Hi all,
I am using Kamailio as a proxy in front of a 3rd part Open IMS (Not IMS
modules in kamailio).
I have defined Kamailio as an outbound proxy in Soft clients(I have
configured IMS users info in Soft Clients). When I send register from
client to IMS, Register message is sent to IMS over Kamailio. Kamailio
forwards this received Register to the 3rd party IMS. Finally the client is
registered into IMS over Kamailio. However when I try to make a call from
registered users (both registered over Kamailio), IMS sends 403 Forbidden -
"Not Registered! You must register first with a S-CSCF" to Kamailio.
When I debugged the issue I found the reason why IMS sends 403. When IMS
receives an Invite message from Kamailio it checks whether source IP which
Invite is sent registered or not. As I make registration over Kamailio
without changing contact header, IMS registers the user with the contact IP
(which is the client IP).
So to make a call from Soft client (IMS users) over Kamailio I also need to
register Kamailio source IP as well.To deal with the issue I have changed
the contact address of Register message coming from Soft client with
Kamailio IP on Kamailio. Then IMS registered Kamailio IP as a contact when
registering IMS user. But this time when I make a call from Soft client
over Kamailio, IMS sends Termination Invite to Kamailio. So to finalize the
call Kamailio has to route this termination Invite to the terminating IMS
user .
Is there any better approach to overcome this issue. Which is the better
approach to use Kamailio in front of IMS. I want to both register and make
a call from Soft clients over Kamailio to the IMS.
Regards,
Serkan CELIK
Hi!
The systemd kamailio.service file for debian (in my case, it's stretch) has
the following unit options set:
[Unit]
> Description=Kamailio (OpenSER) - the Open Source SIP Server
> After=network.target
It would be better to change this to:
[Unit]
> Description=Kamailio (OpenSER) - the Open Source SIP Server
> Wants=network-online.target
> After=network-online.target
Why? With network.target the service starts as soon as the network setup is
started, not explicitly after configuring (=IP) it [1].
This creates a race condition on very fast hardware like mine (booting
incl. all services takes 10s).
Even with static IPs, kamailio often fails directly at boot because eth1
(connection to DB cluster) is not up.
[I have never met this problem on systems which ran on HDDs.]
Setting "network-online.target" as Wants + After makes sure, Kamailio is
started after all interfaces are ready to serve.
Units that strictly require a configured network connection should pull in
> network-online.target (via a Wants= type dependency) and order themselves
> after it. This target unit is intended to pull in a service that delays
> further execution until the network is sufficiently set up. What precisely
> this requires is left to the implementation of the network managing service.
>
Perfect example for this is the Shorewall package (firewall solution):
[Unit]
> Description=Shorewall IPv4 firewall
> Wants=network-online.target
> After=network-online.target
> Conflicts=iptables.service firewalld.service
RFC
Kind regards
Kevin
[1] https://www.freedesktop.org/software/systemd/man/systemd.special.html
Hi
What does this error actually mean? I get it with 5.1.4
Nov 6 13:27:02 scantronpbx /usr/sbin/kamailio[2149]: ERROR: cfgutils
[cfgutils.c:708]: cfg_lock_helper(): lock set not initialized (attempt
to do op: 1 on: u1)
--
-------------------- Med Liberalistiske Hilsner ----------------------
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
