No matter if UA uses ws or wss to connect to Kamailio, when K routes INVITE from this UA and record_route() is called, K always adds ;transport=ws parameter to Record-Route URI, for example,
Record-Route: sip:192.168.43.83:7998;transport=ws;r2=on;lr
In this test, Kamailio is listening on that port like this:
# SIP over WebSocket listen=tls:192.168.43.83:7998
Why doesn't K in this case add ;transport=wss to the R-R URI?
-- Juha
It may be related that also usrloc received uri has ;transport=ws:
sip:192.168.43.83:51176;transport=ws
instead of ;transport=wss.
-- Juha
For SIP URI the parameter value is always ws:
* https://tools.ietf.org/html/rfc7118#section-5.2
Cheers, Daniel
On 26.09.20 20:12, Juha Heinanen wrote:
It may be related that also usrloc received uri has ;transport=ws:
sip:192.168.43.83:51176;transport=ws
instead of ;transport=wss.
-- Juha
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
For SIP URI the parameter value is always ws:
Yes, according to that RFC, but does it make any sense, since how you tell based on usrloc received value if ws or wss was used for the registration?
-- Juha
On 27.09.20 15:43, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
For SIP URI the parameter value is always ws:
Yes, according to that RFC, but does it make any sense, since how you tell based on usrloc received value if ws or wss was used for the registration?
I never went to read all the specs and discover the rationale of having only transport=ws for URI, but I remember that initially the websocket code in Kamailio (iirc, was developed mainly by Peter Dunkley) was using wss, but then had to be updated to match the rfc.
I think that from standardisation point of view, the websocket can be only via tls/https, the version over tcp was more like for troubleshooting. On the other hand, the Via header can have WS and WSS (afaik from RFC). From the point of view of a server that only accepts websocket connection, never opens, practically it has to find an active connection that matches on remote peer ip and port, with websocket protocol flag set (it is impossible to have two matching the same, one over tcp and one over tls).
If nobody else here can add more, this aspect can be clarified by asking on sip-implementors mailing list or maybe ietf sipcore wg mailing list.
Cheers, Daniel
Daniel-Constantin Mierla writes:
If nobody else here can add more, this aspect can be clarified by asking on sip-implementors mailing list or maybe ietf sipcore wg mailing list.
Perhaps Inaki or Jose as authors of the RFC could comment. I agree that secure transport is the only one that makes sense unless testing.
-- Juha
-
Daniel-Constantin Mierla -
Juha Heinanen