You can watch the workshop video on Youtube here.
All videos are available on Youtube.
Here I just want to write a few words that summarize the RFC 7118:
The WebSocket protocol enables message exchange between clients and servers on top of a persistent TCP connection
The connection is optionally secured with TLS
The WebSocket handshake is based on HTTP and uses the HTTP GET method with an Upgrade request → HTTP 101 response on success .
During the connection handshake, the client and server agree on the application-level protocol on top of Websocket transport (Websocket subprotocol) -In this document it is SIP
Each SIP message must be carried in a single WebSocket message and the WebSocket message contains only one SIP message → simplifies the SIP message parsing – no need for message boundaries (Content-Length header)
“ws” is used for plain websocket connections and “wss” for secure Websocket connections. These are for “via” transport parameter and SIP URI transport parameter
The SIP WebSocket server may decide not to add the parameter “received” in the top via header. The Client must accept the responses without this parameter
The SIP webSocket client is not manadated to implement support of UDP and TCP.
“SIP+D2W” DNS NAPTR service value for plain Websocket connections and “SIPS+D2W” for secure websocket connections.
The authentication can be on SIP level or Web level (token/cookie is used) – Appendix A
Using GRUU is valuable here (must be implemented on the client and server)
The Contact URI provided by SIP UAs is not used for routing requests to those UAs.
When SIP WebSocket server behaves as edge outbound proxy (Outbound + Path support), the proxy performs loose routing and remains in the path.