[SR-Users] Confusion about TCP worker ports

[Daniel-Constantin Mierla]

Hello,

confirming what Henning said that dispatcher is not using uac module,
not to be any doubt about that. Actually, uac modules uses some of the
TM-UAC functions as dispatcher module, but between dispatcher and uac
module is no relation, no dependency. Sockets can be enforced in
dispatcher via socket attribute (I think is also a modparam for a global
need), however see next remarks about what can happen.

Besides that, I am writing to add on the original topic related to tcp
local ports. Tipically they have nothing to do with the listen port
(5060), the force socket for TCP is mainly a best-effort to use at least
the same network interface, but the OS/kernel may use a different one,
based on IP routing rules and priorities. The local ports are selected
from ephemeral ports range, searching the web should reveal more details
about, for example:

  *
https://superuser.com/questions/1118735/how-are-source-ports-determined-and-how-can-i-force-it-to-use-a-specific-port

On newer kernels there is an option to try to reuse ports even for tcp
(which was possible for UDP before, but not for TCP), kamailio has a
core parameter to enable it. See if enabling that gives what is wanted.
But if one thinks of firewall rules, for tcp it should allow based on IP
and eventually the ephemeral ports range of the source (which is hard to
figure out if it is not another fully managed system).

Olle added relevant details, adding a bit more: the port in Via header
is for "connect back here if the connection of the request is no longer
available", otherwise the connection is reused and Via address is more
for aesthetic purposes (e.g., think also about a device behind nat that
has via with private ip address, in such case is not possible to connect
back at all).

Cheers,
Daniel

On 30.10.20 09:05, Henning Westerholt wrote:
> Hi Alex,
>
> this is not correct. The dispatcher module uses the uac function from TM module for the generation and sending out of OPTIONS requests.
>
> So setting the mentioned function from the uac module will probably not help.
>
> Cheers,
>
> Henning
>
> -- 
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com 
>
> -----Original Message-----
> From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Alex Balashov
> Sent: Thursday, October 29, 2020 9:11 PM
> To: sr-users at lists.kamailio.org
> Subject: Re: [SR-Users] Confusion about TCP worker ports
>
> On 10/29/20 3:57 PM, Noah Mehl wrote:
>
>> Is there no way to send the requests from the listen port?
> The OPTIONS pinging dispatcher does internally is opaque, so I'm not sure.
>
> However, the source shows that dispatcher uses the UAC module for its internally generated OPTIONS pings, which is sensible:
>
> https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c#L3445
>
> If so, it stands to reason that loading 'uac' and setting this modparam may have some effect:
>
> https://kamailio.org/docs/modules/5.4.x/modules/uac.html#uac.p.default_socket
>
> I am not sure if it applies only to requests synthesised within the config script and sent using uac_req_send(), or to any requests constructed by the UAC module, though.
>
>> And if they’re not going to come from the listen port, can you please 
>> help me with the a way to update the message for the worker chosen 
>> rport?
> Try the above and see if it does anything.
>
> -- Alex
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla