idnits 2.17.1 draft-ietf-sipcore-sip-websocket-02.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 25 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 390 has weird spacing: '...otocols proxy...' == Line 483 has weird spacing: '... Trying proxy...' -- The document date (July 30, 2012) is 4260 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) -- 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 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 4 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 Intended status: Standards Track Unaffiliated 5 Expires: January 31, 2013 V. Pascual 6 Acme Packet 7 July 30, 2012 9 The WebSocket Protocol as a Transport for the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-sip-websocket-02 13 Abstract 15 The WebSocket protocol enables two-way realtime communication between 16 clients and servers. This document specifies a new WebSocket sub- 17 protocol as a reliable transport mechanism between SIP (Session 18 Initiation Protocol) entities to enable usage of SIP in new 19 scenarios. 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 January 31, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6 65 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6 66 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6 67 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 7 68 6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7 69 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 10 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 75 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 15 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 15 78 10.2. Registration of new NAPTR service field values . . . . . . 15 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 17 84 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 18 85 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 19 86 Appendix B. HTTP Topology Hiding . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 The WebSocket [RFC6455] protocol enables message exchange between 92 clients and servers on top of a persistent TCP connection (optionally 93 secured with TLS [RFC5246]). The initial protocol handshake makes 94 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 95 reuse existing HTTP infrastructure. 97 Modern web browsers include a WebSocket client stack complying with 98 the WebSocket API [WS-API] as specified by the W3C. It is expected 99 that other client applications (those running in personal computers 100 and devices such as smartphones) will also make a WebSocket client 101 stack available. The specification in this document enables usage of 102 SIP in these scenarios. 104 This specification defines a new WebSocket sub-protocol (as defined 105 in section 1.9 in [RFC6455]) for transporting SIP messages between a 106 WebSocket client and server, a new reliable and message boundary 107 transport for SIP, new DNS NAPTR [RFC3403] service values and 108 procedures for SIP entities implementing the WebSocket transport. 109 Media transport is out of the scope of this document. 111 2. Terminology 113 All diagrams, examples, and notes in this specification are non- 114 normative, as are all sections explicitly marked non-normative. 115 Everything else in this specification is normative. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2.1. Definitions 123 SIP WebSocket Client: A SIP entity capable of opening outbound 124 connections to WebSocket servers and communicating using the 125 WebSocket SIP sub-protocol as defined by this document. 127 SIP WebSocket Server: A SIP entity capable of listening for inbound 128 connections from WebSocket clients and communicating using the 129 WebSocket SIP sub-protocol as defined by this document. 131 3. The WebSocket Protocol 133 _This section is non-normative._ 134 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 135 (optionally secured with TLS [RFC5246]) in which both client and 136 server exchange message units in both directions. The protocol 137 defines a connection handshake, WebSocket sub-protocol and extensions 138 negotiation, a frame format for sending application and control data, 139 a masking mechanism, and status codes for indicating disconnection 140 causes. 142 The WebSocket connection handshake is based on HTTP [RFC2616] and 143 utilizes the HTTP GET method with an "Upgrade" request. This is sent 144 by the client and then answered by the server (if the negotiation 145 succeeded) with an HTTP 101 status code. Once the handshake is 146 completed the connection upgrades from HTTP to the WebSocket 147 protocol. This handshake procedure is designed to reuse the existing 148 HTTP infrastructure. During the connection handshake, client and 149 server agree on the application protocol to use on top of the 150 WebSocket transport. Such application protocol (also known as a 151 "WebSocket sub-protocol") defines the format and semantics of the 152 messages exchanged by the endpoints. This could be a custom protocol 153 or a standardized one (as the WebSocket SIP sub-protocol defined in 154 this document). Once the HTTP 101 response is processed both client 155 and server reuse the underlying TCP connection for sending WebSocket 156 messages and control frames to each other. Unlike plain HTTP, this 157 connection is persistent and can be used for multiple message 158 exchanges. 160 WebSocket defines message units to be used by applications for the 161 exchange of data, so it provides a message boundary-preserving 162 transport layer. These message units can contain either UTF-8 text 163 or binary data, and can be split into multiple WebSocket text/binary 164 transport frames as needed by the WebSocket stack. 166 The WebSocket API [WS-API] for web browsers only defines callbacks 167 to be invoked upon receipt of an entire message unit, regardless 168 of whether it was received in a single Websocket frame or split 169 across multiple frames. 171 4. The WebSocket SIP Sub-Protocol 173 The term WebSocket sub-protocol refers to an application-level 174 protocol layered on top of a WebSocket connection. This document 175 specifies the WebSocket SIP sub-protocol for carrying SIP requests 176 and responses through a WebSocket connection. 178 4.1. Handshake 180 The SIP WebSocket Client and SIP WebSocket Server negotiate usage of 181 the WebSocket SIP sub-protocol during the WebSocket handshake 182 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 183 include the value "sip" in the Sec-WebSocket-Protocol header in its 184 handshake request. The 101 reply from the Server MUST contain "sip" 185 in its corresponding Sec-WebSocket-Protocol header. 187 Below is an example of a WebSocket handshake in which the Client 188 requests the WebSocket SIP sub-protocol support from the Server: 190 GET / HTTP/1.1 191 Host: sip-ws.example.com 192 Upgrade: websocket 193 Connection: Upgrade 194 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 195 Origin: http://www.example.com 196 Sec-WebSocket-Protocol: sip 197 Sec-WebSocket-Version: 13 199 The handshake response from the Server accepting the WebSocket SIP 200 sub-protocol would look as follows: 202 HTTP/1.1 101 Switching Protocols 203 Upgrade: websocket 204 Connection: Upgrade 205 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 206 Sec-WebSocket-Protocol: sip 208 Once the negotiation has been completed, the WebSocket connection is 209 established and can be used for the transport of SIP requests and 210 responses. The WebSocket messages transmitted over this connection 211 MUST conform to the negotiated WebSocket sub-protocol. 213 4.2. SIP encoding 215 WebSocket messages can be transported in either UTF-8 text frames or 216 binary frames. SIP [RFC3261] allows both text and binary bodies in 217 SIP requests and responses. Therefore SIP WebSocket Clients and SIP 218 WebSocket Servers MUST accept both text and binary frames. 220 5. SIP WebSocket Transport 221 5.1. General 223 WebSocket [RFC6455] is a reliable protocol and therefore the SIP 224 WebSocket sub-protocol defined by this document is a reliable SIP 225 transport. Thus, client and server transactions using WebSocket for 226 transport MUST follow the procedures and timer values for reliable 227 transports as defined in [RFC3261]. 229 Each SIP message MUST be carried within a single WebSocket message, 230 and a WebSocket message MUST NOT contain more than one SIP message. 231 Because the WebSocket transport preserves message boundaries, the use 232 of the Content-Length header in SIP messages is optional when they 233 are transported using the WebSocket sub-protocol. 235 This simplifies parsing of SIP messages for both clients and 236 servers. There is no need to establish message boundaries using 237 Content-Length headers between messages. Other SIP transports, 238 such as UDP and SCTP [RFC4168] also provide this benefit. 240 5.2. Updates to RFC 3261 242 5.2.1. Via Transport Parameter 244 Via header fields in SIP messages carry a transport protocol 245 identifier. This document defines the value "WS" to be used for 246 requests over plain WebSocket connections and "WSS" for requests over 247 secure WebSocket connections (in which the WebSocket connection is 248 established using TLS [RFC5246] with TCP transport). 250 The updated augmented BNF (Backus-Naur Form) [RFC5234] for this 251 parameter is the following (the original BNF for this parameter can 252 be found in [RFC3261], which was then updated by [RFC4168]): 254 transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" 255 / "WS" / "WSS" 256 / other-transport 258 5.2.2. SIP URI Transport Parameter 260 This document defines the value "ws" as the transport parameter value 261 for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub- 262 protocol as transport. 264 The updated augmented BNF (Backus-Naur Form) for this parameter is 265 the following (the original BNF for this parameter can be found in 266 [RFC3261], which was then updated by [RFC4168]): 268 transport-param = "transport=" 269 ( "udp" / "tcp" / "sctp" / "tls" / "ws" 270 / other-transport ) 272 5.3. Locating a SIP Server 274 [RFC3263] specifies the procedures which should be followed by SIP 275 entities for locating SIP servers. This specification defines the 276 NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support 277 plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers 278 that support secure WebSocket connections. 280 At the time this document was written, DNS NAPTR/SRV queries could 281 not be performed by commonly available WebSocket client stacks (in 282 JavaScript engines and web browsers). 284 In the absence of DNS SRV resource records or an explicit port, the 285 default port for a SIP URI using the "sip" scheme and the "ws" 286 transport parameter is 80, and the default port for a SIP URI using 287 the "sips" scheme and the "ws" transport parameter is 443. 289 6. Connection Keep Alive 291 _This section is non-normative._ 293 It is RECOMMENDED that SIP WebSocket Clients and Servers keep their 294 WebSocket connections open by sending periodic WebSocket "Ping" 295 frames as described in [RFC6455] section 5.5.2. 297 The WebSocket API [WS-API] does not provide a mechanism for 298 applications running in a web browser to control whether or not 299 periodic WebSocket "Ping" frames are sent to the server. The 300 implementation of such a keep alive feature is the decision of 301 each web browser manufacturer and may also depend on the 302 configuration of the web browser. 304 A future WebSocket protocol extension providing a similar keep alive 305 mechanism could also be used. 307 The SIP stack in the SIP WebSocket Client MAY also use a Network 308 Address Translation (NAT) keep-alive mechanism defined for SIP 309 connection-oriented transports, such as the CRLF Keep-Alive Technique 310 mechanism described in [RFC5626] section 3.5.1 or [RFC6223]. 312 Implementing this technique would involve sending a WebSocket 313 message to the SIP WebSocket Server with a content consisting of 314 only a double CRLF, and expecting a WebSocket message from the 315 server containing a single CRLF as response. 317 7. Authentication 319 _This section is non-normative._ 321 Prior to sending SIP requests, a SIP WebSocket Client connects to a 322 SIP WebSocket Server and performs the connection handshake. As 323 described in Section 3 the handshake procedure involves a HTTP GET 324 method request from the Client and a response from the Server 325 including an HTTP 101 status code. 327 In order to authorize the WebSocket connection, the SIP WebSocket 328 Server MAY inspect any Cookie [RFC6265] headers present in the HTTP 329 GET request. For many web applications the value of such a Cookie is 330 provided by the web server once the user has authenticated themselves 331 to the web server, which could be done by many existing mechanisms. 332 As an alternative method, the SIP WebSocket Server could request HTTP 333 authentication by replying to the Client's GET method request with a 334 HTTP 401 status code. The WebSocket protocol [RFC6455] covers this 335 usage in section 4.1: 337 If the status code received from the server is not 101, the 338 WebSocket client stack handles the response per HTTP [RFC2616] 339 procedures, in particular the client might perform authentication 340 if it receives 401 status code. 342 Regardless of whether the SIP WebSocket Server requires 343 authentication during the WebSocket handshake, authentication MAY be 344 requested at SIP protocol level. Therefore it is RECOMMENDED that a 345 SIP WebSocket Client implements HTTP Digest [RFC2617] authentication 346 as stated in [RFC3261]. 348 8. Examples 350 8.1. Registration 351 Alice (SIP WSS) proxy.atlanta.com 352 | | 353 |HTTP GET (WS handshake) F1 | 354 |---------------------------->| 355 |101 Switching Protocols F2 | 356 |<----------------------------| 357 | | 358 |REGISTER F3 | 359 |---------------------------->| 360 |200 OK F4 | 361 |<----------------------------| 362 | | 364 Alice loads a web page using her web browser and retrieves JavaScript 365 code implementing the WebSocket SIP sub-protocol defined in this 366 document. The JavaScript code (a SIP WebSocket Client) establishes a 367 secure WebSocket connection with a SIP proxy/registrar (a SIP 368 WebSocket Server) at proxy.atlanta.com. Upon WebSocket connection, 369 Alice constructs and sends a SIP REGISTER request including Outbound 370 and GRUU support. Since the JavaScript stack in a browser has no way 371 to determine the local address from which the WebSocket connection 372 was made, this implementation uses a random ".invalid" domain name 373 for the Via header sent-by parameter and for the hostpart of the URI 374 in the Contact header (see Appendix A.1). 376 Message details (authentication and SDP bodies are omitted for 377 simplicity): 379 F1 HTTP GET (WS handshake) Alice -> proxy.atlanta.com (TLS) 381 GET / HTTP/1.1 382 Host: proxy.atlanta.com 383 Upgrade: websocket 384 Connection: Upgrade 385 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 386 Origin: https://www.atlanta.com 387 Sec-WebSocket-Protocol: sip 388 Sec-WebSocket-Version: 13 390 F2 101 Switching Protocols proxy.atlanta.com -> Alice (TLS) 392 HTTP/1.1 101 Switching Protocols 393 Upgrade: websocket 394 Connection: Upgrade 395 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 396 Sec-WebSocket-Protocol: sip 397 F3 REGISTER Alice -> proxy.atlanta.com (transport WSS) 399 REGISTER sip:proxy.atlanta.com SIP/2.0 400 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 401 From: sip:alice@atlanta.com;tag=65bnmj.34asd 402 To: sip:alice@atlanta.com 403 Call-ID: aiuy7k9njasd 404 CSeq: 1 REGISTER 405 Max-Forwards: 70 406 Supported: path, outbound, gruu 407 Contact: 408 ;reg-id=1 409 ;+sip.instance="" 411 F4 200 OK proxy.atlanta.com -> Alice (transport WSS) 413 SIP/2.0 200 OK 414 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 415 From: sip:alice@atlanta.com;tag=65bnmj.34asd 416 To: sip:alice@atlanta.com;tag=12isjljn8 417 Call-ID: aiuy7k9njasd 418 CSeq: 1 REGISTER 419 Supported: outbound, gruu 420 Contact: 421 ;reg-id=1 422 ;+sip.instance="" 423 ;pub-gruu="sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1" 424 ;temp-gruu="sip:87ash54=3dd.98a@atlanta.com;gr" 425 ;expires=3600 427 8.2. INVITE dialog through a proxy 428 Alice (SIP WSS) proxy.atlanta.com (SIP UDP) Bob 429 | | | 430 |INVITE F1 | | 431 |---------------------------->| | 432 |100 Trying F2 | | 433 |<----------------------------| | 434 | |INVITE F3 | 435 | |---------------------------->| 436 | |200 OK F4 | 437 | |<----------------------------| 438 |200 OK F5 | | 439 |<----------------------------| | 440 | | | 441 |ACK F6 | | 442 |---------------------------->| | 443 | |ACK F7 | 444 | |---------------------------->| 445 | | | 446 | Bidirectional RTP Media | 447 |<=========================================================>| 448 | | | 449 | |BYE F8 | 450 | |<----------------------------| 451 |BYE F9 | | 452 |<----------------------------| | 453 |200 OK F10 | | 454 |---------------------------->| | 455 | |200 OK F11 | 456 | |---------------------------->| 457 | | | 459 In the same scenario Alice places a call to Bob's AoR (Address Of 460 Record). The SIP WebSocket Server at proxy.atlanta.com acts as a SIP 461 proxy, routing the INVITE to Bob's contact address (which happens to 462 be using SIP transported over UDP). Bob answers the call and then 463 terminates it. 465 Message details (authentication and SDP bodies are omitted for 466 simplicity): 468 F1 INVITE Alice -> proxy.atlanta.com (transport WSS) 470 INVITE sip:bob@atlanta.com SIP/2.0 471 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 472 From: sip:alice@atlanta.com;tag=asdyka899 473 To: sip:bob@atlanta.com 474 Call-ID: asidkj3ss 475 CSeq: 1 INVITE 476 Max-Forwards: 70 477 Supported: path, outbound, gruu 478 Route: 479 Contact: 481 Content-Type: application/sdp 483 F2 100 Trying proxy.atlanta.com -> Alice (transport WSS) 485 SIP/2.0 100 Trying 486 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 487 From: sip:alice@atlanta.com;tag=asdyka899 488 To: sip:bob@atlanta.com 489 Call-ID: asidkj3ss 490 CSeq: 1 INVITE 492 F3 INVITE proxy.atlanta.com -> Bob (transport UDP) 494 INVITE sip:bob@203.0.113.22:5060 SIP/2.0 495 Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c 496 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 497 Record-Route: , 498 499 From: sip:alice@atlanta.com;tag=asdyka899 500 To: sip:bob@atlanta.com 501 Call-ID: asidkj3ss 502 CSeq: 1 INVITE 503 Max-Forwards: 69 504 Supported: path, outbound, gruu 505 Contact: 507 Content-Type: application/sdp 509 F4 200 OK Bob -> proxy.atlanta.com (transport UDP) 511 SIP/2.0 200 OK 512 Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c 513 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 514 Record-Route: , 515 516 From: sip:alice@atlanta.com;tag=asdyka899 517 To: sip:bob@atlanta.com;tag=bmqkjhsd 518 Call-ID: asidkj3ss 519 CSeq: 1 INVITE 520 Max-Forwards: 69 521 Contact: 522 Content-Type: application/sdp 524 F5 200 OK proxy.atlanta.com -> Alice (transport WSS) 526 SIP/2.0 200 OK 527 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 528 Record-Route: , 529 530 From: sip:alice@atlanta.com;tag=asdyka899 531 To: sip:bob@atlanta.com;tag=bmqkjhsd 532 Call-ID: asidkj3ss 533 CSeq: 1 INVITE 534 Max-Forwards: 69 535 Contact: 536 Content-Type: application/sdp 538 F6 ACK Alice -> proxy.atlanta.com (transport WSS) 540 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 541 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 542 Route: , 543 , 544 From: sip:alice@atlanta.com;tag=asdyka899 545 To: sip:bob@atlanta.com;tag=bmqkjhsd 546 Call-ID: asidkj3ss 547 CSeq: 1 ACK 548 Max-Forwards: 70 550 F7 ACK proxy.atlanta.com -> Bob (transport UDP) 552 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 553 Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhwpoc80zzx 554 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 555 From: sip:alice@atlanta.com;tag=asdyka899 556 To: sip:bob@atlanta.com;tag=bmqkjhsd 557 Call-ID: asidkj3ss 558 CSeq: 1 ACK 559 Max-Forwards: 69 561 F8 BYE Bob -> proxy.atlanta.com (transport UDP) 563 BYE sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 564 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 565 Route: , 566 567 From: sip:bob@atlanta.com;tag=bmqkjhsd 568 To: sip:alice@atlanta.com;tag=asdyka899 569 Call-ID: asidkj3ss 570 CSeq: 1201 BYE 571 Max-Forwards: 70 573 F9 BYE proxy.atlanta.com -> Alice (transport WSS) 575 BYE sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 576 Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 577 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 578 From: sip:bob@atlanta.com;tag=bmqkjhsd 579 To: sip:alice@atlanta.com;tag=asdyka899 580 Call-ID: asidkj3ss 581 CSeq: 1201 BYE 582 Max-Forwards: 69 584 F10 200 OK Alice -> proxy.atlanta.com (transport WSS) 586 SIP/2.0 200 OK 587 Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 588 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 589 From: sip:bob@atlanta.com;tag=bmqkjhsd 590 To: sip:alice@atlanta.com;tag=asdyka899 591 Call-ID: asidkj3ss 592 CSeq: 1201 BYE 594 F11 200 OK proxy.atlanta.com -> Bob (transport UDP) 596 SIP/2.0 200 OK 597 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 598 From: sip:bob@atlanta.com;tag=bmqkjhsd 599 To: sip:alice@atlanta.com;tag=asdyka899 600 Call-ID: asidkj3ss 601 CSeq: 1201 BYE 603 9. Security Considerations 604 9.1. Secure WebSocket Connection 606 It is recommended that the SIP traffic transported over a WebSocket 607 communication be protected by using a secure WebSocket connection 608 (using TLS [RFC5246] over TCP). 610 9.2. Usage of SIPS Scheme 612 The SIPS scheme in a SIP URI dictates that the entire request path to 613 the target be secure. If such a path includes a WebSocket connection 614 it MUST be a secure WebSocket connection. 616 10. IANA Considerations 618 10.1. Registration of the WebSocket SIP Sub-Protocol 620 This specification requests IANA to register the WebSocket SIP sub- 621 protocol in the registry of WebSocket sub-protocols with the 622 following data: 624 Subprotocol Identifier: sip 626 Subprotocol Common Name: WebSocket Transport for SIP (Session 627 Initiation Protocol) 629 Subprotocol Definition: TBD, it should point to this document 631 10.2. Registration of new NAPTR service field values 633 This document defines two new NAPTR service field values (SIP+D2W and 634 SIPS+D2W) and requests IANA to register these values under the 635 "Registry for the SIP SRV Resource Record Services Field". The 636 resulting entries are as follows: 638 Services Field Protocol Reference 639 -------------------- -------- --------- 640 SIP+D2W WS TBD: this document 641 SIPS+D2W WSS TBD: this document 643 11. Acknowledgements 645 Special thanks to the following people who participated in 646 discussions on the SIPCORE and RTCWEB WG mailing lists and 647 contributed ideas and/or provided detailed reviews (the list is 648 likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Adam Roach, 649 Ranjit Avasarala, Xavier Marjou, Nataraju A. B. 651 Special thanks to Alan Johnston, Christer Holmberg and Salvatore 652 Loreto for their full reviews, and also to Saul Ibarra Corretge for 653 his contribution and suggestions. 655 Special thanks to Kevin P. Fleming for his complete grammatical 656 review along with suggestions, comments and improvements. 658 12. References 660 12.1. Normative References 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 666 A., Peterson, J., Sparks, R., Handley, M., and E. 667 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 668 June 2002. 670 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 671 Protocol (SIP): Locating SIP Servers", RFC 3263, 672 June 2002. 674 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 675 Part Three: The Domain Name System (DNS) Database", 676 RFC 3403, October 2002. 678 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 679 Specifications: ABNF", STD 68, RFC 5234, January 2008. 681 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 682 RFC 6455, December 2011. 684 12.2. Informative References 686 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 687 Names", BCP 32, RFC 2606, June 1999. 689 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 690 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 691 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 693 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 694 Leach, P., Luotonen, A., and L. Stewart, "HTTP 695 Authentication: Basic and Digest Access Authentication", 696 RFC 2617, June 1999. 698 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 699 (SIP) Extension Header Field for Registering Non-Adjacent 700 Contacts", RFC 3327, December 2002. 702 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 703 Resource Identifier (URI): Generic Syntax", STD 66, 704 RFC 3986, January 2005. 706 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 707 Stream Control Transmission Protocol (SCTP) as a Transport 708 for the Session Initiation Protocol (SIP)", RFC 4168, 709 October 2005. 711 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 712 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 714 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 715 Initiated Connections in the Session Initiation Protocol 716 (SIP)", RFC 5626, October 2009. 718 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 719 Agent URIs (GRUUs) in the Session Initiation Protocol 720 (SIP)", RFC 5627, October 2009. 722 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 723 RFC 6223, April 2011. 725 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 726 April 2011. 728 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 730 Appendix A. Implementation Guidelines 732 _This section is non-normative._ 734 Let us assume a scenario in which the users access with their web 735 browsers (probably behind NAT) an application provided by a server on 736 an intranet, login by entering their user identifier and credentials, 737 and retrieve a JavaScript application (along with the HTML) 738 implementing a SIP WebSocket Client. 740 Such a SIP stack connects to a given SIP WebSocket Server (an 741 outbound SIP proxy which also implements classic SIP transports such 742 as UDP and TCP). The HTTP GET method request sent by the web browser 743 for the WebSocket handshake includes a Cookie [RFC6265] header with 744 the value previously provided by the server after the successful 745 login procedure. The Cookie value is then inspected by the WebSocket 746 server to authorize the connection. Once the WebSocket connection is 747 established, the SIP WebSocket Client performs a SIP registration to 748 a SIP registrar server that is reachable through the proxy. After 749 registration, the SIP WebSocket Client and Server exchange SIP 750 messages as would normally be expected. 752 This scenario is quite similar to ones in which SIP UAs behind NATs 753 connect to a proxy and must reuse the same TCP connection for 754 incoming requests (because they are not directly reachable by the 755 proxy otherwise). In both cases, the SIP UAs are only reachable 756 through the proxy they are connected to. 758 The SIP Outbound extension [RFC5626] seems an appropriate solution 759 for this scenario. Therefore these SIP WebSocket Clients and the SIP 760 registrar implement both the Outbound and Path [RFC3327] extensions, 761 and the SIP proxy acts as an Outbound Edge Proxy (as defined in 762 [RFC5626] section 3.4). 764 SIP WebSocket Clients in this scenario receive incoming SIP requests 765 via the SIP WebSocket Server they are connected to. Therefore, in 766 some call transfer cases the usage of GRUU [RFC5627] (which should be 767 implemented in both the SIP WebSocket Clients and SIP registrar) is 768 valuable. 770 If a REFER request is sent to a third SIP user agent including the 771 Contact URI of a SIP WebSocket Client as the target in its 772 Refer-To header field, such a URI will be reachable by the third 773 SIP UA only if it is a globally routable URI. GRUU (Globally 774 Routable User Agent URI) is a solution for those scenarios, and 775 would cause the incoming request from the third SIP user agent to 776 be sent to the SIP registrar, which would route the request to the 777 SIP WebSocket Client via the Outbound Edge Proxy. 779 A.1. SIP WebSocket Client Considerations 781 The JavaScript stack in web browsers does not have the ability to 782 discover the local transport address used for originating WebSocket 783 connections. Therefore the SIP WebSocket Client constructs a domain 784 name consisting of a random token followed by the ".invalid" top- 785 level domain name, as stated in [RFC2606], and uses it within its Via 786 and Contact headers. 788 The Contact URI provided by SIP UAs requesting (and receiving) 789 Outbound support is not used for routing requests to those UAs, 790 thus it is safe to set a random domain in the Contact URI 791 hostpart. 793 Both the Outbound and GRUU specifications require a SIP UA to include 794 a Uniform Resource Name (URN) in a "+sip.instance" parameter of the 795 Contact header they include their SIP REGISTER requests. The client 796 device is responsible for generating or collecting a suitable value 797 for this purpose. 799 In web browsers it is difficult to generate or collect a suitable 800 value to be used as a URN value from the browser itself. This 801 scenario suggests that value is generated according to [RFC5626] 802 section 4.1 by the web application running in the browser the 803 first time it loads the JavaScript SIP stack code, and then it is 804 stored as a Cookie within the browser. 806 A.2. SIP WebSocket Server Considerations 808 The SIP WebSocket Server in this scenario behaves as a SIP Outbound 809 Edge Proxy, which involves support for Outbound [RFC5626] and Path 810 [RFC3327]. 812 The proxy performs Loose Routing and remains in the path of dialogs 813 as specified in [RFC3261]. If it did not do this, in-dialog requests 814 would fail since SIP WebSocket Clients make use of their SIP 815 WebSocket Server in order to send and receive SIP messages. 817 Appendix B. HTTP Topology Hiding 819 _This section is non-normative._ 821 [RFC3261] section 18.2.1 "Receiving Requests" states the following: 823 When the server transport receives a request over any transport, 824 it MUST examine the value of the "sent-by" parameter in the top 825 Via header field value. If the host portion of the "sent-by" 826 parameter contains a domain name, or if it contains an IP address 827 that differs from the packet source address, the server MUST add a 828 "received" parameter to that Via header field value. This 829 parameter MUST contain the source address from which the packet 830 was received. 832 The requirement of adding the "received" parameter does not fit well 833 into the WebSocket protocol design. The WebSocket handshake 834 connection reuses existing HTTP infrastructure in which there could 835 be an unknown number of HTTP proxies and/or TCP load balancers 836 between the SIP WebSocket Client and Server, so the source address 837 the server would write into the Via "received" parameter would be the 838 address of the HTTP/TCP intermediary in front of it. This could 839 reveal sensitive information about the internal topology of the 840 Server's network to the Client. 842 Given the fact that SIP responses can only be sent over the existing 843 WebSocket connection, the Via "received" parameter is of little use. 844 Therefore, in order to allow hiding possible sensitive information 845 about the SIP WebSocket Server's network, the implementor could 846 decide not to satisfy the requirement in [RFC3261] section 18.2.1 847 "Receiving Requests" and not add the "received" parameter to the Via 848 header. 850 Keep in mind that this would make the SIP WebSocket Server non- 851 compliant with [RFC3261]. 853 Authors' Addresses 855 Inaki Baz Castillo 856 Unaffiliated 857 Barakaldo, Basque Country 858 Spain 860 Email: ibc@aliax.net 862 Jose Luis Millan Villegas 863 Unaffiliated 864 Bilbao, Basque Country 865 Spain 867 Email: jmillan@aliax.net 869 Victor Pascual 870 Acme Packet 871 Anabel Segura 10 872 Madrid, Madrid 28108 873 Spain 875 Email: vpascual@acmepacket.com