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