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 MSRP protocol (as defined by and ) supports the delivery of messages and files from one SIP UA 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 the SIPREC Architecture .

(TBD...)

For consistency with the SIPREC Architecture and the SIPREC Protocol 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.

and describe 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)

As with RTP-based media, CS MSRP media streams from different participants may be mixed into a single RS media stream, or they may be conveyed as separate MSRP streams. In RTP, when media from different participants is mixed, it is distinguished by CNAME and SSRC or CSRC. In MSRP, media from different participants is distinguished by wrapping the the message in a CPIM body, with the sender identified by the From header in the CPIM. If the SRC mixes MSRP media from multiple senders, then each message that isn't already in CPIM format SHOULD be embedded in a CPIM message, and the From and To headers of that CPIM wrapper SHOULD identify the sending and receiving participants for that message.

When preparing to record a CS MSRP media stream, the SRC MUST choose a corresponding RS MSRP session. CS MSRP sessions that are being mixed share an RS MSRP session, while those that are not being mixed are assigned to unique RS MSRP sessions. The RS MSRP session MAY be newly created, or a pre-existing RS MSRP session that is no longer in use MAY be repurposed. When an MSRP session is repurposed, the SRC communicates this change to the SRS via a change in the metadata. The SRC is responsible for ensuring that messages for the new session are not sent until the SRS has received the metadata describing this new session. MSRP message flow on a RS MSRP session is always from the SRC to the SRS. The SRC generates SEND messages, and may receive REPORT messages. It does not receive SEND messages or send REPORT messages.

The SRS MUST be able handle a case where an RS MSRP session if first used to record one CS MSRP session and then is repurposed to record a different CS MSRP session. The SRS is learns of this change via a change in the metadata. MSRP message flow on a RS MSRP session is always from the SRC to the SRS. The SRS receives SEND messages, and sends REPORT messages. It does not generate SEND messages or receive REPORT messages.

A mechanism for doing file transfer via MSRP is specified in . If this mechanism is used in the CS, then the SRC MAY use it in the RS to record those files. In turn, the SRS MAY choose to accept some or all of those file transfer requests, or MAY reject them. Both file push and file pull operations are defined. If the SRC chooses to record a file transfer, whether it is initiated in the CS via a push operation or a pull operation, within the RS the SRC MUST initiate the transfer with a push operation in an SDP Offer. (SRS initiation of a file transfer is out of scope of this document.) It is possible that the SRC may support file transfer while the SRS does not. If the SRC sends an SDP offer to the SRS containing an m-line initiating a file transfer, and the SRS sends an answer accepting the MSRP session, but fails to include a matching file-transfer-id, then the SRC MUST abort the file transfer without sending any file content.

An CS MSRP session might involve a chatroom. The SRC discovers this by observing use of the features defined in When the CS MSRP session involves a chatroom, the SRC MUST indicate this in the corresponding RS MSRP session. The key unique features of chatrooms are nicknames and private messages. If either of these features is indicated in a 'chatroom' attribute in the CS, then this MUST also be indicated in the RS. How to reflect the use of nicknames from the CS to the RS is TBD.

The metadata defined in can be used without change to describe MSRP streams.

What the SRC should do if it observes a MSRP error response or a failure report is TBD?

Recording chat sessions that use nicknames presents difficult problems. The chat mechanism doesn't have provision for a single MSRP endpoint to concurrently use multiple nicknames. Perhaps we can handle nicknames via metadata - as an additional attribute to a Participant.

This document contains no IANA considerations.

Not explicitly covered in this version.