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@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?