idnits 2.17.1 draft-ibc-sipcore-sip-websocket-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 22 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 474 has weird spacing: '... Trying proxy...' -- The document date (April 16, 2012) is 4365 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 (~~), 3 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 Consultant 5 Expires: October 18, 2012 V. Pascual 6 Acme Packet 7 April 16, 2012 9 The WebSocket Protocol as a Transport for the Session Initiation 10 Protocol (SIP) 11 draft-ibc-sipcore-sip-websocket-02 13 Abstract 15 The WebSocket protocol enables two-way realtime communication between 16 clients and servers. This document specifies a new WebSocket sub- 17 protocol as a reliable transport mechanism between SIP (Session 18 Initiation Protocol) entities and enables usage of the SIP protocol 19 in new 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 October 18, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. Sending Responses . . . . . . . . . . . . . . . . . . 6 68 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 7 69 6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7 70 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 10 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 14 76 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 14 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 14 79 10.2. Registration of new Via transports . . . . . . . . . . . . 14 80 10.3. Registration of new SIP URI transport . . . . . . . . . . 14 81 10.4. Registration of new NAPTR service field values . . . . . . 15 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 17 87 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 18 88 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 18 89 Appendix B. HTTP Topology Hiding . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 The WebSocket [RFC6455] protocol enables messages exchange between 95 clients and servers on top of a persistent TCP connection (optionally 96 secured with TLS [RFC5246]). The initial protocol handshake makes 97 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 98 reuse existing HTTP infrastructure. 100 Modern web browsers include a WebSocket client stack complying with 101 The WebSocket API [WS-API] as specified by the W3C. It is expected 102 that other client applications (those running in personal computers 103 and devices such as smartphones) will also run a WebSocket client 104 stack. The specification in this document enables usage of the SIP 105 protocol in those new scenarios. 107 This specification defines a new WebSocket sub-protocol (section 1.9 108 in [RFC6455]) for transporting SIP messages between a WebSocket 109 client and server, a new reliable and message boundary transport for 110 the SIP protocol, new DNS NAPTR [RFC3403] service values and 111 procedures for SIP entities implementing the WebSocket transport. 112 Media transport is out of the scope of this document. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2.1. Definitions 122 SIP WebSocket Client: A SIP entity capable of opening outbound 123 connections with WebSocket servers and speaking the WebSocket 124 SIP Sub-Protocol as defined by this document. 126 SIP WebSocket Server: A SIP entity capable of listening for inbound 127 connections from WebSocket clients and speaking the WebSocket 128 SIP Sub-Protocol as defined by this document. 130 3. The WebSocket Protocol 132 _This section is non-normative._ 134 WebSocket protocol [RFC6455] is a transport layer on top of TCP 135 (optionally secured with TLS [RFC5246]) in which both client and 136 server exchange message units in both directions. The protocol 137 defines a connection handshake, WebSocket sub-protocol and extensions 138 negotiation, a frame format for sending application and control data, 139 a masking mechanism, and status codes for indicating disconnection 140 causes. 142 The WebSocket connection handshake is based on HTTP [RFC2616] 143 protocol by means of a specific HTTP GET method with Upgrade request 144 sent by the client which is answered by the server (if the 145 negotiation succeeded) with HTTP 101 status code. Once the handshake 146 is done the connection upgrades from HTTP to the WebSocket protocol. 147 This handshake procedure is designed to reuse the existing HTTP 148 infrastructure. During the connection handshake, client and server 149 agree in the application protocol to use on top of the WebSocket 150 transport. Such application protocol (also known as the "WebSocket 151 sub-protocol") defines the format and semantics of the messages 152 exchanged between both endpoints. It may be a custom protocol or a 153 standarized one (as the WebSocket SIP Sub-Protocol proposed in this 154 document). Once the HTTP 101 response is processed both client and 155 server reuse the underlying TCP connection for sending WebSocket 156 messages and control frames to each other in a persistent way. 158 WebSocket defines message units as application data exchange for 159 communication endpoints, becoming a message boundary transport layer. 160 These messages can contain UTF-8 text or binary data, and can be 161 split into various WebSocket text/binary frames. 163 However, the WebSocket API [WS-API] for web browsers just includes 164 callbacks that are invoked upon receipt of an entire message, 165 regardless of whether it was received in a single or multiple 166 WebSocket frames. 168 4. The WebSocket SIP Sub-Protocol 170 The term WebSocket sub-protocol refers to the application-level 171 protocol layered on top of a WebSocket connection. This document 172 specifies the WebSocket SIP Sub-Protocol for carrying SIP requests 173 and responses through a WebSocket connection. 175 4.1. Handshake 177 The SIP WebSocket Client and SIP WebSocket Server need to agree on 178 the WebSocket SIP Sub-Protocol during the WebSocket handshake 179 procedure as defined in section 1.3 of [RFC6455]. The client MUST 180 include the value "sip" in the Sec-WebSocket-Protocol header in its 181 handshake request. The 101 reply from the server MUST contain "sip" 182 in its corresponding Sec-WebSocket-Protocol header. 184 Below is an example of the WebSocket handshake in which the client 185 requests the WebSocket SIP Sub-Protocol support from the server: 187 GET / HTTP/1.1 188 Host: sip-ws.example.com 189 Upgrade: websocket 190 Connection: Upgrade 191 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 192 Origin: http://www.example.com 193 Sec-WebSocket-Protocol: sip 194 Sec-WebSocket-Version: 13 196 The handshake response from the server supporting the WebSocket SIP 197 Sub-Protocol would look as follows: 199 HTTP/1.1 101 Switching Protocols 200 Upgrade: websocket 201 Connection: Upgrade 202 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 203 Sec-WebSocket-Protocol: sip 205 Once the negotiation is done, the WebSocket connection is established 206 with SIP as the WebSocket sub-protocol. The WebSocket messages to be 207 transmitted over this connection MUST conform to the established 208 application protocol. 210 4.2. SIP encoding 212 WebSocket messages are carried on top of WebSocket UTF-8 text frames 213 or binary frames. The SIP protocol [RFC3261] allows both text and 214 binary bodies in SIP messages. Therefore SIP WebSocket Clients and 215 SIP WebSocket Servers MUST accept both WebSocket text and binary 216 frames. 218 5. SIP WebSocket Transport 220 5.1. General 222 WebSocket [RFC6455] is a reliable protocol and therefore the 223 WebSocket sub-protocol for a SIP transport defined by this document 224 is also a reliable transport. Thus, client and server transactions 225 using WebSocket transport MUST follow the procedures and timer values 226 for reliable transports as defined in [RFC3261]. 228 Each complete SIP message MUST be carried within a single WebSocket 229 message, and a WebSocket message MUST NOT contain more than one SIP 230 message. Therefore the usage of the Content-Length header field is 231 optional. 233 This makes parsing of SIP messages easier on client side 234 (typically web-based applications with an strict and simple API 235 for receiving WebSocket messages). There is no need to establish 236 boundaries (using Content-Length headers) between different 237 messages. Same advantage is present in other message-based SIP 238 transports such as UDP or SCTP [RFC4168]. 240 5.2. Updates to RFC 3261 242 5.2.1. Via Transport Parameter 244 Via header fields carry the transport protocol identifier. This 245 document defines the value "WS" to be used for requests over plain 246 WebSocket protocol and "WSS" for requests over secure WebSocket 247 protocol (in which the WebSocket connection is established using TLS 248 [RFC5246] with TCP transport). 250 The updated RFC 3261 augmented BNF (Backus-Naur Form) [RFC5234] for 251 this parameter reads as follows: 253 transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" 254 / "WS" / "WSS" 255 / other-transport 257 5.2.2. SIP URI Transport Parameter 259 This document defines the value "ws" as the transport parameter value 260 for a SIP URI [RFC3986] to be contacted using WebSocket protocol as 261 transport. 263 The updated RFC 3261 augmented BNF (Backus-Naur Form) for this 264 parameter reads as follows: 266 transport-param = "transport=" 267 ( "udp" / "tcp" / "sctp" / "tls" / "ws" 268 / other-transport ) 270 5.2.3. Sending Responses 272 This specification updates the section 18.2.2 "Sending Responses" in 273 [RFC3261] by adding the following: 275 o If the Via "sent-protocol" is "WS" or "WSS" the response MUST be 276 sent using the existing WebSocket connection to the source of the 277 original request that created the transaction, if that connection 278 is still open. If that connection is no longer open, the server 279 SHOULD NOT attempt to open a WebSocket connection for sending the 280 response. 282 This is due to the nature of the WebSocket protocol in which just 283 the WebSocket client can establish a connection with the WebSocket 284 server. Typically a WebSocket client does not listen for inbound 285 connections and WebSocket servers do not open outbound 286 connections. 288 5.3. Locating a SIP Server 290 RFC 3263 [RFC3263] specifies the procedures which should be followed 291 by SIP entities for locating SIP servers. This specification defines 292 the NAPTR service value "SIP+D2W" for SIP WebSocket Servers that 293 support plain WebSocket transport and "SIPS+D2W" for SIP WebSocket 294 Servers that support secure WebSocket transport. 296 Unfortunately neither JavaScript stacks nor WebSocket stacks 297 running in current web browsers are capable of performing DNS 298 NAPTR/SRV queries. 300 In the absence of an explicit port and DNS SRV resource records, the 301 default port for a SIP URI with "ws" transport parameter is 80 in 302 case of SIP scheme and 443 in case of SIPS scheme. 304 6. Connection Keep Alive 306 _This section is non-normative._ 308 It is RECOMMENDED that the SIP WebSocket Client or Server keeps the 309 WebSocket connection open by sending periodic WebSocket Ping frames 310 as described in [RFC6455] section 5.5.2. 312 Note however that The WebSocket API [WS-API] does not provide a 313 mechanism for web applications running in a web browser to decide 314 whether or not to send periodic WebSocket Ping frames to the 315 server. The usage of such a keep alive feature is a decision of 316 each web browser vendor and may depend on the web browser 317 configuration. 319 Any future WebSocket protocol extension providing a keep alive 320 mechanism could also be used. 322 The SIP stack in the SIP WebSocket Client MAY also use Network 323 Address Translation (NAT) keep-alive mechanisms defined for SIP 324 connection-oriented transports, such as the CRLF Keep-Alive Technique 325 mechanism described in [RFC5626] section 3.5.1 or [RFC6223]. 327 Implementing these techniques would involve sending a WebSocket 328 message to the SIP WebSocket Server whose content is a double 329 CRLF, and expecting a WebSocket message from the server containing 330 a single CRLF as response. 332 7. Authentication 334 _This section is non-normative._ 336 Prior to sending SIP requests, the SIP WebSocket Client connects to 337 the SIP WebSocket Server and performs the connection handshake. As 338 described in Section 3 the handshake procedure involves a HTTP GET 339 request replied with HTTP 101 status code by the server. 341 In order to authorize the WebSocket connection, the SIP WebSocket 342 Server MAY inspect the Cookie [RFC6265] header in the HTTP GET 343 request (if present). In case of web applications the value of such 344 a Cookie is usually provided by the web server once the user has 345 authenticated itself with the web server by following any of the 346 multiple existing mechanisms. As an alternative method, the SIP 347 WebSocket Server could request HTTP authentication by replying with a 348 HTTP 401 status code. The WebSocket protocol [RFC6455] covers this 349 usage in section 4.1: 351 If the status code received from the server is not 101, the client 352 handles the response per HTTP [RFC2616] procedures, in particular 353 the client might perform authentication if it receives 401 status 354 code. 356 Regardless whether the SIP WebSocket Server requires authentication 357 during the WebSocket handshake or not, authentication MAY be 358 requested at SIP protocol level. Therefore it is RECOMMENDED for a 359 SIP WebSocket Client to implement HTTP Digest [RFC2617] 360 authentication as stated in [RFC3261]. 362 8. Examples 364 8.1. Registration 366 Alice (SIP WSS) proxy.atlanta.com 367 | | 368 |REGISTER F1 | 369 |---------------------------->| 370 |200 OK F2 | 371 |<----------------------------| 372 | | 373 Alice loads a web page using her web browser and retrieves a 374 JavaScript code implementing the WebSocket SIP Sub-Protocol defined 375 in this document. The JavaScript code (a SIP WebSocket Client) 376 establishes a secure WebSocket connection with a SIP proxy/registrar 377 (a SIP WebSocket Server) at proxy.atlanta.com. Upon WebSocket 378 connection, Alice constructs and sends a SIP REGISTER by requesting 379 Outbound and GRUU support. Since the JavaScript stack in a browser 380 has no way to determine the local address from which the WebSocket 381 connection is made, this implementation uses a random ".invalid" 382 domain name for the Via sent-by and for the URI hostpart in the 383 Contact header (see Appendix A.1). 385 Message details (authentication and SDP bodies are omitted for 386 simplicity): 388 F1 REGISTER Alice -> proxy.atlanta.com (transport WSS) 390 REGISTER sip:proxy.atlanta.com SIP/2.0 391 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 392 From: sip:alice@atlanta.com;tag=65bnmj.34asd 393 To: sip:alice@atlanta.com 394 Call-ID: aiuy7k9njasd 395 CSeq: 1 REGISTER 396 Max-Forwards: 70 397 Supported: path, outbound, gruu 398 Contact: 399 ;reg-id=1 400 ;+sip.instance="" 402 F2 200 OK proxy.atlanta.com -> Alice (transport WSS) 404 SIP/2.0 200 OK 405 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf 406 From: sip:alice@atlanta.com;tag=65bnmj.34asd 407 To: sip:alice@atlanta.com;tag=12isjljn8 408 Call-ID: aiuy7k9njasd 409 CSeq: 1 REGISTER 410 Supported: outbound, gruu 411 Contact: 412 ;reg-id=1 413 ;+sip.instance="" 414 ;pub-gruu="sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1" 415 ;temp-gruu="sip:87ash54=3dd.98a@atlanta.com;gr" 416 ;expires=3600 418 8.2. INVITE dialog through a proxy 420 Alice (SIP WSS) proxy.atlanta.com (SIP UDP) Bob 421 | | | 422 |INVITE F1 | | 423 |---------------------------->| | 424 |100 Trying F2 | | 425 |<----------------------------| | 426 | |INVITE F3 | 427 | |---------------------------->| 428 | |200 OK F4 | 429 | |<----------------------------| 430 |200 OK F5 | | 431 |<----------------------------| | 432 | | | 433 |ACK F6 | | 434 |---------------------------->| | 435 | |ACK F7 | 436 | |---------------------------->| 437 | | | 438 | Both Way RTP Media | 439 |<=========================================================>| 440 | | | 441 | |BYE F8 | 442 | |<----------------------------| 443 |BYE F9 | | 444 |<----------------------------| | 445 |200 OK F10 | | 446 |---------------------------->| | 447 | |200 OK F11 | 448 | |---------------------------->| 449 | | | 451 In the same scenario Alice places a call to Bob's AoR. The WebSocket 452 SIP server at proxy.atlanta.com acts as a SIP proxy routing the 453 INVITE to the UDP location of Bob, who answers the call and 454 terminates it later. 456 Message details (authentication and SDP bodies are omitted for 457 simplicity): 459 F1 INVITE Alice -> proxy.atlanta.com (transport WSS) 461 INVITE sip:bob@atlanta.com SIP/2.0 462 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 463 From: sip:alice@atlanta.com;tag=asdyka899 464 To: sip:bob@atlanta.com 465 Call-ID: asidkj3ss 466 CSeq: 1 INVITE 467 Max-Forwards: 70 468 Supported: path, outbound, gruu 469 Route: 470 Contact: " 472 Content-Type: application/sdp 474 F2 100 Trying proxy.atlanta.com -> Alice (transport WSS) 476 SIP/2.0 100 Trying 477 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 478 From: sip:alice@atlanta.com;tag=asdyka899 479 To: sip:bob@atlanta.com 480 Call-ID: asidkj3ss 481 CSeq: 1 INVITE 483 F3 INVITE proxy.atlanta.com -> Bob (transport UDP) 485 INVITE sip:bob@203.0.113.22:5060 SIP/2.0 486 Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c 487 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 488 Record-Route: , 489 490 From: sip:alice@atlanta.com;tag=asdyka899 491 To: sip:bob@atlanta.com 492 Call-ID: asidkj3ss 493 CSeq: 1 INVITE 494 Max-Forwards: 69 495 Supported: path, outbound, gruu 496 Contact: " 498 Content-Type: application/sdp 500 F4 200 OK Bob -> proxy.atlanta.com (transport UDP) 502 SIP/2.0 200 OK 503 Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c 504 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 505 Record-Route: , 506 507 From: sip:alice@atlanta.com;tag=asdyka899 508 To: sip:bob@atlanta.com;tag=bmqkjhsd 509 Call-ID: asidkj3ss 510 CSeq: 1 INVITE 511 Max-Forwards: 69 512 Contact: 513 Content-Type: application/sdp 515 F5 200 OK proxy.atlanta.com -> Alice (transport WSS) 517 SIP/2.0 200 OK 518 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks 519 Record-Route: , 520 521 From: sip:alice@atlanta.com;tag=asdyka899 522 To: sip:bob@atlanta.com;tag=bmqkjhsd 523 Call-ID: asidkj3ss 524 CSeq: 1 INVITE 525 Max-Forwards: 69 526 Contact: 527 Content-Type: application/sdp 529 F6 ACK Alice -> proxy.atlanta.com (transport WSS) 531 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 532 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 533 Route: , 534 , 535 From: sip:alice@atlanta.com;tag=asdyka899 536 To: sip:bob@atlanta.com;tag=bmqkjhsd 537 Call-ID: asidkj3ss 538 CSeq: 1 ACK 539 Max-Forwards: 70 541 F7 ACK proxy.atlanta.com -> Bob (transport UDP) 543 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 544 Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhwpoc80zzx 545 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 546 From: sip:alice@atlanta.com;tag=asdyka899 547 To: sip:bob@atlanta.com;tag=bmqkjhsd 548 Call-ID: asidkj3ss 549 CSeq: 1 ACK 550 Max-Forwards: 69 552 F8 BYE Bob -> proxy.atlanta.com (transport UDP) 553 BYE sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 554 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 555 Route: , 556 557 From: sip:bob@atlanta.com;tag=bmqkjhsd 558 To: sip:alice@atlanta.com;tag=asdyka899 559 Call-ID: asidkj3ss 560 CSeq: 1201 BYE 561 Max-Forwards: 70 563 F9 BYE proxy.atlanta.com -> Alice (transport WSS) 565 BYE sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 566 Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 567 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 568 From: sip:bob@atlanta.com;tag=bmqkjhsd 569 To: sip:alice@atlanta.com;tag=asdyka899 570 Call-ID: asidkj3ss 571 CSeq: 1201 BYE 572 Max-Forwards: 69 574 F10 200 OK Alice -> proxy.atlanta.com (transport WSS) 576 SIP/2.0 200 OK 577 Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 578 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 579 From: sip:bob@atlanta.com;tag=bmqkjhsd 580 To: sip:alice@atlanta.com;tag=asdyka899 581 Call-ID: asidkj3ss 582 CSeq: 1201 BYE 584 F11 200 OK proxy.atlanta.com -> Bob (transport UDP) 586 SIP/2.0 200 OK 587 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 588 From: sip:bob@atlanta.com;tag=bmqkjhsd 589 To: sip:alice@atlanta.com;tag=asdyka899 590 Call-ID: asidkj3ss 591 CSeq: 1201 BYE 593 9. Security Considerations 594 9.1. Secure WebSocket Connection 596 It is recommended to protect the privacy of the SIP traffic through 597 the WebSocket communication by using a secure WebSocket connection 598 (tunneled over TLS [RFC5246]). 600 9.2. Usage of SIPS Scheme 602 SIPS scheme within a SIP request dictates that the entire request 603 path to the target be secured. If such a path includes a WebSocket 604 node it MUST be a secure WebSocket connection. 606 10. IANA Considerations 608 10.1. Registration of the WebSocket SIP Sub-Protocol 610 This specification requests IANA to create the WebSocket SIP Sub- 611 Protocol in the registry of WebSocket sub-protocols with the 612 following data: 614 Subprotocol Identifier: sip 616 Subprotocol Common Name: WebSocket Transport for SIP (Session 617 Initiation Protocol) 619 Subprotocol Definition: TBD, it should point to this document 621 10.2. Registration of new Via transports 623 This specification registers two new transport identifiers for Via 624 headers: 626 WS: MUST be used when constructing a SIP request to be sent over a 627 plain WebSocket connection. 629 WSS: MUST be used when constructing a SIP request to be sent over a 630 secure WebSocket connection. 632 10.3. Registration of new SIP URI transport 634 This specification registers a new value for the "transport" 635 parameter in a SIP URI: 637 ws: Identifies a SIP URI to be contacted using a WebSocket 638 connection. 640 10.4. Registration of new NAPTR service field values 642 This document defines two new NAPTR service field values (SIP+D2W and 643 SIPS+D2W) and requests IANA to register these values under the 644 "Registry for the SIP SRV Resource Record Services Field". The 645 resulting entries are as follows: 647 Services Field Protocol Reference 648 -------------------- -------- --------- 649 SIP+D2W WS TBD: this document 650 SIPS+D2W WSS TBD: this document 652 11. Acknowledgements 654 Special thanks to the following people who participated in 655 discussions on the SIPCORE and RTCWEB WG mailing lists and 656 contributed ideas and/or provided detailed reviews (the list is 657 likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Adam Roach, 658 Ranjit Avasarala, Xavier Marjou, Kevin P. Fleming. 660 Special thanks also to Alan Johnston, Christer Holmberg and Salvatore 661 Loreto for their reviews. 663 Special thanks to Saul Ibarra Corretge for his contribution and 664 suggestions. 666 12. References 668 12.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 674 A., Peterson, J., Sparks, R., Handley, M., and E. 675 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 676 June 2002. 678 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 679 Protocol (SIP): Locating SIP Servers", RFC 3263, 680 June 2002. 682 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 683 Part Three: The Domain Name System (DNS) Database", 684 RFC 3403, October 2002. 686 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 687 Specifications: ABNF", STD 68, RFC 5234, January 2008. 689 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 690 RFC 6455, December 2011. 692 12.2. Informative References 694 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 695 Names", BCP 32, RFC 2606, June 1999. 697 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 698 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 699 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 701 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 702 Leach, P., Luotonen, A., and L. Stewart, "HTTP 703 Authentication: Basic and Digest Access Authentication", 704 RFC 2617, June 1999. 706 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 707 (SIP) Extension Header Field for Registering Non-Adjacent 708 Contacts", RFC 3327, December 2002. 710 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 711 Resource Identifier (URI): Generic Syntax", STD 66, 712 RFC 3986, January 2005. 714 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 715 Stream Control Transmission Protocol (SCTP) as a Transport 716 for the Session Initiation Protocol (SIP)", RFC 4168, 717 October 2005. 719 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 720 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 722 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 723 Initiated Connections in the Session Initiation Protocol 724 (SIP)", RFC 5626, October 2009. 726 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 727 Agent URIs (GRUUs) in the Session Initiation Protocol 728 (SIP)", RFC 5627, October 2009. 730 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 731 RFC 6223, April 2011. 733 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 734 April 2011. 736 [WS-API] Hickson, I., "The Web Sockets API", April 2012. 738 Appendix A. Implementation Guidelines 740 _This section is non-normative._ 742 Let us assume a scenario in which the users access with their web 743 browsers (probably behind NAT) to an intranet, perform web login by 744 entering their user identifier and credentials, and retrieve a 745 JavaScript code (along with the HTML code itself) implementing a SIP 746 WebSocket Client. 748 Such a SIP stack connects to a given SIP WebSocket Server (an 749 outbound SIP proxy which also implements classic SIP transports such 750 as UDP and TCP). The HTTP GET request sent by the web browser for 751 the WebSocket handshake includes a Cookie [RFC6265] header with the 752 value previously retrieved after the successful web login procedure. 753 The Cookie value is then inspected by the WebSocket server for 754 authorizing the connection. Once the WebSocket connection is 755 established, the SIP WebSocket Client performs a SIP registration and 756 common SIP stuf begins. The SIP registrar server is located behind 757 the SIP outbound proxy. 759 This scenario is quite similar to the one in which SIP UAs behind NAT 760 connect to an outbound proxy and need to reuse the same TCP 761 connection for incoming requests. In both cases, the SIP clients are 762 just reachable through the outbound proxy they are connected to. 764 Outbound [RFC5626] seems an appropriate solution for this scenario. 765 Therefore these SIP WebSocket Clients and the SIP registrar implement 766 both Outbound and Path [RFC3327], and the SIP outbound proxy becomes 767 an Outbound Edge Proxy (as defined in [RFC5626] section 3.4). 769 SIP WebSocket Clients in this scenario receive incoming SIP requests 770 via the SIP WebSocket Server they are connected to. Therefore, in 771 some call transfer cases the usage of GRUU [RFC5627] (which should be 772 implemented in both the SIP WebSocket Clients and SIP registrar) is 773 valuable. 775 If a REFER request is sent to a thirdy SIP user agent indicating 776 the Contact URI of a SIP WebSocket Client as the target in the 777 Refer-To header field, such a URI will be reachable by the thirdy 778 SIP UA just in the case it is a globally routable URI. GRUU 779 (Globally Routable User Agent URI) is a solution for those 780 scenarios, and would enforce the incoming request from the thirdy 781 SIP user agent to reach the SIP registrar which would route the 782 request via the Outbound Edge Proxy. 784 A.1. SIP WebSocket Client Considerations 786 The JavaScript stack in web browsers does not have the ability to 787 discover the local transport address which the WebSocket connection 788 is originated from. Therefore the SIP WebSocket Client creates a 789 domain consisting of a random token followed by .invalid top domain 790 name, as stated in [RFC2606], and uses it within the Via and Contact 791 header. 793 The Contact URI provided by the SIP clients requesting Outbound 794 support is not later used for routing purposes, thus it is safe to 795 set a random domain in the Contact URI hostpart. 797 Both Outbound and GRUU specifications require the SIP client to 798 indicate a Uniform Resource Name (URN) in the "+sip.instance" 799 parameter of the Contact header during the registration. The client 800 device is responsible for getting such a constant and unique value. 802 In the case of web browsers it is hard to get a URN value from the 803 browser itself. This scenario suggests that value is generated 804 according to [RFC5626] section 4.1 by the web application running 805 in the browser the first time it loads the JavaScript SIP stack 806 code, and then it is stored as a Cookie within the browser. 808 A.2. SIP WebSocket Server Considerations 810 The SIP WebSocket Server in this scenario behaves as a SIP Outbound 811 Edge Proxy, which involves support for Outbound [RFC5626] and Path 812 [RFC3327]. 814 The proxy performs Loose Routing and remains in dialogs path as 815 specified in [RFC3261]. Otherwise in-dialog requests would fail 816 since SIP WebSocket Clients make use of their SIP WebSocket Server in 817 order to send and receive SIP requests and responses. 819 Appendix B. HTTP Topology Hiding 821 _This section is non-normative._ 823 RFC 3261 [RFC3261] section 18.2.1 "Receiving Requests" states the 824 following: 826 When the server transport receives a request over any transport, 827 it MUST examine the value of the "sent-by" parameter in the top 828 Via header field value. If the host portion of the "sent-by" 829 parameter contains a domain name, or if it contains an IP address 830 that differs from the packet source address, the server MUST add a 831 "received" parameter to that Via header field value. This 832 parameter MUST contain the source address from which the packet 833 was received. 835 The requirement of adding the "received" parameter does not fit well 836 into WebSocket protocol nature. The WebSocket handshake connection 837 reuses existing HTTP infrastructure in which there could be certain 838 number of HTTP proxies and/or TCP load balancers between the SIP 839 WebSocket Client and Server, so the source IP the server would write 840 into the Via "received" parameter would be the IP of the HTTP/TCP 841 intermediary in front of it. This could reveal sensitive information 842 about the internal topology of the provider network to the client. 844 Thus, given the fact that SIP responses can only be sent over the 845 existing WebSocket connection, the meaning of the Via "received" 846 parameter added by the SIP WebSocket Server is of little use. 847 Therefore, in order to allow hiding possible sensitive information 848 about the provider infrastructure, the implementer could decide not 849 to satisfy the requirement in RFC 3261 [RFC3261] section 18.2.1 850 "Receiving Requests" and not add the "received" parameter to the Via 851 header. 853 However, keep in mind that this would involve a violation of the 854 RFC 3261. 856 Authors' Addresses 858 Inaki Baz Castillo 859 Consultant 860 Barakaldo, Basque Country 861 Spain 863 Email: ibc@aliax.net 865 Jose Luis Millan Villegas 866 Consultant 867 Bilbao, Basque Country 868 Spain 870 Email: jmillan@aliax.net 871 Victor Pascual 872 Acme Packet 873 Anabel Segura 10 874 Madrid, Madrid 28108 875 Spain 877 Email: vpascual@acmepacket.com