draft-ietf-sipcore-sip-websocket-04.txt   draft-ietf-sipcore-sip-websocket-05.txt 
SIPCORE Working Group I. Baz Castillo SIPCORE Working Group I. Baz Castillo
Internet-Draft J. Millan Villegas Internet-Draft J. Millan Villegas
Updates: 3261 (if approved) Versatica Updates: 3261 (if approved) Versatica
Intended status: Standards Track V. Pascual Intended status: Standards Track V. Pascual
Expires: April 4, 2013 Acme Packet Expires: April 24, 2013 Acme Packet
October 1, 2012 October 21, 2012
The WebSocket Protocol as a Transport for the Session Initiation The WebSocket Protocol as a Transport for the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipcore-sip-websocket-04 draft-ietf-sipcore-sip-websocket-05
Abstract Abstract
The WebSocket protocol enables two-way realtime communication between The WebSocket protocol enables two-way realtime communication between
clients and servers. This document specifies a new WebSocket sub- clients and servers. This document specifies a new WebSocket sub-
protocol as a reliable transport mechanism between SIP (Session protocol as a reliable transport mechanism between SIP (Session
Initiation Protocol) entities to enable usage of SIP in new Initiation Protocol) entities to enable usage of SIP in new
scenarios. scenarios. This document normatively updates RFC 3261.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2013. This Internet-Draft will expire on April 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 3 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 4
4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5
5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6
5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6
5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6
5.2.3. Via received parameter . . . . . . . . . . . . . . . . 7 5.2.3. Via received parameter . . . . . . . . . . . . . . . . 7
5.2.4. SIP transport implementation requirements . . . . . . 7 5.2.4. SIP transport implementation requirements . . . . . . 7
skipping to change at page 2, line 36 skipping to change at page 2, line 36
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15
9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16
10.2. Registration of new NAPTR service field values . . . . . . 16 10.2. Registration of new NAPTR service field values . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 16
10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17
10.5. Header Field Parameters and Parameter Values
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 18 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 19
A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 19 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 20
A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 20 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The WebSocket [RFC6455] protocol enables message exchange between The WebSocket [RFC6455] protocol enables message exchange between
clients and servers on top of a persistent TCP connection (optionally clients and servers on top of a persistent TCP connection (optionally
secured with TLS [RFC5246]). The initial protocol handshake makes secured with TLS [RFC5246]). The initial protocol handshake makes
use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to
reuse existing HTTP infrastructure. reuse existing HTTP infrastructure.
Modern web browsers include a WebSocket client stack complying with Modern web browsers include a WebSocket client stack complying with
skipping to change at page 3, line 27 skipping to change at page 3, line 27
stack available. The specification in this document enables usage of stack available. The specification in this document enables usage of
SIP in these scenarios. SIP in these scenarios.
This specification defines a new WebSocket sub-protocol (as defined This specification defines a new WebSocket sub-protocol (as defined
in section 1.9 in [RFC6455]) for transporting SIP messages between a in section 1.9 in [RFC6455]) for transporting SIP messages between a
WebSocket client and server, a new reliable and message boundary WebSocket client and server, a new reliable and message boundary
transport for SIP, new DNS NAPTR [RFC3403] service values and transport for SIP, new DNS NAPTR [RFC3403] service values and
procedures for SIP entities implementing the WebSocket transport. procedures for SIP entities implementing the WebSocket transport.
Media transport is out of the scope of this document. Media transport is out of the scope of this document.
Section 3 in this specification relaxes the requirement in [RFC3261]
by which the SIP server transport MUST add a "received" parameter in
the top Via header in certain circumstances.
2. Terminology 2. Terminology
All diagrams, examples, and notes in this specification are non- All diagrams, examples, and notes in this specification are non-
normative, as are all sections explicitly marked non-normative. normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 10, line 4 skipping to change at page 10, line 4
Regardless of whether the SIP WebSocket Server requires Regardless of whether the SIP WebSocket Server requires
authentication during the WebSocket handshake, authentication MAY be authentication during the WebSocket handshake, authentication MAY be
requested at SIP protocol level. Therefore it is RECOMMENDED that a requested at SIP protocol level. Therefore it is RECOMMENDED that a
SIP WebSocket Client implements HTTP Digest [RFC2617] authentication SIP WebSocket Client implements HTTP Digest [RFC2617] authentication
as stated in [RFC3261]. as stated in [RFC3261].
8. Examples 8. Examples
8.1. Registration 8.1. Registration
Alice (SIP WSS) proxy.atlanta.com Alice (SIP WSS) proxy.example.com
| | | |
|HTTP GET (WS handshake) F1 | |HTTP GET (WS handshake) F1 |
|---------------------------->| |---------------------------->|
|101 Switching Protocols F2 | |101 Switching Protocols F2 |
|<----------------------------| |<----------------------------|
| | | |
|REGISTER F3 | |REGISTER F3 |
|---------------------------->| |---------------------------->|
|200 OK F4 | |200 OK F4 |
|<----------------------------| |<----------------------------|
| | | |
Alice loads a web page using her web browser and retrieves JavaScript Alice loads a web page using her web browser and retrieves JavaScript
code implementing the WebSocket SIP sub-protocol defined in this code implementing the WebSocket SIP sub-protocol defined in this
document. The JavaScript code (a SIP WebSocket Client) establishes a document. The JavaScript code (a SIP WebSocket Client) establishes a
secure WebSocket connection with a SIP proxy/registrar (a SIP secure WebSocket connection with a SIP proxy/registrar (a SIP
WebSocket Server) at proxy.atlanta.com. Upon WebSocket connection, WebSocket Server) at proxy.example.com. Upon WebSocket connection,
Alice constructs and sends a SIP REGISTER request including Outbound Alice constructs and sends a SIP REGISTER request including Outbound
and GRUU support. Since the JavaScript stack in a browser has no way and GRUU support. Since the JavaScript stack in a browser has no way
to determine the local address from which the WebSocket connection to determine the local address from which the WebSocket connection
was made, this implementation uses a random ".invalid" domain name was made, this implementation uses a random ".invalid" domain name
for the Via header sent-by parameter and for the hostport of the URI for the Via header sent-by parameter and for the hostport of the URI
in the Contact header (see Appendix A.1). in the Contact header (see Appendix A.1).
Message details (authentication and SDP bodies are omitted for Message details (authentication and SDP bodies are omitted for
simplicity): simplicity):
F1 HTTP GET (WS handshake) Alice -> proxy.atlanta.com (TLS) F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS)
GET / HTTP/1.1 GET / HTTP/1.1
Host: proxy.atlanta.com Host: proxy.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.atlanta.com Origin: https://www.example.com
Sec-WebSocket-Protocol: sip Sec-WebSocket-Protocol: sip
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
F2 101 Switching Protocols proxy.atlanta.com -> Alice (TLS) F2 101 Switching Protocols proxy.example.com -> Alice (TLS)
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: sip Sec-WebSocket-Protocol: sip
F3 REGISTER Alice -> proxy.atlanta.com (transport WSS) F3 REGISTER Alice -> proxy.example.com (transport WSS)
REGISTER sip:proxy.atlanta.com SIP/2.0 REGISTER sip:proxy.example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
From: sip:alice@atlanta.com;tag=65bnmj.34asd From: sip:alice@example.com;tag=65bnmj.34asd
To: sip:alice@atlanta.com To: sip:alice@example.com
Call-ID: aiuy7k9njasd Call-ID: aiuy7k9njasd
CSeq: 1 REGISTER CSeq: 1 REGISTER
Max-Forwards: 70 Max-Forwards: 70
Supported: path, outbound, gruu Supported: path, outbound, gruu
Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws> Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws>
;reg-id=1 ;reg-id=1
;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>" ;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>"
F4 200 OK proxy.atlanta.com -> Alice (transport WSS) F4 200 OK proxy.example.com -> Alice (transport WSS)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
From: sip:alice@atlanta.com;tag=65bnmj.34asd From: sip:alice@example.com;tag=65bnmj.34asd
To: sip:alice@atlanta.com;tag=12isjljn8 To: sip:alice@example.com;tag=12isjljn8
Call-ID: aiuy7k9njasd Call-ID: aiuy7k9njasd
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: outbound, gruu Supported: outbound, gruu
Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws> Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws>
;reg-id=1 ;reg-id=1
;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>" ;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>"
;pub-gruu="sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1" ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1"
;temp-gruu="sip:87ash54=3dd.98a@atlanta.com;gr" ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr"
;expires=3600 ;expires=3600
8.2. INVITE dialog through a proxy 8.2. INVITE dialog through a proxy
Alice (SIP WSS) proxy.atlanta.com (SIP UDP) Bob Alice (SIP WSS) proxy.example.com (SIP UDP) Bob
| | | | | |
|INVITE F1 | | |INVITE F1 | |
|---------------------------->| | |---------------------------->| |
|100 Trying F2 | | |100 Trying F2 | |
|<----------------------------| | |<----------------------------| |
| |INVITE F3 | | |INVITE F3 |
| |---------------------------->| | |---------------------------->|
| |200 OK F4 | | |200 OK F4 |
| |<----------------------------| | |<----------------------------|
|200 OK F5 | | |200 OK F5 | |
skipping to change at page 12, line 36 skipping to change at page 12, line 36
| |<----------------------------| | |<----------------------------|
|BYE F9 | | |BYE F9 | |
|<----------------------------| | |<----------------------------| |
|200 OK F10 | | |200 OK F10 | |
|---------------------------->| | |---------------------------->| |
| |200 OK F11 | | |200 OK F11 |
| |---------------------------->| | |---------------------------->|
| | | | | |
In the same scenario Alice places a call to Bob's AoR (Address Of In the same scenario Alice places a call to Bob's AoR (Address Of
Record). The SIP WebSocket Server at proxy.atlanta.com acts as a SIP Record). The SIP WebSocket Server at proxy.example.com acts as a SIP
proxy, routing the INVITE to Bob's contact address (which happens to proxy, routing the INVITE to Bob's contact address (which happens to
be using SIP transported over UDP). Bob answers the call and then be using SIP transported over UDP). Bob answers the call and then
terminates it. terminates it.
Message details (authentication and SDP bodies are omitted for Message details (authentication and SDP bodies are omitted for
simplicity): simplicity):
F1 INVITE Alice -> proxy.atlanta.com (transport WSS) F1 INVITE Alice -> proxy.example.com (transport WSS)
INVITE sip:bob@atlanta.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@example.com;tag=asdyka899
To: sip:bob@atlanta.com To: sip:bob@example.com
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 Max-Forwards: 70
Supported: path, outbound, gruu Supported: path, outbound, gruu
Route: <sip:proxy.atlanta.com:443;transport=ws;lr> Route: <sip:proxy.example.com:443;transport=ws;lr>
Contact: <sip:alice@atlanta.com Contact: <sip:alice@example.com
;gr=urn:uuid:f81-7dec-14a06cf1;ob> ;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp Content-Type: application/sdp
F2 100 Trying proxy.atlanta.com -> Alice (transport WSS) F2 100 Trying proxy.example.com -> Alice (transport WSS)
SIP/2.0 100 Trying SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@example.com;tag=asdyka899
To: sip:bob@atlanta.com To: sip:bob@example.com
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 INVITE CSeq: 1 INVITE
F3 INVITE proxy.atlanta.com -> Bob (transport UDP) F3 INVITE proxy.example.com -> Bob (transport UDP)
INVITE sip:bob@203.0.113.22:5060 SIP/2.0 INVITE sip:bob@203.0.113.22:5060 SIP/2.0
Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.atlanta.com;transport=udp;lr>, Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr> <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@example.com;tag=asdyka899
To: sip:bob@atlanta.com To: sip:bob@example.com
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 69 Max-Forwards: 69
Supported: path, outbound, gruu Supported: path, outbound, gruu
Contact: <sip:alice@atlanta.com Contact: <sip:alice@example.com
;gr=urn:uuid:f81-7dec-14a06cf1;ob> ;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp Content-Type: application/sdp
F4 200 OK Bob -> proxy.atlanta.com (transport UDP) F4 200 OK Bob -> proxy.example.com (transport UDP)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
;received=192.0.2.10 ;received=192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.atlanta.com;transport=udp;lr>, Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr> <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@example.com;tag=asdyka899
To: sip:bob@atlanta.com;tag=bmqkjhsd To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=udp> Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp Content-Type: application/sdp
F5 200 OK proxy.atlanta.com -> Alice (transport WSS) F5 200 OK proxy.example.com -> Alice (transport WSS)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.atlanta.com;transport=udp;lr>, Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr> <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@example.com;tag=asdyka899
To: sip:bob@atlanta.com;tag=bmqkjhsd To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=udp> Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp Content-Type: application/sdp
F6 ACK Alice -> proxy.atlanta.com (transport WSS) F6 ACK Alice -> proxy.example.com (transport WSS)
ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
Route: <sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr>, Route: <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>,
<sip:proxy.atlanta.com;transport=udp;lr>, <sip:proxy.example.com;transport=udp;lr>,
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@example.com;tag=asdyka899
To: sip:bob@atlanta.com;tag=bmqkjhsd To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 ACK CSeq: 1 ACK
Max-Forwards: 70 Max-Forwards: 70
F7 ACK proxy.atlanta.com -> Bob (transport UDP) F7 ACK proxy.example.com -> Bob (transport UDP)
ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP proxy.atlanta.com;branch=z9hG4bKhwpoc80zzx Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
From: sip:alice@atlanta.com;tag=asdyka899 From: sip:alice@example.com;tag=asdyka899
To: sip:bob@atlanta.com;tag=bmqkjhsd To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1 ACK CSeq: 1 ACK
Max-Forwards: 69 Max-Forwards: 69
F8 BYE Bob -> proxy.atlanta.com (transport UDP) F8 BYE Bob -> proxy.example.com (transport UDP)
BYE sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
Route: <sip:proxy.atlanta.com;transport=udp;lr>, Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.atlanta.com:443;transport=ws;lr> <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:bob@atlanta.com;tag=bmqkjhsd From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@atlanta.com;tag=asdyka899 To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1201 BYE CSeq: 1201 BYE
Max-Forwards: 70 Max-Forwards: 70
F9 BYE proxy.atlanta.com -> Alice (transport WSS) F9 BYE proxy.example.com -> Alice (transport WSS)
BYE sip:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@atlanta.com;tag=bmqkjhsd From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@atlanta.com;tag=asdyka899 To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1201 BYE CSeq: 1201 BYE
Max-Forwards: 69 Max-Forwards: 69
F10 200 OK Alice -> proxy.atlanta.com (transport WSS) F10 200 OK Alice -> proxy.example.com (transport WSS)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@atlanta.com;tag=bmqkjhsd From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@atlanta.com;tag=asdyka899 To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1201 BYE CSeq: 1201 BYE
F11 200 OK proxy.atlanta.com -> Bob (transport UDP) F11 200 OK proxy.example.com -> Bob (transport UDP)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@atlanta.com;tag=bmqkjhsd From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@atlanta.com;tag=asdyka899 To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1201 BYE CSeq: 1201 BYE
9. Security Considerations 9. Security Considerations
9.1. Secure WebSocket Connection 9.1. Secure WebSocket Connection
It is recommended that the SIP traffic transported over a WebSocket It is recommended that the SIP traffic transported over a WebSocket
communication be protected by using a secure WebSocket connection communication be protected by using a secure WebSocket connection
(using TLS [RFC5246] over TCP). (using TLS [RFC5246] over TCP).
skipping to change at page 16, line 17 skipping to change at page 16, line 17
The SIPS scheme in a SIP URI dictates that the entire request path to The SIPS scheme in a SIP URI dictates that the entire request path to
the target be secure. If such a path includes a WebSocket connection the target be secure. If such a path includes a WebSocket connection
it MUST be a secure WebSocket connection. it MUST be a secure WebSocket connection.
10. IANA Considerations 10. IANA Considerations
10.1. Registration of the WebSocket SIP Sub-Protocol 10.1. Registration of the WebSocket SIP Sub-Protocol
This specification requests IANA to register the WebSocket SIP sub- This specification requests IANA to register the WebSocket SIP sub-
protocol in the registry of WebSocket sub-protocols with the protocol under the "WebSocket Subprotocol Name" Registry with the
following data: following data:
Subprotocol Identifier: sip Subprotocol Identifier: sip
Subprotocol Common Name: WebSocket Transport for SIP (Session Subprotocol Common Name: WebSocket Transport for SIP (Session
Initiation Protocol) Initiation Protocol)
Subprotocol Definition: TBD, it should point to this document Subprotocol Definition: TBD: this document
10.2. Registration of new NAPTR service field values 10.2. Registration of new NAPTR service field values
This document defines two new NAPTR service field values (SIP+D2W and This document defines two new NAPTR service field values (SIP+D2W and
SIPS+D2W) and requests IANA to register these values under the SIPS+D2W) and requests IANA to register these values under the
"Registry for the SIP SRV Resource Record Services Field". The "Registry for the SIP SRV Resource Record Services Field". The
resulting entries are as follows: resulting entries are as follows:
Services Field Protocol Reference Services Field Protocol Reference
-------------------- -------- --------- -------------- -------- ---------
SIP+D2W WS TBD: this document SIP+D2W WS TBD: this document
SIPS+D2W WSS TBD: this document SIPS+D2W WSS TBD: this document
10.3. SIP/SIPS URI Parameters Sub-Registry
This specification requests IANA to add a reference to this document
under the "SIP/SIPS URI Parameters" Sub-Registry within the "Session
Initiation Protocol (SIP) Parameters" Registry:
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
transport Yes [RFC3261][TBD: this document]
10.4. Header Fields Sub-Registry
This specification requests IANA to add a reference to this document
under the "Header Fields" Sub-Registry within the "Session Initiation
Protocol (SIP) Parameters" Registry:
Header Name compact Reference
----------- ------- ---------
Via v [RFC3261][TBD: this document]
10.5. Header Field Parameters and Parameter Values Sub-Registry
This specification requests IANA to add a reference to this document
under the "Header Field Parameters and Parameter Values" Sub-Registry
within the "Session Initiation Protocol (SIP) Parameters" Registry:
Predefined
Header Field Parameter Name Values Reference
------------ -------------- ------ ---------
Via received No [RFC3261][TBD: this document]
11. Acknowledgements 11. Acknowledgements
Special thanks to the following people who participated in Special thanks to the following people who participated in
discussions on the SIPCORE and RTCWEB WG mailing lists and discussions on the SIPCORE and RTCWEB WG mailing lists and
contributed ideas and/or provided detailed reviews (the list is contributed ideas and/or provided detailed reviews (the list is
likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Adam Roach, likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Adam Roach,
Ranjit Avasarala, Xavier Marjou, Nataraju A. B. Ranjit Avasarala, Xavier Marjou, Nataraju A. B.
Special thanks to Alan Johnston, Christer Holmberg and Salvatore Special thanks to Alan Johnston, Christer Holmberg and Salvatore
 End of changes. 57 change blocks. 
88 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/