idnits 2.17.1 draft-ietf-sipcore-sip-websocket-09.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 471 has weird spacing: '...otocols proxy...' == Line 565 has weird spacing: '... Trying proxy...' == Line 755 has weird spacing: '...er Name comp...' (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 13, 2013) is 3970 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 782, but not defined == Missing Reference: 'RFC 4168' is mentioned on line 783, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 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 Updates: 3261 (if approved) Versatica 5 Intended status: Standards Track V. Pascual 6 Expires: December 15, 2013 Acme Packet 7 June 13, 2013 9 The WebSocket Protocol as a Transport for the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-sip-websocket-09 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. This document normatively updates 20 RFC 3261. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 15, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 5 60 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 5 61 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 7 64 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 7 66 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 7 67 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 7 68 5.2.3. Via received Parameter . . . . . . . . . . . . . . . . 8 69 5.2.4. SIP Transport Implementation Requirements . . . . . . 8 70 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 9 71 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 9 72 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 12 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 16 78 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 17 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 17 81 10.2. Registration of new NAPTR Service Field Values . . . . . . 17 82 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 18 83 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 18 84 10.5. Header Field Parameters and Parameter Values 85 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 18 86 10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 18 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 91 Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 21 92 A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 21 93 A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 21 94 A.3. Cookie Based Authentication . . . . . . . . . . . . . . . 22 95 Appendix B. Implementation Guidelines . . . . . . . . . . . . . . 23 96 B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 24 97 B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 24 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 100 1. Introduction 102 The WebSocket [RFC6455] protocol enables message exchange between 103 clients and servers on top of a persistent TCP connection (optionally 104 secured with TLS [RFC5246]). The initial protocol handshake makes 105 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 106 reuse existing HTTP infrastructure. 108 Modern web browsers include a WebSocket client stack complying with 109 the WebSocket API [WS-API] as specified by the W3C. It is expected 110 that other client applications (those running in personal computers 111 and devices such as smartphones) will also make a WebSocket client 112 stack available. The specification in this document enables usage of 113 SIP in these scenarios. 115 This specification defines a WebSocket sub-protocol (as defined in 116 section 1.9 in [RFC6455]) for transporting SIP messages between a 117 WebSocket client and server, a reliable and message-boundary 118 preserving transport for SIP, DNS NAPTR [RFC3403] service values and 119 procedures for SIP entities implementing the WebSocket transport. 120 Media transport is out of the scope of this document. 122 Section 3 in this specification relaxes the requirement in [RFC3261] 123 by which the SIP server transport MUST add a "received" parameter in 124 the top Via header in certain circumstances. 126 2. Terminology 128 All diagrams, examples, and notes in this specification are non- 129 normative, as are all sections explicitly marked non-normative. 130 Everything else in this specification is normative. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2.1. Definitions 138 SIP WebSocket Client: A SIP entity capable of opening outbound 139 connections to WebSocket servers and communicating using the 140 WebSocket SIP sub-protocol as defined by this document. 142 SIP WebSocket Server: A SIP entity capable of listening for inbound 143 connections from WebSocket clients and communicating using the 144 WebSocket SIP sub-protocol as defined by this document. 146 3. The WebSocket Protocol 148 _This section is non-normative._ 150 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 151 (optionally secured with TLS [RFC5246]) in which both client and 152 server exchange message units in both directions. The protocol 153 defines a connection handshake, WebSocket sub-protocol and extensions 154 negotiation, a frame format for sending application and control data, 155 a masking mechanism, and status codes for indicating disconnection 156 causes. 158 The WebSocket connection handshake is based on HTTP [RFC2616] and 159 utilizes the HTTP GET method with an "Upgrade" request. This is sent 160 by the client and then answered by the server (if the negotiation 161 succeeded) with an HTTP 101 status code. Once the handshake is 162 completed the connection upgrades from HTTP to the WebSocket 163 protocol. This handshake procedure is designed to reuse the existing 164 HTTP infrastructure. During the connection handshake, client and 165 server agree on the application protocol to use on top of the 166 WebSocket transport. Such application protocol (also known as a 167 "WebSocket sub-protocol") defines the format and semantics of the 168 messages exchanged by the endpoints. This could be a custom protocol 169 or a standardized one (as the WebSocket SIP sub-protocol defined in 170 this document). Once the HTTP 101 response is processed both client 171 and server reuse the underlying TCP connection for sending WebSocket 172 messages and control frames to each other. Unlike plain HTTP, this 173 connection is persistent and can be used for multiple message 174 exchanges. 176 WebSocket defines message units to be used by applications for the 177 exchange of data, so it provides a message boundary-preserving 178 transport layer. These message units can contain either UTF-8 text 179 or binary data, and can be split into multiple WebSocket text/binary 180 transport frames as needed by the WebSocket stack. 182 The WebSocket API [WS-API] for web browsers only defines callbacks 183 to be invoked upon receipt of an entire message unit, regardless 184 of whether it was received in a single Websocket frame or split 185 across multiple frames. 187 4. The WebSocket SIP Sub-Protocol 189 The term WebSocket sub-protocol refers to an application-level 190 protocol layered on top of a WebSocket connection. This document 191 specifies the WebSocket SIP sub-protocol for carrying SIP requests 192 and responses through a WebSocket connection. 194 4.1. Handshake 196 The SIP WebSocket Client and SIP WebSocket Server negotiate usage of 197 the WebSocket SIP sub-protocol during the WebSocket handshake 198 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 199 include the value "sip" in the Sec-WebSocket-Protocol header in its 200 handshake request. The 101 reply from the Server MUST contain "sip" 201 in its corresponding Sec-WebSocket-Protocol header. 203 The WebSocket Client initiates a WebSocket connection when 204 attempting to send a SIP request (unless there is an already 205 established WebSocket connection for sending the SIP request). In 206 case there is no HTTP 101 response during the WebSocket handshake 207 it is considered a transaction error as per [RFC3261] section 208 8.1.3.1 "Transaction Layer Errors". 210 Below is an example of a WebSocket handshake in which the Client 211 requests the WebSocket SIP sub-protocol support from the Server: 213 GET / HTTP/1.1 214 Host: sip-ws.example.com 215 Upgrade: websocket 216 Connection: Upgrade 217 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 218 Origin: http://www.example.com 219 Sec-WebSocket-Protocol: sip 220 Sec-WebSocket-Version: 13 222 The handshake response from the Server accepting the WebSocket SIP 223 sub-protocol would look as follows: 225 HTTP/1.1 101 Switching Protocols 226 Upgrade: websocket 227 Connection: Upgrade 228 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 229 Sec-WebSocket-Protocol: sip 231 Once the negotiation has been completed, the WebSocket connection is 232 established and can be used for the transport of SIP requests and 233 responses. The WebSocket messages transmitted over this connection 234 MUST conform to the negotiated WebSocket sub-protocol. 236 4.2. SIP Encoding 238 WebSocket messages can be transported in either UTF-8 text frames or 239 binary frames. SIP [RFC3261] allows both text and binary bodies in 240 SIP requests and responses. Therefore SIP WebSocket Clients and SIP 241 WebSocket Servers MUST accept both text and binary frames. 243 5. SIP WebSocket Transport 245 5.1. General 247 WebSocket [RFC6455] is a reliable protocol and therefore the SIP 248 WebSocket sub-protocol defined by this document is a reliable SIP 249 transport. Thus, client and server transactions using WebSocket for 250 transport MUST follow the procedures and timer values for reliable 251 transports as defined in [RFC3261]. 253 Each SIP message MUST be carried within a single WebSocket message, 254 and a WebSocket message MUST NOT contain more than one SIP message. 255 Because the WebSocket transport preserves message boundaries, the use 256 of the Content-Length header in SIP messages is optional when they 257 are transported using the WebSocket sub-protocol. 259 This simplifies parsing of SIP messages for both clients and 260 servers. There is no need to establish message boundaries using 261 Content-Length headers between messages. Other SIP transports, 262 such as UDP and SCTP [RFC4168] also provide this benefit. 264 5.2. Updates to RFC 3261 266 5.2.1. Via Transport Parameter 268 Via header fields in SIP messages carry a transport protocol 269 identifier. This document defines the value "WS" to be used for 270 requests over plain WebSocket connections and "WSS" for requests over 271 secure WebSocket connections (in which the WebSocket connection is 272 established using TLS [RFC5246] with TCP transport). 274 The updated augmented BNF (Backus-Naur Form) [RFC5234] for this 275 parameter is the following (the original BNF for this parameter can 276 be found in [RFC3261], which was then updated by [RFC4168]): 278 transport =/ "WS" / "WSS" 280 5.2.2. SIP URI Transport Parameter 282 This document defines the value "ws" as the transport parameter value 283 for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub- 284 protocol as transport. 286 The updated augmented BNF (Backus-Naur Form) for this parameter is 287 the following (the original BNF for this parameter can be found in 288 [RFC3261]): 290 transport-param =/ "transport=" "ws" 292 5.2.3. Via received Parameter 294 [RFC3261] section 18.2.1 "Receiving Requests" states the following: 296 When the server transport receives a request over any transport, 297 it MUST examine the value of the "sent-by" parameter in the top 298 Via header field value. If the host portion of the "sent-by" 299 field contains a domain name, or if it contains an IP address that 300 differs from the packet source address, the server MUST add a 301 "received" parameter to that Via header field value. This 302 parameter MUST contain the source address from which the packet 303 was received. 305 The requirement of adding the "received" parameter does not fit well 306 into the WebSocket protocol design. The WebSocket connection 307 handshake reuses existing HTTP infrastructure in which there could be 308 an unknown number of HTTP proxies and/or TCP load balancers between 309 the SIP WebSocket Client and Server, so the source address the server 310 would write into the Via "received" parameter would be the address of 311 the HTTP/TCP intermediary in front of it. This could reveal 312 sensitive information about the internal topology of the Server's 313 network to the Client. 315 Given the fact that SIP responses can only be sent over the existing 316 WebSocket connection, the Via "received" parameter is of little use. 317 Therefore, in order to allow hiding possible sensitive information 318 about the SIP WebSocket Server's network, this document updates 319 [RFC3261] section 18.2.1 by stating: 321 When a SIP WebSocket Server receives a request it MAY decide not 322 to add a "received" parameter to the top Via header. Therefore 323 SIP WebSocket Clients MUST accept responses without such a 324 parameter in the top Via header regardless of whether the Via 325 "sent-by" field contains a domain name. 327 5.2.4. SIP Transport Implementation Requirements 329 [RFC3261] section 18 "Transport" states the following: 331 All SIP elements MUST implement UDP and TCP. SIP elements MAY 332 implement other protocols. 334 The specification of this transport enables SIP to be used as a 335 session establishment protocol in scenarios where none of other 336 transport protocols defined for SIP can be used. Since some 337 environments do not enable SIP elements to use UDP and TCP as SIP 338 transport protocols, a SIP element acting as a SIP WebSocket Client 339 is not mandated to implement support of UDP and TCP. 341 The sentence quoted above from [RFC3261] section 18 is thus amended 342 as follows: 344 All SIP elements MUST implement at least one of the following: 346 * Both UDP and TCP transports. 348 * SIP WebSocket transport. 350 5.3. Locating a SIP Server 352 [RFC3263] specifies the procedures which should be followed by SIP 353 entities for locating SIP servers. This specification defines the 354 NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support 355 plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers 356 that support secure WebSocket connections. 358 At the time this document was written, DNS NAPTR/SRV queries could 359 not be performed by commonly available WebSocket client stacks (in 360 JavaScript engines and web browsers). 362 In the absence of DNS SRV resource records or an explicit port, the 363 default port for a SIP URI using the "sip" scheme and the "ws" 364 transport parameter is 80, and the default port for a SIP URI using 365 the "sips" scheme and the "ws" transport parameter is 443. 367 6. Connection Keep-Alive 369 _This section is non-normative._ 371 SIP WebSocket Clients and Servers may keep their WebSocket 372 connections open by sending periodic WebSocket "Ping" frames as 373 described in [RFC6455] section 5.5.2. 375 The WebSocket API [WS-API] does not provide a mechanism for 376 applications running in a web browser to control whether or not 377 periodic WebSocket "Ping" frames are sent to the server. The 378 implementation of such a keep-alive feature is the decision of 379 each web browser manufacturer and may also depend on the 380 configuration of the web browser. 382 The indication and use of the CRLF NAT keep-alive mechanism defined 383 for SIP connection-oriented transports in [RFC5626] section 3.5.1 or 384 [RFC6223] are, of course, usable over the transport defined in this 385 specification. 387 7. Authentication 389 This section describes how authentication is achieved through the 390 requirements in [RFC6455], [RFC6265] and [RFC3261]. 392 Prior to sending SIP requests, a SIP WebSocket Client connects to a 393 SIP WebSocket Server and performs the connection handshake. As 394 described in Section 3 the handshake procedure involves a HTTP GET 395 method request from the Client and a response from the Server 396 including an HTTP 101 status code. 398 In order to authorize the WebSocket connection, the SIP WebSocket 399 Server MAY require specific values for some fields in the WebSocket 400 handshake request (such as the Origin header value or query 401 parameters in the request URL). The SIP WebSocket Server MAY also 402 inspect any Cookie [RFC6265] headers present in the HTTP GET request. 403 For many web applications the value of such a Cookie is provided by 404 the web server once the user has authenticated to the web server, 405 which could be done by many existing mechanisms. As an alternative 406 method, the SIP WebSocket Server MAY request HTTP authentication by 407 replying to the Client's GET method request with a HTTP 401 status 408 code. The WebSocket protocol [RFC6455] covers this usage in section 409 4.1: 411 If the status code received from the server is not 101, the 412 WebSocket client stack handles the response per HTTP [RFC2616] 413 procedures, in particular the client might perform authentication 414 if it receives 401 status code. 416 If SIP Digest authentication is not requested for SIP requests coming 417 from the SIP WebSocket Client, then the SIP WebSocket Server MUST 418 authorize SIP requests based on a previous Web or WebSocket login / 419 authentication procedure, and MUST validate that the SIP identity in 420 those SIP requests match the SIP identity associated to the WebSocket 421 connection. 423 If no authentication is done at WebSocket level then SIP Digest 424 authentication is required for every SIP request coming over the 425 WebSocket connection. 427 Some authentication use cases are exposed in Appendix A. 429 8. Examples 430 8.1. Registration 432 Alice (SIP WSS) proxy.example.com 433 | | 434 |HTTP GET (WS handshake) F1 | 435 |---------------------------->| 436 |101 Switching Protocols F2 | 437 |<----------------------------| 438 | | 439 |REGISTER F3 | 440 |---------------------------->| 441 |200 OK F4 | 442 |<----------------------------| 443 | | 445 Alice loads a web page using her web browser and retrieves JavaScript 446 code implementing the WebSocket SIP sub-protocol defined in this 447 document. The JavaScript code (a SIP WebSocket Client) establishes a 448 secure WebSocket connection with a SIP proxy/registrar (a SIP 449 WebSocket Server) at proxy.example.com. Upon WebSocket connection, 450 Alice constructs and sends a SIP REGISTER request including Outbound 451 and GRUU support. Since the JavaScript stack in a browser has no way 452 to determine the local address from which the WebSocket connection 453 was made, this implementation uses a random ".invalid" domain name 454 for the Via header sent-by parameter and for the hostport of the URI 455 in the Contact header (see Appendix B.1). 457 Message details (authentication and SDP bodies are omitted for 458 simplicity): 460 F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS) 462 GET / HTTP/1.1 463 Host: proxy.example.com 464 Upgrade: websocket 465 Connection: Upgrade 466 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 467 Origin: https://www.example.com 468 Sec-WebSocket-Protocol: sip 469 Sec-WebSocket-Version: 13 471 F2 101 Switching Protocols proxy.example.com -> Alice (TLS) 473 HTTP/1.1 101 Switching Protocols 474 Upgrade: websocket 475 Connection: Upgrade 476 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 477 Sec-WebSocket-Protocol: sip 479 F3 REGISTER Alice -> proxy.example.com (transport WSS) 481 REGISTER sip:proxy.example.com SIP/2.0 482 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 483 From: sip:alice@example.com;tag=65bnmj.34asd 484 To: sip:alice@example.com 485 Call-ID: aiuy7k9njasd 486 CSeq: 1 REGISTER 487 Max-Forwards: 70 488 Supported: path, outbound, gruu 489 Contact: 490 ;reg-id=1 491 ;+sip.instance="" 493 F4 200 OK proxy.example.com -> Alice (transport WSS) 495 SIP/2.0 200 OK 496 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 497 From: sip:alice@example.com;tag=65bnmj.34asd 498 To: sip:alice@example.com;tag=12isjljn8 499 Call-ID: aiuy7k9njasd 500 CSeq: 1 REGISTER 501 Supported: outbound, gruu 502 Contact: 503 ;reg-id=1 504 ;+sip.instance="" 505 ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1" 506 ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr" 507 ;expires=3600 509 8.2. INVITE Dialog through a Proxy 510 Alice (SIP WSS) proxy.example.com (SIP UDP) Bob 511 | | | 512 |INVITE F1 | | 513 |---------------------------->| | 514 |100 Trying F2 | | 515 |<----------------------------| | 516 | |INVITE F3 | 517 | |---------------------------->| 518 | |200 OK F4 | 519 | |<----------------------------| 520 |200 OK F5 | | 521 |<----------------------------| | 522 | | | 523 |ACK F6 | | 524 |---------------------------->| | 525 | |ACK F7 | 526 | |---------------------------->| 527 | | | 528 | Bidirectional RTP Media | 529 |<=========================================================>| 530 | | | 531 | |BYE F8 | 532 | |<----------------------------| 533 |BYE F9 | | 534 |<----------------------------| | 535 |200 OK F10 | | 536 |---------------------------->| | 537 | |200 OK F11 | 538 | |---------------------------->| 539 | | | 541 In the same scenario Alice places a call to Bob's AoR (Address Of 542 Record). The SIP WebSocket Server at proxy.example.com acts as a SIP 543 proxy, routing the INVITE to Bob's contact address (which happens to 544 be using SIP transported over UDP). Bob answers the call and then 545 terminates it. 547 Message details (authentication and SDP bodies are omitted for 548 simplicity): 550 F1 INVITE Alice -> proxy.example.com (transport WSS) 552 INVITE sip:bob@example.com SIP/2.0 553 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 554 From: sip:alice@example.com;tag=asdyka899 555 To: sip:bob@example.com 556 Call-ID: asidkj3ss 557 CSeq: 1 INVITE 558 Max-Forwards: 70 559 Supported: path, outbound, gruu 560 Route: 561 Contact: 563 Content-Type: application/sdp 565 F2 100 Trying proxy.example.com -> Alice (transport WSS) 567 SIP/2.0 100 Trying 568 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 569 From: sip:alice@example.com;tag=asdyka899 570 To: sip:bob@example.com 571 Call-ID: asidkj3ss 572 CSeq: 1 INVITE 574 F3 INVITE proxy.example.com -> Bob (transport UDP) 576 INVITE sip:bob@203.0.113.22:5060 SIP/2.0 577 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 578 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 579 Record-Route: , 580 581 From: sip:alice@example.com;tag=asdyka899 582 To: sip:bob@example.com 583 Call-ID: asidkj3ss 584 CSeq: 1 INVITE 585 Max-Forwards: 69 586 Supported: path, outbound, gruu 587 Contact: 589 Content-Type: application/sdp 591 F4 200 OK Bob -> proxy.example.com (transport UDP) 593 SIP/2.0 200 OK 594 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 595 ;received=192.0.2.10 596 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 597 Record-Route: , 598 599 From: sip:alice@example.com;tag=asdyka899 600 To: sip:bob@example.com;tag=bmqkjhsd 601 Call-ID: asidkj3ss 602 CSeq: 1 INVITE 603 Contact: 604 Content-Type: application/sdp 606 F5 200 OK proxy.example.com -> Alice (transport WSS) 608 SIP/2.0 200 OK 609 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 610 Record-Route: , 611 612 From: sip:alice@example.com;tag=asdyka899 613 To: sip:bob@example.com;tag=bmqkjhsd 614 Call-ID: asidkj3ss 615 CSeq: 1 INVITE 616 Contact: 617 Content-Type: application/sdp 619 F6 ACK Alice -> proxy.example.com (transport WSS) 621 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 622 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 623 Route: , 624 , 625 From: sip:alice@example.com;tag=asdyka899 626 To: sip:bob@example.com;tag=bmqkjhsd 627 Call-ID: asidkj3ss 628 CSeq: 1 ACK 629 Max-Forwards: 70 631 F7 ACK proxy.example.com -> Bob (transport UDP) 633 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 634 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx 635 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 636 From: sip:alice@example.com;tag=asdyka899 637 To: sip:bob@example.com;tag=bmqkjhsd 638 Call-ID: asidkj3ss 639 CSeq: 1 ACK 640 Max-Forwards: 69 642 F8 BYE Bob -> proxy.example.com (transport UDP) 644 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 645 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 646 Route: , 647 648 From: sip:bob@example.com;tag=bmqkjhsd 649 To: sip:alice@example.com;tag=asdyka899 650 Call-ID: asidkj3ss 651 CSeq: 1201 BYE 652 Max-Forwards: 70 654 F9 BYE proxy.example.com -> Alice (transport WSS) 656 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 657 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 658 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 659 From: sip:bob@example.com;tag=bmqkjhsd 660 To: sip:alice@example.com;tag=asdyka899 661 Call-ID: asidkj3ss 662 CSeq: 1201 BYE 663 Max-Forwards: 69 665 F10 200 OK Alice -> proxy.example.com (transport WSS) 667 SIP/2.0 200 OK 668 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 669 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 670 From: sip:bob@example.com;tag=bmqkjhsd 671 To: sip:alice@example.com;tag=asdyka899 672 Call-ID: asidkj3ss 673 CSeq: 1201 BYE 675 F11 200 OK proxy.example.com -> Bob (transport UDP) 677 SIP/2.0 200 OK 678 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 679 From: sip:bob@example.com;tag=bmqkjhsd 680 To: sip:alice@example.com;tag=asdyka899 681 Call-ID: asidkj3ss 682 CSeq: 1201 BYE 684 9. Security Considerations 686 9.1. Secure WebSocket Connection 688 It is recommended that the SIP traffic transported over a WebSocket 689 communication be protected by using a secure WebSocket connection 690 (using TLS [RFC5246] over TCP). 692 When establishing a connection using SIP over secure WebSocket 693 transport, the client MUST authenticate the server using the server's 694 certificate according to the WebSocket validation procedure in 695 [RFC6455]. 697 Server operators should note that this authentication procedure is 698 different from the procedure for SIP Domain Certificates defined 699 in [RFC5922]. Certificates that are appropriate for SIP over TLS 700 over TCP will probably not be appropriate for SIP over secure 701 WebSocket connections. 703 9.2. Usage of SIPS Scheme 705 The SIPS scheme in a SIP URI dictates that the entire request path to 706 the target be secure. If such a path includes a WebSocket connection 707 it MUST be a secure WebSocket connection. 709 10. IANA Considerations 711 RFC Editor Note: Please set the RFC number assigned for this document 712 in the sub-sections below and remove this note. 714 10.1. Registration of the WebSocket SIP Sub-Protocol 716 This specification requests IANA to register the WebSocket SIP sub- 717 protocol under the "WebSocket Subprotocol Name" Registry with the 718 following data: 720 Subprotocol Identifier: sip 722 Subprotocol Common Name: WebSocket Transport for SIP (Session 723 Initiation Protocol) 725 Subprotocol Definition: TBD: this document 727 10.2. Registration of new NAPTR Service Field Values 729 This document defines two new NAPTR service field values (SIP+D2W and 730 SIPS+D2W) and requests IANA to register these values under the 731 "Registry for the Session Initiation Protocol (SIP) NAPTR Resource 732 Record Services Field". The resulting entries are as follows: 734 Services Field Protocol Reference 735 -------------- -------- --------- 736 SIP+D2W WS TBD: this document 737 SIPS+D2W WS TBD: this document 739 10.3. SIP/SIPS URI Parameters Sub-Registry 741 This specification requests IANA to add a reference to this document 742 under the "SIP/SIPS URI Parameters" Sub-Registry within the "Session 743 Initiation Protocol (SIP) Parameters" Registry: 745 Parameter Name Predefined Values Reference 746 -------------- ----------------- --------- 747 transport Yes [RFC3261][TBD: this document] 749 10.4. Header Fields Sub-Registry 751 This specification requests IANA to add a reference to this document 752 under the "Header Fields" Sub-Registry within the "Session Initiation 753 Protocol (SIP) Parameters" Registry: 755 Header Name compact Reference 756 ----------- ------- --------- 757 Via v [RFC3261][TBD: this document] 759 10.5. Header Field Parameters and Parameter Values Sub-Registry 761 This specification requests IANA to add a reference to this document 762 under the "Header Field Parameters and Parameter Values" Sub-Registry 763 within the "Session Initiation Protocol (SIP) Parameters" Registry: 765 Predefined 766 Header Field Parameter Name Values Reference 767 ------------ -------------- ------ --------- 768 Via received No [RFC3261][TBD: this document] 770 10.6. SIP Transport Sub-Registry 772 This document adds a new registry, "SIP Transport", to the "Session 773 Initiation Protocol (SIP) Parameters" Registry. Its format and 774 initial values are as shown in the following table: 776 +------------+------------------------+ 777 | Transport | Reference | 778 +------------+------------------------+ 779 | UDP | [RFC 3261] | 780 | TCP | [RFC 3261] | 781 | TLS | [RFC 3261] | 782 | SCTP | [RFC 3261], [RFC 4168] | 783 | TLS-SCTP | [RFC 4168] | 784 | WS | [TBD: this document] | 785 | WSS | [TBD: this document] | 786 +------------+------------------------+ 788 The policy for registration of values in this registry is "Standards 789 Action", as that term is defined by [RFC5226]. 791 11. Acknowledgements 793 Special thanks to the following people who participated in 794 discussions on the SIPCORE and RTCWEB WG mailing lists and 795 contributed ideas and/or provided detailed reviews (the list is 796 likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Robert 797 Sparks, Adam Roach, Ranjit Avasarala, Xavier Marjou, Nataraju A. B., 798 Martin Vopatek, Alexey Melnikov, Alan Johnston, Christer Holmberg, 799 Salvatore Loreto, Kevin P. Fleming, Suresh Krishnan, Yaron Sheffer, 800 Richard Barnes, Barry Leiba, Saul Ibarra Corretge. 802 12. References 804 12.1. Normative References 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 830 RFC 6455, December 2011. 832 12.2. Informative References 834 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 835 Names", BCP 32, RFC 2606, June 1999. 837 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 838 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 839 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 841 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 842 (SIP) Extension Header Field for Registering Non-Adjacent 843 Contacts", RFC 3327, December 2002. 845 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 846 Resource Identifier (URI): Generic Syntax", STD 66, 847 RFC 3986, January 2005. 849 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 850 Stream Control Transmission Protocol (SCTP) as a Transport 851 for the Session Initiation Protocol (SIP)", RFC 4168, 852 October 2005. 854 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 855 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 857 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 858 Initiated Connections in the Session Initiation Protocol 859 (SIP)", RFC 5626, October 2009. 861 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 862 Agent URIs (GRUUs) in the Session Initiation Protocol 863 (SIP)", RFC 5627, October 2009. 865 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 866 Certificates in the Session Initiation Protocol (SIP)", 867 RFC 5922, June 2010. 869 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 870 RFC 6223, April 2011. 872 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 873 April 2011. 875 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", April 2013. 877 Appendix A. Authentication Use Cases 879 _This section is non-normative._ 881 Sections below briefly describe some SIP over WebSocket scenarios in 882 which authentication take place in different ways. 884 A.1. Just SIP Authentication 886 SIP PBX model A implements the SIP WebSocket transport defined by 887 this specification. Its implementation is 100% website agnostic as 888 it does not share information with the web server providing the HTML 889 code to browsers, meaning that the SIP WebSocket Server (here the PBX 890 model A) has no knowledge about web login activity within the 891 website. 893 In this simple scenario, the SIP WebSocket Server does not inspect 894 fields in the WebSocket handshake HTTP GET request such as the 895 request URL, the Origin header value, the Host header value or the 896 Cookie header value (if present). However some of those fields could 897 be inspected for a minimal validation (i.e. PBX model A could 898 require that the Origin header value contains a specific URL so just 899 users navigating such a website would be able to establish a 900 WebSocket connection with PBX model A). 902 Once the WebSocket connection has been established, SIP 903 authentication is requested by PBX model A for each SIP request 904 coming over that connection. Therefore SIP WebSocket Clients must be 905 provisioned with their corresponding SIP password. 907 A.2. Just Web Authentication 909 A SIP-to-PSTN provider offers telephony service for clients logged 910 into its website. The provider does not want to expose SIP passwords 911 into the web for security/privacy reasons. 913 Once the user is logged into the web, the web server provides him 914 with a SIP identity (SIP URI) and a session temporary token string 915 (along with the SIP WebSocket Client JavaScript application and SIP 916 settings). The web server stores the SIP identity and session token 917 into a database. 919 The web application adds the SIP identity and session token as URL 920 query parameters in the WebSocket handshake request and attempts the 921 connection. The SIP WebSocket Server inspects the handshake request 922 and validates that the session token matches the value stored in the 923 database for the given SIP identity. In case the value matches, the 924 WebSocket connection gets "authenticated" for that SIP identity. The 925 SIP WebSocket Client can then register and make calls. The SIP 926 WebSocket Server would however verify that the identity in those SIP 927 requests (i.e. the From URI value) matches the SIP identity the 928 WebSocket connection is associated to (otherwise the SIP request is 929 rejected). 931 When the user performs logout action in the web, the web server 932 removes the SIP identity and session token tuple from the database 933 and notifies it to the SIP WebSocket Server which revokes and closes 934 the WebSocket connection. 936 No SIP authentication takes place in this scenario. 938 A.3. Cookie Based Authentication 940 Apache web server comes with a new module mod_sip_websocket. The web 941 server is configured to listen in port 80 for both HTTP common 942 requests and WebSocket handshake requests. Therefore both the web 943 server and the SIP WebSocket Server are co-located within the same 944 host and same domain. 946 Once the user is logged into the web, he is provided with the SIP 947 WebSocket Client JavaScript application and SIP settings. The HTTP 948 200 response after the login procedure also contains a session Cookie 949 [RFC6265]. The web application attempts then a WebSocket connection 950 against the same URL/domain of the website and thus, the session 951 Cookie is automatically added by the browser into the WebSocket 952 handshake request (as the WebSocket protocol [RFC6455] states). 954 The web server inspects the Cookie value (as it would do for a common 955 HTTP request containing a session Cookie, so login procedure is not 956 required again). If the Cookie is valid the WebSocket connection is 957 authorized and, as in the previous use case, the connection is also 958 associated with a specific SIP identity which must be satisfied by 959 every SIP request coming over that connection. 961 No SIP authentication takes place in this scenario but just common 962 Cookie usage as widely deployed in the WWW. 964 Appendix B. Implementation Guidelines 966 _This section is non-normative._ 968 Let us assume a scenario in which the users access with their web 969 browsers (probably behind NAT) an application provided by a server on 970 an intranet, login by entering their user identifier and credentials, 971 and retrieve a JavaScript application (along with the HTML) 972 implementing a SIP WebSocket Client. 974 Such a SIP stack connects to a given SIP WebSocket Server (an 975 outbound SIP proxy which also implements classic SIP transports such 976 as UDP and TCP). The HTTP GET method request sent by the web browser 977 for the WebSocket handshake includes a Cookie [RFC6265] header with 978 the value previously provided by the server after the successful 979 login procedure. The Cookie value is then inspected by the WebSocket 980 server to authorize the connection. Once the WebSocket connection is 981 established, the SIP WebSocket Client performs a SIP registration to 982 a SIP registrar server that is reachable through the proxy. After 983 registration, the SIP WebSocket Client and Server exchange SIP 984 messages as would normally be expected. 986 This scenario is quite similar to ones in which SIP UAs behind NATs 987 connect to a proxy and must reuse the same TCP connection for 988 incoming requests (because they are not directly reachable by the 989 proxy otherwise). In both cases, the SIP UAs are only reachable 990 through the proxy they are connected to. 992 The SIP Outbound extension [RFC5626] seems an appropriate solution 993 for this scenario. Therefore these SIP WebSocket Clients and the SIP 994 registrar implement both the Outbound and Path [RFC3327] extensions, 995 and the SIP proxy acts as an Outbound Edge Proxy (as defined in 996 [RFC5626] section 3.4). 998 SIP WebSocket Clients in this scenario receive incoming SIP requests 999 via the SIP WebSocket Server they are connected to. Therefore, in 1000 some call transfer cases the usage of GRUU [RFC5627] (which should be 1001 implemented in both the SIP WebSocket Clients and SIP registrar) is 1002 valuable. 1004 If a REFER request is sent to a third SIP user agent including the 1005 Contact URI of a SIP WebSocket Client as the target in its 1006 Refer-To header field, such a URI will be reachable by the third 1007 SIP UA only if it is a globally routable URI. GRUU (Globally 1008 Routable User Agent URI) is a solution for those scenarios, and 1009 would cause the incoming request from the third SIP user agent to 1010 be sent to the SIP registrar, which would route the request to the 1011 SIP WebSocket Client via the Outbound Edge Proxy. 1013 B.1. SIP WebSocket Client Considerations 1015 The JavaScript stack in web browsers does not have the ability to 1016 discover the local transport address used for originating WebSocket 1017 connections. A SIP WebSocket client running in such an environment 1018 can construct a domain name consisting of a random token followed by 1019 the ".invalid" top-level domain name, as stated in [RFC2606], and 1020 uses it within its Via and Contact headers. 1022 The Contact URI provided by SIP UAs requesting (and receiving) 1023 Outbound support is not used for routing requests to those UAs, 1024 thus it is safe to set a random domain in the Contact URI 1025 hostport. 1027 Both the Outbound and GRUU specifications require a SIP UA to include 1028 a Uniform Resource Name (URN) in a "+sip.instance" parameter of the 1029 Contact header they include their SIP REGISTER requests. The client 1030 device is responsible for generating or collecting a suitable value 1031 for this purpose. 1033 In web browsers it is difficult to generate or collect a suitable 1034 value to be used as a URN value from the browser itself. This 1035 scenario suggests that value is generated according to [RFC5626] 1036 section 4.1 by the web application running in the browser the 1037 first time it loads the JavaScript SIP stack code, and then it is 1038 stored as a Cookie within the browser. 1040 B.2. SIP WebSocket Server Considerations 1042 The SIP WebSocket Server in this scenario behaves as a SIP Outbound 1043 Edge Proxy, which involves support for Outbound [RFC5626] and Path 1044 [RFC3327]. 1046 The proxy performs Loose Routing and remains in the path of dialogs 1047 as specified in [RFC3261]. If it did not do this, in-dialog requests 1048 would fail since SIP WebSocket Clients make use of their SIP 1049 WebSocket Server in order to send and receive SIP messages. 1051 Authors' Addresses 1053 Inaki Baz Castillo 1054 Versatica 1055 Barakaldo, Basque Country 1056 Spain 1058 Email: ibc@aliax.net 1059 Jose Luis Millan Villegas 1060 Versatica 1061 Bilbao, Basque Country 1062 Spain 1064 Email: jmillan@aliax.net 1066 Victor Pascual 1067 Acme Packet 1068 Anabel Segura 10 1069 Madrid, Madrid 28108 1070 Spain 1072 Email: vpascual@acmepacket.com