Re: [sr-dev] [kamailio/kamailio] usrloc keepalive does not work for TLS connections (Issue #3178)

UDP is not a valid transport for SIPS based on [RFC 3261](https://datatracker.ietf.org/doc/html/rfc3261#section-26.2.2) but it doesn't mean that it's TCP. and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since [RFC 2543](https://datatracker.ietf.org/doc/html/rfc2543). I think we have a few options to get the transport. We could get the transport by calling fix_nated_register() to set `received` but that seems silly to have to include the nathelper module. On my test, that's set to `sip:10.15.5.117:36557;transport=tls` (which also doesn't seem possible to have the scheme set to "sip" when the transport is TLS.). Probably doesn't work for other transports. This seems ugly. We could determine the transport based on the scheme and the tcpconn-id. - If scheme=sip and tcpconn_id is 0, then transport is UDP - If scheme=sip and tcpconn_id is not 0, then transport is TCP - If scheme=sips and tcpconn_id is not 0, then transport is TLS Won't work for SCTP. Not sure about WSS. We could store the transport on the ucontact struct. Probably the cleanest solution to have an explicit storage of the transport but some of the same problems might be pushed upstream to determine the correct transport to save in the first place. Any thoughts on a go forward direction? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3178#issuecomment-1183387544 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3178/1183387544(a)github.com>