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

[abrezinsky]

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.

> Note that in the SIPS URI scheme, transport is independent of TLS,
and thus "sips:alice at atlanta.com;transport=tcp" and
"sips:alice at 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 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20220713/108f6889/attachment.htm>