idnits 2.17.1 draft-ietf-sipcore-sip-websocket-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 445 has weird spacing: '...otocols proxy...' == Line 539 has weird spacing: '... Trying proxy...' == Line 725 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 (March 11, 2013) is 4063 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 752, but not defined == Missing Reference: 'RFC 4168' is mentioned on line 753, 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 (~~), 6 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: September 12, 2013 Acme Packet 7 March 11, 2013 9 The WebSocket Protocol as a Transport for the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-sip-websocket-08 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 September 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 4 60 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 61 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 64 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6 66 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6 67 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6 68 5.2.3. Via received parameter . . . . . . . . . . . . . . . . 7 69 5.2.4. SIP transport implementation requirements . . . . . . 7 70 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8 71 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8 72 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 78 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16 81 10.2. Registration of new NAPTR service field values . . . . . . 16 82 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 17 83 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17 84 10.5. Header Field Parameters and Parameter Values 85 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17 86 10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 17 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 20 92 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 21 93 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 The WebSocket [RFC6455] protocol enables message exchange between 99 clients and servers on top of a persistent TCP connection (optionally 100 secured with TLS [RFC5246]). The initial protocol handshake makes 101 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 102 reuse existing HTTP infrastructure. 104 Modern web browsers include a WebSocket client stack complying with 105 the WebSocket API [WS-API] as specified by the W3C. It is expected 106 that other client applications (those running in personal computers 107 and devices such as smartphones) will also make a WebSocket client 108 stack available. The specification in this document enables usage of 109 SIP in these scenarios. 111 This specification defines a WebSocket sub-protocol (as defined in 112 section 1.9 in [RFC6455]) for transporting SIP messages between a 113 WebSocket client and server, a reliable and message-boundary 114 preserving transport for SIP, DNS NAPTR [RFC3403] service values and 115 procedures for SIP entities implementing the WebSocket transport. 116 Media transport is out of the scope of this document. 118 Section 3 in this specification relaxes the requirement in [RFC3261] 119 by which the SIP server transport MUST add a "received" parameter in 120 the top Via header in certain circumstances. 122 2. Terminology 124 All diagrams, examples, and notes in this specification are non- 125 normative, as are all sections explicitly marked non-normative. 126 Everything else in this specification is normative. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2.1. Definitions 134 SIP WebSocket Client: A SIP entity capable of opening outbound 135 connections to WebSocket servers and communicating using the 136 WebSocket SIP sub-protocol as defined by this document. 138 SIP WebSocket Server: A SIP entity capable of listening for inbound 139 connections from WebSocket clients and communicating using the 140 WebSocket SIP sub-protocol as defined by this document. 142 3. The WebSocket Protocol 144 _This section is non-normative._ 146 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 147 (optionally secured with TLS [RFC5246]) in which both client and 148 server exchange message units in both directions. The protocol 149 defines a connection handshake, WebSocket sub-protocol and extensions 150 negotiation, a frame format for sending application and control data, 151 a masking mechanism, and status codes for indicating disconnection 152 causes. 154 The WebSocket connection handshake is based on HTTP [RFC2616] and 155 utilizes the HTTP GET method with an "Upgrade" request. This is sent 156 by the client and then answered by the server (if the negotiation 157 succeeded) with an HTTP 101 status code. Once the handshake is 158 completed the connection upgrades from HTTP to the WebSocket 159 protocol. This handshake procedure is designed to reuse the existing 160 HTTP infrastructure. During the connection handshake, client and 161 server agree on the application protocol to use on top of the 162 WebSocket transport. Such application protocol (also known as a 163 "WebSocket sub-protocol") defines the format and semantics of the 164 messages exchanged by the endpoints. This could be a custom protocol 165 or a standardized one (as the WebSocket SIP sub-protocol defined in 166 this document). Once the HTTP 101 response is processed both client 167 and server reuse the underlying TCP connection for sending WebSocket 168 messages and control frames to each other. Unlike plain HTTP, this 169 connection is persistent and can be used for multiple message 170 exchanges. 172 WebSocket defines message units to be used by applications for the 173 exchange of data, so it provides a message boundary-preserving 174 transport layer. These message units can contain either UTF-8 text 175 or binary data, and can be split into multiple WebSocket text/binary 176 transport frames as needed by the WebSocket stack. 178 The WebSocket API [WS-API] for web browsers only defines callbacks 179 to be invoked upon receipt of an entire message unit, regardless 180 of whether it was received in a single Websocket frame or split 181 across multiple frames. 183 4. The WebSocket SIP Sub-Protocol 185 The term WebSocket sub-protocol refers to an application-level 186 protocol layered on top of a WebSocket connection. This document 187 specifies the WebSocket SIP sub-protocol for carrying SIP requests 188 and responses through a WebSocket connection. 190 4.1. Handshake 192 The SIP WebSocket Client and SIP WebSocket Server negotiate usage of 193 the WebSocket SIP sub-protocol during the WebSocket handshake 194 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 195 include the value "sip" in the Sec-WebSocket-Protocol header in its 196 handshake request. The 101 reply from the Server MUST contain "sip" 197 in its corresponding Sec-WebSocket-Protocol header. 199 Below is an example of a WebSocket handshake in which the Client 200 requests the WebSocket SIP sub-protocol support from the Server: 202 GET / HTTP/1.1 203 Host: sip-ws.example.com 204 Upgrade: websocket 205 Connection: Upgrade 206 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 207 Origin: http://www.example.com 208 Sec-WebSocket-Protocol: sip 209 Sec-WebSocket-Version: 13 211 The handshake response from the Server accepting the WebSocket SIP 212 sub-protocol would look as follows: 214 HTTP/1.1 101 Switching Protocols 215 Upgrade: websocket 216 Connection: Upgrade 217 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 218 Sec-WebSocket-Protocol: sip 220 Once the negotiation has been completed, the WebSocket connection is 221 established and can be used for the transport of SIP requests and 222 responses. The WebSocket messages transmitted over this connection 223 MUST conform to the negotiated WebSocket sub-protocol. 225 4.2. SIP encoding 227 WebSocket messages can be transported in either UTF-8 text frames or 228 binary frames. SIP [RFC3261] allows both text and binary bodies in 229 SIP requests and responses. Therefore SIP WebSocket Clients and SIP 230 WebSocket Servers MUST accept both text and binary frames. 232 5. SIP WebSocket Transport 233 5.1. General 235 WebSocket [RFC6455] is a reliable protocol and therefore the SIP 236 WebSocket sub-protocol defined by this document is a reliable SIP 237 transport. Thus, client and server transactions using WebSocket for 238 transport MUST follow the procedures and timer values for reliable 239 transports as defined in [RFC3261]. 241 Each SIP message MUST be carried within a single WebSocket message, 242 and a WebSocket message MUST NOT contain more than one SIP message. 243 Because the WebSocket transport preserves message boundaries, the use 244 of the Content-Length header in SIP messages is optional when they 245 are transported using the WebSocket sub-protocol. 247 This simplifies parsing of SIP messages for both clients and 248 servers. There is no need to establish message boundaries using 249 Content-Length headers between messages. Other SIP transports, 250 such as UDP and SCTP [RFC4168] also provide this benefit. 252 5.2. Updates to RFC 3261 254 5.2.1. Via Transport Parameter 256 Via header fields in SIP messages carry a transport protocol 257 identifier. This document defines the value "WS" to be used for 258 requests over plain WebSocket connections and "WSS" for requests over 259 secure WebSocket connections (in which the WebSocket connection is 260 established using TLS [RFC5246] with TCP transport). 262 The updated augmented BNF (Backus-Naur Form) [RFC5234] for this 263 parameter is the following (the original BNF for this parameter can 264 be found in [RFC3261], which was then updated by [RFC4168]): 266 transport =/ "WS" / "WSS" 268 5.2.2. SIP URI Transport Parameter 270 This document defines the value "ws" as the transport parameter value 271 for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub- 272 protocol as transport. 274 The updated augmented BNF (Backus-Naur Form) for this parameter is 275 the following (the original BNF for this parameter can be found in 276 [RFC3261], which was then updated by [RFC4168]): 278 transport-param =/ "transport=" "ws" 280 5.2.3. Via received parameter 282 [RFC3261] section 18.2.1 "Receiving Requests" states the following: 284 When the server transport receives a request over any transport, 285 it MUST examine the value of the "sent-by" parameter in the top 286 Via header field value. If the host portion of the "sent-by" 287 field contains a domain name, or if it contains an IP address that 288 differs from the packet source address, the server MUST add a 289 "received" parameter to that Via header field value. This 290 parameter MUST contain the source address from which the packet 291 was received. 293 The requirement of adding the "received" parameter does not fit well 294 into the WebSocket protocol design. The WebSocket connection 295 handshake reuses existing HTTP infrastructure in which there could be 296 an unknown number of HTTP proxies and/or TCP load balancers between 297 the SIP WebSocket Client and Server, so the source address the server 298 would write into the Via "received" parameter would be the address of 299 the HTTP/TCP intermediary in front of it. This could reveal 300 sensitive information about the internal topology of the Server's 301 network to the Client. 303 Given the fact that SIP responses can only be sent over the existing 304 WebSocket connection, the Via "received" parameter is of little use. 305 Therefore, in order to allow hiding possible sensitive information 306 about the SIP WebSocket Server's network, this document updates 307 [RFC3261] section 18.2.1 by stating: 309 When a SIP WebSocket Server receives a request it MAY decide not 310 to add a "received" parameter to the top Via header. Therefore 311 SIP WebSocket Clients MUST accept responses without such a 312 parameter in the top Via header regardless of whether the Via 313 "sent-by" field contains a domain name. 315 5.2.4. SIP transport implementation requirements 317 [RFC3261] section 18 "Transport" states the following: 319 All SIP elements MUST implement UDP and TCP. SIP elements MAY 320 implement other protocols. 322 The specification of this transport enables SIP to be used as a 323 session establishment protocol in scenarios where none of other 324 transport protocols defined for SIP can be used. Since some 325 environments do not enable SIP elements to use UDP and TCP as SIP 326 transport protocols, a SIP element acting as a SIP WebSocket Client 327 is not mandated to implement support of UDP and TCP and thus MAY just 328 implement the WebSocket transport defined by this specification. 330 5.3. Locating a SIP Server 332 [RFC3263] specifies the procedures which should be followed by SIP 333 entities for locating SIP servers. This specification defines the 334 NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support 335 plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers 336 that support secure WebSocket connections. 338 At the time this document was written, DNS NAPTR/SRV queries could 339 not be performed by commonly available WebSocket client stacks (in 340 JavaScript engines and web browsers). 342 In the absence of DNS SRV resource records or an explicit port, the 343 default port for a SIP URI using the "sip" scheme and the "ws" 344 transport parameter is 80, and the default port for a SIP URI using 345 the "sips" scheme and the "ws" transport parameter is 443. 347 6. Connection Keep-Alive 349 _This section is non-normative._ 351 SIP WebSocket Clients and Servers may keep their WebSocket 352 connections open by sending periodic WebSocket "Ping" frames as 353 described in [RFC6455] section 5.5.2. 355 The WebSocket API [WS-API] does not provide a mechanism for 356 applications running in a web browser to control whether or not 357 periodic WebSocket "Ping" frames are sent to the server. The 358 implementation of such a keep-alive feature is the decision of 359 each web browser manufacturer and may also depend on the 360 configuration of the web browser. 362 The indication and use of the CRLF NAT keep-alive mechanism defined 363 for SIP connection-oriented transports in [RFC5626] section 3.5.1 or 364 [RFC6223] are, of course, usable over the transport defined in this 365 specification. 367 7. Authentication 369 _This section is non-normative._ 371 This section describes how authentication is achieved through the 372 requirements in [RFC6455], [RFC6265] and [RFC3261]. 374 Prior to sending SIP requests, a SIP WebSocket Client connects to a 375 SIP WebSocket Server and performs the connection handshake. As 376 described in Section 3 the handshake procedure involves a HTTP GET 377 method request from the Client and a response from the Server 378 including an HTTP 101 status code. 380 In order to authorize the WebSocket connection, the SIP WebSocket 381 Server is allowed to inspect any Cookie [RFC6265] headers present in 382 the HTTP GET request. For many web applications the value of such a 383 Cookie is provided by the web server once the user has authenticated 384 themselves to the web server, which could be done by many existing 385 mechanisms. As an alternative method, the SIP WebSocket Server could 386 request HTTP authentication by replying to the Client's GET method 387 request with a HTTP 401 status code. The WebSocket protocol 388 [RFC6455] covers this usage in section 4.1: 390 If the status code received from the server is not 101, the 391 WebSocket client stack handles the response per HTTP [RFC2616] 392 procedures, in particular the client might perform authentication 393 if it receives 401 status code. 395 Regardless of whether the SIP WebSocket Server requires 396 authentication during the WebSocket handshake, authentication can be 397 requested at SIP protocol level. Note that RFC 3261 requires that 398 all SIP implementations (which includes implementations of this 399 specification) implement Digest Authorization ([RFC3261] section 400 26.3.1). 402 8. Examples 404 8.1. Registration 406 Alice (SIP WSS) proxy.example.com 407 | | 408 |HTTP GET (WS handshake) F1 | 409 |---------------------------->| 410 |101 Switching Protocols F2 | 411 |<----------------------------| 412 | | 413 |REGISTER F3 | 414 |---------------------------->| 415 |200 OK F4 | 416 |<----------------------------| 417 | | 419 Alice loads a web page using her web browser and retrieves JavaScript 420 code implementing the WebSocket SIP sub-protocol defined in this 421 document. The JavaScript code (a SIP WebSocket Client) establishes a 422 secure WebSocket connection with a SIP proxy/registrar (a SIP 423 WebSocket Server) at proxy.example.com. Upon WebSocket connection, 424 Alice constructs and sends a SIP REGISTER request including Outbound 425 and GRUU support. Since the JavaScript stack in a browser has no way 426 to determine the local address from which the WebSocket connection 427 was made, this implementation uses a random ".invalid" domain name 428 for the Via header sent-by parameter and for the hostport of the URI 429 in the Contact header (see Appendix A.1). 431 Message details (authentication and SDP bodies are omitted for 432 simplicity): 434 F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS) 436 GET / HTTP/1.1 437 Host: proxy.example.com 438 Upgrade: websocket 439 Connection: Upgrade 440 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 441 Origin: https://www.example.com 442 Sec-WebSocket-Protocol: sip 443 Sec-WebSocket-Version: 13 445 F2 101 Switching Protocols proxy.example.com -> Alice (TLS) 447 HTTP/1.1 101 Switching Protocols 448 Upgrade: websocket 449 Connection: Upgrade 450 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 451 Sec-WebSocket-Protocol: sip 453 F3 REGISTER Alice -> proxy.example.com (transport WSS) 455 REGISTER sip:proxy.example.com SIP/2.0 456 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 457 From: sip:alice@example.com;tag=65bnmj.34asd 458 To: sip:alice@example.com 459 Call-ID: aiuy7k9njasd 460 CSeq: 1 REGISTER 461 Max-Forwards: 70 462 Supported: path, outbound, gruu 463 Contact: 464 ;reg-id=1 465 ;+sip.instance="" 467 F4 200 OK proxy.example.com -> Alice (transport WSS) 469 SIP/2.0 200 OK 470 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 471 From: sip:alice@example.com;tag=65bnmj.34asd 472 To: sip:alice@example.com;tag=12isjljn8 473 Call-ID: aiuy7k9njasd 474 CSeq: 1 REGISTER 475 Supported: outbound, gruu 476 Contact: 477 ;reg-id=1 478 ;+sip.instance="" 479 ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1" 480 ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr" 481 ;expires=3600 483 8.2. INVITE dialog through a proxy 484 Alice (SIP WSS) proxy.example.com (SIP UDP) Bob 485 | | | 486 |INVITE F1 | | 487 |---------------------------->| | 488 |100 Trying F2 | | 489 |<----------------------------| | 490 | |INVITE F3 | 491 | |---------------------------->| 492 | |200 OK F4 | 493 | |<----------------------------| 494 |200 OK F5 | | 495 |<----------------------------| | 496 | | | 497 |ACK F6 | | 498 |---------------------------->| | 499 | |ACK F7 | 500 | |---------------------------->| 501 | | | 502 | Bidirectional RTP Media | 503 |<=========================================================>| 504 | | | 505 | |BYE F8 | 506 | |<----------------------------| 507 |BYE F9 | | 508 |<----------------------------| | 509 |200 OK F10 | | 510 |---------------------------->| | 511 | |200 OK F11 | 512 | |---------------------------->| 513 | | | 515 In the same scenario Alice places a call to Bob's AoR (Address Of 516 Record). The SIP WebSocket Server at proxy.example.com acts as a SIP 517 proxy, routing the INVITE to Bob's contact address (which happens to 518 be using SIP transported over UDP). Bob answers the call and then 519 terminates it. 521 Message details (authentication and SDP bodies are omitted for 522 simplicity): 524 F1 INVITE Alice -> proxy.example.com (transport WSS) 526 INVITE sip:bob@example.com SIP/2.0 527 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 528 From: sip:alice@example.com;tag=asdyka899 529 To: sip:bob@example.com 530 Call-ID: asidkj3ss 531 CSeq: 1 INVITE 532 Max-Forwards: 70 533 Supported: path, outbound, gruu 534 Route: 535 Contact: 537 Content-Type: application/sdp 539 F2 100 Trying proxy.example.com -> Alice (transport WSS) 541 SIP/2.0 100 Trying 542 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 543 From: sip:alice@example.com;tag=asdyka899 544 To: sip:bob@example.com 545 Call-ID: asidkj3ss 546 CSeq: 1 INVITE 548 F3 INVITE proxy.example.com -> Bob (transport UDP) 550 INVITE sip:bob@203.0.113.22:5060 SIP/2.0 551 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 552 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 553 Record-Route: , 554 555 From: sip:alice@example.com;tag=asdyka899 556 To: sip:bob@example.com 557 Call-ID: asidkj3ss 558 CSeq: 1 INVITE 559 Max-Forwards: 69 560 Supported: path, outbound, gruu 561 Contact: 563 Content-Type: application/sdp 565 F4 200 OK Bob -> proxy.example.com (transport UDP) 567 SIP/2.0 200 OK 568 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 569 ;received=192.0.2.10 570 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 571 Record-Route: , 572 573 From: sip:alice@example.com;tag=asdyka899 574 To: sip:bob@example.com;tag=bmqkjhsd 575 Call-ID: asidkj3ss 576 CSeq: 1 INVITE 577 Contact: 578 Content-Type: application/sdp 580 F5 200 OK proxy.example.com -> Alice (transport WSS) 582 SIP/2.0 200 OK 583 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 584 Record-Route: , 585 586 From: sip:alice@example.com;tag=asdyka899 587 To: sip:bob@example.com;tag=bmqkjhsd 588 Call-ID: asidkj3ss 589 CSeq: 1 INVITE 590 Contact: 591 Content-Type: application/sdp 593 F6 ACK Alice -> proxy.example.com (transport WSS) 595 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 596 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 597 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 ACK 603 Max-Forwards: 70 605 F7 ACK proxy.example.com -> Bob (transport UDP) 607 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 608 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx 609 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 610 From: sip:alice@example.com;tag=asdyka899 611 To: sip:bob@example.com;tag=bmqkjhsd 612 Call-ID: asidkj3ss 613 CSeq: 1 ACK 614 Max-Forwards: 69 616 F8 BYE Bob -> proxy.example.com (transport UDP) 618 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 619 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 620 Route: , 621 622 From: sip:bob@example.com;tag=bmqkjhsd 623 To: sip:alice@example.com;tag=asdyka899 624 Call-ID: asidkj3ss 625 CSeq: 1201 BYE 626 Max-Forwards: 70 628 F9 BYE proxy.example.com -> Alice (transport WSS) 630 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 631 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 632 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 633 From: sip:bob@example.com;tag=bmqkjhsd 634 To: sip:alice@example.com;tag=asdyka899 635 Call-ID: asidkj3ss 636 CSeq: 1201 BYE 637 Max-Forwards: 69 639 F10 200 OK Alice -> proxy.example.com (transport WSS) 641 SIP/2.0 200 OK 642 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 643 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 644 From: sip:bob@example.com;tag=bmqkjhsd 645 To: sip:alice@example.com;tag=asdyka899 646 Call-ID: asidkj3ss 647 CSeq: 1201 BYE 649 F11 200 OK proxy.example.com -> Bob (transport UDP) 651 SIP/2.0 200 OK 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 658 9. Security Considerations 660 9.1. Secure WebSocket Connection 662 It is recommended that the SIP traffic transported over a WebSocket 663 communication be protected by using a secure WebSocket connection 664 (using TLS [RFC5246] over TCP). 666 However none of the SIP TLS certificate checks specified in [RFC3261] 667 or [RFC5922] will be made when using SIP over secure WebSocket 668 transport. Instead, only the checks specified by [RFC6455] will be 669 made. The certificates that are appropriate for SIP over TLS over 670 TCP will probably not be appropriate for SIP over secure WebSocket 671 connections. 673 9.2. Usage of SIPS Scheme 675 The SIPS scheme in a SIP URI dictates that the entire request path to 676 the target be secure. If such a path includes a WebSocket connection 677 it MUST be a secure WebSocket connection. 679 10. IANA Considerations 681 RFC Editor Note: Please set the RFC number assigned for this document 682 in the sub-sections below and remove this note. 684 10.1. Registration of the WebSocket SIP Sub-Protocol 686 This specification requests IANA to register the WebSocket SIP sub- 687 protocol under the "WebSocket Subprotocol Name" Registry with the 688 following data: 690 Subprotocol Identifier: sip 692 Subprotocol Common Name: WebSocket Transport for SIP (Session 693 Initiation Protocol) 695 Subprotocol Definition: TBD: this document 697 10.2. Registration of new NAPTR service field values 699 This document defines two new NAPTR service field values (SIP+D2W and 700 SIPS+D2W) and requests IANA to register these values under the 701 "Registry for the Session Initiation Protocol (SIP) NAPTR Resource 702 Record Services Field". The resulting entries are as follows: 704 Services Field Protocol Reference 705 -------------- -------- --------- 706 SIP+D2W WS TBD: this document 707 SIPS+D2W WS TBD: this document 709 10.3. SIP/SIPS URI Parameters Sub-Registry 711 This specification requests IANA to add a reference to this document 712 under the "SIP/SIPS URI Parameters" Sub-Registry within the "Session 713 Initiation Protocol (SIP) Parameters" Registry: 715 Parameter Name Predefined Values Reference 716 -------------- ----------------- --------- 717 transport Yes [RFC3261][TBD: this document] 719 10.4. Header Fields Sub-Registry 721 This specification requests IANA to add a reference to this document 722 under the "Header Fields" Sub-Registry within the "Session Initiation 723 Protocol (SIP) Parameters" Registry: 725 Header Name compact Reference 726 ----------- ------- --------- 727 Via v [RFC3261][TBD: this document] 729 10.5. Header Field Parameters and Parameter Values Sub-Registry 731 This specification requests IANA to add a reference to this document 732 under the "Header Field Parameters and Parameter Values" Sub-Registry 733 within the "Session Initiation Protocol (SIP) Parameters" Registry: 735 Predefined 736 Header Field Parameter Name Values Reference 737 ------------ -------------- ------ --------- 738 Via received No [RFC3261][TBD: this document] 740 10.6. SIP Transport Sub-Registry 742 This document adds a new registry, "SIP Transport", to the "Session 743 Initiation Protocol (SIP) Parameters" Registry. Its format and 744 initial values are as shown in the following table: 746 +------------+------------------------+ 747 | Transport | Reference | 748 +------------+------------------------+ 749 | UDP | [RFC 3261] | 750 | TCP | [RFC 3261] | 751 | TLS | [RFC 3261] | 752 | SCTP | [RFC 3261], [RFC 4168] | 753 | TLS-SCTP | [RFC 4168] | 754 | WS | [TBD: this document] | 755 | WSS | [TBD: this document] | 756 +------------+------------------------+ 757 The policy for registration of values in this registry is "Standards 758 Action", as that term is defined by [RFC5226]. 760 11. Acknowledgements 762 Special thanks to the following people who participated in 763 discussions on the SIPCORE and RTCWEB WG mailing lists and 764 contributed ideas and/or provided detailed reviews (the list is 765 likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Robert 766 Sparks, Adam Roach, Ranjit Avasarala, Xavier Marjou, Nataraju A. B., 767 Martin Vopatek, Alexey Melnikov, Alan Johnston, Christer Holmberg, 768 Salvatore Loreto, Kevin P. Fleming (complete grammatical review), 769 Saul Ibarra Corretge. 771 12. References 773 12.1. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, March 1997. 778 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 779 A., Peterson, J., Sparks, R., Handley, M., and E. 780 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 781 June 2002. 783 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 784 Protocol (SIP): Locating SIP Servers", RFC 3263, 785 June 2002. 787 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 788 Part Three: The Domain Name System (DNS) Database", 789 RFC 3403, October 2002. 791 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 792 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 793 May 2008. 795 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 796 Specifications: ABNF", STD 68, RFC 5234, January 2008. 798 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 799 RFC 6455, December 2011. 801 12.2. Informative References 803 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 804 Names", BCP 32, RFC 2606, June 1999. 806 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 807 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 808 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 810 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 811 (SIP) Extension Header Field for Registering Non-Adjacent 812 Contacts", RFC 3327, December 2002. 814 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 815 Resource Identifier (URI): Generic Syntax", STD 66, 816 RFC 3986, January 2005. 818 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 819 Stream Control Transmission Protocol (SCTP) as a Transport 820 for the Session Initiation Protocol (SIP)", RFC 4168, 821 October 2005. 823 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 824 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 826 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 827 Initiated Connections in the Session Initiation Protocol 828 (SIP)", RFC 5626, October 2009. 830 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 831 Agent URIs (GRUUs) in the Session Initiation Protocol 832 (SIP)", RFC 5627, October 2009. 834 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 835 Certificates in the Session Initiation Protocol (SIP)", 836 RFC 5922, June 2010. 838 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 839 RFC 6223, April 2011. 841 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 842 April 2011. 844 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", 845 September 2012. 847 Appendix A. Implementation Guidelines 849 _This section is non-normative._ 851 Let us assume a scenario in which the users access with their web 852 browsers (probably behind NAT) an application provided by a server on 853 an intranet, login by entering their user identifier and credentials, 854 and retrieve a JavaScript application (along with the HTML) 855 implementing a SIP WebSocket Client. 857 Such a SIP stack connects to a given SIP WebSocket Server (an 858 outbound SIP proxy which also implements classic SIP transports such 859 as UDP and TCP). The HTTP GET method request sent by the web browser 860 for the WebSocket handshake includes a Cookie [RFC6265] header with 861 the value previously provided by the server after the successful 862 login procedure. The Cookie value is then inspected by the WebSocket 863 server to authorize the connection. Once the WebSocket connection is 864 established, the SIP WebSocket Client performs a SIP registration to 865 a SIP registrar server that is reachable through the proxy. After 866 registration, the SIP WebSocket Client and Server exchange SIP 867 messages as would normally be expected. 869 This scenario is quite similar to ones in which SIP UAs behind NATs 870 connect to a proxy and must reuse the same TCP connection for 871 incoming requests (because they are not directly reachable by the 872 proxy otherwise). In both cases, the SIP UAs are only reachable 873 through the proxy they are connected to. 875 The SIP Outbound extension [RFC5626] seems an appropriate solution 876 for this scenario. Therefore these SIP WebSocket Clients and the SIP 877 registrar implement both the Outbound and Path [RFC3327] extensions, 878 and the SIP proxy acts as an Outbound Edge Proxy (as defined in 879 [RFC5626] section 3.4). 881 SIP WebSocket Clients in this scenario receive incoming SIP requests 882 via the SIP WebSocket Server they are connected to. Therefore, in 883 some call transfer cases the usage of GRUU [RFC5627] (which should be 884 implemented in both the SIP WebSocket Clients and SIP registrar) is 885 valuable. 887 If a REFER request is sent to a third SIP user agent including the 888 Contact URI of a SIP WebSocket Client as the target in its 889 Refer-To header field, such a URI will be reachable by the third 890 SIP UA only if it is a globally routable URI. GRUU (Globally 891 Routable User Agent URI) is a solution for those scenarios, and 892 would cause the incoming request from the third SIP user agent to 893 be sent to the SIP registrar, which would route the request to the 894 SIP WebSocket Client via the Outbound Edge Proxy. 896 A.1. SIP WebSocket Client Considerations 898 The JavaScript stack in web browsers does not have the ability to 899 discover the local transport address used for originating WebSocket 900 connections. A SIP WebSocket client running in such an environment 901 can construct a domain name consisting of a random token followed by 902 the ".invalid" top-level domain name, as stated in [RFC2606], and 903 uses it within its Via and Contact headers. 905 The Contact URI provided by SIP UAs requesting (and receiving) 906 Outbound support is not used for routing requests to those UAs, 907 thus it is safe to set a random domain in the Contact URI 908 hostport. 910 Both the Outbound and GRUU specifications require a SIP UA to include 911 a Uniform Resource Name (URN) in a "+sip.instance" parameter of the 912 Contact header they include their SIP REGISTER requests. The client 913 device is responsible for generating or collecting a suitable value 914 for this purpose. 916 In web browsers it is difficult to generate or collect a suitable 917 value to be used as a URN value from the browser itself. This 918 scenario suggests that value is generated according to [RFC5626] 919 section 4.1 by the web application running in the browser the 920 first time it loads the JavaScript SIP stack code, and then it is 921 stored as a Cookie within the browser. 923 A.2. SIP WebSocket Server Considerations 925 The SIP WebSocket Server in this scenario behaves as a SIP Outbound 926 Edge Proxy, which involves support for Outbound [RFC5626] and Path 927 [RFC3327]. 929 The proxy performs Loose Routing and remains in the path of dialogs 930 as specified in [RFC3261]. If it did not do this, in-dialog requests 931 would fail since SIP WebSocket Clients make use of their SIP 932 WebSocket Server in order to send and receive SIP messages. 934 Authors' Addresses 936 Inaki Baz Castillo 937 Versatica 938 Barakaldo, Basque Country 939 Spain 941 Email: ibc@aliax.net 942 Jose Luis Millan Villegas 943 Versatica 944 Bilbao, Basque Country 945 Spain 947 Email: jmillan@aliax.net 949 Victor Pascual 950 Acme Packet 951 Anabel Segura 10 952 Madrid, Madrid 28108 953 Spain 955 Email: vpascual@acmepacket.com