UDP is not a valid transport for SIPS based on RFC 3261 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.

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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.