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