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(a)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_s…
>>
>> Cheers
>>
>> On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users
<sr-users(a)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(a)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(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
sender!
> Edit mailing list options or unsubscribe: