[kamailio/kamailio] path: add_path_received() appends transport=ws instead of transport=wss (Issue #4168)
ChristianBergerSipgate created an issue (kamailio/kamailio#4168)
We think we have found a potential bug in the path module.
When we call `add_path_received()` we get the following for WSS connections:
`Path: sip:217.10.77.242;lr;received=sip:217.10.69.93:42612%3Btransport%3Dws`
We think there should be a `transport%3Dwss` appended instead of ws.
We have looked a bit into the code and think that this is caused by the following definition:
``` in modules/path/path.c
const static char *proto_strings[] = { [PROTO_TCP] = "%3Btransport%3Dtcp", [PROTO_TLS] = "%3Btransport%3Dtls", [PROTO_SCTP] = "%3Btransport%3Dsctp", [PROTO_WS] = "%3Btransport%3Dws", [PROTO_WSS] = "%3Btransport%3Dws", };
```
We think that on the last line, it should read ` [PROTO_WSS] = "%3Btransport%3Dwss",`
oej left a comment (kamailio/kamailio#4168)
RFC 7118 only specifies "ws" as a SIP URI parameter in section 5.2. The distinction for Via header transports says "WS/WSS". It kind of repeats the old mistake of using the "SIPS" uri to indicate a secure transport. I would recommend ignoring this as we do in the case of TLS transport for SIP: URI's and follow the suggestion in this issue.
henningw left a comment (kamailio/kamailio#4168)
Its not a bug in Kamailio, but more a specification issue. A similar approach is done also at other places inside Kamailio. In my opinion this should be not changed isolated inside the path module without considering the impact and also check other places where this might be used in Kamailio. The relevant RFC part:
[5.2](https://datatracker.ietf.org/doc/html/rfc7118#section-5.2). SIP URI Transport Parameter
This document defines the value "ws" as the transport parameter value for a SIP URI [[RFC3986](https://datatracker.ietf.org/doc/html/rfc3986)] to be contacted using the SIP WebSocket subprotocol as transport.
The updated augmented BNF for this parameter is the following (the original BNF for this parameter can be found in [[RFC3261](https://datatracker.ietf.org/doc/html/rfc3261)]):
transport-param =/ "transport=" "ws"
As Olle stated, we are already in violation of the (proposed) RFC 5630, for similar reasons.
To emphasize what is already defined in [[RFC3261](https://datatracker.ietf.org/doc/html/rfc3261)], proxies MUST NOT use the "transport=tls" parameter.
-
Christian Berger -
Henning Westerholt
-
Olle E. Johansson