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