| SIPREC | M. Yan |
| Internet-Draft | P. Kyzivat |
| Intended status: Informational | Huawei |
| Expires: February 27, 2016 | August 26, 2015 |
Overview for MSRP Recording based on SIPREC
draft-yan-siprec-msrp-recording-04
SIPREC is capable of recording interactive text media that is transmitted via RTP. 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 and multimedia conferences.
This document describes how to achieve MSRP channel recording within the mechanism of SIP Recording (SIPREC).
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].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 27, 2016.
Copyright (c) 2015 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.
SIPREC is capable of recording interactive text media that is transmitted via RTP, as defined by [RFC4103]. 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 [I-D.ietf-simple-chat]) and multimedia conferences (as defined by [RFC4597]).
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 [RFC4975] and [RFC4976]) 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 [RFC3261] and uses SDP [RFC4566] for describing the media to be used during the session as described by the SIPREC Architecture [RFC7245].
This version addresses comments received on the -01 version, both on the mailing list and at IETF90. The following is my list of things to address:
The primary change is to introduce a new wrapper MIME type ("application/msrp-recording") that is used in RS MSRP sessions for all CS MSRP messages that are to be recorded. This is used with SEND messages whether they have a CPIM wrapper or not. It also allows non-SEND messages from the CS to be sent intact in the RS for recording. And it provides a vehicle for carrying other data as needed.
Adding another layer of wrapper could substantially increase the total amount of data send on the RS session, relative to what is present on the CS. I've tried to mitigate that via the details of the design. For SEND messages, only the body of the SEND message is wrapped. And From and To headers in this wrapper can be omitted in cases where that information is redundant. I've assumed that messages other than SEND should in general be infrequent enough that extra overhead when sending them isn't worth a lot of concern.
This wrapper can carry a DateTime header. This provides a mechanism to address the timestamp issues. I've left it as optional to use.
I clarified the non-guarantee of recording in the architecture section.
I've provided a special header in the wrapper to carry the MESSAGE-ID from SEND messages in the CS. And SEND messages will get a separate MESSAGE-ID on the RS MSRP session when sent to the SRS. This provides the SRS with enough information to solve the correlation problem when a message is incomplete in one CS MSRP session and is resumed on another. (The problem of reassembly is left to the SRS.)
The wrapper format includes a mechanism for the SRC to report dropped messages to the SRS.
The wrapper format also includes a mechanism for encapsulating CS REPORT messages for sending to the SRS.
I realized that this level of wrapping provides an opportunity to multiplex unrelated CS MSRP sessions on a single RS MSRP session. To allow this I've provided a way to include the session-id from the metadata, that identifies the particular CS MSRP session, as a value in the wrapper of the message sent on the RS. But I also made that optional when it is redundant. This gives a choice: multiplex but make the messages bigger, or create a separate RS MSRP session for each CS MSRP session and keep the messages smaller. I've included this as a trial balloon for discussion. I'm undecided about it.
The formatting of all of this could be better. But for now I just wanted to get the basic concepts down for review. Once the approach is reasonably well worked out I'll try to improve the formatting.
There are many places here where I am uncertain what normative strength to apply to individual requirements. I've indicated this inline for many of those. Please comment on this.
(TBD...)
For consistency with the SIPREC Architecture [RFC7245] and the SIPREC Protocol [I-D.ietf-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.
Note: The decision to record or not is a policy decision on the part of both the SRC and the SRS. Support for this specification provides no guarantee that any particular MSRP session, or message within a session, will be recorded. However MSRP recording is subject to the notification requirements called out in Section 6.1.2 of [I-D.ietf-siprec-protocol].
[RFC4975] and [RFC4976] 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.
+-------------+
| MSRP CLIENT |
+-------------+
^
| (Communication Session)
|
| SIP
v
+-------------+ (Recording Session) +-------------+
| MSRP CLIENT |<---------------------->| Recorder |
| (SRC) | SIP/Metadata | (SRS) |
+-------------+ +-------------+
Figure 1: MSRP Client Acts as SRC
(TBD... RFC4976)
+-------------+
| MSRP CLIENT |
+-------------+
^
| (Communication Session)
| SIP
+-------------+ (Recording Session) +-------------+
| MSRP RELAY |<---------------------->| Recorder |
| (SRC) | SIP/Metadata | (SRS) |
+-------------+ +-------------+
|
|
v
+-------------+
| MSRP CLIENT |
+-------------+
Figure 2: MSRP Relay Acts as SRC
(TBD... ietf-simple-chat)
+-------------+ +-------------+
| MSRP CLIENT | | MSRP CLIENT |
+-------------+ +-------------+
^ ^
\ SIP / (Communication Session)
\ / SIP
+-------------+ +-------------+
| MSRP switch | (Recording Session) | Recorder |
| (SRC) |<------------------->| (SRS) |
+-------------+ SIP/Metadata +-------------+
/ \
/ SIP \ SIP
v v
+-------------+ +-------------+
| MSRP CLIENT | | MSRP CLIENT |
+-------------+ +-------------+
Figure 3: MSRP Switch Acts as SRC
[TODO: Revise this to cover multiplexing of unrelated media streams.]
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.
[TODO: Revise this to cover multiplexing of unrelated media streams.]
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.
[TODO: Revise this to cover multiplexing of unrelated media streams.]
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 [RFC5547]. 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 NOT send the content of CS MSRP file transfer session to the SRS.
An CS MSRP session might involve a chatroom. The SRC discovers this by observing use of the features defined in [I-D.ietf-simple-chat]
When the CS MSRP session involves a chatroom, the SRC SHOULD [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 an SDP 'chatroom' attribute in the CS, then this MAY also be indicated in the RS SDP.
Requests for nickanmes in the CS via the NICKNAME message are reported to the SRS using the mechanism described in Section 11.3.
When messages are sent by sources that have had a nickname assigned, the nickname is conveyed to the SRS using the mechanism described in Section 10.4.
Private messages used in a chatroom are identified in the CS via a CPIM wrapper with a To header that identifies the intended recipient(s) rather than the URI of the chatroom itself. This information is retained when the message is forwarded to the RS, while the chatroom URI is also conveyed using the "To" header of the "application/msrp-recording" wrapper, as described in section Section 11.
The metadata defined in [I-D.ietf-siprec-metadata] can be used without change to describe MSRP streams.
The document defines a new MIME type "application/msrp-recording" as an extension to type "application/cpim". This type includes new headers for carrying details about the wrapped message. The new headers are all identified by a namespace prefix of "rs.".
The value of the "rs.Content" header is a token identifying the sort of content contained in the body of this message. The following types of content are defined:
At most one "rs.Content" header may be present in a message. If no "rs.Content" header is is present, then "rs.Content: send" is implied.
The 'send' token indicates that the content of the message contains all or a fragment of the body of an MSRP SEND message.
The 'drop' token indicates that the content of a SEND message in the CS is not being sent to the RS for recording.
The 'msrp' token indicates that the body of the message contains a complete MSRP message from the CS. This form MAY be used to convey REPORT messages, NICKNAME messages, and transaction responses.
The value of the "rs.Stream-ID" header is the stream-id used in the SIPREC metadata to identify the stream that this message belongs to. This header MAY be omitted if the SIPREC metadata associates exactly one stream with this MSRP session. If present, the value MUST match the stream-id of exactly one of the streams associated with this MSRP session.
The value of the "rs.Message-ID" header carries the value of the "Messsage-ID" from the MSRP SEND message. At most one "rs.Message-ID" header may be present in a message. It MUST be present when the "rs.Content" value is 'send' or 'drop', and MUST NOT be present in other cases.
The value of the "rs.Nickname" header carries the nickname of the sender of the MSRP SEND message. At most one "rs.Nickname" header may be present in a message. It MAY be present when the "rs.Content" value is 'send' or 'drop', and MUST NOT be present in other cases.
The value of the "rs.Unsupported-Type" header carries a content-type from a CS MSRP SEND message that is not supported by the SRS. It may be the outermost type, or the type of a component of a container type. Any number of "rs.Unsupported-Type" headers may be present in a message. It MAY be present when the "rs.Content" value is 'drop', and MUST NOT be present in other cases.
The value of the "rs.Size" header carries the integer size of an CS MSRP SEND message. At most one "rs.Size" header may be present in a message. It MAY be present when the "rs.Content" value is 'drop', and MUST NOT be present in other cases.
When CS MSRP messages are being recorded, the SRC encapsulates them in the wrapper type "application/msrp-recording". This wrapper type is used to encapsulate the basic MSRP SEND message content, and also to send CS MSRP control messages that should be recorded. It also provides the means for conveying per-message metadata.
The CPIM From and To headers of the wrapper are optional. They MUST be supplied when the proper value cannot be determined by other means:
The CPIM DateTime header MAY be included. If included, it SHOULD indicate the time that the corresponding CS message was sent or received by the SRC.
When the SRC wishes to record a SEND message from the CS it rewraps the message, taking body from the CS SEND message, placing that into the body of a new "application/msrp-recording" message, and then sending that with a SEND message in the corresponding RS MSRP session.
The SRC MAY retain the fragmentation present in the CS, mapping one CS SEND message to one RS SEND message. Or it MAY merge CS message fragments and/or re-fragment CS SEND message fragments. If a received fragment ends with a continuation-flag of "#", then last fragment sent on the RS MUST also end with a continuation-flag of "#".
Each SEND message fragment MAY, but need not, contain a "rs.Content: send" header.
Each SEND message fragment MUST contain an "rs.Message-ID" header identifying the Message-ID from the corresponding CS MSRP SEND message. (The resulting RS MSRP SEND message will also contain a Message-ID in the RS. This is a distinct value.)
If the SRC knows that the sender of the message on the CS has an associated Nickname [I-D.ietf-simple-chat], then the SRC SHOULD insert an "rs.Nickname" header containing the nickname.
[QUESTION: Do we need a way for the SRS to indicate a desire (or not) to receive indications of dropped messages?]
The SRC might decide not to record selected SEND messages from the CS MSRP session. When doing so is MAY send a 'drop' message as a indicator that a message has been dropped. The following considerations apply when deciding whether to send a 'drop' message:
When a 'drop' message is sent:
The SRC SHOULD forward NICKNAME messages in the CS to the SRS.
[QUESTION: Do we need a way for the SRS to indicate a desire (or not) to receive CS Transaction Error messages?]
To forward a NICKNAME message from the CS to the RS, the SRC places the entire NICKNAME message into the body of of a new "application/msrp-recording" message, and then sends that with a SEND message in the corresponding RS MSRP session.
The SRC SHOULD [MUST?] forward CS Failure Report messages on the RS.
The SRC MAY [SHOULD?] forward CS Success Report messages on the RS.
[QUESTION: Do we need a way for the SRS to indicate a desire (or not) to receive CS REPORT messages?]
To forward a REPORT message from the CS to the RS, the SRC places the entire REPORT message into the body of of a new "application/msrp-recording" message, and then sends that with a SEND message in the corresponding RS MSRP session.
The SRC SHOULD [MUST?] forward CS transaction responses indicating errors to the SRS.
The SRC MAY, but SHOULD NOT forward CS transaction responses indicating success to the SRS. An exception is success responses to NICKNAME messages, which MAY [SHOULD?] be passed to the SRS.
[QUESTION: Do we need a way for the SRS to indicate a desire (or not) to receive CS transaction response messages?]
To forward a transaction response from the CS to the RS, the SRC places the entire transaction response message into the body of of a new "application/msrp-recording" message, and then sends that with a SEND message in the corresponding RS MSRP session.
[TODO: Register application/msrp-recording.]
Not explicitly covered in this version.
| [RFC4103] | Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005. |
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006. |
| [RFC4597] | Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, DOI 10.17487/RFC4597, August 2006. |