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 dispatcher version of the solution (not with the t_relay_to_udp though)...
I am still wondering because my udp_mtu was configured to 1300 and the message is not larger than that, but I don't want to use more time understanding the tm module, although it would be helpful if someone did understand it eventually :D
Best regards
alberto
El 08/03/2024 a las 12:24, Daniel-Constantin Mierla escribió:
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:
- https://www.kamailio.org/wikidocs/cookbooks/5.7.x/core/#udp_mtu_try_protopro...
Cheers, Daniel
On 08.03.24 12:01, Alberto Diez via sr-users wrote:
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 than a given MTU for UDP that you can define in the core config it will change you to TCP even if you have used t_relay_to_udp so I am trying to find out why my message has that flag and what's the value of that MTU parameter etc.
I just explain it here so that in the future someone else has the problem kamilio all of a sudden deciding TCP when it should have been UDP, maybe its because of this flag, config parameter and crazy behavior (if I would have used t_relay maybe not so crazy but I used t_relay_to_udp explicitly... so quite crazy that instead of returning an error or something it tries TCP).
Best regards
alberto
El 08/03/2024 a las 11:38, Henning Westerholt escribió:
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 open an issue in our tracker.
Cheers,
Henning
-----Original Message----- From: Alberto Diez via sr-users sr-users@lists.kamailio.org Sent: Freitag, 8. März 2024 10:28 To: sr-users@lists.kamailio.org Cc: Alberto Diez alberto-lists@mobileplots.com Subject: [SR-Users] Re: from TCP to UDP and Kamailio doing it wrong
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 counter-intuitive, and for me a bug, that you call t_relay_to_udp and Kamailio tries to connect over TCP.... Same if its dispatcher module asking to dispatch to UDP and t_relay decides TCP (because it calls this same function at the end) etc.
By the way I also tried forcing the socket from the config file to be the UDP one, and nothing. Prior to calling prepare_new_uac the socket is the UDP one, but after calling that function it has changed the socket to a TCP one.
Would be great if anyone has a hint what could be going on and why prepare_new_uac changes the socket and based on what param
Best regards
alberto
El 07/03/2024 a las 21:44, Alex Balashov via sr-users escribió:
If you just strip the incoming ;transport=tcp attribute, I think all should be
well when t_relay() consumes the modified RURI.
On 7 Mar 2024, at 12:48, Alberto Diez via sr-users <sr-
users@lists.kamailio.org> wrote:
Hi Sergiu, yes I am pretty sure something is going wrong. I do have kamailio listening udp sockets and also the dispatcher is on UDP
doing SIP OPTIONS over UDP all the time without any problem.
I have not tried forcing the socket I tried to find out why kamailio is trying to
use TCP with the targets even when I use t_relay_to_udp and that's how I ended up finding that function which claims not to do something if next_hop is 0 but doing it nevertheless (which I guess is something going wrong in general in Kamailio not in particular in my setup).
I will try forcing the socket, but that crazy tm module function rewrites the socket was already given as a destination (yes I already checked that in the C code before!) Best regards alberto El 07/03/2024 a las 17:43, Sergiu Pojoga escribió: > You must be doing something essentially wrong if it came down to
checking C functions for something as trivial as transport conversion..
> Are you sure you have a UDP listening socket? > kamcmd corex.list_sockets > > Result of: > kamcmd dispatcher.list > > Have you tried forcing the send socket? > https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_f > orced_send_socket > > Cheers > > On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users <sr-
users@lists.kamailio.org> wrote:
> Hi kamailio community, > > I have an issue with a Kamailio 5.7. It's listening both in TCP and > UDP. In my scenario requests arrive from devices on TCP, but I want > to forward to the next hops on UDP. I am avoiding using any type of > DNS resolution; since I am always forwarding to predefined next hops > I am using the dispatcher module (defined with the IP addresses and > transport=udp) or I wrote config files using t_relay_to_udp or > t_relay_to with a udp: followed by IP address. I never set up FQDNS > only IP addresses and in all of them I explicitly mention UDP. > > In all of these scenarios I have tried Kamailio insists in trying to > use TCP with the next hop and failing because the next_hop is only > UDP. I guess because the message arrived using TCP Kamilio does that > but I find the behavior very confusing. > > I nailed down that in my situation its the tm module function > prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the > one that missbehaves. The documentation of the function says > literraly : > > "* t->uac[branch].request.dst will be filled if next_hop !=0 with > the result > * of the DNS resolution (next_hop, fproto and fsocket). > * If next_hop is 0 all the dst members except the send_flags > are read-
only
> * (send_flags it's updated) and are supposed to be pre-filled." > > I found out that even when next_hop is 0 the function changes the > t->uac[branch].request.dst proto, socket etc. its there that the > kamailio takes the wrong decision, until that function is called > within add_auc, the destination proto or the fproto etc is always 1 > (UDP) which is what I am trying to force from the config file or the > dispatcher definition (I tried both ways). But after calling that > function then it comes as a 2 (TCP) > > The problematic function is a monster of 500 lines and I would like > to avoid having to understand it. Since I think the scenario is not > so unusual I just want to ask if maybe I am missing something that I > should do to avoid the Kamailio to select TCP and in order to have > the tm module respecting my preference for UDP (either with > dispatcher module and the transport param or with t_relay_to or > t_relay_to_udp I don't care the way). > > Any hints are welcome. > > Best regards > > alberto > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions To > unsubscribe send an email to sr-users-leave@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply > only to the
sender!
> Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: