An Alternative Connection Model for the Message Session Relay Protocol (MSRP)
Extracted elements (22)
COMEDIA is introduced for MSRP to allow endpoints behind NATs to negotiate which side initiates the TCP transport connection, avoiding the need for complex mechanisms such as ICE-TCP or relays. RFC 4975 mandates the SDP offerer is always active, but this is inflexible when the offerer is behind a NAT.
Even when 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. The relay connection direction and the COMEDIA active/passive role are independent.
The OMA 'Instant Message using SIMPLE' deployment motivated COMEDIA for MSRP: one UA of every MSRP session represents a media server with a globally reachable IP in the carrier network, and all OMA IM MSRP clients support COMEDIA for NAT traversal.
An MSRP UA conformant to this document can interoperate with a UA following the RFC 4975 connection model. However, if the COMEDIA UA is behind a NAT without an MSRP relay and the remote UA follows RFC 4975, NAT traversal requires ICE-TCP or SBC-assisted NAT traversal for TCP.
Some UAs detect NAT presence by comparing the IP address in the SIP Via sent-by parameter with the received parameter in the 200 OK response to REGISTER. This method fails when a SIP proxy sits between the UA and the NAT.
An MSRP UA MUST always include an explicit a=setup attribute in its SDP offers and answers, so that the other endpoint and network entities can determine whether COMEDIA is supported.
An MSRP UA MUST NOT use the a=setup 'passive' attribute value in an SDP offer.
An MSRP UA MUST support the a=setup attribute values 'active', 'actpass', and 'passive'. An MSRP UA MUST NOT send the 'holdconn' attribute value.
If an MSRP UA can provide a globally reachable IP address, the UA MUST use the a=setup 'actpass' attribute value in SDP offers, to allow the remote UA to answer with 'active' if behind a NAT and to maintain compatibility with non-COMEDIA UAs that act as passive endpoints.
If an MSRP UA cannot provide the actual transport address (e.g., it is behind a NAT without a relay), the UA MUST use the a=setup 'active' attribute value.
If an MSRP UA conformant to this document uses TLS, it MUST use the TLS mechanisms defined in RFC 4975 and RFC 4976.
If an MSRP UA is located behind an MSRP relay (RFC 4976), the UA MUST always initiate a transport connection towards the relay regardless of the value in the a=setup attribute.
If an MSRP UA receives the a=setup 'holdconn' attribute value, it MUST ignore it and process the message as if it did not contain an a=setup attribute.
If an SDP offer includes an a=setup 'actpass' value, the SDP answerer MAY include 'active' in the answer, but SHOULD include 'passive' if it knows it is not located behind a NAT.
MSRP UAs MUST NOT use the SDP a=connection attribute. RFC 4975 defines connection reuse procedures for MSRP and this document does not modify those. If an MSRP UA receives an a=connection attribute, it MUST ignore it.
Once the active UA has established the MSRP transport connection, the UA must immediately send an MSRP SEND request as defined in RFC 4975, allowing the passive party to bind the inbound TCP connection to the session.
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 to improve chances of successful TCP NAT traversal.
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.
A UA can determine it provides a globally reachable IP address in three scenarios: it is not behind a NAT; it relays MSRP connections via an MSRP relay or TURN server; or it has used STUN to retrieve the NAT address and confirmed endpoint-independent mapping and filtering behavior.
When an MSRP UA uses a self-signed TLS certificate to authenticate itself to peers, it includes its certificate fingerprint in the SDP. Fingerprints can only be exchanged in peer-to-peer communication, as MSRP relays do not receive SDP payloads.
The active party takes the role of TLS client when TLS is used. There are no procedures in RFC 4975 that break if the SDP offer receiver takes the TLS client role, and the security level provided by TLS is unaffected by which endpoint is active.
With COMEDIA, either the SDP offer sender or receiver can become the active party. RFC 4975 requires the active party to immediately issue an MSRP SEND request upon connection establishment, allowing the passive party to bind the inbound TCP connection to the session. COMEDIA does not change this security binding requirement.