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_-_forced_se...
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: