Overview for MSRP Recording based on SIPREC

SIPREC is capable of recording interactive text media that is transmitted via RTP, as defined by . However that format is not commonly used for message or chat scenarios. There is also a need for recording text media carried via MSRP. One case of note is exchange of text between hearing-impaired users and emergence service bureaus. Also, recording support is needed for MSRP used in chat conferences (as defined by ) and multimedia conferences (as defined by ). Instant message media is carried by a variety of protocols such as IRC, MSRP and XMPP/JINGLE. The SIP based protocol MSRP (as defined by ) supports the delivery of messages and files from one SIPUA to another. When a SIPREC SRC is recording a CS that contains an MSRP channel, it may want to record the messages passing over that channel. To gain access to the messages, the SRC may act as an MSRP client, relay, or switch. The SRC needs to replicate and deliver the messages over an MSRP channel within a Recording Session (RS) to an SRS. The replicated content could be in Message/CPIM format containing plain text, HTML, images, etc. In this document, file delivering sessions have not yet been considered. Other instant message protocols, like IRC or XMPP, are out of scope. This document describes how MRSP sessions are established between an SRC and SRS, and used for conveying the replicated MSRP Media, and also specifies metadata that describes the recorded MSRP sessions. A Recording Session employing MSRP is established using the normal procedures for establishing INVITE initiated dialogs and uses SDP for describing the media to be used during the session as described by .

(TBD...)

For consistency with and , MSRP recording needs to deliver duplicated MSRP message content from the SRC to the SRS, with suitable descriptive metadata. The SRC may be associated with SIP UA (endpoint) with an MSRP client, or with a SIP B2BUA that accesses the media via an MRSP Relay. An SRC may also be associated with a SIP conference focus and an MSRP switch.

describes how an MSRP client communicates to another MSRP client via a SIP session. A MSRP client that has access to the MSRP content to be recorded may act as SRC. The MSRP client may send the replicated media to the SRS along with corresponding metadata. If the MSRP client/SRC is aware the MSRP session needs to be recorded, it can initiate the establishment of a SIP RS by sending an INVITE to SRS, or vice-versa. The MSRP client/SRC is responsible for notifying the other MSRP client involved in the CS that the MSRP session is being recorded. The MSRP client/SRC is responsible for complying with request from recording aware UAs or through some configured policies indicating that the CS should not be recorded.

| Recorder | | (SRC) | SIP/Metadata | (SRS) | +-------------+ +-------------+ ]]>

(TBD... RFC4976)

| Recorder | | (SRC) | SIP/Metadata | (SRS) | +-------------+ +-------------+ | | v +-------------+ | MSRP CLIENT | +-------------+ ]]>

(TBD... ietf-simple-chat)

There are several possible ways of passing CS MSRP messages from the SRC to the SRS. Here are three: For each CS MSRP channel that is recorded, a corresponding new MSRP channel is created in the RS. For each CS MSRP channel that is recorded, a corresponding MSRP channel is dedicated in the RS. When recording of the CS MSRP channel ceases, the corresponding MSRP channel may be reassigned. MSRP messages from multiple MSRP participants of a CS are multiplexed (mixed) over a single MSRP channel in the RS.

(TBD...)

Is there any need for in-band indication that MSRP is being recorded? MSRP-based file transfers (in scope or not?)

This document contains no IANA considerations.

Not explicitly covered in this version.