Hi,
When I modify INVITEs with set_contact_alias() / add_contact_alias(), this is not preserved in dialog data, and therefore not honoured in BYEs locally generated due to dialog timeout.
For example, if the initial INVITE contained:
Contact: sip:line1@192.168.1.100
and, after transit, became:
Contact: <sip:line1@192.168.1.100>;alias=1.1.1.1~25844~1
There is no ;alias value stored in the caller dialog data, just the original URI + parameters.
A related problem:
I tried to work around this by storing an alias in dialog user variables, e.g.
$dlg_var(alternate_ct) = $_s($si~$sp~$prid)
and in fact, I am able to recover this value later:
event_route[tm:local-request] {
if($dlg_var(alternate_ct) ne $null) {
$ru = $ru + ";alias=" + $dlg_var(alternate_ct);
handle_ruri_alias();
}
}
And in fact, if I print the value of $du after calling handle_ruri_alias(), I can see that it is modified. However, this seems to have no effect on where the request actually goes at the network and transport level. I assume this is because the event_route does not actually allow one to overwrite elements of the spoofed request, and that its essential attributes have been pre-populated elsewhere.
Nevertheless, the effect is that these BYEs do not reach NAT'd endpoints. Any suggestions are appreciated!
Thanks in advance,
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
The header style was wrong for ctl, fixed, thanks.
Daniel
On 15.05.23 18:55, Дилян Палаузов wrote:
> Off-list
>
> Hello,
>
> at
> https://github.com/kamailio/kamailio-wiki/blob/main/docs/features/new-in-5.… there
> is a horizonal line after ctl, which shall not be there.
>
> Greetings
> Дилян
>
>
> На 15 май 2023 г. 7:20:55 UTC, Daniel-Constantin Mierla
> <miconda(a)gmail.com> написа:
>
> Hello, with a few public holidays coming soon around here, I am
> considering to release 5.7.0 this week on Wednesday, May 17, 2023.
> Rather short notice, but there were no major bug reports that need
> to be tracked. The list of new features is being built in the
> wiki: -
> https://github.com/kamailio/kamailio-wiki/blob/main/docs/features/new-in-5.…
> The other tutorials related to this major release should be ready
> by then as well. Should anyone think more time is needed, then it
> can be postponed, not a problem at all. Cheers, Daniel
>
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Hello,
with a few public holidays coming soon around here, I am considering to
release 5.7.0 this week on Wednesday, May 17, 2023. Rather short notice,
but there were no major bug reports that need to be tracked.
The list of new features is being built in the wiki:
-
https://github.com/kamailio/kamailio-wiki/blob/main/docs/features/new-in-5.…
The other tutorials related to this major release should be ready by
then as well.
Should anyone think more time is needed, then it can be postponed, not a
problem at all.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Hello sr-users,
i use the guide for "how to integrate an IMS using Kamailio with open5gs EPC" from Supreeth Herle.
When my CotsUE(ONEPLUS8) try to Register. I get an 403 Forbidden HSS Authorization Rejected (see udp-stream.txt). The output of the fhoss looks like this.
de.fhg.fokus.hss.cx.CxFinalResultException: Diameter_Authorization_Rejected
at de.fhg.fokus.hss.cx.op.UAR.processRequest(UAR.java:134)
at de.fhg.fokus.hss.main.Task.execute(Task.java:169)
at de.fhg.fokus.hss.main.Worker.run(Worker.java:66)
Insufficient access rights for the mysql hss_db? The user hss@localhost and hss@% have grant access. Maybe someone has had the error and has a hint and can help. Can't find the error.
Many thanks in advance for an answer.
-M.Wilmes
Hi team
Is there any way to get correct CDRS when using the dialog module and
restarting kamailio?
I have configured the dialog timeout to be 12 hours.
But today while doing IC billing, we stumbled over a call that lasted
for a week. Probably due to a stale entry in the database dialogue
tables left over after a kamailio restart.
Looking at the logs there definitely was something wrong:
dialog [dlg_req_within.c:211]: bye_reply_cb(): inconsistent dlg timer
data on dlg 0x7f153f503778 [956:2612] with clid '35BEFD13@7f33ff47' and
tags '7f33ff47+1+75300082+dde85140' '3891401256-2097511021'
acc [acc_cdr.c:229]: db_write_cdr(): fallback to dlg_only search
because of message doesn't exist.
--
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
______________________________________________________
Hello!
After a major upgrade of Kamailio (5.1 -> 5.6), an error appears that it is
not possible to open configuration file (I think this is about
/etc/radiusclient/radiusclient.conf), although it exists with the necessary
access rights:
*0(27075) DEBUG: <core> [core/sr_module.c:969]: init_mod():
auth_radius0(27075) ERROR: auth_radius [auth_radius.c:123]: mod_init():
failed to open configuration file0(27075) ERROR: <core>
[core/sr_module.c:975]: init_mod(): Error while initializing module
auth_radius (/usr/lib64/kamailio/modules/auth_radius.so)ERROR: error while
initializing modules*
For the test, I made Kamailio downgrade back to 5.1 and the problem went
away.
Shortened the Kamailio config to the minimum for reproducing the problem:
*#!KAMAILIOmemdbg=5memlog=5children=1log_stderror=nolisten=udp:127.0.0.1:5060
<http://127.0.0.1:5060>loadmodule "kex.so"loadmodule "corex.so"loadmodule
"tm.so"loadmodule "sl.so"loadmodule "rr.so"loadmodule "pv.so"loadmodule
"maxfwd.so"loadmodule "auth.so"loadmodule
"auth_radius.so"modparam("auth_radius", "radius_config",
"/etc/radiusclient/radiusclient.conf")request_route { return;}*
Could the commit below somehow affect the acceptance of the radius_config
module parameter?
https://github.com/kamailio/kamailio/commit/f33ba318b20cbd2b34d278a7e2c4e64…
--
BR,
Denys Pozniak
Good morning.
I'm trying to get the number of registered contacts with kamcmd
ul.db_contacts.
The table has the default name 'location'.
But no matter what I try:
kamcmd ul.db_contacts location
kamcmd ul.db_contacts s:location
kamcmd ul.db_contacts database.location
kamcmd ul.db_contacts s:database.location
Kamcmd complains the table is not found. What would be the correct
syntax to provide the table name?
Attempted with Kamailio 5.5 and 5.6
--
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
______________________________________________________
The scenario is Kamailio on Debian 11 talking to an external application
server that returns a 302 with a Contact that contains Kamailio's own IP
and a different port. Kamailio is listening on the correct port via at the
given IP address. However, when Kamailio creates the packet to talk to
itself, it it send over the loopback adapter "lo" and gets an ICMP port
reply:
listen=udp:KAMAILIO_INTERNAL_FLOATING_IP:8888
10.z.a.b.5000 > 10.z.x.y.5060: SIP, length: 849
SIP/2.0 302 Moved Temporarily
Contact: <sip:44123456...@10.z.x.y:8888>
15:39:00.548722 lo In IP (tos 0x10, ttl 64, id 5431, offset 0, flags
[none], proto UDP (17), length 949)
10.z.x.y.5060 > 10.z.x.y.8888: SIP, length: 921
15:39:00.548732 lo In IP (tos 0xd0, ttl 64, id 19038, offset 0, flags
[none], proto ICMP (1), length 576)
10.z.x.y > 10.z.x.y: ICMP 10.44.7.136 udp port 8888 unreachable, length
556
Do I need to configure something in the OS or Kamailio to allow the
ethernet IP to work via the loopback adapter? I haven't set up any special
networking to cause this, it appears to be a Linux kernel behavior.
Hi I want to know where kamailio sends ack messages to faiurel messages
(status >=400) so that I I add Contact header to the ack.
I tried WITHINDLG with no luck.
thanks