Hi,
Does anyone know what this WARNING means or how to fix it?
2024-03-09T00:39:15.406674-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE
CALL-ID} [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0)
called from dialplan: dp_db.c: pcre2_free(206)
2024-03-09T00:39:15.406823-05:00 csbc03
I'm trying to add something simple like the following:
append_hf("X-testheader: True\r\n", "From");
However, I don't see my X-testheader in a packet capture. Are there
any common pitfalls that would prevent append_hf from working as
expected?
Try removing `ssl_sessionkey_udp_ip`, I don't have that set on mine.
Changing it to 127.0.0.1 might also work, but that's only a guess.
Keep in mind this part is open source, if you want to check it out:
https://github.com/voipmonitor/sniffer
Only the GUI is licensed, but isn't required if you
Yes, the problem was I had udp_mtu_try_proto set to TCP as a global
parameter, I have removed that and now it behaves.
I have, on the side, also disabled use_dns_failover because that
triggers also a special behavior in those tm functions I mentioned and
gave problems when using the
Hey Sergio,
thanks for the detailed explanation. If you like you could create a PR for this
topic against the module docs XML file.
Cheers,
Henning
From: Sergio Charrua via sr-users
Sent: Donnerstag, 7. März 2024 18:10
To: Kamailio (SER) - Users Mailing List
Cc: Sergio Charrua
Subject:
Hello,
check your config if the mtu-related parameters are set:
- https://www.kamailio.org/wikidocs/cookbooks/5.7.x/core/#udp_mtu
Be sure you grep all the files if the config is split in many.
There is also a function that could result in switching protocols:
-
Hi Henning,
yes as soon as I solve it I will try to give you a config and a sipp
script that shows you the issue. It seems its in the function
build_req_buf_from_sip_req (modules/tm/msg_translator.c) that if you
have a flag in the message that says FL_TCP_MTU_FB and your message is
larger
Hello,
this sound indeed strange, as this is used from many people without any
problems. Its not expected to use C programming to alter the message transport
for relaying.
If you can reproduce and minimize the problem towards a small test cfg and a
test message, it would be great if you could
thanks Alex. Sadly in my case the Request-URI does not contain a
transport parameter.
So the call to prepare_new_uac() function is deciding based on another
parameter (don't know which, was trying to avoid investigating that
because the function is a pain and not commented). I think its quite
