idnits 2.17.1 draft-ietf-sipcore-sip-websocket-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 465 has weird spacing: '...otocols proxy...' == Line 559 has weird spacing: '... Trying proxy...' == Line 749 has weird spacing: '...er Name comp...' -- The document date (November 29, 2013) is 3801 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3261' is mentioned on line 776, but not defined == Missing Reference: 'RFC 4168' is mentioned on line 777, but not defined ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group I. Baz Castillo 3 Internet-Draft J. Millan Villegas 4 Intended status: Standards Track Versatica 5 Expires: June 2, 2014 V. Pascual 6 Quobis 7 November 29, 2013 9 The WebSocket Protocol as a Transport for the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-sip-websocket-10 13 Abstract 15 The WebSocket protocol enables two-way realtime communication between 16 clients and servers in web-based applications. This document 17 specifies a WebSocket sub-protocol as a reliable transport mechanism 18 between SIP (Session Initiation Protocol) entities to enable usage of 19 SIP in web-oriented deployments. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 2, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 3 59 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 60 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 6 63 5.1. Via Transport Parameter . . . . . . . . . . . . . . . . . 6 64 5.2. SIP URI Transport Parameter . . . . . . . . . . . . . . . 6 65 5.3. Via received Parameter . . . . . . . . . . . . . . . . . . 7 66 5.4. SIP Transport Implementation Requirements . . . . . . . . 7 67 5.5. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8 68 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8 69 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 11 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 75 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16 78 10.2. Registration of new NAPTR Service Field Values . . . . . . 16 79 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 17 80 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17 81 10.5. Header Field Parameters and Parameter Values 82 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17 83 10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 17 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 20 89 A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 20 90 A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 20 91 A.3. Cookie Based Authentication . . . . . . . . . . . . . . . 21 92 Appendix B. Implementation Guidelines . . . . . . . . . . . . . . 22 93 B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 23 94 B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 The WebSocket [RFC6455] protocol enables message exchange between 100 clients and servers on top of a persistent TCP connection (optionally 101 secured with TLS [RFC5246]). The initial protocol handshake makes 102 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 103 reuse existing HTTP infrastructure. 105 Modern web browsers include a WebSocket client stack complying with 106 the WebSocket API [WS-API] as specified by the W3C. It is expected 107 that other client applications (those running in personal computers 108 and devices such as smartphones) will also make a WebSocket client 109 stack available. The specification in this document enables usage of 110 SIP in these scenarios. 112 This specification defines a WebSocket sub-protocol (as defined in 113 section 1.9 in [RFC6455]) for transporting SIP messages between a 114 WebSocket client and server, a reliable and message-boundary 115 preserving transport for SIP, DNS NAPTR [RFC3403] service values and 116 procedures for SIP entities implementing the WebSocket transport. 117 Media transport is out of the scope of this document. 119 Section 3 in this specification relaxes the requirement in [RFC3261] 120 by which the SIP server transport MUST add a "received" parameter in 121 the top Via header in certain circumstances. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2.1. Definitions 131 SIP WebSocket Client: A SIP entity capable of opening outbound 132 connections to WebSocket servers and communicating using the 133 WebSocket SIP sub-protocol as defined by this document. 135 SIP WebSocket Server: A SIP entity capable of listening for inbound 136 connections from WebSocket clients and communicating using the 137 WebSocket SIP sub-protocol as defined by this document. 139 3. The WebSocket Protocol 141 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 142 (optionally secured with TLS [RFC5246]) in which both client and 143 server exchange message units in both directions. The protocol 144 defines a connection handshake, WebSocket sub-protocol and extensions 145 negotiation, a frame format for sending application and control data, 146 a masking mechanism, and status codes for indicating disconnection 147 causes. 149 The WebSocket connection handshake is based on HTTP [RFC2616] and 150 utilizes the HTTP GET method with an "Upgrade" request. This is sent 151 by the client and then answered by the server (if the negotiation 152 succeeded) with an HTTP 101 status code. Once the handshake is 153 completed the connection upgrades from HTTP to the WebSocket 154 protocol. This handshake procedure is designed to reuse the existing 155 HTTP infrastructure. During the connection handshake, client and 156 server agree on the application protocol to use on top of the 157 WebSocket transport. Such application protocol (also known as a 158 "WebSocket sub-protocol") defines the format and semantics of the 159 messages exchanged by the endpoints. This could be a custom protocol 160 or a standardized one (as the WebSocket SIP sub-protocol defined in 161 this document). Once the HTTP 101 response is processed both client 162 and server reuse the underlying TCP connection for sending WebSocket 163 messages and control frames to each other. Unlike plain HTTP, this 164 connection is persistent and can be used for multiple message 165 exchanges. 167 WebSocket defines message units to be used by applications for the 168 exchange of data, so it provides a message boundary-preserving 169 transport layer. These message units can contain either UTF-8 text 170 or binary data, and can be split into multiple WebSocket text/binary 171 transport frames as needed by the WebSocket stack. 173 The WebSocket API [WS-API] for web browsers only defines callbacks 174 to be invoked upon receipt of an entire message unit, regardless 175 of whether it was received in a single Websocket frame or split 176 across multiple frames. 178 4. The WebSocket SIP Sub-Protocol 180 The term WebSocket sub-protocol refers to an application-level 181 protocol layered on top of a WebSocket connection. This document 182 specifies the WebSocket SIP sub-protocol for carrying SIP requests 183 and responses through a WebSocket connection. 185 4.1. Handshake 187 The SIP WebSocket Client and SIP WebSocket Server negotiate usage of 188 the WebSocket SIP sub-protocol during the WebSocket handshake 189 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 190 include the value "sip" in the Sec-WebSocket-Protocol header in its 191 handshake request. The 101 reply from the Server MUST contain "sip" 192 in its corresponding Sec-WebSocket-Protocol header. 194 The WebSocket Client initiates a WebSocket connection when 195 attempting to send a SIP request (unless there is an already 196 established WebSocket connection for sending the SIP request). In 197 case there is no HTTP 101 response during the WebSocket handshake 198 it is considered a transaction error as per [RFC3261] section 199 8.1.3.1 "Transaction Layer Errors". 201 Below is an example of a WebSocket handshake in which the Client 202 requests the WebSocket SIP sub-protocol support from the Server: 204 GET / HTTP/1.1 205 Host: sip-ws.example.com 206 Upgrade: websocket 207 Connection: Upgrade 208 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 209 Origin: http://www.example.com 210 Sec-WebSocket-Protocol: sip 211 Sec-WebSocket-Version: 13 213 The handshake response from the Server accepting the WebSocket SIP 214 sub-protocol would look as follows: 216 HTTP/1.1 101 Switching Protocols 217 Upgrade: websocket 218 Connection: Upgrade 219 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 220 Sec-WebSocket-Protocol: sip 222 Once the negotiation has been completed, the WebSocket connection is 223 established and can be used for the transport of SIP requests and 224 responses. Messages other than SIP requests and responses MUST NOT 225 be transmitted over this connection. 227 4.2. SIP Encoding 229 WebSocket messages can be transported in either UTF-8 text frames or 230 binary frames. SIP [RFC3261] allows both text and binary bodies in 231 SIP requests and responses. Therefore SIP WebSocket Clients and SIP 232 WebSocket Servers MUST accept both text and binary frames. 234 If there is at least one non-UTF-8 symbol in the whole SIP message 235 (including headers and body) then the whole message MUST be sent 236 within a WebSocket binary message. Given the nature of JavaScript 237 and the WebSocket API it is RECOMMENDED to use UTF-8 encoding (or 238 ASCII which is a subset of UTF-8) for SIP messages carried over a 239 WebSocket connection. 241 5. SIP WebSocket Transport 243 WebSocket [RFC6455] is a reliable protocol and therefore the SIP 244 WebSocket sub-protocol defined by this document is a reliable SIP 245 transport. Thus, client and server transactions using WebSocket for 246 transport MUST follow the procedures and timer values for reliable 247 transports as defined in [RFC3261]. 249 Each SIP message MUST be carried within a single WebSocket message, 250 and a WebSocket message MUST NOT contain more than one SIP message. 251 Because the WebSocket transport preserves message boundaries, the use 252 of the Content-Length header in SIP messages is not necessary when 253 they are transported using the WebSocket sub-protocol. 255 This simplifies parsing of SIP messages for both clients and 256 servers. There is no need to establish message boundaries using 257 Content-Length headers between messages. Other SIP transports, 258 such as UDP and SCTP [RFC4168] also provide this benefit. 260 5.1. Via Transport Parameter 262 Via header fields in SIP messages carry a transport protocol 263 identifier. This document defines the value "WS" to be used for 264 requests over plain WebSocket connections and "WSS" for requests over 265 secure WebSocket connections (in which the WebSocket connection is 266 established using TLS [RFC5246] with TCP transport). 268 The updated augmented BNF (Backus-Naur Form) [RFC5234] for this 269 parameter is the following (the original BNF for this parameter can 270 be found in [RFC3261], which was then updated by [RFC4168]): 272 transport =/ "WS" / "WSS" 274 5.2. SIP URI Transport Parameter 276 This document defines the value "ws" as the transport parameter value 277 for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub- 278 protocol as transport. 280 The updated augmented BNF (Backus-Naur Form) for this parameter is 281 the following (the original BNF for this parameter can be found in 282 [RFC3261]): 284 transport-param =/ "transport=" "ws" 286 5.3. Via received Parameter 288 [RFC3261] section 18.2.1 "Receiving Requests" states the following: 290 When the server transport receives a request over any transport, 291 it MUST examine the value of the "sent-by" parameter in the top 292 Via header field value. If the host portion of the "sent-by" 293 field contains a domain name, or if it contains an IP address that 294 differs from the packet source address, the server MUST add a 295 "received" parameter to that Via header field value. This 296 parameter MUST contain the source address from which the packet 297 was received. 299 The requirement of adding the "received" parameter does not fit well 300 into the WebSocket protocol design. The WebSocket connection 301 handshake reuses existing HTTP infrastructure in which there could be 302 an unknown number of HTTP proxies and/or TCP load balancers between 303 the SIP WebSocket Client and Server, so the source address the server 304 would write into the Via "received" parameter would be the address of 305 the HTTP/TCP intermediary in front of it. This could reveal 306 sensitive information about the internal topology of the Server's 307 network to the Client. 309 Given the fact that SIP responses can only be sent over the existing 310 WebSocket connection, the Via "received" parameter is of little use. 311 Therefore, in order to allow hiding possible sensitive information 312 about the SIP WebSocket Server's network, this document updates 313 [RFC3261] section 18.2.1 by stating: 315 When a SIP WebSocket Server receives a request it MAY decide not 316 to add a "received" parameter to the top Via header. Therefore 317 SIP WebSocket Clients MUST accept responses without such a 318 parameter in the top Via header regardless of whether the Via 319 "sent-by" field contains a domain name. 321 5.4. SIP Transport Implementation Requirements 323 [RFC3261] section 18 "Transport" states the following: 325 All SIP elements MUST implement UDP and TCP. SIP elements MAY 326 implement other protocols. 328 The specification of this transport enables SIP to be used as a 329 session establishment protocol in scenarios where none of other 330 transport protocols defined for SIP can be used. Since some 331 environments do not enable SIP elements to use UDP and TCP as SIP 332 transport protocols, a SIP element acting as a SIP WebSocket Client 333 is not mandated to implement support of UDP and TCP. 335 5.5. Locating a SIP Server 337 [RFC3263] specifies the procedures which should be followed by SIP 338 entities for locating SIP servers. This specification defines the 339 NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support 340 plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers 341 that support secure WebSocket connections. 343 At the time this document was written, DNS NAPTR/SRV queries could 344 not be performed by commonly available WebSocket client stacks (in 345 JavaScript engines and web browsers). 347 In the absence of DNS SRV resource records or an explicit port, the 348 default port for a SIP URI using the "sip" scheme and the "ws" 349 transport parameter is 80, and the default port for a SIP URI using 350 the "sips" scheme and the "ws" transport parameter is 443. 352 6. Connection Keep-Alive 354 SIP WebSocket Clients and Servers may keep their WebSocket 355 connections open by sending periodic WebSocket "Ping" frames as 356 described in [RFC6455] section 5.5.2. 358 The WebSocket API [WS-API] does not provide a mechanism for 359 applications running in a web browser to control whether or not 360 periodic WebSocket "Ping" frames are sent to the server. The 361 implementation of such a keep-alive feature is the decision of 362 each web browser manufacturer and may also depend on the 363 configuration of the web browser. 365 The indication and use of the CRLF NAT keep-alive mechanism defined 366 for SIP connection-oriented transports in [RFC5626] section 3.5.1 or 367 [RFC6223] are, of course, usable over the transport defined in this 368 specification. 370 7. Authentication 372 This section describes how authentication is achieved through the 373 requirements in [RFC6455], [RFC6265], [RFC2617] and [RFC3261]. 375 WebSocket protocol [RFC6455] does not define an authentication 376 mechanism, instead it exposes the following text in section 10.5 377 "WebSocket Client Authentication": 379 This protocol doesn't prescribe any particular way that servers 380 can authenticate clients during the WebSocket handshake. The 381 WebSocket server can use any client authentication mechanism 382 available to a generic HTTP server, such as cookies, HTTP 383 authentication, or TLS authentication. 385 The following list exposes mandatory to implement and optional 386 mechanisms for SIP WebSocket Clients and Servers in order to get 387 interoperability at WebSocket authentication level: 389 o A SIP WebSocket Client MUST be ready to add a session Cookie when 390 it runs in a web browser (or behaves like a browser navigating a 391 website) and has previously retrieved a session Cookie from the 392 web server whose URL domain matches the domain in the WebSocket 393 URI. This mechanism is defined by [RFC6265]. 395 o A SIP WebSocket Client MUST be ready to be challenged with HTTP 396 401 status code by the SIP WebSocket Server when performing the 397 WebSocket handshake as stated in [RFC2617]. 399 o A SIP WebSocket Client MAY use TLS client authentication (when in 400 a secure WebSocket connection) as an optional authentication 401 mechanism. 403 Note however that TLS client authentication in WebSocket 404 protocol is governed by the rules of HTTP protocol rather than 405 the rules of SIP protocol. 407 o A SIP WebSocket Server MUST be ready to read session Cookies when 408 present in the WebSocket handshake request, and use such a Cookie 409 value for determining whether the WebSocket connection has been 410 initiated by a HTTP client navigating a website in the same domain 411 (or subdomain) as the SIP WebSocket Server. 413 o A SIP WebSocket Server SHOULD be able to reject a WebSocket 414 handshake request with HTTP 401 status code by providing a Basic/ 415 Digest challenge as defined for HTTP protocol. 417 Regardless of whether the SIP WebSocket Server requires 418 authentication during the WebSocket handshake or not, authentication 419 MAY be requested at SIP protocol level. 421 Some authentication use cases are exposed in Appendix A. 423 8. Examples 424 8.1. Registration 426 Alice (SIP WSS) proxy.example.com 427 | | 428 |HTTP GET (WS handshake) F1 | 429 |---------------------------->| 430 |101 Switching Protocols F2 | 431 |<----------------------------| 432 | | 433 |REGISTER F3 | 434 |---------------------------->| 435 |200 OK F4 | 436 |<----------------------------| 437 | | 439 Alice loads a web page using her web browser and retrieves JavaScript 440 code implementing the WebSocket SIP sub-protocol defined in this 441 document. The JavaScript code (a SIP WebSocket Client) establishes a 442 secure WebSocket connection with a SIP proxy/registrar (a SIP 443 WebSocket Server) at proxy.example.com. Upon WebSocket connection, 444 Alice constructs and sends a SIP REGISTER request including Outbound 445 and GRUU support. Since the JavaScript stack in a browser has no way 446 to determine the local address from which the WebSocket connection 447 was made, this implementation uses a random ".invalid" domain name 448 for the Via header sent-by parameter and for the hostport of the URI 449 in the Contact header (see Appendix B.1). 451 Message details (authentication and SDP bodies are omitted for 452 simplicity): 454 F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS) 456 GET / HTTP/1.1 457 Host: proxy.example.com 458 Upgrade: websocket 459 Connection: Upgrade 460 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 461 Origin: https://www.example.com 462 Sec-WebSocket-Protocol: sip 463 Sec-WebSocket-Version: 13 465 F2 101 Switching Protocols proxy.example.com -> Alice (TLS) 467 HTTP/1.1 101 Switching Protocols 468 Upgrade: websocket 469 Connection: Upgrade 470 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 471 Sec-WebSocket-Protocol: sip 473 F3 REGISTER Alice -> proxy.example.com (transport WSS) 475 REGISTER sip:proxy.example.com SIP/2.0 476 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 477 From: sip:alice@example.com;tag=65bnmj.34asd 478 To: sip:alice@example.com 479 Call-ID: aiuy7k9njasd 480 CSeq: 1 REGISTER 481 Max-Forwards: 70 482 Supported: path, outbound, gruu 483 Contact: 484 ;reg-id=1 485 ;+sip.instance="" 487 F4 200 OK proxy.example.com -> Alice (transport WSS) 489 SIP/2.0 200 OK 490 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 491 From: sip:alice@example.com;tag=65bnmj.34asd 492 To: sip:alice@example.com;tag=12isjljn8 493 Call-ID: aiuy7k9njasd 494 CSeq: 1 REGISTER 495 Supported: outbound, gruu 496 Contact: 497 ;reg-id=1 498 ;+sip.instance="" 499 ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1" 500 ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr" 501 ;expires=3600 503 8.2. INVITE Dialog through a Proxy 504 Alice (SIP WSS) proxy.example.com (SIP UDP) Bob 505 | | | 506 |INVITE F1 | | 507 |---------------------------->| | 508 |100 Trying F2 | | 509 |<----------------------------| | 510 | |INVITE F3 | 511 | |---------------------------->| 512 | |200 OK F4 | 513 | |<----------------------------| 514 |200 OK F5 | | 515 |<----------------------------| | 516 | | | 517 |ACK F6 | | 518 |---------------------------->| | 519 | |ACK F7 | 520 | |---------------------------->| 521 | | | 522 | Bidirectional RTP Media | 523 |<=========================================================>| 524 | | | 525 | |BYE F8 | 526 | |<----------------------------| 527 |BYE F9 | | 528 |<----------------------------| | 529 |200 OK F10 | | 530 |---------------------------->| | 531 | |200 OK F11 | 532 | |---------------------------->| 533 | | | 535 In the same scenario Alice places a call to Bob's AoR (Address Of 536 Record). The SIP WebSocket Server at proxy.example.com acts as a SIP 537 proxy, routing the INVITE to Bob's contact address (which happens to 538 be using SIP transported over UDP). Bob answers the call and then 539 terminates it. 541 Message details (authentication and SDP bodies are omitted for 542 simplicity): 544 F1 INVITE Alice -> proxy.example.com (transport WSS) 546 INVITE sip:bob@example.com SIP/2.0 547 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 548 From: sip:alice@example.com;tag=asdyka899 549 To: sip:bob@example.com 550 Call-ID: asidkj3ss 551 CSeq: 1 INVITE 552 Max-Forwards: 70 553 Supported: path, outbound, gruu 554 Route: 555 Contact: 557 Content-Type: application/sdp 559 F2 100 Trying proxy.example.com -> Alice (transport WSS) 561 SIP/2.0 100 Trying 562 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 563 From: sip:alice@example.com;tag=asdyka899 564 To: sip:bob@example.com 565 Call-ID: asidkj3ss 566 CSeq: 1 INVITE 568 F3 INVITE proxy.example.com -> Bob (transport UDP) 570 INVITE sip:bob@203.0.113.22:5060 SIP/2.0 571 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 572 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 573 Record-Route: , 574 575 From: sip:alice@example.com;tag=asdyka899 576 To: sip:bob@example.com 577 Call-ID: asidkj3ss 578 CSeq: 1 INVITE 579 Max-Forwards: 69 580 Supported: path, outbound, gruu 581 Contact: 583 Content-Type: application/sdp 585 F4 200 OK Bob -> proxy.example.com (transport UDP) 587 SIP/2.0 200 OK 588 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 589 ;received=192.0.2.10 590 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 591 Record-Route: , 592 593 From: sip:alice@example.com;tag=asdyka899 594 To: sip:bob@example.com;tag=bmqkjhsd 595 Call-ID: asidkj3ss 596 CSeq: 1 INVITE 597 Contact: 598 Content-Type: application/sdp 600 F5 200 OK proxy.example.com -> Alice (transport WSS) 602 SIP/2.0 200 OK 603 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 604 Record-Route: , 605 606 From: sip:alice@example.com;tag=asdyka899 607 To: sip:bob@example.com;tag=bmqkjhsd 608 Call-ID: asidkj3ss 609 CSeq: 1 INVITE 610 Contact: 611 Content-Type: application/sdp 613 F6 ACK Alice -> proxy.example.com (transport WSS) 615 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 616 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 617 Route: , 618 , 619 From: sip:alice@example.com;tag=asdyka899 620 To: sip:bob@example.com;tag=bmqkjhsd 621 Call-ID: asidkj3ss 622 CSeq: 1 ACK 623 Max-Forwards: 70 625 F7 ACK proxy.example.com -> Bob (transport UDP) 627 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 628 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx 629 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 630 From: sip:alice@example.com;tag=asdyka899 631 To: sip:bob@example.com;tag=bmqkjhsd 632 Call-ID: asidkj3ss 633 CSeq: 1 ACK 634 Max-Forwards: 69 636 F8 BYE Bob -> proxy.example.com (transport UDP) 638 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 639 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 640 Route: , 641 642 From: sip:bob@example.com;tag=bmqkjhsd 643 To: sip:alice@example.com;tag=asdyka899 644 Call-ID: asidkj3ss 645 CSeq: 1201 BYE 646 Max-Forwards: 70 648 F9 BYE proxy.example.com -> Alice (transport WSS) 650 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 651 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 652 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 653 From: sip:bob@example.com;tag=bmqkjhsd 654 To: sip:alice@example.com;tag=asdyka899 655 Call-ID: asidkj3ss 656 CSeq: 1201 BYE 657 Max-Forwards: 69 659 F10 200 OK Alice -> proxy.example.com (transport WSS) 661 SIP/2.0 200 OK 662 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 663 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 664 From: sip:bob@example.com;tag=bmqkjhsd 665 To: sip:alice@example.com;tag=asdyka899 666 Call-ID: asidkj3ss 667 CSeq: 1201 BYE 669 F11 200 OK proxy.example.com -> Bob (transport UDP) 671 SIP/2.0 200 OK 672 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 673 From: sip:bob@example.com;tag=bmqkjhsd 674 To: sip:alice@example.com;tag=asdyka899 675 Call-ID: asidkj3ss 676 CSeq: 1201 BYE 678 9. Security Considerations 680 9.1. Secure WebSocket Connection 682 It is RECOMMENDED that the SIP traffic transported over a WebSocket 683 communication be protected by using a secure WebSocket connection 684 (using TLS [RFC5246] over TCP). 686 When establishing a connection using SIP over secure WebSocket 687 transport, the client MUST authenticate the server using the server's 688 certificate according to the WebSocket validation procedure in 689 [RFC6455]. 691 Server operators should note that this authentication procedure is 692 different from the procedure for SIP Domain Certificates defined 693 in [RFC5922]. Certificates that are appropriate for SIP over TLS 694 over TCP will probably not be appropriate for SIP over secure 695 WebSocket connections. 697 9.2. Usage of SIPS Scheme 699 The SIPS scheme in a SIP URI dictates that the entire request path to 700 the target be secure. If such a path includes a WebSocket connection 701 it MUST be a secure WebSocket connection. 703 10. IANA Considerations 705 RFC Editor Note: Please set the RFC number assigned for this document 706 in the sub-sections below and remove this note. 708 10.1. Registration of the WebSocket SIP Sub-Protocol 710 This specification requests IANA to register the WebSocket SIP sub- 711 protocol under the "WebSocket Subprotocol Name" Registry with the 712 following data: 714 Subprotocol Identifier: sip 716 Subprotocol Common Name: WebSocket Transport for SIP (Session 717 Initiation Protocol) 719 Subprotocol Definition: TBD: this document 721 10.2. Registration of new NAPTR Service Field Values 723 This document defines two new NAPTR service field values (SIP+D2W and 724 SIPS+D2W) and requests IANA to register these values under the 725 "Registry for the Session Initiation Protocol (SIP) NAPTR Resource 726 Record Services Field". The resulting entries are as follows: 728 Services Field Protocol Reference 729 -------------- -------- --------- 730 SIP+D2W WS TBD: this document 731 SIPS+D2W WS TBD: this document 733 10.3. SIP/SIPS URI Parameters Sub-Registry 735 This specification requests IANA to add a reference to this document 736 under the "SIP/SIPS URI Parameters" Sub-Registry within the "Session 737 Initiation Protocol (SIP) Parameters" Registry: 739 Parameter Name Predefined Values Reference 740 -------------- ----------------- --------- 741 transport Yes [RFC3261][TBD: this document] 743 10.4. Header Fields Sub-Registry 745 This specification requests IANA to add a reference to this document 746 under the "Header Fields" Sub-Registry within the "Session Initiation 747 Protocol (SIP) Parameters" Registry: 749 Header Name compact Reference 750 ----------- ------- --------- 751 Via v [RFC3261][TBD: this document] 753 10.5. Header Field Parameters and Parameter Values Sub-Registry 755 This specification requests IANA to add a reference to this document 756 under the "Header Field Parameters and Parameter Values" Sub-Registry 757 within the "Session Initiation Protocol (SIP) Parameters" Registry: 759 Predefined 760 Header Field Parameter Name Values Reference 761 ------------ -------------- ------ --------- 762 Via received No [RFC3261][TBD: this document] 764 10.6. SIP Transport Sub-Registry 766 This document adds a new registry, "SIP Transport", to the "Session 767 Initiation Protocol (SIP) Parameters" Registry. Its format and 768 initial values are as shown in the following table: 770 +------------+------------------------+ 771 | Transport | Reference | 772 +------------+------------------------+ 773 | UDP | [RFC 3261] | 774 | TCP | [RFC 3261] | 775 | TLS | [RFC 3261] | 776 | SCTP | [RFC 3261], [RFC 4168] | 777 | TLS-SCTP | [RFC 4168] | 778 | WS | [TBD: this document] | 779 | WSS | [TBD: this document] | 780 +------------+------------------------+ 782 The policy for registration of values in this registry is "Standards 783 Action", as that term is defined by [RFC5226]. 785 11. Acknowledgements 787 Special thanks to the following people who participated in 788 discussions on the SIPCORE and RTCWEB WG mailing lists and 789 contributed ideas and/or provided detailed reviews (the list is 790 likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Robert 791 Sparks, Adam Roach, Ranjit Avasarala, Xavier Marjou, Nataraju A. B., 792 Martin Vopatek, Alexey Melnikov, Alan Johnston, Christer Holmberg, 793 Salvatore Loreto, Kevin P. Fleming, Suresh Krishnan, Yaron Sheffer, 794 Richard Barnes, Barry Leiba, Stephen Farrell, Ted Lemon, Benoit 795 Claise, Pete Resnick, Binod, Saul Ibarra Corretge. 797 12. References 799 12.1. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, March 1997. 804 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 805 Leach, P., Luotonen, A., and L. Stewart, "HTTP 806 Authentication: Basic and Digest Access Authentication", 807 RFC 2617, June 1999. 809 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 810 A., Peterson, J., Sparks, R., Handley, M., and E. 811 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 812 June 2002. 814 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 815 Protocol (SIP): Locating SIP Servers", RFC 3263, 816 June 2002. 818 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 819 Part Three: The Domain Name System (DNS) Database", 820 RFC 3403, October 2002. 822 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 823 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 824 May 2008. 826 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 827 Specifications: ABNF", STD 68, RFC 5234, January 2008. 829 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 830 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 832 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 833 April 2011. 835 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 836 RFC 6455, December 2011. 838 12.2. Informative References 840 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 841 Names", BCP 32, RFC 2606, June 1999. 843 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 844 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 845 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 847 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 848 (SIP) Extension Header Field for Registering Non-Adjacent 849 Contacts", RFC 3327, December 2002. 851 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 852 Resource Identifier (URI): Generic Syntax", STD 66, 853 RFC 3986, January 2005. 855 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 856 Stream Control Transmission Protocol (SCTP) as a Transport 857 for the Session Initiation Protocol (SIP)", RFC 4168, 858 October 2005. 860 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 861 Initiated Connections in the Session Initiation Protocol 862 (SIP)", RFC 5626, October 2009. 864 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 865 Agent URIs (GRUUs) in the Session Initiation Protocol 866 (SIP)", RFC 5627, October 2009. 868 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 869 Certificates in the Session Initiation Protocol (SIP)", 870 RFC 5922, June 2010. 872 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 873 RFC 6223, April 2011. 875 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", April 2013. 877 Appendix A. Authentication Use Cases 879 Sections below briefly describe some SIP over WebSocket scenarios in 880 which authentication take place in different ways. 882 A.1. Just SIP Authentication 884 SIP PBX model A implements the SIP WebSocket transport defined by 885 this specification. Its implementation is 100% website agnostic as 886 it does not share information with the web server providing the HTML 887 code to browsers, meaning that the SIP WebSocket Server (here the PBX 888 model A) has no knowledge about web login activity within the 889 website. 891 In this simple scenario, the SIP WebSocket Server does not inspect 892 fields in the WebSocket handshake HTTP GET request such as the 893 request URL, the Origin header value, the Host header value or the 894 Cookie header value (if present). However some of those fields could 895 be inspected for a minimal validation (i.e. PBX model A could 896 require that the Origin header value contains a specific URL so just 897 users navigating such a website would be able to establish a 898 WebSocket connection with PBX model A). 900 Once the WebSocket connection has been established, SIP 901 authentication is requested by PBX model A for each SIP request 902 coming over that connection. Therefore SIP WebSocket Clients must be 903 provisioned with their corresponding SIP password. 905 A.2. Just Web Authentication 907 A SIP-to-PSTN provider offers telephony service for clients logged 908 into its website. The provider does not want to expose SIP passwords 909 into the web for security/privacy reasons. 911 Once the user is logged into the web, the web server provides him 912 with a SIP identity (SIP URI) and a session temporary token string 913 (along with the SIP WebSocket Client JavaScript application and SIP 914 settings). The web server stores the SIP identity and session token 915 into a database. 917 The web application adds the SIP identity and session token as URL 918 query parameters in the WebSocket handshake request and attempts the 919 connection. The SIP WebSocket Server inspects the handshake request 920 and validates that the session token matches the value stored in the 921 database for the given SIP identity. In case the value matches, the 922 WebSocket connection gets "authenticated" for that SIP identity. The 923 SIP WebSocket Client can then register and make calls. The SIP 924 WebSocket Server would however verify that the identity in those SIP 925 requests (i.e. the From URI value) matches the SIP identity the 926 WebSocket connection is associated to (otherwise the SIP request is 927 rejected). 929 When the user performs logout action in the web, the web server 930 removes the SIP identity and session token tuple from the database 931 and notifies it to the SIP WebSocket Server which revokes and closes 932 the WebSocket connection. 934 No SIP authentication takes place in this scenario. 936 A.3. Cookie Based Authentication 938 Apache web server comes with a new module mod_sip_websocket. The web 939 server is configured to listen in port 80 for both HTTP common 940 requests and WebSocket handshake requests. Therefore both the web 941 server and the SIP WebSocket Server are co-located within the same 942 host and same domain. 944 Once the user is logged into the web, he is provided with the SIP 945 WebSocket Client JavaScript application and SIP settings. The HTTP 946 200 response after the login procedure also contains a session Cookie 947 [RFC6265]. The web application attempts then a WebSocket connection 948 against the same URL/domain of the website and thus, the session 949 Cookie is automatically added by the browser into the WebSocket 950 handshake request (as the WebSocket protocol [RFC6455] states). 952 The web server inspects the Cookie value (as it would do for a common 953 HTTP request containing a session Cookie, so login procedure is not 954 required again). If the Cookie is valid the WebSocket connection is 955 authorized and, as in the previous use case, the connection is also 956 associated with a specific SIP identity which must be satisfied by 957 every SIP request coming over that connection. 959 No SIP authentication takes place in this scenario but just common 960 Cookie usage as widely deployed in the WWW. 962 Appendix B. Implementation Guidelines 964 Let us assume a scenario in which the users access with their web 965 browsers (probably behind NAT) an application provided by a server on 966 an intranet, login by entering their user identifier and credentials, 967 and retrieve a JavaScript application (along with the HTML) 968 implementing a SIP WebSocket Client. 970 Such a SIP stack connects to a given SIP WebSocket Server (an 971 outbound SIP proxy which also implements classic SIP transports such 972 as UDP and TCP). The HTTP GET method request sent by the web browser 973 for the WebSocket handshake includes a Cookie [RFC6265] header with 974 the value previously provided by the server after the successful 975 login procedure. The Cookie value is then inspected by the WebSocket 976 server to authorize the connection. Once the WebSocket connection is 977 established, the SIP WebSocket Client performs a SIP registration to 978 a SIP registrar server that is reachable through the proxy. After 979 registration, the SIP WebSocket Client and Server exchange SIP 980 messages as would normally be expected. 982 This scenario is quite similar to ones in which SIP UAs behind NATs 983 connect to a proxy and must reuse the same TCP connection for 984 incoming requests (because they are not directly reachable by the 985 proxy otherwise). In both cases, the SIP UAs are only reachable 986 through the proxy they are connected to. 988 The SIP Outbound extension [RFC5626] seems an appropriate solution 989 for this scenario. Therefore these SIP WebSocket Clients and the SIP 990 registrar implement both the Outbound and Path [RFC3327] extensions, 991 and the SIP proxy acts as an Outbound Edge Proxy (as defined in 992 [RFC5626] section 3.4). 994 SIP WebSocket Clients in this scenario receive incoming SIP requests 995 via the SIP WebSocket Server they are connected to. Therefore, in 996 some call transfer cases the usage of GRUU [RFC5627] (which should be 997 implemented in both the SIP WebSocket Clients and SIP registrar) is 998 valuable. 1000 If a REFER request is sent to a third SIP user agent including the 1001 Contact URI of a SIP WebSocket Client as the target in its 1002 Refer-To header field, such a URI will be reachable by the third 1003 SIP UA only if it is a globally routable URI. GRUU (Globally 1004 Routable User Agent URI) is a solution for those scenarios, and 1005 would cause the incoming request from the third SIP user agent to 1006 be sent to the SIP registrar, which would route the request to the 1007 SIP WebSocket Client via the Outbound Edge Proxy. 1009 B.1. SIP WebSocket Client Considerations 1011 The JavaScript stack in web browsers does not have the ability to 1012 discover the local transport address used for originating WebSocket 1013 connections. A SIP WebSocket client running in such an environment 1014 can construct a domain name consisting of a random token followed by 1015 the ".invalid" top-level domain name, as stated in [RFC2606], and 1016 uses it within its Via and Contact headers. 1018 The Contact URI provided by SIP UAs requesting (and receiving) 1019 Outbound support is not used for routing requests to those UAs, 1020 thus it is safe to set a random domain in the Contact URI 1021 hostport. 1023 Both the Outbound and GRUU specifications require a SIP UA to include 1024 a Uniform Resource Name (URN) in a "+sip.instance" parameter of the 1025 Contact header they include their SIP REGISTER requests. The client 1026 device is responsible for generating or collecting a suitable value 1027 for this purpose. 1029 In web browsers it is difficult to generate or collect a suitable 1030 value to be used as a URN value from the browser itself. This 1031 scenario suggests that value is generated according to [RFC5626] 1032 section 4.1 by the web application running in the browser the 1033 first time it loads the JavaScript SIP stack code, and then it is 1034 stored as a Cookie within the browser. 1036 B.2. SIP WebSocket Server Considerations 1038 The SIP WebSocket Server in this scenario behaves as a SIP Outbound 1039 Edge Proxy, which involves support for Outbound [RFC5626] and Path 1040 [RFC3327]. 1042 The proxy performs Loose Routing and remains in the path of dialogs 1043 as specified in [RFC3261]. If it did not do this, in-dialog requests 1044 would fail since SIP WebSocket Clients make use of their SIP 1045 WebSocket Server in order to send and receive SIP messages. 1047 Authors' Addresses 1049 Inaki Baz Castillo 1050 Versatica 1051 Barakaldo, Basque Country 1052 Spain 1054 Email: ibc@aliax.net 1056 Jose Luis Millan Villegas 1057 Versatica 1058 Bilbao, Basque Country 1059 Spain 1061 Email: jmillan@aliax.net 1063 Victor Pascual 1064 Quobis 1065 Spain 1067 Email: victor.pascual@quobis.com