[siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt

[Paul Kyzivat <[e-mail]>]

I just submitted a revised version of the MSRP recording draft.

The following is a summary of what is different in this version. (It is 
in the draft too.)

    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:

    o  Define a new MIME type that is used to wrap the CS MSRP messages
       that are being recorded.  This allows the original message to be
       left as-is, so it is always clear what it was.  While CPIM could
       be used for this, defining a new type will allow capturing other
       necessary metadata.

    o  Need to further consider the need to track message timing.  Can
       the timing of messages received by the SRS on the RS MSRP stream
       be considered a sufficient proxy for the timing of messages in the
       CS, or should we explicitly pass timestamps of messages as
       received on the CS?  (The issue was raised but not decided.)

    o  We need to clarify that there is no guarantee that messages
       received on the CS have been recorded.

    o  It was agreed that there is no need to record the MSRP URIs that
       are used to establish the CS MSRP session.

    o  It is important that we maintain a 1:1 consistency between MSRP
       MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used
       in the RS.  But we should not violate MSRP by using the same
       MESSAGE-IDs.  We came up with the idea of adding an SRC-specific
       prefix to the CS message ids to create unique ones for the RS.
       This should be done in a standard way so that the SRS can recover
       the original CS message ids, in order to support correlation
       across redundant SRCs.

    o  Will need to work out the details of what happens when a CS MSRP
       session is terminated with an incomplete message.  It will be
       necessary to send the incomplete message to the SRS, but must it
       appear to be incomplete within the SRS MSRP session?

    o  There are a variety of reasons why the SRC may not want, or be
       able to, record individual messages in the CS session.  (One
       example is because the message size is greater than the maximum
       indicated by the SRS.  Another is because the mime type of the
       message is a type that the SRS did not indicate support for.)
       There should be a type of placeholder message that can be sent to
       the SRS to indicate a message has been dropped, why, and some key
       attributes about the message.  The new SIPREC wrapper mime type
       could be designed to serve this purpose.

    o  REPORT messages on the CS can't be sent directly on the RS.  The
       new SIPREC wrapper mime type could also serve as a way to
       encapsulate those.

    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.

I believe this is in line with what was discussed in Toronto.

I especially want to hear whether people find this an acceptable 
direction, as well as thoughts on the details. And anything I might have 
overlooked that still needs to be addressed.

	Thanks,
	Paul

-------- Original Message --------
Subject: New Version Notification for draft-yan-siprec-msrp-recording-02.txt
Date: Wed, 27 Aug 2014 13:19:15 -0700
From: [e-mail]
To: Michael Yan <[e-mail]>,        "Paul H. Kyzivat" 
<[e-mail]>,        "Michael Yan" <[e-mail]>, 
        "Paul Kyzivat" <[e-mail]>


A new version of I-D, draft-yan-siprec-msrp-recording-02.txt
has been successfully submitted by Paul H. Kyzivat and posted to the
IETF repository.

Name:		draft-yan-siprec-msrp-recording
Revision:	02
Title:		Overview for MSRP Recording based on SIPREC
Document date:	2014-08-27
Group:		Individual Submission
Pages:		17
URL: 
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
Htmlized: 
http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-02

Abstract:
    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).


 



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat