idnits 2.17.1 draft-ietf-sipcore-sip-websocket-07.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 444 has weird spacing: '...otocols proxy...' == Line 538 has weird spacing: '... Trying proxy...' == Line 721 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 (February 18, 2013) is 4082 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 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 Updates: 3261 (if approved) Versatica 5 Intended status: Standards Track V. Pascual 6 Expires: August 22, 2013 Acme Packet 7 February 18, 2013 9 The WebSocket Protocol as a Transport for the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipcore-sip-websocket-07 13 Abstract 15 The WebSocket protocol enables two-way realtime communication between 16 clients and servers in web-based applications. This document 17 specifies a WebSocket sub-protocol as a reliable transport mechanism 18 between SIP (Session Initiation Protocol) entities to enable usage of 19 SIP in web-oriented deployments. This document normatively updates 20 RFC 3261. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 22, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 4 60 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 61 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 64 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6 66 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6 67 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6 68 5.2.3. Via received parameter . . . . . . . . . . . . . . . . 7 69 5.2.4. SIP transport implementation requirements . . . . . . 7 70 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8 71 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8 72 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 78 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16 81 10.2. Registration of new NAPTR service field values . . . . . . 16 82 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 16 83 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17 84 10.5. Header Field Parameters and Parameter Values 85 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 89 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 90 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 19 91 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 20 92 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 95 1. Introduction 97 The WebSocket [RFC6455] protocol enables message exchange between 98 clients and servers on top of a persistent TCP connection (optionally 99 secured with TLS [RFC5246]). The initial protocol handshake makes 100 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 101 reuse existing HTTP infrastructure. 103 Modern web browsers include a WebSocket client stack complying with 104 the WebSocket API [WS-API] as specified by the W3C. It is expected 105 that other client applications (those running in personal computers 106 and devices such as smartphones) will also make a WebSocket client 107 stack available. The specification in this document enables usage of 108 SIP in these scenarios. 110 This specification defines a WebSocket sub-protocol (as defined in 111 section 1.9 in [RFC6455]) for transporting SIP messages between a 112 WebSocket client and server, a reliable and message-boundary 113 preserving transport for SIP, DNS NAPTR [RFC3403] service values and 114 procedures for SIP entities implementing the WebSocket transport. 115 Media transport is out of the scope of this document. 117 Section 3 in this specification relaxes the requirement in [RFC3261] 118 by which the SIP server transport MUST add a "received" parameter in 119 the top Via header in certain circumstances. 121 2. Terminology 123 All diagrams, examples, and notes in this specification are non- 124 normative, as are all sections explicitly marked non-normative. 125 Everything else in this specification is normative. 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2.1. Definitions 133 SIP WebSocket Client: A SIP entity capable of opening outbound 134 connections to WebSocket servers and communicating using the 135 WebSocket SIP sub-protocol as defined by this document. 137 SIP WebSocket Server: A SIP entity capable of listening for inbound 138 connections from WebSocket clients and communicating using the 139 WebSocket SIP sub-protocol as defined by this document. 141 3. The WebSocket Protocol 143 _This section is non-normative._ 145 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 146 (optionally secured with TLS [RFC5246]) in which both client and 147 server exchange message units in both directions. The protocol 148 defines a connection handshake, WebSocket sub-protocol and extensions 149 negotiation, a frame format for sending application and control data, 150 a masking mechanism, and status codes for indicating disconnection 151 causes. 153 The WebSocket connection handshake is based on HTTP [RFC2616] and 154 utilizes the HTTP GET method with an "Upgrade" request. This is sent 155 by the client and then answered by the server (if the negotiation 156 succeeded) with an HTTP 101 status code. Once the handshake is 157 completed the connection upgrades from HTTP to the WebSocket 158 protocol. This handshake procedure is designed to reuse the existing 159 HTTP infrastructure. During the connection handshake, client and 160 server agree on the application protocol to use on top of the 161 WebSocket transport. Such application protocol (also known as a 162 "WebSocket sub-protocol") defines the format and semantics of the 163 messages exchanged by the endpoints. This could be a custom protocol 164 or a standardized one (as the WebSocket SIP sub-protocol defined in 165 this document). Once the HTTP 101 response is processed both client 166 and server reuse the underlying TCP connection for sending WebSocket 167 messages and control frames to each other. Unlike plain HTTP, this 168 connection is persistent and can be used for multiple message 169 exchanges. 171 WebSocket defines message units to be used by applications for the 172 exchange of data, so it provides a message boundary-preserving 173 transport layer. These message units can contain either UTF-8 text 174 or binary data, and can be split into multiple WebSocket text/binary 175 transport frames as needed by the WebSocket stack. 177 The WebSocket API [WS-API] for web browsers only defines callbacks 178 to be invoked upon receipt of an entire message unit, regardless 179 of whether it was received in a single Websocket frame or split 180 across multiple frames. 182 4. The WebSocket SIP Sub-Protocol 184 The term WebSocket sub-protocol refers to an application-level 185 protocol layered on top of a WebSocket connection. This document 186 specifies the WebSocket SIP sub-protocol for carrying SIP requests 187 and responses through a WebSocket connection. 189 4.1. Handshake 191 The SIP WebSocket Client and SIP WebSocket Server negotiate usage of 192 the WebSocket SIP sub-protocol during the WebSocket handshake 193 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 194 include the value "sip" in the Sec-WebSocket-Protocol header in its 195 handshake request. The 101 reply from the Server MUST contain "sip" 196 in its corresponding Sec-WebSocket-Protocol header. 198 Below is an example of a WebSocket handshake in which the Client 199 requests the WebSocket SIP sub-protocol support from the Server: 201 GET / HTTP/1.1 202 Host: sip-ws.example.com 203 Upgrade: websocket 204 Connection: Upgrade 205 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 206 Origin: http://www.example.com 207 Sec-WebSocket-Protocol: sip 208 Sec-WebSocket-Version: 13 210 The handshake response from the Server accepting the WebSocket SIP 211 sub-protocol would look as follows: 213 HTTP/1.1 101 Switching Protocols 214 Upgrade: websocket 215 Connection: Upgrade 216 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 217 Sec-WebSocket-Protocol: sip 219 Once the negotiation has been completed, the WebSocket connection is 220 established and can be used for the transport of SIP requests and 221 responses. The WebSocket messages transmitted over this connection 222 MUST conform to the negotiated WebSocket sub-protocol. 224 4.2. SIP encoding 226 WebSocket messages can be transported in either UTF-8 text frames or 227 binary frames. SIP [RFC3261] allows both text and binary bodies in 228 SIP requests and responses. Therefore SIP WebSocket Clients and SIP 229 WebSocket Servers MUST accept both text and binary frames. 231 5. SIP WebSocket Transport 232 5.1. General 234 WebSocket [RFC6455] is a reliable protocol and therefore the SIP 235 WebSocket sub-protocol defined by this document is a reliable SIP 236 transport. Thus, client and server transactions using WebSocket for 237 transport MUST follow the procedures and timer values for reliable 238 transports as defined in [RFC3261]. 240 Each SIP message MUST be carried within a single WebSocket message, 241 and a WebSocket message MUST NOT contain more than one SIP message. 242 Because the WebSocket transport preserves message boundaries, the use 243 of the Content-Length header in SIP messages is optional when they 244 are transported using the WebSocket sub-protocol. 246 This simplifies parsing of SIP messages for both clients and 247 servers. There is no need to establish message boundaries using 248 Content-Length headers between messages. Other SIP transports, 249 such as UDP and SCTP [RFC4168] also provide this benefit. 251 5.2. Updates to RFC 3261 253 5.2.1. Via Transport Parameter 255 Via header fields in SIP messages carry a transport protocol 256 identifier. This document defines the value "WS" to be used for 257 requests over plain WebSocket connections and "WSS" for requests over 258 secure WebSocket connections (in which the WebSocket connection is 259 established using TLS [RFC5246] with TCP transport). 261 The updated augmented BNF (Backus-Naur Form) [RFC5234] for this 262 parameter is the following (the original BNF for this parameter can 263 be found in [RFC3261], which was then updated by [RFC4168]): 265 transport =/ "WS" / "WSS" 267 5.2.2. SIP URI Transport Parameter 269 This document defines the value "ws" as the transport parameter value 270 for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub- 271 protocol as transport. 273 The updated augmented BNF (Backus-Naur Form) for this parameter is 274 the following (the original BNF for this parameter can be found in 275 [RFC3261], which was then updated by [RFC4168]): 277 transport-param =/ "transport=" "ws" 279 5.2.3. Via received parameter 281 [RFC3261] section 18.2.1 "Receiving Requests" states the following: 283 When the server transport receives a request over any transport, 284 it MUST examine the value of the "sent-by" parameter in the top 285 Via header field value. If the host portion of the "sent-by" 286 field contains a domain name, or if it contains an IP address that 287 differs from the packet source address, the server MUST add a 288 "received" parameter to that Via header field value. This 289 parameter MUST contain the source address from which the packet 290 was received. 292 The requirement of adding the "received" parameter does not fit well 293 into the WebSocket protocol design. The WebSocket connection 294 handshake reuses existing HTTP infrastructure in which there could be 295 an unknown number of HTTP proxies and/or TCP load balancers between 296 the SIP WebSocket Client and Server, so the source address the server 297 would write into the Via "received" parameter would be the address of 298 the HTTP/TCP intermediary in front of it. This could reveal 299 sensitive information about the internal topology of the Server's 300 network to the Client. 302 Given the fact that SIP responses can only be sent over the existing 303 WebSocket connection, the Via "received" parameter is of little use. 304 Therefore, in order to allow hiding possible sensitive information 305 about the SIP WebSocket Server's network, this document updates 306 [RFC3261] section 18.2.1 by stating: 308 When a SIP WebSocket Server receives a request it MAY decide not 309 to add a "received" parameter to the top Via header. Therefore 310 SIP WebSocket Clients MUST accept responses without such a 311 parameter in the top Via header regardless of whether the Via 312 "sent-by" field contains a domain name. 314 5.2.4. SIP transport implementation requirements 316 [RFC3261] section 18 "Transport" states the following: 318 All SIP elements MUST implement UDP and TCP. SIP elements MAY 319 implement other protocols. 321 The specification of this transport enables SIP to be used as a 322 session establishment protocol in scenarios where none of other 323 transport protocols defined for SIP can be used. Since some 324 environments do not enable SIP elements to use UDP and TCP as SIP 325 transport protocols, a SIP element acting as a SIP WebSocket Client 326 is not mandated to implement support of UDP and TCP and thus MAY just 327 implement the WebSocket transport defined by this specification. 329 5.3. Locating a SIP Server 331 [RFC3263] specifies the procedures which should be followed by SIP 332 entities for locating SIP servers. This specification defines the 333 NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support 334 plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers 335 that support secure WebSocket connections. 337 At the time this document was written, DNS NAPTR/SRV queries could 338 not be performed by commonly available WebSocket client stacks (in 339 JavaScript engines and web browsers). 341 In the absence of DNS SRV resource records or an explicit port, the 342 default port for a SIP URI using the "sip" scheme and the "ws" 343 transport parameter is 80, and the default port for a SIP URI using 344 the "sips" scheme and the "ws" transport parameter is 443. 346 6. Connection Keep-Alive 348 _This section is non-normative._ 350 SIP WebSocket Clients and Servers may keep their WebSocket 351 connections open by sending periodic WebSocket "Ping" frames as 352 described in [RFC6455] section 5.5.2. 354 The WebSocket API [WS-API] does not provide a mechanism for 355 applications running in a web browser to control whether or not 356 periodic WebSocket "Ping" frames are sent to the server. The 357 implementation of such a keep-alive feature is the decision of 358 each web browser manufacturer and may also depend on the 359 configuration of the web browser. 361 The indication and use of the CRLF NAT keep-alive mechanism defined 362 for SIP connection-oriented transports in [RFC5626] section 3.5.1 or 363 [RFC6223] are, of course, usable over the transport defined in this 364 specification. 366 7. Authentication 368 _This section is non-normative._ 370 This section describes how authentication is achieved through the 371 requirements in [RFC6455], [RFC6265] and [RFC3261]. 373 Prior to sending SIP requests, a SIP WebSocket Client connects to a 374 SIP WebSocket Server and performs the connection handshake. As 375 described in Section 3 the handshake procedure involves a HTTP GET 376 method request from the Client and a response from the Server 377 including an HTTP 101 status code. 379 In order to authorize the WebSocket connection, the SIP WebSocket 380 Server is allowed to inspect any Cookie [RFC6265] headers present in 381 the HTTP GET request. For many web applications the value of such a 382 Cookie is provided by the web server once the user has authenticated 383 themselves to the web server, which could be done by many existing 384 mechanisms. As an alternative method, the SIP WebSocket Server could 385 request HTTP authentication by replying to the Client's GET method 386 request with a HTTP 401 status code. The WebSocket protocol 387 [RFC6455] covers this usage in section 4.1: 389 If the status code received from the server is not 101, the 390 WebSocket client stack handles the response per HTTP [RFC2616] 391 procedures, in particular the client might perform authentication 392 if it receives 401 status code. 394 Regardless of whether the SIP WebSocket Server requires 395 authentication during the WebSocket handshake, authentication can be 396 requested at SIP protocol level. Note that RFC 3261 requires that 397 all SIP implementations (which includes implementations of this 398 specification) implement Digest Authorization ([RFC3261] section 399 26.3.1). 401 8. Examples 403 8.1. Registration 405 Alice (SIP WSS) proxy.example.com 406 | | 407 |HTTP GET (WS handshake) F1 | 408 |---------------------------->| 409 |101 Switching Protocols F2 | 410 |<----------------------------| 411 | | 412 |REGISTER F3 | 413 |---------------------------->| 414 |200 OK F4 | 415 |<----------------------------| 416 | | 418 Alice loads a web page using her web browser and retrieves JavaScript 419 code implementing the WebSocket SIP sub-protocol defined in this 420 document. The JavaScript code (a SIP WebSocket Client) establishes a 421 secure WebSocket connection with a SIP proxy/registrar (a SIP 422 WebSocket Server) at proxy.example.com. Upon WebSocket connection, 423 Alice constructs and sends a SIP REGISTER request including Outbound 424 and GRUU support. Since the JavaScript stack in a browser has no way 425 to determine the local address from which the WebSocket connection 426 was made, this implementation uses a random ".invalid" domain name 427 for the Via header sent-by parameter and for the hostport of the URI 428 in the Contact header (see Appendix A.1). 430 Message details (authentication and SDP bodies are omitted for 431 simplicity): 433 F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS) 435 GET / HTTP/1.1 436 Host: proxy.example.com 437 Upgrade: websocket 438 Connection: Upgrade 439 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 440 Origin: https://www.example.com 441 Sec-WebSocket-Protocol: sip 442 Sec-WebSocket-Version: 13 444 F2 101 Switching Protocols proxy.example.com -> Alice (TLS) 446 HTTP/1.1 101 Switching Protocols 447 Upgrade: websocket 448 Connection: Upgrade 449 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 450 Sec-WebSocket-Protocol: sip 452 F3 REGISTER Alice -> proxy.example.com (transport WSS) 454 REGISTER sip:proxy.example.com SIP/2.0 455 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 456 From: sip:alice@example.com;tag=65bnmj.34asd 457 To: sip:alice@example.com 458 Call-ID: aiuy7k9njasd 459 CSeq: 1 REGISTER 460 Max-Forwards: 70 461 Supported: path, outbound, gruu 462 Contact: 463 ;reg-id=1 464 ;+sip.instance="" 466 F4 200 OK proxy.example.com -> Alice (transport WSS) 468 SIP/2.0 200 OK 469 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 470 From: sip:alice@example.com;tag=65bnmj.34asd 471 To: sip:alice@example.com;tag=12isjljn8 472 Call-ID: aiuy7k9njasd 473 CSeq: 1 REGISTER 474 Supported: outbound, gruu 475 Contact: 476 ;reg-id=1 477 ;+sip.instance="" 478 ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1" 479 ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr" 480 ;expires=3600 482 8.2. INVITE dialog through a proxy 483 Alice (SIP WSS) proxy.example.com (SIP UDP) Bob 484 | | | 485 |INVITE F1 | | 486 |---------------------------->| | 487 |100 Trying F2 | | 488 |<----------------------------| | 489 | |INVITE F3 | 490 | |---------------------------->| 491 | |200 OK F4 | 492 | |<----------------------------| 493 |200 OK F5 | | 494 |<----------------------------| | 495 | | | 496 |ACK F6 | | 497 |---------------------------->| | 498 | |ACK F7 | 499 | |---------------------------->| 500 | | | 501 | Bidirectional RTP Media | 502 |<=========================================================>| 503 | | | 504 | |BYE F8 | 505 | |<----------------------------| 506 |BYE F9 | | 507 |<----------------------------| | 508 |200 OK F10 | | 509 |---------------------------->| | 510 | |200 OK F11 | 511 | |---------------------------->| 512 | | | 514 In the same scenario Alice places a call to Bob's AoR (Address Of 515 Record). The SIP WebSocket Server at proxy.example.com acts as a SIP 516 proxy, routing the INVITE to Bob's contact address (which happens to 517 be using SIP transported over UDP). Bob answers the call and then 518 terminates it. 520 Message details (authentication and SDP bodies are omitted for 521 simplicity): 523 F1 INVITE Alice -> proxy.example.com (transport WSS) 525 INVITE sip:bob@example.com SIP/2.0 526 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 527 From: sip:alice@example.com;tag=asdyka899 528 To: sip:bob@example.com 529 Call-ID: asidkj3ss 530 CSeq: 1 INVITE 531 Max-Forwards: 70 532 Supported: path, outbound, gruu 533 Route: 534 Contact: 536 Content-Type: application/sdp 538 F2 100 Trying proxy.example.com -> Alice (transport WSS) 540 SIP/2.0 100 Trying 541 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 542 From: sip:alice@example.com;tag=asdyka899 543 To: sip:bob@example.com 544 Call-ID: asidkj3ss 545 CSeq: 1 INVITE 547 F3 INVITE proxy.example.com -> Bob (transport UDP) 549 INVITE sip:bob@203.0.113.22:5060 SIP/2.0 550 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 551 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 552 Record-Route: , 553 554 From: sip:alice@example.com;tag=asdyka899 555 To: sip:bob@example.com 556 Call-ID: asidkj3ss 557 CSeq: 1 INVITE 558 Max-Forwards: 69 559 Supported: path, outbound, gruu 560 Contact: 562 Content-Type: application/sdp 564 F4 200 OK Bob -> proxy.example.com (transport UDP) 566 SIP/2.0 200 OK 567 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c 568 ;received=192.0.2.10 569 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 570 Record-Route: , 571 572 From: sip:alice@example.com;tag=asdyka899 573 To: sip:bob@example.com;tag=bmqkjhsd 574 Call-ID: asidkj3ss 575 CSeq: 1 INVITE 576 Contact: 577 Content-Type: application/sdp 579 F5 200 OK proxy.example.com -> Alice (transport WSS) 581 SIP/2.0 200 OK 582 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 583 Record-Route: , 584 585 From: sip:alice@example.com;tag=asdyka899 586 To: sip:bob@example.com;tag=bmqkjhsd 587 Call-ID: asidkj3ss 588 CSeq: 1 INVITE 589 Contact: 590 Content-Type: application/sdp 592 F6 ACK Alice -> proxy.example.com (transport WSS) 594 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 595 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 596 Route: , 597 , 598 From: sip:alice@example.com;tag=asdyka899 599 To: sip:bob@example.com;tag=bmqkjhsd 600 Call-ID: asidkj3ss 601 CSeq: 1 ACK 602 Max-Forwards: 70 604 F7 ACK proxy.example.com -> Bob (transport UDP) 606 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 607 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx 608 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 609 From: sip:alice@example.com;tag=asdyka899 610 To: sip:bob@example.com;tag=bmqkjhsd 611 Call-ID: asidkj3ss 612 CSeq: 1 ACK 613 Max-Forwards: 69 615 F8 BYE Bob -> proxy.example.com (transport UDP) 617 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 618 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 619 Route: , 620 621 From: sip:bob@example.com;tag=bmqkjhsd 622 To: sip:alice@example.com;tag=asdyka899 623 Call-ID: asidkj3ss 624 CSeq: 1201 BYE 625 Max-Forwards: 70 627 F9 BYE proxy.example.com -> Alice (transport WSS) 629 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 630 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 631 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 632 From: sip:bob@example.com;tag=bmqkjhsd 633 To: sip:alice@example.com;tag=asdyka899 634 Call-ID: asidkj3ss 635 CSeq: 1201 BYE 636 Max-Forwards: 69 638 F10 200 OK Alice -> proxy.example.com (transport WSS) 640 SIP/2.0 200 OK 641 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 642 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 643 From: sip:bob@example.com;tag=bmqkjhsd 644 To: sip:alice@example.com;tag=asdyka899 645 Call-ID: asidkj3ss 646 CSeq: 1201 BYE 648 F11 200 OK proxy.example.com -> Bob (transport UDP) 650 SIP/2.0 200 OK 651 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 652 From: sip:bob@example.com;tag=bmqkjhsd 653 To: sip:alice@example.com;tag=asdyka899 654 Call-ID: asidkj3ss 655 CSeq: 1201 BYE 657 9. Security Considerations 659 9.1. Secure WebSocket Connection 661 It is recommended that the SIP traffic transported over a WebSocket 662 communication be protected by using a secure WebSocket connection 663 (using TLS [RFC5246] over TCP). 665 However none of the SIP TLS certificate checks specified in [RFC3261] 666 or [RFC5922] will be made when using SIP over secure WebSocket 667 transport. Instead, only the checks specified by [RFC6455] will be 668 made. The certificates that are appropriate for SIP over TLS over 669 TCP will probably not be appropriate for SIP over secure WebSocket 670 connections. 672 9.2. Usage of SIPS Scheme 674 The SIPS scheme in a SIP URI dictates that the entire request path to 675 the target be secure. If such a path includes a WebSocket connection 676 it MUST be a secure WebSocket connection. 678 10. IANA Considerations 680 10.1. Registration of the WebSocket SIP Sub-Protocol 682 This specification requests IANA to register the WebSocket SIP sub- 683 protocol under the "WebSocket Subprotocol Name" Registry with the 684 following data: 686 Subprotocol Identifier: sip 688 Subprotocol Common Name: WebSocket Transport for SIP (Session 689 Initiation Protocol) 691 Subprotocol Definition: TBD: this document 693 10.2. Registration of new NAPTR service field values 695 This document defines two new NAPTR service field values (SIP+D2W and 696 SIPS+D2W) and requests IANA to register these values under the 697 "Registry for the Session Initiation Protocol (SIP) NAPTR Resource 698 Record Services Field". The resulting entries are as follows: 700 Services Field Protocol Reference 701 -------------- -------- --------- 702 SIP+D2W WS TBD: this document 703 SIPS+D2W WS TBD: this document 705 10.3. SIP/SIPS URI Parameters Sub-Registry 707 This specification requests IANA to add a reference to this document 708 under the "SIP/SIPS URI Parameters" Sub-Registry within the "Session 709 Initiation Protocol (SIP) Parameters" Registry: 711 Parameter Name Predefined Values Reference 712 -------------- ----------------- --------- 713 transport Yes [RFC3261][TBD: this document] 715 10.4. Header Fields Sub-Registry 717 This specification requests IANA to add a reference to this document 718 under the "Header Fields" Sub-Registry within the "Session Initiation 719 Protocol (SIP) Parameters" Registry: 721 Header Name compact Reference 722 ----------- ------- --------- 723 Via v [RFC3261][TBD: this document] 725 10.5. Header Field Parameters and Parameter Values Sub-Registry 727 This specification requests IANA to add a reference to this document 728 under the "Header Field Parameters and Parameter Values" Sub-Registry 729 within the "Session Initiation Protocol (SIP) Parameters" Registry: 731 Predefined 732 Header Field Parameter Name Values Reference 733 ------------ -------------- ------ --------- 734 Via received No [RFC3261][TBD: this document] 736 11. Acknowledgements 738 Special thanks to the following people who participated in 739 discussions on the SIPCORE and RTCWEB WG mailing lists and 740 contributed ideas and/or provided detailed reviews (the list is 741 likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Adam Roach, 742 Ranjit Avasarala, Xavier Marjou, Nataraju A. B., Martin Vopatek, 743 Alexey Melnikov. 745 Special thanks to Alan Johnston, Christer Holmberg and Salvatore 746 Loreto for their full reviews, and also to Saul Ibarra Corretge for 747 his contribution and suggestions. 749 Special thanks to Kevin P. Fleming for his complete grammatical 750 review along with suggestions, comments and improvements. 752 12. References 753 12.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 759 A., Peterson, J., Sparks, R., Handley, M., and E. 760 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 761 June 2002. 763 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 764 Protocol (SIP): Locating SIP Servers", RFC 3263, 765 June 2002. 767 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 768 Part Three: The Domain Name System (DNS) Database", 769 RFC 3403, October 2002. 771 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 772 Specifications: ABNF", STD 68, RFC 5234, January 2008. 774 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 775 RFC 6455, December 2011. 777 12.2. Informative References 779 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 780 Names", BCP 32, RFC 2606, June 1999. 782 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 783 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 784 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 786 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 787 (SIP) Extension Header Field for Registering Non-Adjacent 788 Contacts", RFC 3327, December 2002. 790 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 791 Resource Identifier (URI): Generic Syntax", STD 66, 792 RFC 3986, January 2005. 794 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 795 Stream Control Transmission Protocol (SCTP) as a Transport 796 for the Session Initiation Protocol (SIP)", RFC 4168, 797 October 2005. 799 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 800 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 802 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 803 Initiated Connections in the Session Initiation Protocol 804 (SIP)", RFC 5626, October 2009. 806 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 807 Agent URIs (GRUUs) in the Session Initiation Protocol 808 (SIP)", RFC 5627, October 2009. 810 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 811 Certificates in the Session Initiation Protocol (SIP)", 812 RFC 5922, June 2010. 814 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 815 RFC 6223, April 2011. 817 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 818 April 2011. 820 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", 821 September 2012. 823 Appendix A. Implementation Guidelines 825 _This section is non-normative._ 827 Let us assume a scenario in which the users access with their web 828 browsers (probably behind NAT) an application provided by a server on 829 an intranet, login by entering their user identifier and credentials, 830 and retrieve a JavaScript application (along with the HTML) 831 implementing a SIP WebSocket Client. 833 Such a SIP stack connects to a given SIP WebSocket Server (an 834 outbound SIP proxy which also implements classic SIP transports such 835 as UDP and TCP). The HTTP GET method request sent by the web browser 836 for the WebSocket handshake includes a Cookie [RFC6265] header with 837 the value previously provided by the server after the successful 838 login procedure. The Cookie value is then inspected by the WebSocket 839 server to authorize the connection. Once the WebSocket connection is 840 established, the SIP WebSocket Client performs a SIP registration to 841 a SIP registrar server that is reachable through the proxy. After 842 registration, the SIP WebSocket Client and Server exchange SIP 843 messages as would normally be expected. 845 This scenario is quite similar to ones in which SIP UAs behind NATs 846 connect to a proxy and must reuse the same TCP connection for 847 incoming requests (because they are not directly reachable by the 848 proxy otherwise). In both cases, the SIP UAs are only reachable 849 through the proxy they are connected to. 851 The SIP Outbound extension [RFC5626] seems an appropriate solution 852 for this scenario. Therefore these SIP WebSocket Clients and the SIP 853 registrar implement both the Outbound and Path [RFC3327] extensions, 854 and the SIP proxy acts as an Outbound Edge Proxy (as defined in 855 [RFC5626] section 3.4). 857 SIP WebSocket Clients in this scenario receive incoming SIP requests 858 via the SIP WebSocket Server they are connected to. Therefore, in 859 some call transfer cases the usage of GRUU [RFC5627] (which should be 860 implemented in both the SIP WebSocket Clients and SIP registrar) is 861 valuable. 863 If a REFER request is sent to a third SIP user agent including the 864 Contact URI of a SIP WebSocket Client as the target in its 865 Refer-To header field, such a URI will be reachable by the third 866 SIP UA only if it is a globally routable URI. GRUU (Globally 867 Routable User Agent URI) is a solution for those scenarios, and 868 would cause the incoming request from the third SIP user agent to 869 be sent to the SIP registrar, which would route the request to the 870 SIP WebSocket Client via the Outbound Edge Proxy. 872 A.1. SIP WebSocket Client Considerations 874 The JavaScript stack in web browsers does not have the ability to 875 discover the local transport address used for originating WebSocket 876 connections. A SIP WebSocket client running in such an environment 877 can construct a domain name consisting of a random token followed by 878 the ".invalid" top-level domain name, as stated in [RFC2606], and 879 uses it within its Via and Contact headers. 881 The Contact URI provided by SIP UAs requesting (and receiving) 882 Outbound support is not used for routing requests to those UAs, 883 thus it is safe to set a random domain in the Contact URI 884 hostport. 886 Both the Outbound and GRUU specifications require a SIP UA to include 887 a Uniform Resource Name (URN) in a "+sip.instance" parameter of the 888 Contact header they include their SIP REGISTER requests. The client 889 device is responsible for generating or collecting a suitable value 890 for this purpose. 892 In web browsers it is difficult to generate or collect a suitable 893 value to be used as a URN value from the browser itself. This 894 scenario suggests that value is generated according to [RFC5626] 895 section 4.1 by the web application running in the browser the 896 first time it loads the JavaScript SIP stack code, and then it is 897 stored as a Cookie within the browser. 899 A.2. SIP WebSocket Server Considerations 901 The SIP WebSocket Server in this scenario behaves as a SIP Outbound 902 Edge Proxy, which involves support for Outbound [RFC5626] and Path 903 [RFC3327]. 905 The proxy performs Loose Routing and remains in the path of dialogs 906 as specified in [RFC3261]. If it did not do this, in-dialog requests 907 would fail since SIP WebSocket Clients make use of their SIP 908 WebSocket Server in order to send and receive SIP messages. 910 Authors' Addresses 912 Inaki Baz Castillo 913 Versatica 914 Barakaldo, Basque Country 915 Spain 917 Email: ibc@aliax.net 919 Jose Luis Millan Villegas 920 Versatica 921 Bilbao, Basque Country 922 Spain 924 Email: jmillan@aliax.net 926 Victor Pascual 927 Acme Packet 928 Anabel Segura 10 929 Madrid, Madrid 28108 930 Spain 932 Email: vpascual@acmepacket.com