draft-ietf-sipcore-sip-websocket-01.txt   draft-ietf-sipcore-sip-websocket-02.txt 
SIPCORE Working Group I. Baz Castillo SIPCORE Working Group I. Baz Castillo
Internet-Draft J. Millan Villegas Internet-Draft J. Millan Villegas
Intended status: Standards Track Consultant Intended status: Standards Track Unaffiliated
Expires: December 29, 2012 V. Pascual Expires: January 31, 2013 V. Pascual
Acme Packet Acme Packet
June 27, 2012 July 30, 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-01 draft-ietf-sipcore-sip-websocket-02
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 and enables usage of the SIP protocol Initiation Protocol) entities to enable usage of SIP in new
in new scenarios. scenarios.
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 December 29, 2012. This Internet-Draft will expire on January 31, 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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . 3
4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 6 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 7
6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7 6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 10 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 14 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15
9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 14 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 14 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 15
10.2. Registration of new Via transports . . . . . . . . . . . . 14 10.2. Registration of new NAPTR service field values . . . . . . 15
10.3. Registration of new SIP URI transport . . . . . . . . . . 15
10.4. Registration of new NAPTR service field values . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 17 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 17
A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 18 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 18
A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 18 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 19
Appendix B. HTTP Topology Hiding . . . . . . . . . . . . . . . . 19 Appendix B. HTTP Topology Hiding . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The WebSocket [RFC6455] protocol enables messages 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
The WebSocket API [WS-API] as specified by the W3C. It is expected the WebSocket API [WS-API] as specified by the W3C. It is expected
that other client applications (those running in personal computers that other client applications (those running in personal computers
and devices such as smartphones) will also run a WebSocket client and devices such as smartphones) will also make a WebSocket client
stack. The specification in this document enables usage of the SIP stack available. The specification in this document enables usage of
protocol in those new scenarios. SIP in these scenarios.
This specification defines a new WebSocket sub-protocol (section 1.9 This specification defines a new WebSocket sub-protocol (as defined
in [RFC6455]) for transporting SIP messages between a WebSocket in section 1.9 in [RFC6455]) for transporting SIP messages between a
client and server, a new reliable and message boundary transport for WebSocket client and server, a new reliable and message boundary
the SIP protocol, 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.
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].
2.1. Definitions 2.1. Definitions
SIP WebSocket Client: A SIP entity capable of opening outbound SIP WebSocket Client: A SIP entity capable of opening outbound
connections with WebSocket servers and speaking the WebSocket connections to WebSocket servers and communicating using the
SIP Sub-Protocol as defined by this document. WebSocket SIP sub-protocol as defined by this document.
SIP WebSocket Server: A SIP entity capable of listening for inbound SIP WebSocket Server: A SIP entity capable of listening for inbound
connections from WebSocket clients and speaking the WebSocket connections from WebSocket clients and communicating using the
SIP Sub-Protocol as defined by this document. WebSocket SIP sub-protocol as defined by this document.
3. The WebSocket Protocol 3. The WebSocket Protocol
_This section is non-normative._ _This section is non-normative._
WebSocket protocol [RFC6455] is a transport layer on top of TCP The WebSocket protocol [RFC6455] is a transport layer on top of TCP
(optionally secured with TLS [RFC5246]) in which both client and (optionally secured with TLS [RFC5246]) in which both client and
server exchange message units in both directions. The protocol server exchange message units in both directions. The protocol
defines a connection handshake, WebSocket sub-protocol and extensions defines a connection handshake, WebSocket sub-protocol and extensions
negotiation, a frame format for sending application and control data, negotiation, a frame format for sending application and control data,
a masking mechanism, and status codes for indicating disconnection a masking mechanism, and status codes for indicating disconnection
causes. causes.
The WebSocket connection handshake is based on HTTP [RFC2616] The WebSocket connection handshake is based on HTTP [RFC2616] and
protocol by means of a specific HTTP GET method with Upgrade request utilizes the HTTP GET method with an "Upgrade" request. This is sent
sent by the client which is answered by the server (if the by the client and then answered by the server (if the negotiation
negotiation succeeded) with HTTP 101 status code. Once the handshake succeeded) with an HTTP 101 status code. Once the handshake is
is done the connection upgrades from HTTP to the WebSocket protocol. completed the connection upgrades from HTTP to the WebSocket
This handshake procedure is designed to reuse the existing HTTP protocol. This handshake procedure is designed to reuse the existing
infrastructure. During the connection handshake, client and server HTTP infrastructure. During the connection handshake, client and
agree in the application protocol to use on top of the WebSocket server agree on the application protocol to use on top of the
transport. Such application protocol (also known as the "WebSocket WebSocket transport. Such application protocol (also known as a
sub-protocol") defines the format and semantics of the messages "WebSocket sub-protocol") defines the format and semantics of the
exchanged between both endpoints. It may be a custom protocol or a messages exchanged by the endpoints. This could be a custom protocol
standarized one (as the WebSocket SIP Sub-Protocol proposed in this or a standardized one (as the WebSocket SIP sub-protocol defined in
document). Once the HTTP 101 response is processed both client and this document). Once the HTTP 101 response is processed both client
server reuse the underlying TCP connection for sending WebSocket and server reuse the underlying TCP connection for sending WebSocket
messages and control frames to each other in a persistent way. messages and control frames to each other. Unlike plain HTTP, this
connection is persistent and can be used for multiple message
exchanges.
WebSocket defines message units as application data exchange for WebSocket defines message units to be used by applications for the
communication endpoints, becoming a message boundary transport layer. exchange of data, so it provides a message boundary-preserving
These messages can contain UTF-8 text or binary data, and can be transport layer. These message units can contain either UTF-8 text
split into various WebSocket text/binary frames. or binary data, and can be split into multiple WebSocket text/binary
transport frames as needed by the WebSocket stack.
However, the WebSocket API [WS-API] for web browsers just includes The WebSocket API [WS-API] for web browsers only defines callbacks
callbacks that are invoked upon receipt of an entire message, to be invoked upon receipt of an entire message unit, regardless
regardless of whether it was received in a single or multiple of whether it was received in a single Websocket frame or split
WebSocket frames. across multiple frames.
4. The WebSocket SIP Sub-Protocol 4. The WebSocket SIP Sub-Protocol
The term WebSocket sub-protocol refers to the application-level The term WebSocket sub-protocol refers to an application-level
protocol layered on top of a WebSocket connection. This document protocol layered on top of a WebSocket connection. This document
specifies the WebSocket SIP Sub-Protocol for carrying SIP requests specifies the WebSocket SIP sub-protocol for carrying SIP requests
and responses through a WebSocket connection. and responses through a WebSocket connection.
4.1. Handshake 4.1. Handshake
The SIP WebSocket Client and SIP WebSocket Server need to agree on The SIP WebSocket Client and SIP WebSocket Server negotiate usage of
the WebSocket SIP Sub-Protocol during the WebSocket handshake the WebSocket SIP sub-protocol during the WebSocket handshake
procedure as defined in section 1.3 of [RFC6455]. The client MUST procedure as defined in section 1.3 of [RFC6455]. The Client MUST
include the value "sip" in the Sec-WebSocket-Protocol header in its include the value "sip" in the Sec-WebSocket-Protocol header in its
handshake request. The 101 reply from the server MUST contain "sip" handshake request. The 101 reply from the Server MUST contain "sip"
in its corresponding Sec-WebSocket-Protocol header. in its corresponding Sec-WebSocket-Protocol header.
Below is an example of the WebSocket handshake in which the client Below is an example of a WebSocket handshake in which the Client
requests the WebSocket SIP Sub-Protocol support from the server: requests the WebSocket SIP sub-protocol support from the Server:
GET / HTTP/1.1 GET / HTTP/1.1
Host: sip-ws.example.com Host: sip-ws.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com Origin: http://www.example.com
Sec-WebSocket-Protocol: sip Sec-WebSocket-Protocol: sip
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
The handshake response from the server supporting the WebSocket SIP The handshake response from the Server accepting the WebSocket SIP
Sub-Protocol would look as follows: sub-protocol would look as follows:
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
Once the negotiation is done, the WebSocket connection is established Once the negotiation has been completed, the WebSocket connection is
with SIP as the WebSocket sub-protocol. The WebSocket messages to be established and can be used for the transport of SIP requests and
transmitted over this connection MUST conform to the established responses. The WebSocket messages transmitted over this connection
application protocol. MUST conform to the negotiated WebSocket sub-protocol.
4.2. SIP encoding 4.2. SIP encoding
WebSocket messages are carried on top of WebSocket UTF-8 text frames WebSocket messages can be transported in either UTF-8 text frames or
or binary frames. The SIP protocol [RFC3261] allows both text and binary frames. SIP [RFC3261] allows both text and binary bodies in
binary bodies in SIP messages. Therefore SIP WebSocket Clients and SIP requests and responses. Therefore SIP WebSocket Clients and SIP
SIP WebSocket Servers MUST accept both WebSocket text and binary WebSocket Servers MUST accept both text and binary frames.
frames.
5. SIP WebSocket Transport 5. SIP WebSocket Transport
5.1. General 5.1. General
WebSocket [RFC6455] is a reliable protocol and therefore the WebSocket [RFC6455] is a reliable protocol and therefore the SIP
WebSocket sub-protocol for a SIP transport defined by this document WebSocket sub-protocol defined by this document is a reliable SIP
is also a reliable transport. Thus, client and server transactions transport. Thus, client and server transactions using WebSocket for
using WebSocket transport MUST follow the procedures and timer values transport MUST follow the procedures and timer values for reliable
for reliable transports as defined in [RFC3261]. transports as defined in [RFC3261].
Each complete SIP message MUST be carried within a single WebSocket Each SIP message MUST be carried within a single WebSocket message,
message, and a WebSocket message MUST NOT contain more than one SIP and a WebSocket message MUST NOT contain more than one SIP message.
message. Therefore the usage of the Content-Length header field is Because the WebSocket transport preserves message boundaries, the use
optional. of the Content-Length header in SIP messages is optional when they
are transported using the WebSocket sub-protocol.
This makes parsing of SIP messages easier on client side This simplifies parsing of SIP messages for both clients and
(typically web-based applications with a strict and simple API for servers. There is no need to establish message boundaries using
receiving WebSocket messages). There is no need to establish Content-Length headers between messages. Other SIP transports,
boundaries (using Content-Length headers) between different such as UDP and SCTP [RFC4168] also provide this benefit.
messages. Same advantage is present in other message-based SIP
transports such as UDP or SCTP [RFC4168].
5.2. Updates to RFC 3261 5.2. Updates to RFC 3261
5.2.1. Via Transport Parameter 5.2.1. Via Transport Parameter
Via header fields carry the transport protocol identifier. This Via header fields in SIP messages carry a transport protocol
document defines the value "WS" to be used for requests over plain identifier. This document defines the value "WS" to be used for
WebSocket protocol and "WSS" for requests over secure WebSocket requests over plain WebSocket connections and "WSS" for requests over
protocol (in which the WebSocket connection is established using TLS secure WebSocket connections (in which the WebSocket connection is
[RFC5246] with TCP transport). established using TLS [RFC5246] with TCP transport).
The updated RFC 3261 augmented BNF (Backus-Naur Form) [RFC5234] for The updated augmented BNF (Backus-Naur Form) [RFC5234] for this
this parameter reads as follows: parameter is the following (the original BNF for this parameter can
be found in [RFC3261], which was then updated by [RFC4168]):
transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
/ "WS" / "WSS" / "WS" / "WSS"
/ other-transport / other-transport
5.2.2. SIP URI Transport Parameter 5.2.2. SIP URI Transport Parameter
This document defines the value "ws" as the transport parameter value This document defines the value "ws" as the transport parameter value
for a SIP URI [RFC3986] to be contacted using WebSocket protocol as for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub-
transport. protocol as transport.
The updated RFC 3261 augmented BNF (Backus-Naur Form) for this The updated augmented BNF (Backus-Naur Form) for this parameter is
parameter reads as follows: the following (the original BNF for this parameter can be found in
[RFC3261], which was then updated by [RFC4168]):
transport-param = "transport=" transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls" / "ws" ( "udp" / "tcp" / "sctp" / "tls" / "ws"
/ other-transport ) / other-transport )
5.3. Locating a SIP Server 5.3. Locating a SIP Server
RFC 3263 [RFC3263] specifies the procedures which should be followed [RFC3263] specifies the procedures which should be followed by SIP
by SIP entities for locating SIP servers. This specification defines entities for locating SIP servers. This specification defines the
the NAPTR service value "SIP+D2W" for SIP WebSocket Servers that NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support
support plain WebSocket transport and "SIPS+D2W" for SIP WebSocket plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers
Servers that support secure WebSocket transport. that support secure WebSocket connections.
Unfortunately neither JavaScript stacks nor WebSocket stacks At the time this document was written, DNS NAPTR/SRV queries could
running in current web browsers are capable of performing DNS not be performed by commonly available WebSocket client stacks (in
NAPTR/SRV queries. JavaScript engines and web browsers).
In the absence of an explicit port and DNS SRV resource records, the In the absence of DNS SRV resource records or an explicit port, the
default port for a SIP URI with "ws" transport parameter is 80 in default port for a SIP URI using the "sip" scheme and the "ws"
case of SIP scheme and 443 in case of SIPS scheme. transport parameter is 80, and the default port for a SIP URI using
the "sips" scheme and the "ws" transport parameter is 443.
6. Connection Keep Alive 6. Connection Keep Alive
_This section is non-normative._ _This section is non-normative._
It is RECOMMENDED that the SIP WebSocket Client or Server keeps the It is RECOMMENDED that SIP WebSocket Clients and Servers keep their
WebSocket connection open by sending periodic WebSocket Ping frames WebSocket connections open by sending periodic WebSocket "Ping"
as described in [RFC6455] section 5.5.2. frames as described in [RFC6455] section 5.5.2.
Note however that The WebSocket API [WS-API] does not provide a The WebSocket API [WS-API] does not provide a mechanism for
mechanism for web applications running in a web browser to decide applications running in a web browser to control whether or not
whether or not to send periodic WebSocket Ping frames to the periodic WebSocket "Ping" frames are sent to the server. The
server. The usage of such a keep alive feature is a decision of implementation of such a keep alive feature is the decision of
each web browser vendor and may depend on the web browser each web browser manufacturer and may also depend on the
configuration. configuration of the web browser.
Any future WebSocket protocol extension providing a keep alive A future WebSocket protocol extension providing a similar keep alive
mechanism could also be used. mechanism could also be used.
The SIP stack in the SIP WebSocket Client MAY also use Network The SIP stack in the SIP WebSocket Client MAY also use a Network
Address Translation (NAT) keep-alive mechanisms defined for SIP Address Translation (NAT) keep-alive mechanism defined for SIP
connection-oriented transports, such as the CRLF Keep-Alive Technique connection-oriented transports, such as the CRLF Keep-Alive Technique
mechanism described in [RFC5626] section 3.5.1 or [RFC6223]. mechanism described in [RFC5626] section 3.5.1 or [RFC6223].
Implementing these techniques would involve sending a WebSocket Implementing this technique would involve sending a WebSocket
message to the SIP WebSocket Server whose content is a double message to the SIP WebSocket Server with a content consisting of
CRLF, and expecting a WebSocket message from the server containing only a double CRLF, and expecting a WebSocket message from the
a single CRLF as response. server containing a single CRLF as response.
7. Authentication 7. Authentication
_This section is non-normative._ _This section is non-normative._
Prior to sending SIP requests, the SIP WebSocket Client connects to Prior to sending SIP requests, a SIP WebSocket Client connects to a
the SIP WebSocket Server and performs the connection handshake. As SIP WebSocket Server and performs the connection handshake. As
described in Section 3 the handshake procedure involves a HTTP GET described in Section 3 the handshake procedure involves a HTTP GET
request replied with HTTP 101 status code by the server. method request from the Client and a response from the Server
including an HTTP 101 status code.
In order to authorize the WebSocket connection, the SIP WebSocket In order to authorize the WebSocket connection, the SIP WebSocket
Server MAY inspect the Cookie [RFC6265] header in the HTTP GET Server MAY inspect any Cookie [RFC6265] headers present in the HTTP
request (if present). In case of web applications the value of such GET request. For many web applications the value of such a Cookie is
a Cookie is usually provided by the web server once the user has provided by the web server once the user has authenticated themselves
authenticated itself with the web server by following any of the to the web server, which could be done by many existing mechanisms.
multiple existing mechanisms. As an alternative method, the SIP As an alternative method, the SIP WebSocket Server could request HTTP
WebSocket Server could request HTTP authentication by replying with a authentication by replying to the Client's GET method request with a
HTTP 401 status code. The WebSocket protocol [RFC6455] covers this HTTP 401 status code. The WebSocket protocol [RFC6455] covers this
usage in section 4.1: usage in section 4.1:
If the status code received from the server is not 101, the client If the status code received from the server is not 101, the
handles the response per HTTP [RFC2616] procedures, in particular WebSocket client stack handles the response per HTTP [RFC2616]
the client might perform authentication if it receives 401 status procedures, in particular the client might perform authentication
code. if it receives 401 status code.
Regardless whether the SIP WebSocket Server requires authentication Regardless of whether the SIP WebSocket Server requires
during the WebSocket handshake or not, authentication MAY be authentication during the WebSocket handshake, authentication MAY be
requested at SIP protocol level. Therefore it is RECOMMENDED for a requested at SIP protocol level. Therefore it is RECOMMENDED that a
SIP WebSocket Client to implement HTTP Digest [RFC2617] SIP WebSocket Client implements HTTP Digest [RFC2617] authentication
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.atlanta.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 |
skipping to change at page 8, line 43 skipping to change at page 9, line 17
|---------------------------->| |---------------------------->|
|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 a Alice loads a web page using her web browser and retrieves JavaScript
JavaScript code implementing the WebSocket SIP Sub-Protocol defined code implementing the WebSocket SIP sub-protocol defined in this
in this document. The JavaScript code (a SIP WebSocket Client) document. The JavaScript code (a SIP WebSocket Client) establishes a
establishes a secure WebSocket connection with a SIP proxy/registrar secure WebSocket connection with a SIP proxy/registrar (a SIP
(a SIP WebSocket Server) at proxy.atlanta.com. Upon WebSocket WebSocket Server) at proxy.atlanta.com. Upon WebSocket connection,
connection, Alice constructs and sends a SIP REGISTER by requesting Alice constructs and sends a SIP REGISTER request including Outbound
Outbound and GRUU support. Since the JavaScript stack in a browser and GRUU support. Since the JavaScript stack in a browser has no way
has no way to determine the local address from which the WebSocket to determine the local address from which the WebSocket connection
connection is made, this implementation uses a random ".invalid" was made, this implementation uses a random ".invalid" domain name
domain name for the Via sent-by and for the URI hostpart in the for the Via header sent-by parameter and for the hostpart of the URI
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.atlanta.com (TLS)
GET / HTTP/1.1 GET / HTTP/1.1
Host: proxy.atlanta.com Host: proxy.atlanta.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
skipping to change at page 10, line 36 skipping to change at page 11, line 22
| |200 OK F4 | | |200 OK F4 |
| |<----------------------------| | |<----------------------------|
|200 OK F5 | | |200 OK F5 | |
|<----------------------------| | |<----------------------------| |
| | | | | |
|ACK F6 | | |ACK F6 | |
|---------------------------->| | |---------------------------->| |
| |ACK F7 | | |ACK F7 |
| |---------------------------->| | |---------------------------->|
| | | | | |
| Both Way RTP Media | | Bidirectional RTP Media |
|<=========================================================>| |<=========================================================>|
| | | | | |
| |BYE F8 | | |BYE F8 |
| |<----------------------------| | |<----------------------------|
|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. The WebSocket In the same scenario Alice places a call to Bob's AoR (Address Of
SIP server at proxy.atlanta.com acts as a SIP proxy routing the Record). The SIP WebSocket Server at proxy.atlanta.com acts as a SIP
INVITE to the UDP location of Bob, who answers the call and proxy, routing the INVITE to Bob's contact address (which happens to
terminates it later. be using SIP transported over UDP). Bob answers the call and then
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.atlanta.com (transport WSS)
INVITE sip:bob@atlanta.com SIP/2.0 INVITE sip:bob@atlanta.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@atlanta.com;tag=asdyka899
To: sip:bob@atlanta.com To: sip:bob@atlanta.com
skipping to change at page 14, line 4 skipping to change at page 14, line 35
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.atlanta.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@atlanta.com;tag=bmqkjhsd
To: sip:alice@atlanta.com;tag=asdyka899 To: sip:alice@atlanta.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.atlanta.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@atlanta.com;tag=bmqkjhsd
To: sip:alice@atlanta.com;tag=asdyka899 To: sip:alice@atlanta.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 to protect the privacy of the SIP traffic through It is recommended that the SIP traffic transported over a WebSocket
the WebSocket communication by using a secure WebSocket connection communication be protected by using a secure WebSocket connection
(tunneled over TLS [RFC5246]). (using TLS [RFC5246] over TCP).
9.2. Usage of SIPS Scheme 9.2. Usage of SIPS Scheme
SIPS scheme within a SIP request dictates that the entire request The SIPS scheme in a SIP URI dictates that the entire request path to
path to the target be secured. If such a path includes a WebSocket the target be secure. If such a path includes a WebSocket connection
node 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 create 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 in the registry of WebSocket sub-protocols 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, it should point to this document
10.2. Registration of new Via transports 10.2. Registration of new NAPTR service field values
This specification registers two new transport identifiers for Via
headers:
WS: MUST be used when constructing a SIP request to be sent over a
plain WebSocket connection.
WSS: MUST be used when constructing a SIP request to be sent over a
secure WebSocket connection.
10.3. Registration of new SIP URI transport
This specification registers a new value for the "transport"
parameter in a SIP URI:
ws: Identifies a SIP URI to be contacted using a WebSocket
connection.
10.4. 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
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, Kevin P. Fleming, 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
Loreto for their full reviews, and also to Saul Ibarra Corretge for Loreto for their full reviews, and also to Saul Ibarra Corretge for
his contribution and suggestions. his contribution and suggestions.
Special thanks to Kevin P. Fleming for his complete grammatical
review along with suggestions, comments and improvements.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
skipping to change at page 17, line 15 skipping to change at page 17, line 35
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive",
RFC 6223, April 2011. RFC 6223, April 2011.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[WS-API] Hickson, I., "The Web Sockets API", May 2012. [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012.
Appendix A. Implementation Guidelines Appendix A. Implementation Guidelines
_This section is non-normative._ _This section is non-normative._
Let us assume a scenario in which the users access with their web Let us assume a scenario in which the users access with their web
browsers (probably behind NAT) to an intranet, perform web login by browsers (probably behind NAT) an application provided by a server on
entering their user identifier and credentials, and retrieve a an intranet, login by entering their user identifier and credentials,
JavaScript code (along with the HTML code itself) implementing a SIP and retrieve a JavaScript application (along with the HTML)
WebSocket Client. implementing a SIP WebSocket Client.
Such a SIP stack connects to a given SIP WebSocket Server (an Such a SIP stack connects to a given SIP WebSocket Server (an
outbound SIP proxy which also implements classic SIP transports such outbound SIP proxy which also implements classic SIP transports such
as UDP and TCP). The HTTP GET request sent by the web browser for as UDP and TCP). The HTTP GET method request sent by the web browser
the WebSocket handshake includes a Cookie [RFC6265] header with the for the WebSocket handshake includes a Cookie [RFC6265] header with
value previously retrieved after the successful web login procedure. the value previously provided by the server after the successful
The Cookie value is then inspected by the WebSocket server for login procedure. The Cookie value is then inspected by the WebSocket
authorizing the connection. Once the WebSocket connection is server to authorize the connection. Once the WebSocket connection is
established, the SIP WebSocket Client performs a SIP registration and established, the SIP WebSocket Client performs a SIP registration to
common SIP stuf begins. The SIP registrar server is located behind a SIP registrar server that is reachable through the proxy. After
the SIP outbound proxy. registration, the SIP WebSocket Client and Server exchange SIP
messages as would normally be expected.
This scenario is quite similar to the one in which SIP UAs behind NAT This scenario is quite similar to ones in which SIP UAs behind NATs
connect to an outbound proxy and need to reuse the same TCP connect to a proxy and must reuse the same TCP connection for
connection for incoming requests. In both cases, the SIP clients are incoming requests (because they are not directly reachable by the
just reachable through the outbound proxy they are connected to. proxy otherwise). In both cases, the SIP UAs are only reachable
through the proxy they are connected to.
Outbound [RFC5626] seems an appropriate solution for this scenario. The SIP Outbound extension [RFC5626] seems an appropriate solution
Therefore these SIP WebSocket Clients and the SIP registrar implement for this scenario. Therefore these SIP WebSocket Clients and the SIP
both Outbound and Path [RFC3327], and the SIP outbound proxy becomes registrar implement both the Outbound and Path [RFC3327] extensions,
an Outbound Edge Proxy (as defined in [RFC5626] section 3.4). and the SIP proxy acts as an Outbound Edge Proxy (as defined in
[RFC5626] section 3.4).
SIP WebSocket Clients in this scenario receive incoming SIP requests SIP WebSocket Clients in this scenario receive incoming SIP requests
via the SIP WebSocket Server they are connected to. Therefore, in via the SIP WebSocket Server they are connected to. Therefore, in
some call transfer cases the usage of GRUU [RFC5627] (which should be some call transfer cases the usage of GRUU [RFC5627] (which should be
implemented in both the SIP WebSocket Clients and SIP registrar) is implemented in both the SIP WebSocket Clients and SIP registrar) is
valuable. valuable.
If a REFER request is sent to a thirdy SIP user agent indicating If a REFER request is sent to a third SIP user agent including the
the Contact URI of a SIP WebSocket Client as the target in the Contact URI of a SIP WebSocket Client as the target in its
Refer-To header field, such a URI will be reachable by the thirdy Refer-To header field, such a URI will be reachable by the third
SIP UA just in the case it is a globally routable URI. GRUU SIP UA only if it is a globally routable URI. GRUU (Globally
(Globally Routable User Agent URI) is a solution for those Routable User Agent URI) is a solution for those scenarios, and
scenarios, and would enforce the incoming request from the thirdy would cause the incoming request from the third SIP user agent to
SIP user agent to reach the SIP registrar which would route the be sent to the SIP registrar, which would route the request to the
request via the Outbound Edge Proxy. SIP WebSocket Client via the Outbound Edge Proxy.
A.1. SIP WebSocket Client Considerations A.1. SIP WebSocket Client Considerations
The JavaScript stack in web browsers does not have the ability to The JavaScript stack in web browsers does not have the ability to
discover the local transport address which the WebSocket connection discover the local transport address used for originating WebSocket
is originated from. Therefore the SIP WebSocket Client creates a connections. Therefore the SIP WebSocket Client constructs a domain
domain consisting of a random token followed by .invalid top domain name consisting of a random token followed by the ".invalid" top-
name, as stated in [RFC2606], and uses it within the Via and Contact level domain name, as stated in [RFC2606], and uses it within its Via
header. and Contact headers.
The Contact URI provided by the SIP clients requesting Outbound The Contact URI provided by SIP UAs requesting (and receiving)
support is not later used for routing purposes, thus it is safe to Outbound support is not used for routing requests to those UAs,
set a random domain in the Contact URI hostpart. thus it is safe to set a random domain in the Contact URI
hostpart.
Both Outbound and GRUU specifications require the SIP client to Both the Outbound and GRUU specifications require a SIP UA to include
indicate a Uniform Resource Name (URN) in the "+sip.instance" a Uniform Resource Name (URN) in a "+sip.instance" parameter of the
parameter of the Contact header during the registration. The client Contact header they include their SIP REGISTER requests. The client
device is responsible for getting such a constant and unique value. device is responsible for generating or collecting a suitable value
for this purpose.
In the case of web browsers it is hard to get a URN value from the In web browsers it is difficult to generate or collect a suitable
browser itself. This scenario suggests that value is generated value to be used as a URN value from the browser itself. This
according to [RFC5626] section 4.1 by the web application running scenario suggests that value is generated according to [RFC5626]
in the browser the first time it loads the JavaScript SIP stack section 4.1 by the web application running in the browser the
code, and then it is stored as a Cookie within the browser. first time it loads the JavaScript SIP stack code, and then it is
stored as a Cookie within the browser.
A.2. SIP WebSocket Server Considerations A.2. SIP WebSocket Server Considerations
The SIP WebSocket Server in this scenario behaves as a SIP Outbound The SIP WebSocket Server in this scenario behaves as a SIP Outbound
Edge Proxy, which involves support for Outbound [RFC5626] and Path Edge Proxy, which involves support for Outbound [RFC5626] and Path
[RFC3327]. [RFC3327].
The proxy performs Loose Routing and remains in dialogs path as The proxy performs Loose Routing and remains in the path of dialogs
specified in [RFC3261]. Otherwise in-dialog requests would fail as specified in [RFC3261]. If it did not do this, in-dialog requests
since SIP WebSocket Clients make use of their SIP WebSocket Server in would fail since SIP WebSocket Clients make use of their SIP
order to send and receive SIP requests and responses. WebSocket Server in order to send and receive SIP messages.
Appendix B. HTTP Topology Hiding Appendix B. HTTP Topology Hiding
_This section is non-normative._ _This section is non-normative._
RFC 3261 [RFC3261] section 18.2.1 "Receiving Requests" states the [RFC3261] section 18.2.1 "Receiving Requests" states the following:
following:
When the server transport receives a request over any transport, When the server transport receives a request over any transport,
it MUST examine the value of the "sent-by" parameter in the top it MUST examine the value of the "sent-by" parameter in the top
Via header field value. If the host portion of the "sent-by" Via header field value. If the host portion of the "sent-by"
parameter contains a domain name, or if it contains an IP address parameter contains a domain name, or if it contains an IP address
that differs from the packet source address, the server MUST add a that differs from the packet source address, the server MUST add a
"received" parameter to that Via header field value. This "received" parameter to that Via header field value. This
parameter MUST contain the source address from which the packet parameter MUST contain the source address from which the packet
was received. was received.
The requirement of adding the "received" parameter does not fit well The requirement of adding the "received" parameter does not fit well
into WebSocket protocol nature. The WebSocket handshake connection into the WebSocket protocol design. The WebSocket handshake
reuses existing HTTP infrastructure in which there could be certain connection reuses existing HTTP infrastructure in which there could
number of HTTP proxies and/or TCP load balancers between the SIP be an unknown number of HTTP proxies and/or TCP load balancers
WebSocket Client and Server, so the source IP the server would write between the SIP WebSocket Client and Server, so the source address
into the Via "received" parameter would be the IP of the HTTP/TCP the server would write into the Via "received" parameter would be the
intermediary in front of it. This could reveal sensitive information address of the HTTP/TCP intermediary in front of it. This could
about the internal topology of the provider network to the client. reveal sensitive information about the internal topology of the
Server's network to the Client.
Thus, given the fact that SIP responses can only be sent over the Given the fact that SIP responses can only be sent over the existing
existing WebSocket connection, the meaning of the Via "received" WebSocket connection, the Via "received" parameter is of little use.
parameter added by the SIP WebSocket Server is of little use.
Therefore, in order to allow hiding possible sensitive information Therefore, in order to allow hiding possible sensitive information
about the provider infrastructure, the implementer could decide not about the SIP WebSocket Server's network, the implementor could
to satisfy the requirement in RFC 3261 [RFC3261] section 18.2.1 decide not to satisfy the requirement in [RFC3261] section 18.2.1
"Receiving Requests" and not add the "received" parameter to the Via "Receiving Requests" and not add the "received" parameter to the Via
header. header.
However, keep in mind that this would involve a violation of the Keep in mind that this would make the SIP WebSocket Server non-
RFC 3261. compliant with [RFC3261].
Authors' Addresses Authors' Addresses
Inaki Baz Castillo Inaki Baz Castillo
Consultant Unaffiliated
Barakaldo, Basque Country Barakaldo, Basque Country
Spain Spain
Email: ibc@aliax.net Email: ibc@aliax.net
Jose Luis Millan Villegas Jose Luis Millan Villegas
Consultant Unaffiliated
Bilbao, Basque Country Bilbao, Basque Country
Spain Spain
Email: jmillan@aliax.net Email: jmillan@aliax.net
Victor Pascual Victor Pascual
Acme Packet Acme Packet
Anabel Segura 10 Anabel Segura 10
Madrid, Madrid 28108 Madrid, Madrid 28108
Spain Spain
 End of changes. 83 change blocks. 
265 lines changed or deleted 257 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/