wdiff rfc7977.original rfc7977.txt

Dispatch Working Group
Internet Engineering Task Force (IETF) P. Dunkley
Internet-Draft
Request for Comments: 7977 G. Llewellyn
Updates: 4975, 4976 (if approved) Xura
Intended status:
Category: Standards Track V. Pascual
Expires: February 16, 2017
ISSN: 2070-1721 Oracle
G. Salgueiro
Ram.
R. Ravindranath
Cisco
August 15,
September 2016

The WebSocket Protocol as a Transport
for the Message Session Relay Protocol (MSRP)
draft-pd-dispatch-msrp-websocket-15

Abstract

The WebSocket protocol enables two-way real-time communication
between clients and servers in situations where direct access to TCP
and UDP are is not available (for example, from within Javascript JavaScript in a
web browser). This document specifies a new WebSocket sub-protocol subprotocol as
a reliable transport mechanism between MSRP (Message Message Session Relay
Protocol) Protocol
(MSRP) clients and relays to enable usage of MSRP in new scenarios.
This document normatively updates RFC RFCs 4975 and RFC 4976.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 16, 2017.
http://www.rfc-editor.org/info/rfc7977.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 5
3. WebSocket Protocol Overview . . . . . . . . . . . . . . . . . 4 5
4. The WebSocket MSRP Sub-Protocol Subprotocol . . . . . . . . . . . . . . . 5 6
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 6
4.2. MSRP Encoding . . . . . . . . . . . . . . . . . . . . . . 6 7
5. MSRP WebSocket Transport . . . . . . . . . . . . . . . . . . 6 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 7
5.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . 7
5.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . 7
5.2.2. SDP Transport Protocol . . . . . . . . . . . . . . . 7 8
5.3. Updates to RFC 4976 . . . . . . . . . . . . . . . . . . . 7 8
5.3.1. AUTH Request Authentication . . . . . . . . . . . . . 7 8
6. Connection Keep-alive Keepalive . . . . . . . . . . . . . . . . . . . . 8 9
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 9
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10
8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 9 10
8.1.1. WebSocket Authentication . . . . . . . . . . . . . . 9 10
8.1.2. MSRP Authentication . . . . . . . . . . . . . . . . . 10 12
8.2. Example Session: MSRP WebSocket Client to MSRP Client . . 12 14
8.2.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 13 14
8.2.2. SEND (MSRP WebSocket Client to MSRP Client) . . . . . 13 15
8.2.3. SEND (MSRP Client to MSRP WebSocket Client) . . . . . 16
8.3. Example Session: Two MSRP WebSocket Clients . . . . . . . 18
8.3.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 18
8.3.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 18 19
8.4. Example Session: MSRP WebSocket Client to MSRP Client
Using a Relay . . . . . . . . . . . . . . . . . . . . . . 21 20
8.4.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 21 20
8.4.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
9.1. Kamailio SIP Server Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.2. Crocodile MSRP . . . . . . . . . . . . . . . . . . . . . 25
10. Security IANA Considerations . . . . . . . . . . . . . . . . . . . 25 . . 24
11. IANA Considerations References . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
13. 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Implementation Guidelines: MSRP WebSocket Client
Considerations . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . 27
Acknowledgements . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Implementation Guidelines: MSRP WebSocket Client
Considerations . . . .
Authors' Addresses . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 28

1. Introduction

The WebSocket [RFC6455] protocol enables message exchange between
clients and servers on top of a persistent TCP connection (optionally
secured with TLS Transport Layer Security (TLS) [RFC5246]). The initial
protocol handshake makes use of HTTP [RFC7230] semantics, allowing
the WebSocket protocol to reuse existing HTTP infrastructure.

Modern web browsers include a WebSocket client stack complying with
the WebSocket API [WS-API] as specified by the W3C. It is expected
that other client applications (those running in personal computers
and devices such as smart-phones) smartphones) will also make a WebSocket client
stack available. The specification in this document enables usage of
Message Session Relay Protocol [RFC4975] in these scenarios.

This specification defines a new WebSocket sub-protocol subprotocol (as defined in section
Section 1.9 in [RFC6455]) for transporting MSRP messages between a
WebSocket client and MSRP relay [RFC4976] containing a WebSocket
server, a new transport for MSRP, and procedures for MSRP clients and
relays implementing the WebSocket transport.

MSRP over WebSocket is well suited for MSRP interactions between
clients and servers. Common use cases for MSRP over WebSocket
include:

o Human-to-machine messaging

o Client-to-server data exchange (for example, application control
signalling)
signaling)

o Human-to-human messaging where local policy requires
authentication and/or logging

MSRP-CEMA

MSRP Connection Establishment for Media Anchoring (MSRP-CEMA)
[RFC6714] is outside of the scope of this document document, as this document
is intended to describe connecting to a WebSocket server that is an
MSRP relay.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

2.1. Definitions

MSRP WebSocket Client: An MSRP entity capable of opening outbound
connections to MSRP relays which that are WebSocket servers and
communicating using the WebSocket MSRP sub-protocol subprotocol as defined
by this document.

MSRP WebSocket Server: An MSRP entity (specifically an MSRP relay
[RFC4976]) capable of listening for inbound connections from
WebSocket clients and communicating using the WebSocket MSRP
sub-protocol
subprotocol as defined by this document.

3. WebSocket Protocol Overview

The WebSocket protocol [RFC6455] is a transport layer on top of TCP
(optionally secured with TLS [RFC5246]) in which both the client and
server exchange message units in both directions. The protocol
defines a connection handshake, WebSocket sub-protocol subprotocol and extensions
negotiation, a frame format for sending application and control data,
a masking mechanism, and status codes for indicating disconnection
causes.

The WebSocket connection handshake is based on HTTP [RFC7230] and
utilizes the HTTP GET method with an "Upgrade" request. This is sent
by the client and then answered by the server (if the negotiation
succeeded) with an HTTP 101 status code. Once the handshake is
completed
completed, the connection upgrades from HTTP to the WebSocket
protocol. This handshake procedure is designed to reuse the existing
HTTP infrastructure. During the connection handshake, client and
server agree on the application protocol to use on top of the
WebSocket transport. Such application protocol (also known as a
"WebSocket sub-protocol") subprotocol") defines the format and semantics of the
messages exchanged by the endpoints. This could be a custom protocol
or a standardized one (such as the WebSocket MSRP sub-protocol subprotocol defined
in this document). Once the HTTP 101 response is processed processed, both
client and server reuse the underlying TCP connection for sending
WebSocket 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 to be used by applications for the
exchange of data, so it provides a message boundary-preserving
transport layer. These message units can contain either UTF-8 text
or binary data, data and can be split into multiple WebSocket text/binary
transport frames as needed by the WebSocket stack.

The WebSocket API [WS-API] for web browsers only defines callbacks to
be invoked upon receipt of an entire message unit, unit regardless of
whether it was received in a single WebSocket frame or split across
multiple frames.

4. The WebSocket MSRP Sub-Protocol Subprotocol

The term WebSocket sub-protocol subprotocol refers to an application-level
protocol layered on top of a WebSocket connection. This document
specifies the WebSocket MSRP sub-protocol subprotocol for carrying MSRP requests
and responses through a WebSocket connection.

4.1. Handshake

The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage
of the WebSocket MSRP sub-protocol subprotocol during the WebSocket handshake
procedure as defined in section Section 1.3 of [RFC6455]. The Client MUST
include the value "msrp" in the Sec-WebSocket-Protocol header in its
handshake request. The 101 reply from the Server MUST contain "msrp"
in its corresponding Sec-WebSocket-Protocol header.

Below is an example of a WebSocket handshake in which the Client
requests the WebSocket MSRP sub-protocol subprotocol support from the Server:

GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13

The handshake response from the Server accepting the WebSocket MSRP
sub-protocol
subprotocol would look as follows:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp

Once the negotiation has been completed, the WebSocket connection is
established and can be used for the transport of MSRP requests and
responses. The WebSocket messages transmitted over this connection
MUST conform to the negotiated WebSocket sub-protocol. subprotocol.

4.2. MSRP Encoding

WebSocket messages can be transported in either UTF-8 text frames or
binary frames. MSRP [RFC4975] allows both text and binary bodies in
MSRP requests. Therefore Therefore, MSRP WebSocket Clients and Servers MUST
accept both text and binary frames.

The WebSocket API [WS-API] does not allow developers to choose
whether to send UTF-8 text or binary frames, frames but will not send
non-UTF-8 characters in a text frame. The content of text frames
MUST be interpreted as binary by WebSocket Clients and Servers.

5. MSRP WebSocket Transport

5.1. General

WebSocket clients cannot receive WebSocket connections initiated by
other WebSocket clients or WebSocket servers. This means that it is
challenging for an MSRP client to communicate directly with other
MSRP clients. Therefore, all MSRP over WebSocket MSRP-over-WebSocket messages MUST be
routed via an MSRP WebSocket Server. MSRP traffic transported over
WebSockets MUST be protected by using a secure Secure WebSocket (WSS)
connection (using TLS [RFC5246] over TCP).

MSRP WebSocket Servers can be used to route MSRP messages between
MSRP WebSocket Clients, Clients and between MSRP WebSocket Clients and
"normal" MSRP clients and relays.

Each MSRP chunk MUST be carried within a single WebSocket message,
and a WebSocket message MUST NOT contain more than one MSRP chunk.

This simplifies parsing of MSRP messages for both clients and
servers. When large messages are sent by a non-WebSocket peer, MSRP
chunking (as defined in section Section 5.1 of [RFC4975]) MUST be used by the
WebSocket MSRP Servers to split the message into several smaller MSRP
chunks.

5.2. Updates to RFC 4975

5.2.1. MSRP URI Transport Parameter

This document defines the value "ws" as the transport parameter value
for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket
sub-protocol
subprotocol as transport.

The updated augmented BNF (Backus-Naur Form) ABNF [RFC5234] for this parameter is the following (the
original BNF for this parameter can be found in [RFC4975]):

transport = "tcp" / "ws" / 1*ALPHANUM

5.2.2. SDP Transport Protocol

This document does not define a new SDP Session Description Protocol
(SDP) transport protocol for MSRP over WebSockets. As all MSRP over MSRP-over-
WebSocket messages MUST be routed via an MSRP WebSocket Server, the
MSRP WebSocket Client MUST specify "TCP/TLS/MSRP" protocols in the
SDP m-line - -- that being the protocol used by non-WebSocket clients
and between MSRP relays ([RFC4975]
section 8.1). (see Section 8.1 of [RFC4975]).

The "ws" transport parameter will appear in the endpoint URI in the
SDP "path" attribute ([RFC4975] (see Section 8.2). 8.2 of [RFC4975]). MSRP was
designed with the possibility of new transport bindings in mind ([RFC4975] (see
Section 6) 6 of [RFC4975]), so MSRP implementations are expected to
allow unrecognised unrecognized transports, provided that they do not have to
establish a direct connection to the resource described by the URI.

5.3. Updates to RFC 4976

5.3.1. AUTH Request Authentication

The MSRP relay specification [RFC4976] states that AUTH requests MUST
be authenticated. This document modifies this requirement to state
that all connections between MSRP clients and relays MUST be
authenticated. In the case of the MSRP WebSocket Clients Clients, there are
two
three possible authentication mechanisms:

1. HTTP Digest authentication in AUTH (as per [RFC4976]).

2. Cookie-based or HTTP Digest authentication in the WebSocket
Handshake (see Section 7).

3. Mutual TLS between the WebSocket based WebSocket-based MSRP client and the
WebSocket server.

The AUTH request is a required event when authentication occurs at
the WebSocket connection level, level since the Use-Path: "Use-Path:" header required
to create the SDP offer is included in the 200 OK response to the
AUTH request.

6. Connection Keep-alive Keepalive

It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their
WebSocket connections open by sending periodic WebSocket "Ping"
frames as described in [RFC6455] section 5.5.2. Section 5.5.2 of [RFC6455].

The WebSocket API [WS-API] does not provide a mechanism for
applications running in a web browser to control whether or not
periodic WebSocket "Ping" frames are sent to the server. The
implementation of such a keep alive keepalive feature is the decision of each
web browser manufacturer and may also depend on the configuration of
the web browser.

A future WebSocket protocol extension providing a similar keep alive keepalive
mechanism could also be used.

When MSRP WebSocket Clients or Servers cannot use WebSocket "Ping"
frames to keep connections open open, an MSRP implementation MAY use
bodiless SEND requests as described in [RFC4975] section 7.1. Section 7.1 of [RFC4975].
MSRP WebSocket Clients or Servers MUST be prepared to receive
bodiless SEND requests.

7. Authentication

Prior to sending MSRP requests, an MSRP WebSocket Client connects to
an MSRP WebSocket Server and performs the connection handshake. As
described in Section 3 3, the handshake procedure involves a HTTP GET
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 MSRP WebSocket
Server MAY inspect any HTTP headers present (for example, Cookie
[RFC6265], Host [RFC7230], or Origin [RFC6454]) in the HTTP GET
request. For many web applications applications, the value of such a Cookie is
provided by the web server once the user has authenticated themselves
to the web server, which could be done by many existing mechanisms.
As an alternative method, the MSRP WebSocket Server could request
HTTP authentication by replying to the Client's GET method request
with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers
this usage in section 4.1: Section 4.1 and is paraphrased as follows:

If the status code received from the server is not 101, the
WebSocket client stack handles the response per HTTP [RFC7230]
procedures,
procedures; in particular particular, the client might perform authentication
if it receives a 401 status code.

If the HTTP GET request contains an Origin header header, the MSRP WebSocket
Server SHOULD indicate Cross-Origin Resource Sharing [CORS] by adding
an Access-Control-Allow-Origin header to the 101 response.

Regardless of whether the MSRP WebSocket Server requires
authentication during the WebSocket handshake, authentication MAY be
requested at the MSRP protocol level by an MSRP Server challenging
AUTH requests using a 401 response. Therefore, an MSRP WebSocket
Client SHOULD support HTTP Digest [RFC7235] authentication as stated
in [RFC4976].

8. Examples

8.1. Authentication

8.1.1. WebSocket Authentication

Alice (MSRP WSS) a.example.com
| |
|HTTP GET (WS handshake) F1 |
|---------------------------->|
|101 Switching Protocols F2 |
|<----------------------------|
| |
|AUTH F3 |
|---------------------------->|
|200 OK F4 |
|<----------------------------|
| |

Alice loads a web page using her web browser and retrieves JavaScript
code implementing the WebSocket MSRP sub-protocol subprotocol defined in this
document. The JavaScript code (an MSRP WebSocket Client) establishes
a secure WebSocket connection with an MSRP relay (an MSRP WebSocket
Server) at a.example.com. Upon WebSocket connection, Alice
constructs and sends an MSRP AUTH request. Since the JavaScript
stack in a browser has no way to determine the local address from
which the WebSocket connection was made, this implementation uses a
random ".invalid" domain name for the hostpart of the From-Path URI
(see Appendix A).

In this example, it is assumed that authentication is performed at
the WebSocket layer (not shown), so no challenge is issued for the
MSRP AUTH message:

F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS)

GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13

F2 101 Switching Protocols a.example.com -> Alice (TLS)

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp

F3 AUTH Alice -> a.example.com (transport WSS)

MSRP 49fi AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------49fi$

F4 200 OK a.example.com -> Alice (transport WSS)

MSRP 49fi 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
Expires: 900
-------49fi$

8.1.2. MSRP Authentication

This example uses the same scenario as Section 8.1.1, 8.1.1 but with
authentication performed at the MSRP layer.

Note that MSRP does not permit line folding. A "\" in the examples
shows a line continuation due to limitations in line length of this
document. Neither the backslash nor the extra CRLF is included in
the actual MSRP message.

F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS)

F2 101 Switching Protocols a.example.com -> Alice (TLS)

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp
F3 AUTH Alice -> a.example.com (transport WSS)

MSRP 4rsxt9nz AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------4rsxt9nz$

F4 401 Unauthorized a.example.com -> Alice (transport WSS)

MSRP 4rsxt9nz 401 Unauthorized
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
WWW-Authenticate: Digest realm="example.com", \
nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", qop="auth"
-------4rsxt9nz$

F5 AUTH Alice -> a.example.com (transport WSS)

MSRP qy1hsow5 AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Authorization: Digest username="alice", realm="example.com", \
nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", \
uri="msrps://alice@a.example.com:443;ws", \
response="5011d0d58fe975e0d0cdc007ae26f4b7", \
qop=auth, cnonce="zic5ml401prb", nc=00000001
-------qy1hsow5$

F6 200 OK a.example.com -> Alice (transport WSS)

MSRP qy1hsow5 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
Expires: 900
-------qy1hsow5$

8.2. Example Session: MSRP WebSocket Client to MSRP Client

The following sub-sections subsections show various message exchanges occuring occurring
during the course of an MSRP session between a WebSocket client and a
non-WebSocket client.

8.2.1. SDP Exchange

The following example shows SDP that could be included in a SIP
message to set up an MSRP session between Alice and Bob where Alice
uses a WebSocket MSRP relay, relay and Bob uses a traditional MSRP client
without a relay.

A "\" in the examples shows a line continuation due to limitations in
line length of this document. Neither the backslash nor the extra
CRLF is included in the actual SDP.

Alice makes an offer with a path including the relay (having already
successfully authenticated with the relay):

c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws

In this offer, Alice wishes to receive MSRP messages via the relay at
a.example.com. She wants to use TLS as the transport for the MSRP
session (beyond the relay). She can accept message/cpim, text/plain,
and text/html message bodies in SEND requests.

Bob's answer to this offer could look like:

c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://bob.example.com:49154/foo;tcp

Here

Here, Bob wishes to receive the MSRP messages at bob.example.com. He
can accept only message/cpim and text/plain message bodies in SEND
requests and has rejected the text/html content offered by Alice. He
does not need a relay to set up the MSRP session.

8.2.2. SEND (MSRP WebSocket Client to MSRP Client)

Alice (MSRP WSS) a.example.com (MSRP TLS) Bob
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|

Later in the session, Alice sends an instant message to Bob. The
MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
the message to Bob over TLS.

Message details (A "\" in the examples shows a line continuation due
to limitations in line length of this document. Neither the
backslash nor the extra CRLF is included in the actual request or
response):

F1 SEND Alice -> a.example.com (transport WSS)

MSRP 6aef SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Hi Bob, I'm about to send you file.mpeg
-------6aef$

F2 200 OK a.example.com -> Alice (transport WSS)

MSRP 6aef 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------6aef$
F3 SEND a.example.com -> Bob (transport TLS)

MSRP juh76 SEND
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Hi Bob, I'm about to send you file.mpeg
-------juh76$

F4 200 OK Bob -> a.example.com (transport TLS)

MSRP juh76 200 OK
To-Path: msrps://a.example.com:2855/jui787s2f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------juh76$

8.2.3. SEND (MSRP Client to MSRP WebSocket Client)

Bob (MSRP TLS) a.example.com (MSRP WSS) Alice
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|

Later in the session, Bob sends an instant message to Alice. The
MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
the message to Alice over secure WebSocket.

F1 SEND Bob -> a.example.com (transport TLS)

MSRP xght6 SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://bob.example.com:49154/foo;tcp
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Thanks for the file.
-------xght6$

F2 200 OK a.example.com -> Bob (transport TLS)

MSRP xght6 200 OK
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------xght6$

F3 SEND a.example.com -> Alice (transport WSS)

MSRP yh67 SEND
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://bob.example.com:49154/foo;tcp
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Thanks for the file.
-------yh67$
F4 200 OK Alice -> a.example.com (transport WSS)

MSRP yh67 200 OK
To-Path: msrps://a.example.com:2855/jui787s2f;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------yh67$

8.3. Example Session: Two MSRP WebSocket Clients

The following sub-sections subsections show various message exchanges occuring occurring
during the course of an MSRP session between two WebSocket clients.

8.3.1. SDP Exchange

The following example shows SDP that could be included in a SIP
message to set up an MSRP session between Alice and Carol where both
of them are using the same WebSocket MSRP relay.

Alice makes an offer with a path including the relay (having already
successfully authenticated with the relay):

c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws

Carol's answer to this offer could look like:

c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://a.example.com:2855/iwnslt;tcp \
msrps://jk9awp14vj8x.invalid:2855/76qwe;ws

Here

Here, Carol also wishes to receive the MSRP messages via
a.example.com. She can accept only message/cpim and text/plain
message bodies in SEND requests and has rejected the text/html
content offered by Alice.

8.3.2. SEND

Alice (MSRP WSS) a.example.com (MSRP WSS) Carol
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|

Later in the session session, Alice sends an instant message to Carol. The
MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
the message to Carol over secure WebSocket.

In this example example, both Alice and Carol are using MSRP WebSocket
Clients,
Clients and the same MSRP WebSocket Server. This means that
a.example.com will appear twice in the To-Path in F1. a.example.com
can either handle this internally or loop the MSRP SEND request back
to itself as if it were two, separate, two separate MSRP relays.

F1 SEND Alice -> a.example.com (transport WSS)

MSRP kjh6 SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://a.example.com:2855/iwnslt;tcp \
msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Carol, I sent that file to Bob.
-------kjh6$
F2 200 OK a.example.com -> Alice (transport WSS)

MSRP kjh6 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------kjh6$

F3 SEND a.example.com -> Carol (transport WSS)

MSRP re58 SEND
To-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
From-Path: msrps://a.example.com:2855/iwnslt;tcp \
msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Carol, I sent that file to Bob.
-------re58$

F4 200 OK Carol -> a.example.com (transport WSS)

MSRP re58 200 OK
To-Path: msrps://a.example.com:2855/iwnslt;tcp
From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
-------re58$

8.4. Example Session: MSRP WebSocket Client to MSRP Client Using a
Relay

The following sub-sections subsections show various message exchanges occuring
during the course of an MSRP session between a WebSocket client and a
non-WebSocket client, where the latter is also using an MSRP relay.

8.4.1. SDP Exchange

Alice makes an offer with a path including the relay (having already
successfully authenticated with the relay):

c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws

Bob's answer to this offer could look like:

c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp

Here

Here, Bob wishes to receive the MSRP messages via the relay at
relay.example.net. He can accept only message/cpim and text/plain
message bodies in SEND requests and has rejected the text/html
content offered by Alice.

8.4.2. SEND

Alice (MSRP WSS) a.example.com (MSRP) relay.example.net (MSRP) Bob
| | | |
|SEND F1 | | |
|--------------------->| | |
|200 OK F2 | | |
|<---------------------| | |
| |SEND F3 | |
| |---------------------->| |
| |200 OK F4 | |
| |<----------------------| |
| | |SEND F5 |
| | |------------------->|
| | |200 OK F6 |
| | |<-------------------|

Later in the session session, Alice sends an instant message to Bob. The
MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
the message to Bob via his relay, relay.example.net.

F1 SEND Alice -> a.example.com (transport WSS)

MSRP Ycwt SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Bob, that was the wrong file - don't watch it!
-------Ycwt$

F2 200 OK a.example.com -> Alice (transport WSS)

MSRP Ycwt 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------Ycwt$

F3 SEND a.example.com -> relay.example.net (transport TLS)

MSRP 13GA SEND
To-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Bob, that was the wrong file - don't watch it!
-------13GA$
F4 200 OK relay.example.net -> a.example.com (transport TLS)

MSRP 13GA 200 OK
To-Path: msrps://a.example.com:2855/iwnslt;tcp
From-Path: msrps://relay.example.net:2855/kwvin5f;tcp
-------13GA$

F5 SEND relay.example.net -> bob.example.com (transport TLS)

MSRP kXeg SEND
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain

Bob, that was the wrong file - don't watch it!
-------kXeg$

F6 200 OK bob.example.com -> relay.example.net (transport TLS)

MSRP kXeg 200 OK
To-Path: msrps://relay.example.net:2855/kwvin5f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------kXeg$

9. Implementation Status

Note to RFC Editor: Please remove this section and Security Considerations

MSRP traffic transported over WebSockets MUST be protected by using a
secure WebSocket connection (using TLS [RFC5246] over TCP).

When establishing a connection using MSRP over secure WebSockets, the reference
client MUST authenticate the server using the server's certificate
according to
[RFC6982] before publication.

This section records the status of known implementations of WebSocket validation procedure in [RFC6455].

Any security considerations specific to the WebSocket protocol defined by this are
detailed in the relevant specification at [RFC6455] and are considered
outside the time of posting scope of this
Internet-Draft, and is based on a proposal described in [RFC6982]. document. The description of implementations in this section is intended to
assist certificate name matching
(described by [RFC6455]) and cryptosuite selection will be handled by
the IETF in its decision processes browser, and the browser's procedures will supersede those
specified in progressing drafts to
RFCs. Please note that [RFC4975].

Since the listing of any individual implementation
here does not imply endorsement by TLS session is always terminated at the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.

According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".

9.1. Kamailio SIP Server

Organization: Kamailio

Name: Kamailio v4.0.0 (4.0.0 http://www.kamailio.org/w/kamailio-
v4-0-0-release-notes/)

Description: Kamailio (former OpenSER) is an Open Source SIP
Server, able to handle thousands of call setups per second.
(http://www.kamailio.org)

Level of maturity: Beta

Coverage: This module implements a WebSocket (RFC 6455) server and
provides connection establishment (handshaking), management
(including connection keep-alive), and framing for the SIP and
MSRP WebSocket sub-protocols (draft-ietf-sipcore-sip-websocket and
draft-pd-dispatch-msrp-websocket). The module supports WebSockets
(ws) and secure WebSockets (wss).

Licensing: Open Source GPLv2

Contact: http://www.kamailio.org/w/contact-us/
URL: http://git.sip-router.org/cgi-
bin/gitweb.cgi?p=kamailio;a=tree;f=modules/
websocket;h=e75c6cd28493f812a955eeff9e64905aee01bcbf;hb=HEAD

http://git.sip-router.org/cgi-
bin/gitweb.cgi?p=kamailio;a=tree;f=modules/
msrp;h=0ffaeb57fb43a4d429680209262ad847f7ce6074;hb=HEAD

9.2. Crocodile MSRP

Organization: Crocodile RCS Ltd.

Name: Crocodile MSRP (https://github.com/crocodilertc/crocodile-
msrp)

Description: Crocodile MSRP is a Javascript MSRP over WebSocket
stack.

Level of maturity: Beta

Coverage: Open source client implementation of draft-pd-dispatch-
msrp-websocket.

Licensing: Released under the MIT license
(http://www.opensource.org/licenses/mit-license.php).

Contact: Gavin Llewellyn (gavin.llewellyn@crocodilertc.net)

URL: https://github.com/crocodilertc/crocodile-msrp

10. Security Considerations

MSRP traffic transported over WebSockets MUST be protected by using a
secure WebSocket connection (using TLS [RFC5246] over TCP).

When establishing a connection using MSRP over secure WebSockets, the
client MUST authenticate the server using the server's certificate
according to the WebSocket validation procedure in [RFC6455].

Any security considerations specific to the WebSocket protocol is
detailed in the relevant specification([RFC6455] and is considered
outside the scope of this document. The certificate name matching,
described by [RFC6455], and cryptosuite selection will be handled by
the browser, and the browser's procedures will supersede those
specified in [RFC4975].

Since the TLS session is always terminated at the MSRP WebSocket
server and MSRP WebSocket
Server and the WebSocket server can see the plain text, the MSRP
client (browser) SHOULD NOT indicate end-to-end security to user.

TLS, as used in this document, should follow the best current
practices defined in [RFC7525].

11. IANA Considerations

This specification requests IANA to register the WebSocket MSRP sub-
protocol in the "WebSocket Subprotocol Name Registry" with the
following data:

Subprotocol Identifier: msrp

Subprotocol Common Name: WebSocket Transport for MSRP (Message
Session Relay Protocol)

Subprotocol Definition: TBD, it should point to this document

Reference: TBD, it should point to this document

12. Acknowledgements

Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and
Victor Pascual, the authors of [RFC7118] which has inspired this
draft.

Additional thanks to Inaki Baz Castillo who pointed out that "web-
browser" shouldn't be used all the time as this specification should
be valid for smartphones and apps other than browsers and suggested
clarifications to the SDP handling for MSRP over WebSocket.

Special thanks to James Wyatt from Crocodile RCS Ltd for helping with
the JavaScript MSRP over WebSockets prototyping.

Special thanks to Anton Roman who has contributed to this draft.

Thanks to Saul Ibarra Corretge for suggesting that the existing MSRP
keep alive mechanism may be used when WebSocket pings are not
available.

Thanks to Ben Cambell, Inaki Baz Castillo, Keith Drage, Olle
Johansson, Christer Holmberg for their thoughtful discussion comments
and review feedback that led to the improvement of this document.
Special thanks to Mary Barnes for both her technical review and for
offering to act as document shepherd. Thanks also to Stephen
Farrell, Alissa Cooper, Mirja Kuehlewind, Allison Mankin, Alexey
Melnikov and Kathleen Moriarty used in this document, should follow the best current
practices defined in [RFC7525].

10. IANA Considerations

Per this specification, IANA has registered the WebSocket MSRP
subprotocol in the "WebSocket Subprotocol Name Registry" with the
following data:

Subprotocol Identifier: msrp

Subprotocol Common Name: WebSocket Transport for their review comments.

13. MSRP (Message
Session Relay Protocol)

Subprotocol Definition: RFC 7977

Reference: RFC 7977

11. References

13.1.

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"The Message Session Relay Protocol (MSRP)", RFC 4975,
DOI 10.17487/RFC4975, September 2007,
<http://www.rfc-editor.org/info/rfc4975>.

[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
DOI 10.17487/RFC4976, September 2007,
<http://www.rfc-editor.org/info/rfc4976>.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.

[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>.

13.2.

11.2. Informative References

[CORS] W3C and A. van Kesteren, A., Ed., "Cross-Origin Resource Sharing",
W3C Recommendation, January 2013. 2014,
<http://www.w3.org/TR/2014/REC-cors-20140116/>.

[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<http://www.rfc-editor.org/info/rfc2606>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.

[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.

[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>.

[RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection
Establishment for Media Anchoring (CEMA) for the Message
Session Relay Protocol (MSRP)", RFC 6714,
DOI 10.17487/RFC6714, August 2012,
<http://www.rfc-editor.org/info/rfc6714>.

[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>.

[RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual,
"The WebSocket Protocol as a Transport for the Session
Initiation Protocol (SIP)", RFC 7118,
DOI 10.17487/RFC7118, January 2014,
<http://www.rfc-editor.org/info/rfc7118>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.

[WS-API] W3C and I. Hickson, I., Ed., "The WebSocket API", W3C Candidate
Recommendation, September
2012. 2012,
<https://www.w3.org/TR/2012/CR-websockets-20120920/>.

Appendix A. Implementation Guidelines: MSRP WebSocket Client
Considerations

The JavaScript stack in web browsers does not have the ability to
discover the local transport address used for originating WebSocket
connections. Therefore Therefore, the MSRP WebSocket Client constructs a
domain name consisting of a random token followed by the ".invalid" top-
level
top-level domain name, as stated in [RFC2606], and uses it within its
From-Path headers.

The From-Path URI provided by MSRP clients which that use an MSRP relay is
not used for routing MSRP messages, thus thus, it is safe to set a random
domain in the hostpart of the From-Path URI.

Acknowledgements

Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and
Victor Pascual, the authors of [RFC7118], which has inspired this
document.

Additional thanks to Inaki Baz Castillo, who pointed out that "web
browser" shouldn't be used all the time, as this specification should
be valid for smartphones and apps other than browsers and suggested
clarifications to the SDP handling for MSRP over WebSocket.

Special thanks to James Wyatt from Crocodile RCS Ltd for helping with
the JavaScript MSRP-over-WebSockets prototyping.

Special thanks to Anton Roman who has contributed to this document.

Thanks to Saul Ibarra Corretge for suggesting that the existing MSRP
keepalive mechanism may be used when WebSocket pings are not
available.

Thanks to Ben Campbell, Inaki Baz Castillo, Keith Drage, Olle
Johansson, and Christer Holmberg for their thoughtful discussion
comments and review feedback that led to the improvement of this
document. Special thanks to Mary Barnes for both her technical
review and for offering to act as Document Shepherd. Thanks also to
Stephen Farrell, Alissa Cooper, Mirja Kuehlewind, Allison Mankin,
Alexey Melnikov, and Kathleen Moriarty for their review comments.

Authors' Addresses

Peter Dunkley
Xura
Lancaster Court
8 Barnes Wallis Road
Fareham PO15 5TU
United Kingdom

Email: peter.dunkley@xura.com

Gavin Llewellyn
Xura
Lancaster Court
8 Barnes Wallis Road
Fareham PO15 5TU
United Kingdom

Email: gavin.llewellyn@xura.com

Victor Pascual
Oracle

Email: victor.pascual.avila@oracle.com

Gonzalo Salgueiro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
United States of America

Email: gsalguei@cisco.com

Ram Mohan Ravindranath
Cisco Systems, Inc.

Email: rmohanr@cisco.com