Hello Daniel,
Thanks for the reply.
The extra dictionary is already included otherwise an error is thrown and Kamailio doesn't start.
However, i realized my mistake now and you were right. I was checking for the extra attributes in a tcpdump and on radius server and i didn't had the dictionary configured on both of them. The extra attributes are in the packet but weren't being listed.
One more question. Kamailio doesn't have a way to do a totally custom RADIUS access-request packet right?
(Sorry if this opens another thread. I usually just hit reply on the mailing list and let Outlook create the e-mail, but it usually creates another thread and i'm not sure why).
Thanks again.
Cheers,
Duarte
Hello,
in RFC 3261 (sec. 8.1.1.6) it states about the Max-Forwards header field:
> A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70.
>
> Source: https://datatracker.ietf.org/doc/html/rfc3261#section-8.1.1.6
When Kamailio sends its OPTIONS keep-alive requests (from the nathelper
module I believe), Max-Forwards is missing:
> OPTIONS sip:alice@example.com:61266 SIP/2.0
> Via: SIP/2.0/UDP aa.bb.cc.dd:5060;branch=z9hG4bK5124450
> From: sip:pinger@sip.example.com;tag=uloc-6550aa14-7456-2461-6390f173-5fdb4667
> To: sip:alice@example.com:61266
> Call-ID: aba25282-2ca72be1-9d1fd53(a)aa.bb.cc.dd
> CSeq: 1 OPTIONS
> Content-Length: 0
The user agent library I'm using (libre from baresip) rejects these
requests with a "400 Bad Request" response, I looked at the sources and
it denies these requests because of the missing Max-Forwards header.
Of course this suffices for the keep-alive logic because all that's
needed is any traffic in both directions to keep both (potential) NATs
open. However you might agree that it does look a bit confusing at
first, and the RFC is clear about that.
So it's not a bug, but is this behavior intended?
Thanks, also thanks for all the great work that has been put into Kamailio.
Christian
Hello all,
I'm currently implementing a Kamailio with RADIUS.
I want to send an Access-Request to my RADIUS server and in order to do that i'm using misc_radius module and radius_does_uri_exist() function without any arguments :
"if (radius_does_uri_exist()) {"
For my module configuration I have the following configurations :
"modparam("misc_radius", "radius_config", "/etc/radcli/radiusclient.conf")
modparam("misc_radius", "uri_extra", "Sip-Method=$rm")"
From what i understand, with this config my access-request should contain the default attributes and Sip-Method Attribute but that is not happening. Only defaults attributes are included.
I've tried to run Kamailio with "-ddd" flag for better debug and i only get this error : "1(176) DEBUG: misc_radius [functions.c:615]: radius_does_uri_user_host_exist(): failure".
Is there any other configuration that i must do?
Thanks for the help.
Cheers,
Duarte
Hello,
we should consider an online devel meeting sometime soon to summarize
what was done at (and still needs to be done after) devel meeting in
Dusseldorf and plan a bit the targets for next major release (5.8 or 6.0)?
If considered useful, I propose Dec 5 at 14:30UTC (15:30
Berlin/Paris/Madrid/Rome), but we can also look for other dates as well.
Topics to be discussed can be added at:
-
https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings…
Pull requests can be made by users without git access.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello guys,
I have this setup where one side is TLS and the other UDP. Normally this
works fine, but we have this provider sending sips as the schema everywhere
(from, to, rr, contacts), kamailio sends the same sips to the upstream usp
freeswitch.
My problem is when FS sends back a 200OK and kamailio forwards it back to
the provider, the provider sends an ACK and kamailio can't match it with
the dialog and doesn't know where to forward it.
i think this is happening because FS when is sees SIPS is setting the
contact port as 5081 instead of the usual 5080...
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
Hello World!
Kamailio 5.5 in use.
I wonder, how I could prevent this issue.
modparam("dialog", "send_bye", 1)
modparam("dialog", "default_timeout", 21600)
in the corresponding route:
$dlg_ctx(timeout_route) = "DIALOG_TIMEOUT";
dlg_manage();
Dialog starts on Node01 and it's variables, status and timer are DMQ
synced to Node02
As both nodes have the same information, I guess both arm the timeout
trigger and sometimes the wrong node is more trigger friendly.
If dlg_ontimeout() is triggered on Node02 then:
* No Bye is send, as Node02 is not handling that Dialog.
* Dialog is removed from Memory on Node02 and state synced back to
Node01
* Dialog is removed from Memory on Node01 too, but NOT from database [*1]
* Dialog CDR is never commited on Node01
* Call is never sent to timeout_route
And subsequent in dialog messages on Node01 result in:
dlg_onroute(): unable to find dialog
Did I misconfigure something?
Is there a way to make sure the timer is NOT triggered on the node not
handling the dialogue?
Shall I try by setting the default_timeout and then use a timeout_avp
to set that timeout slightly lower AFTER the dialog has started? Or
would this be synced to the other node too?
I found out, session timer changes are not synced after an initial timer
was synced, so you can not extend the session timer after setting a
initial timeout. So maybe this is also true for dialog timeout?
[*1] this also explains why upon restarting kamailio, the dialog
suddenly is back and after timing out again, a CDR is then written with
a way too long duration.
--
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 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi
I'm trying to change the lifetime timer on a KDMQ dialog message before
handing it with dmq_handle_message();
if(has_body("application/json") && $fU == 'dialog')
{
if (jansson_get("lifetime", $rb, "$var(lifetime)"))
{
xlog("L_INFO", "$cfg(route): DIALOG JSON action: $var(action) state: $var(state) lifetime: $var(lifetime)\n");
$var(new_lifetime) = $var(lifetime) + 60;
$var(newrb) = $rb;
jansson_set("integer", "lifetime", $var(new_lifetime), "$var(newrb)");
xlog("L_INFO", "$cfg(route): DIALOG JSON NEW: $var(newrb)\n");
set_body("$var(newrb)","application/json");
msg_apply_changes();
}
}
dmq_handle_message();
exit;
The JSON string looks good after that manipulation, it contains the
updated lifetime.
But dmq_handle_message() does not seem to get the body anymore. So I
wonder what set_body() exactly does. Is it replacing the body or
appending to it?
Is there a way to crank up debug output in the dialog and/or dmq module?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hello,
Kamailio SIP Server v5.6.5 stable release is out.
This is a maintenance release of the latest stable branch, 5.6, that
includes fixes since the release of v5.6.4. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.6.x. Deployments running previous v5.6.x
versions are strongly recommended to be upgraded to v5.6.5.
Note that 5.6 is the second last stable branch, still officially
maintained by Kamailio development team. The latest stable branch is
5.7, with v5.7.3 being release out of it.
For more details about version 5.6.5 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2023/11/kamailio-v5-6-5-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
