Connection setup negociation for the Message Session Relay Protocol

MSRP allows transmission of byte streams (such as computer files) between two nodes using a SIP infrastructure. Because reliability and congestion control are required, MSRP uses TCP as its underlying transport protocol. Furthermore, MSRP specifies that the party initiating the session shall act as the active endpoint in establishing the connection-oriented transport session. The answering party shall wait for an incoming connection request, then check the MSRP path header in the first MSRP request, to bind the connection with the SIP dialog. This poses a significant challenge if the answering party is located behind a NAT and/or a stateful firewall. To address these issues, MSRP defines relay nodes (in ), which MSRP clients can use as application-layer proxies. However, deploying these relays bears a significant extra cost, especially as MSRP relays are limitated to a single application-layer protocol (contrary to TURN or SOCKS). This also constitute a chicken-and-egg problem to MSRP deployment. In addition, MSRP relaying affects the reliability of the data transmission, due to the lack of end-to-end congestion control and reliable end-to-end partial delivery acknowledgement mechanism (partial acknowledgment are optional for receiver to send). This memo proposes an alternative connection model for MSRP. It avoids the use of any middlebox when either party to the MSRP session, is not behind a NAT or a firewall. It also brings reliability and congestion control to MSRP through to the use of an end-to-end TCP session.

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 .

Under some usage scenarios, the offerer of an MSRP session description is more likely to be able to receive incoming transport-layer connection requests than the answerer. Some examples scenarios might be: a MSRP chat server inviting an user to a chat session , a file being pushed to the receiver from a file server, a SOCKS proxy, or a TURN relay available to the offerer but not the answerer, adequate hole punching provision on the offerer side (e.g. with UPnP IGD profile, or manual configuration). In these cases, it would be possible for the answerer to use an MSRP relay, if it cannot receive incoming connection requests, such as if it is located behind a NAT. However, if the offerer can act as the passive side in the establishment of the media connection, the connection setup can be negotiated using COMEDIA. This has the following advantages: no need to deploy and provision a MSRP relay, reliability and congestion control are transparently ensured, as the transport connection is end-to-end,

If the offerer of an MSRP session knows that it is prepared to handle transport-layer connection requests, it MUST include the "setup" SDP attribute, as defined in . It MAY also include the "connection" SDP attribute (to specify whether a transport connection may be re-used), as defined in the same document. In that case, the setup attribute MUST be set to either "passive" or "actpass". However, for the sake of compatibility with MSRP client which do not implement this specification, it is RECOMMENDED: that "actpass" be used, rather than "passive", that the offerer be ready to establish an active connection, as per the basic MSRP connection model. The following example shows an exerpt of an SDP offer using COMEDIA:

v=0 o=alice 8459831645 4643536435 IN IP4 alice.example.com s= - c=IN IP4 alice.example.com t=0 0 m=message 4535 TCP/MSRP * a=setup:actpass a=connection:new ... other session attributes ... If the offerer is not willing or capable of handling incoming connection requests, it MAY set the setup attribute to "active". If not specified, this is assumed to be the default. For backward compatiblity with MSRP endpoints that do not support the extension specified in this memo, it SHOULD include its actual transport-layer source port number in the offer m= line, rather than specify the port number 9 (discard). The "holdconn" setup type is not defined, and MUST NOT be used. It is left for future specification.

When the offerer receives a succesful answer, it looks for the setup attribute in the SDP for each media: If the setup attribute is absent from the answer, and if the offerer had included a setup attribute with the value "passive", the answerer does not support this specification, and the media establishment MUST be considered as failed. Otherwise, if the setup attribute is absent from the answer, even though the answerer might not support this specification, the COMEDIA connection model can be used (because it is then compatible with the baseline MSRP connection model). Otherwise, the answerer supports the COMEDIA connection model described in this specification.

If it has been determined that the connection can be established according to the model described in this memo, the offerer MUST establish the media connection according to , with the following exception: The source address of the active connection endpoint would normally be found in the relevant c= line, as well as in MSRP path line from the SDP. However, if a NAT device is present on the media path, these addresses might not match the IP address and port numbers of the actual TCP packets. To compensate for this inconsistency, the passive endpoint MUST ignore the address found in the c= and a=path: SDP lines, and accept incoming TCP connection requests from any remote peer. To protect against a potential denial of service, the passive peer might need to process multiple incoming TCP sessions, until one of them has been authenticated. The legitimate TCP session MUST be authenticated by checking the From-Path and To-Path fields from MSRP requests received through that TCP session. As specified in , the active endpoint MUST use the host/address and ports as found in the SDP m= and c= line. It SHOULD not match the MSRP path in the SDP a=path: attribute with the m= and c= line. That should allow interoperating with COMEDIA-aware application layer gateways if there is one on the signaling path.

When a MSRP client receives a MSRP session offer, and determines that it will accept the offer, it looks for the setup attribute. If it is absent, or its value is active, the client MUST follow the normal MSRP connection model. If the value is "passive", the answerer MUST initiate the TCP connection to the offerer, as specified in . It will still need to process other SDP parameters (such as "a=accept-bytes") as specified in . In particular, it needs to cross-match the MSRP a=path SDP attribute with the From-Path headers used in the received MSRP messages. If the value is "actpass", it MUST choose either of two above connection models, and send format its answer accordingly as specified above. In particular, if it is known that connection requests cannot be processed by the answerer, it SHOULD act as the active endpoint. Similarly, if it is known that connection requests can be processed efficiently (i.e. not using any relaying protocol), it SHOULD act as the passive endpoint.

If the answerer is to initiate the TCP connection (as per the rules set above), it MUST include a COMEDIA setup attribute with a value of "active" in the answer SDP which it sends back to the offerer (see example below). It MUST also format the c= and m= line as specified in .

v=0 o=alice 3245439832 1457605654 IN IP4 bob.example.com s= - c=IN IP4 bob.example.com t=0 0 m=message 9 TCP/MSRP * a=setup:active a=connection:new ... other session attributes ... Otherwise, the answerer MAY include a COMEDIA setup attribute with a value of "passive", as in the following example:

v=0 o=alice 3245439832 1457605654 IN IP4 bob.example.com s= - c=IN IP4 bob.example.com t=0 0 m=message 34567 TCP/MSRP * a=setup:active a=connection:new ... other session attributes ...

Once the TCP session is established, and if the answerer was the active connection endpoint, it MUST send an MSRP request. In particular, if it has no pending data to send, it MUST send an empty MSRP SEND request. That is necessary for the other endpoint to authenticate this TCP session. Some extension to this specification MAY specify other methods to authenticate the peer, (see also ).

It is not possible to use the MSRP COMEDIA connection model as defined in this memo, and one or more MSRP relays for a given MSRP session. Whenever the offerer uses a MSRP relay, then it MUST NOT advertise support of the MSRP COMEDIA connection model. Instead, it MUST follow the baseline MSRP connection model. Whenever the answerer detects a MSRP media with a COMEDIA "a=setup" SDP parameter within an offer, while it wants to use a MSRP relay, it MUST discard the "a=setup" attribute in the offer. Note that the discarded "a=setup" SDP attribute might still apply to any other media in the same offer, if there are more than one m= lines in the SDP offer.

The MSRP protocol does not allow leading CRLF (contrary to e.g., HTTP or SIP). If a keep-alive is required, a dummy MSRP SEND request SHOULD be sent, similar to when establishing a new MSRP connection. It should be noted that sending frequent keep-alives may have very adverse effect when used with certain network access technologies (such as 3G cellular), such as dramatic increase of current drain. As TCP bindings tend to have much longer expiration timers than UDP, on middleboxes, sending of keep-alives might not be as critical as with a UDP-based protocol.

If an MSRP connection that is negotiated using the mechanism described in section , uses the Transport Layer Security protocol, the Client and Server TLS roles MUST negotiate the relevant parameter as specified per COMEDIA-TLS. In addition, the MSRP "a=path" attribute MUST specify "msrps" as the URI scheme, consistent with . If TLS is not used, the URI scheme would be "msrp".

ICE-TCP can be used as is with the MSRP COMEDIA, as it is an extension to COMEDIA.

TBD.

This document raises no new IANA considerations.

The authors would like to thank Christian Schmidt, Bernhard Böhmer, Miguel Garcia, Thomas Theimer, Ivo Sedlacek, Markku Vimpari and Thomas Belling for their comments on this document.