Difference between revisions of "RFC6135"
Line 26: | Line 26: | ||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | ||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | ||
− | Internet Standards is available in Section 2 of RFC 5741. | + | Internet Standards is available in Section 2 of [[RFC5741|RFC 5741]]. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
Line 37: | Line 37: | ||
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 [[BCP78|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 | ||
Line 47: | Line 47: | ||
described in the Simplified BSD License. | described in the Simplified BSD License. | ||
− | 5. Interoperability with the Connection Model Defined in RFC 4975 ..6 | + | 5. Interoperability with the Connection Model Defined in [[RFC4975|RFC 4975]] ..6 |
== Introduction == | == Introduction == | ||
The Message Session Relay Protocol (MSRP) core specification | The Message Session Relay Protocol (MSRP) core specification | ||
− | + | [[RFC4975]] states that the MSRP User Agent (UA) that sends the Session | |
Description Protocol (SDP) offer is "active", and it is responsible | Description Protocol (SDP) offer is "active", and it is responsible | ||
for creating the MSRP transport connection towards the remote UA if a | for creating the MSRP transport connection towards the remote UA if a | ||
Line 59: | Line 59: | ||
transport connections. | transport connections. | ||
− | + | [[RFC4145]] defines a connection-oriented media (COMEDIA) mechanism, | |
which endpoints can use to negotiate the endpoint that initiates the | which endpoints can use to negotiate the endpoint that initiates the | ||
creation of media transport connection. | creation of media transport connection. | ||
Line 71: | Line 71: | ||
Establishment (ICE)" [ICE-TCP]). In addition, COMEDIA allows the | Establishment (ICE)" [ICE-TCP]). In addition, COMEDIA allows the | ||
usage of identical procedures in establishing Transmission Control | usage of identical procedures in establishing Transmission Control | ||
− | Protocol (TCP) | + | Protocol (TCP) [[RFC0793]] connections for different types of media. |
An example is the Open Mobile Alliance (OMA)-defined "Instant Message | An example is the Open Mobile Alliance (OMA)-defined "Instant Message | ||
Line 92: | Line 92: | ||
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 RFC 2119 | + | document are to be interpreted as described in [[RFC2119|RFC 2119]] [[RFC2119]]. |
== Applicability Statement == | == Applicability Statement == | ||
Line 108: | Line 108: | ||
This section defines how an MSRP UA that supports this specification | This section defines how an MSRP UA that supports this specification | ||
− | uses the COMEDIA SDP attributes defined in | + | uses the COMEDIA SDP attributes defined in [[RFC4145]]. |
=== a=setup === | === a=setup === | ||
Line 114: | Line 114: | ||
==== General ==== | ==== General ==== | ||
− | An MSRP UA uses the SDP a=setup attribute | + | An MSRP UA uses the SDP a=setup attribute [[RFC4145]] in order to |
negotiate which endpoint will create the MSRP transport connection | negotiate which endpoint will create the MSRP transport connection | ||
towards the other UA. | towards the other UA. | ||
Line 136: | Line 136: | ||
receive a TCP connection for the MSRP transport connection. | receive a TCP connection for the MSRP transport connection. | ||
− | In accordance with | + | In accordance with [[RFC4145]], if the a=setup attribute value is |
"active", the port number value should be 9. | "active", the port number value should be 9. | ||
Line 161: | Line 161: | ||
o the UA has used Session Traversal Utilities for NAT (STUN) | o the UA has used Session Traversal Utilities for NAT (STUN) | ||
− | + | [[RFC5389]] signaling to retrieve the NAT address and port through | |
the local port to be used for the eventual transport connection, | the local port to be used for the eventual transport connection, | ||
while also having determined that the NAT has endpoint-independent | while also having determined that the NAT has endpoint-independent | ||
− | mapping and filtering behavior | + | mapping and filtering behavior [[RFC5382]], e.g., using the |
− | mechanism defined in | + | mechanism defined in [[RFC5780]]. |
− | Some UAs can determine whether the SIP | + | Some UAs can determine whether the SIP [[RFC3261]] signaling has |
traversed a NAT by inspecting the SIP Via header field in the 200 | traversed a NAT by inspecting the SIP Via header field in the 200 | ||
(OK) response to the initial SIP REGISTER request, and comparing the | (OK) response to the initial SIP REGISTER request, and comparing the | ||
Line 187: | Line 187: | ||
Once the active UA has established the MSRP transport connection, the | Once the active UA has established the MSRP transport connection, the | ||
UA must immediately send an MSRP SEND request, as defined in | UA must immediately send an MSRP SEND request, as defined in | ||
− | + | [[RFC4975]]. | |
− | NOTE: According to | + | NOTE: According to [[RFC4975]], the initiating UA is always active, |
but when COMEDIA is used, the a=setup attribute is used to | but when COMEDIA is used, the a=setup attribute is used to | ||
negotiate which UA becomes active. | negotiate which UA becomes active. | ||
Line 196: | Line 196: | ||
If an MSRP UA conformant to this document uses Transport Layer | If an MSRP UA conformant to this document uses Transport Layer | ||
− | Security (TLS), it MUST use the TLS mechanisms defined in | + | Security (TLS), it MUST use the TLS mechanisms defined in [[RFC4975]] |
− | and | + | and [[RFC4976]]. |
− | According to | + | According to [[RFC4975]], the connection can be established with or |
without TLS mutual authentication. In case mutual authentication is | without TLS mutual authentication. In case mutual authentication is | ||
not used, the listening device waits until it receives a request on | not used, the listening device waits until it receives a request on | ||
Line 212: | Line 212: | ||
Note that fingerprints can only be exchanged in peer-to-peer | Note that fingerprints can only be exchanged in peer-to-peer | ||
− | communication, as MSRP relays | + | communication, as MSRP relays [[RFC4976]] will not receive the SDP |
payloads containing the fingerprint attributes. | payloads containing the fingerprint attributes. | ||
=== a=connection === | === a=connection === | ||
− | MSRP UAs MUST NOT use the SDP a=connection attribute. | + | MSRP UAs MUST NOT use the SDP a=connection attribute. [[RFC4975]] |
defines connection reuse procedures for MSRP, and this document does | defines connection reuse procedures for MSRP, and this document does | ||
not modify those procedures. | not modify those procedures. | ||
Line 226: | Line 226: | ||
=== MSRP Relay Connection === | === MSRP Relay Connection === | ||
− | If an MSRP UA is located behind an MSRP relay | + | If an MSRP UA is located behind an MSRP relay [[RFC4976]], the UA MUST |
always initiate a transport connection towards the relay, no matter | always initiate a transport connection towards the relay, no matter | ||
what value the client has provided in the a=setup attribute. | what value the client has provided in the a=setup attribute. | ||
Line 234: | Line 234: | ||
based on the COMEDIA negotiation. | based on the COMEDIA negotiation. | ||
− | == Interoperability with the Connection Model Defined in RFC 4975 == | + | == Interoperability with the Connection Model Defined in [[RFC4975|RFC 4975]] == |
An MSRP UA conformant to this document can interoperate with a UA | An MSRP UA conformant to this document can interoperate with a UA | ||
− | that follows the connection model defined in | + | that follows the connection model defined in [[RFC4975]]. However, if |
an MSRP UA conformant to this document is located behind a NAT, does | an MSRP UA conformant to this document is located behind a NAT, does | ||
not proxy its MSRP communication via an MSRP relay, and receives an | not proxy its MSRP communication via an MSRP relay, and receives an | ||
SDP offer from a remote UA that follows the connection model defined | SDP offer from a remote UA that follows the connection model defined | ||
− | in | + | in [[RFC4975]], then NAT traversal can only be achieved if the MSRP UA |
supports ICE [ICE-TCP] or if the network supports Session Border | supports ICE [ICE-TCP] or if the network supports Session Border | ||
Controller (SBC)-assisted NAT traversal for TCP. | Controller (SBC)-assisted NAT traversal for TCP. | ||
Line 247: | Line 247: | ||
== Security Considerations == | == Security Considerations == | ||
− | According to the connection model defined in | + | According to the connection model defined in [[RFC4975]], the MSRP UA |
that sends the SDP offer becomes the active party, and it is | that sends the SDP offer becomes the active party, and it is | ||
responsible for creating the MSRP transport connection towards the | responsible for creating the MSRP transport connection towards the | ||
Line 253: | Line 253: | ||
When COMEDIA is used, either the sender or the receiver of the SDP | When COMEDIA is used, either the sender or the receiver of the SDP | ||
− | offer can become the active party. | + | offer can become the active party. [[RFC4975]] requires that the |
active party immediately issue an MSRP SEND request once the | active party immediately issue an MSRP SEND request once the | ||
connection has been established. This allows the passive party to | connection has been established. This allows the passive party to | ||
Line 263: | Line 263: | ||
The active party also takes the role of the TLS client, if TLS is | The active party also takes the role of the TLS client, if TLS is | ||
used to protect the MSRP messages. However, there are no procedures | used to protect the MSRP messages. However, there are no procedures | ||
− | in | + | in [[RFC4975]] that would break in case the receiver of the SDP offer |
takes the role of the TLS client, and the level of security provided | takes the role of the TLS client, and the level of security provided | ||
by TLS is not affected. | by TLS is not affected. | ||
Line 277: | Line 277: | ||
=== Normative References === | === Normative References === | ||
− | + | [[RFC0793]] Postel, J., "Transmission Control Protocol", [[STD7|STD 7]], | |
− | RFC 793, September 1981. | + | [[RFC793|RFC 793]], September 1981. |
− | + | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate | |
− | Requirement Levels", BCP 14, RFC 2119, March 1997. | + | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. |
− | + | [[RFC4145]] Yon, D. and G. Camarillo, "TCP-Based Media Transport in | |
− | the Session Description Protocol (SDP)", RFC 4145, | + | the Session Description Protocol (SDP)", [[RFC4145|RFC 4145]], |
September 2005. | September 2005. | ||
− | + | [[RFC4975]] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., | |
− | "The Message Session Relay Protocol (MSRP)", RFC 4975, | + | "The Message Session Relay Protocol (MSRP)", [[RFC4975|RFC 4975]], |
September 2007. | September 2007. | ||
− | + | [[RFC4976]] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions | |
for the Message Sessions Relay Protocol (MSRP)", | for the Message Sessions Relay Protocol (MSRP)", | ||
− | RFC 4976, September 2007. | + | [[RFC4976|RFC 4976]], September 2007. |
=== Informative References === | === Informative References === | ||
− | + | [[RFC3261]] Rosenberg, J., Schulzrinne, H., Camarillo, G., | |
Johnston, A., Peterson, J., Sparks, R., Handley, M., | Johnston, A., Peterson, J., Sparks, R., Handley, M., | ||
and E. Schooler, "SIP: Session Initiation Protocol", | and E. Schooler, "SIP: Session Initiation Protocol", | ||
− | RFC 3261, June 2002. | + | [[RFC3261|RFC 3261]], June 2002. |
− | + | [[RFC5382]] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and | |
P. Srisuresh, "NAT Behavioral Requirements for TCP", | P. Srisuresh, "NAT Behavioral Requirements for TCP", | ||
− | BCP 142, RFC 5382, October 2008. | + | [[BCP142|BCP 142]], [[RFC5382|RFC 5382]], October 2008. |
− | + | [[RFC5389]] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, | |
− | "Session Traversal Utilities for NAT (STUN)", RFC 5389, | + | "Session Traversal Utilities for NAT (STUN)", [[RFC5389|RFC 5389]], |
October 2008. | October 2008. | ||
− | + | [[RFC5780]] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery | |
Using Session Traversal Utilities for NAT (STUN)", | Using Session Traversal Utilities for NAT (STUN)", | ||
− | RFC 5780, May 2010. | + | [[RFC5780|RFC 5780]], May 2010. |
[ICE-TCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, | [ICE-TCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, |
Latest revision as of 03:58, 22 October 2020
Internet Engineering Task Force (IETF) C. Holmberg Request for Comments: 6135 Ericsson Category: Standards Track S. Blau ISSN: 2070-1721 Ericsson AB
February 2011
An Alternative Connection Model for the Message Session Relay Protocol (MSRP)
Abstract
This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6135.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
5. Interoperability with the Connection Model Defined in RFC 4975 ..6
Contents
Introduction
The Message Session Relay Protocol (MSRP) core specification RFC4975 states that the MSRP User Agent (UA) that sends the Session Description Protocol (SDP) offer is "active", and it is responsible for creating the MSRP transport connection towards the remote UA if a new connection is required. The core specification also allows, but does not define, alternate mechanisms for MSRP UAs to create MSRP transport connections.
RFC4145 defines a connection-oriented media (COMEDIA) mechanism, which endpoints can use to negotiate the endpoint that initiates the creation of media transport connection.
COMEDIA is especially useful when one of the endpoints is located behind a Network Address Translator (NAT). The endpoint can use the mechanism to indicate that it will create the media transport connection, in order for the media to traverse the NAT without the usage of relays and without being required to support more complex mechanisms (e.g., "TCP Candidates with Interactive Connectivity Establishment (ICE)" [ICE-TCP]). In addition, COMEDIA allows the usage of identical procedures in establishing Transmission Control Protocol (TCP) RFC0793 connections for different types of media.
An example is the Open Mobile Alliance (OMA)-defined "Instant Message using SIMPLE" [OMA-SIMPLE], where one MSRP UA of every MSRP transport connection represents a media server, which is always located in the carrier network. The media server has a globally reachable IP
address and handles application-specific policy control as well as NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA for NAT traversal, and all OMA IM MSRP clients support COMEDIA.
This document defines how an MSRP UA uses COMEDIA in order to negotiate which UA will create the MSRP transport TCP connection towards the other UA. The document also defines how an MSRP UA that uses COMEDIA can establish an MSRP transport connection with a remote UA that does not support COMEDIA.
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 RFC 2119 RFC2119.
Applicability Statement
Support of this specification is OPTIONAL for MSRP UAs in general. UAs that are likely to be deployed in networks with NATs SHOULD support this specification. It will improve the odds of being able to make TCP connections successfully traverse NATs, since UAs behind NATs can be requested to initiate the establishment of the TCP connections.
COMEDIA for MSRP
General
This section defines how an MSRP UA that supports this specification uses the COMEDIA SDP attributes defined in RFC4145.
a=setup
General
An MSRP UA uses the SDP a=setup attribute RFC4145 in order to negotiate which endpoint will create the MSRP transport connection towards the other UA.
An MSRP UA MUST always include an explicit a=setup attribute in its SDP offers and answers, since it might be useful for the other endpoint, or for entities in the network, to know whether the UA supports COMEDIA or not.
An MSRP UA MUST support the a=setup "active", "actpass", and "passive" attribute values. An MSRP UA MUST NOT send the "holdconn" attribute value. If an MSRP UA receives the "holdconn" attribute value, it MUST ignore it and process the message as if it did not contain an a=setup attribute.
Attribute Usage
When the a=setup attribute value is "actpass" or "passive", the IP address and port values in the MSRP URI of the SDP a=path attribute MUST contain the actual address and port values on which the UA can receive a TCP connection for the MSRP transport connection.
In accordance with RFC4145, if the a=setup attribute value is "active", the port number value should be 9.
If an MSRP UA can provide a globally reachable IP address that the other endpoint can use as a destination for a TCP connection, the UA MUST use the a=setup "actpass" attribute value in SDP offers. This is in order to allow the remote UA to send an SDP answer with an a=setup "active" attribute value if the UA is located behind a NAT, and in order to be compatible with UAs that do not support COMEDIA and thus always will act as passive endpoints. If an MSRP UA cannot provide the actual transport address, the UA MUST use the a=setup "active" attribute value.
The UA MUST NOT use the a=setup "passive" attribute value in an SDP offer.
The MSRP UA can determine that it provides a globally reachable IP address in the following scenarios:
o the UA can determine that it is not located behind a NAT;
o the UA relays its MSRP transport connections via a relay (e.g., an
MSRP relay or Traversal Using Relay NAT (TURN) server); or
o the UA has used Session Traversal Utilities for NAT (STUN)
RFC5389 signaling to retrieve the NAT address and port through the local port to be used for the eventual transport connection, while also having determined that the NAT has endpoint-independent mapping and filtering behavior RFC5382, e.g., using the mechanism defined in RFC5780.
Some UAs can determine whether the SIP RFC3261 signaling has traversed a NAT by inspecting the SIP Via header field in the 200 (OK) response to the initial SIP REGISTER request, and comparing the IP addresses in the Via sent-by and the received header field
parameters. If the IP addresses are not the same, then the UA can determine that there is a NAT in the path. Even though the media transport might not traverse the NAT, it is safe to assume that it will. This comparing mechanism does not work in all scenarios, though. For example, if SIP a request crosses a SIP proxy before crossing a NAT, the UA will not be able to detect the NAT by comparing the IP addresses.
If an SDP offer includes an a=setup "actpass" attribute value, the SDP answerer MAY include an a=setup "active" attribute value in the SDP answer, but SHOULD include an a=setup "passive" attribute value if it knows that it is not located behind a NAT.
Once the active UA has established the MSRP transport connection, the UA must immediately send an MSRP SEND request, as defined in RFC4975.
NOTE: According to RFC4975, the initiating UA is always active, but when COMEDIA is used, the a=setup attribute is used to negotiate which UA becomes active.
TLS
If an MSRP UA conformant to this document uses Transport Layer Security (TLS), it MUST use the TLS mechanisms defined in RFC4975 and RFC4976.
According to RFC4975, the connection can be established with or without TLS mutual authentication. In case mutual authentication is not used, the listening device waits until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description. From the TLS authentication point of view, it is thus irrelevant whether an endpoint takes the active or passive role.
If an MSRP UA uses a self-signed TLS certificate to authenticate itself to MSRP peers, it also includes its certificate fingerprint in the SDP.
Note that fingerprints can only be exchanged in peer-to-peer communication, as MSRP relays RFC4976 will not receive the SDP payloads containing the fingerprint attributes.
a=connection
MSRP UAs MUST NOT use the SDP a=connection attribute. RFC4975 defines connection reuse procedures for MSRP, and this document does not modify those procedures.
If an MSRP UA receives an a=connection attribute, the UA MUST ignore it.
MSRP Relay Connection
If an MSRP UA is located behind an MSRP relay RFC4976, the UA MUST always initiate a transport connection towards the relay, no matter what value the client has provided in the a=setup attribute.
NOTE: Even if an MSRP UA initiates the TCP connection towards its relay, the UA will only send a SEND request if the UA is active, based on the COMEDIA negotiation.
Interoperability with the Connection Model Defined in RFC 4975
An MSRP UA conformant to this document can interoperate with a UA that follows the connection model defined in RFC4975. However, if an MSRP UA conformant to this document is located behind a NAT, does not proxy its MSRP communication via an MSRP relay, and receives an SDP offer from a remote UA that follows the connection model defined in RFC4975, then NAT traversal can only be achieved if the MSRP UA supports ICE [ICE-TCP] or if the network supports Session Border Controller (SBC)-assisted NAT traversal for TCP.
Security Considerations
According to the connection model defined in RFC4975, the MSRP UA that sends the SDP offer becomes the active party, and it is responsible for creating the MSRP transport connection towards the remote UA if a new connection is required.
When COMEDIA is used, either the sender or the receiver of the SDP offer can become the active party. RFC4975 requires that the active party immediately issue an MSRP SEND request once the connection has been established. This allows the passive party to bind the inbound TCP connection to the message session identified by the session id part of its MSRP URI. The use of COMEDIA does not change this requirement, but the sender of the SDP offer is no longer assumed to always become the active party.
The active party also takes the role of the TLS client, if TLS is used to protect the MSRP messages. However, there are no procedures in RFC4975 that would break in case the receiver of the SDP offer takes the role of the TLS client, and the level of security provided by TLS is not affected.
Acknowledgements
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, and Shida Schubert for their guidance and input in producing this document.
References
Normative References
RFC0793 Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC4145 Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, September 2005.
RFC4975 Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
RFC4976 Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
Informative References
RFC3261 Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
RFC5382 Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and
P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
RFC5389 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
RFC5780 MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010.
[ICE-TCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, February 2011.
[OMA-SIMPLE] Open Mobile Alliance, "Instant Messaging using SIMPLE",
OMA-TS-SIMPLE_IM-V1_0-20090901-D, September 2009.
Authors' Addresses
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
EMail: [email protected]
Staffan Blau Ericsson AB PO Box 407 Sweden
EMail: [email protected]