idnits 2.17.1 draft-yan-siprec-msrp-recording-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 26, 2015) is 3164 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-18 == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-17 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC M. Yan 3 Internet-Draft P. Kyzivat 4 Intended status: Informational Huawei 5 Expires: February 27, 2016 August 26, 2015 7 Overview for MSRP Recording based on SIPREC 8 draft-yan-siprec-msrp-recording-04 10 Abstract 12 SIPREC is capable of recording interactive text media that is 13 transmitted via RTP. However that format is not commonly used for 14 message or chat scenarios. There is also a need for recording text 15 media carried via MSRP. One case of note is exchange of text between 16 hearing-impaired users and emergence service bureaus. Also, 17 recording support is needed for MSRP used in chat conferences and 18 multimedia conferences. 20 This document describes how to achieve MSRP channel recording within 21 the mechanism of SIP Recording (SIPREC). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 27, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. EDITOR NOTES . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. MSRP Recording Architecture . . . . . . . . . . . . . . . . . 6 67 3.1. MSRP Client acts as SRC . . . . . . . . . . . . . . . . . 6 68 3.2. MSRP Relay acts as SRC . . . . . . . . . . . . . . . . . 7 69 3.3. MSRP Switch acts as SRC . . . . . . . . . . . . . . . . . 7 70 4. MSRP Media Stream Mixing . . . . . . . . . . . . . . . . . . 8 71 5. MSRP Session Usage by the SRC . . . . . . . . . . . . . . . . 9 72 6. MSRP Session Usage by the SRS . . . . . . . . . . . . . . . . 9 73 7. File Transfer . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. Recording Chatrooms . . . . . . . . . . . . . . . . . . . . . 10 75 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. MIME Type for MSRP Recording . . . . . . . . . . . . . . . . 11 77 10.1. CPIM Extension Header - rs.Content . . . . . . . . . . . 11 78 10.2. CPIM Extension Header - rs.Stream-ID . . . . . . . . . . 11 79 10.3. CPIM Extension Header - rs.Message-ID . . . . . . . . . 12 80 10.4. CPIM Extension Header - rs.Nickname . . . . . . . . . . 12 81 10.5. CPIM Extension Header - rs.Unsupported-Type . . . . . . 12 82 10.6. CPIM Extension Header - rs.Size . . . . . . . . . . . . 12 83 11. Representation of CS MSRP Messages in the RS . . . . . . . . 12 84 11.1. Recording CS SEND Messages . . . . . . . . . . . . . . . 13 85 11.2. Dropping CS SEND Messages . . . . . . . . . . . . . . . 13 86 11.3. Recording NICKNAME Messages . . . . . . . . . . . . . . 14 87 11.4. Recording CS REPORT Messages . . . . . . . . . . . . . . 15 88 11.5. Recording CS Transaction Responses . . . . . . . . . . . 15 89 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 15.2. Informative References . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 SIPREC is capable of recording interactive text media that is 100 transmitted via RTP, as defined by [RFC4103]. However that format is 101 not commonly used for message or chat scenarios. There is also a 102 need for recording text media carried via MSRP. One case of note is 103 exchange of text between hearing-impaired users and emergence service 104 bureaus. Also, recording support is needed for MSRP used in chat 105 conferences (as defined by [I-D.ietf-simple-chat]) and multimedia 106 conferences (as defined by [RFC4597]). 108 Instant message media is carried by a variety of protocols such as 109 IRC, MSRP and XMPP/JINGLE. The SIP based MSRP protocol (as defined 110 by [RFC4975] and [RFC4976]) supports the delivery of messages and 111 files from one SIP UA to another. When a SIPREC SRC is recording a 112 CS that contains an MSRP channel, it may want to record the messages 113 passing over that channel. To gain access to the messages, the SRC 114 may act as an MSRP client, relay, or switch. The SRC needs to 115 replicate and deliver the messages over an MSRP channel within a 116 Recording Session (RS) to an SRS. The replicated content could be in 117 Message/CPIM format containing plain text, HTML, images, etc. In 118 this document, file delivering sessions have not yet been considered. 119 Other instant message protocols, like IRC or XMPP, are out of scope. 121 This document describes how MRSP sessions are established between an 122 SRC and SRS, and used for conveying the replicated MSRP Media, and 123 also specifies metadata that describes the recorded MSRP sessions. A 124 Recording Session employing MSRP is established using the normal 125 procedures for establishing INVITE initiated dialogs [RFC3261] and 126 uses SDP [RFC4566] for describing the media to be used during the 127 session as described by the SIPREC Architecture [RFC7245]. 129 1.1. EDITOR NOTES 131 This version addresses comments received on the -01 version, both on 132 the mailing list and at IETF90. The following is my list of things 133 to address: 135 o Define a new MIME type that is used to wrap the CS MSRP messages 136 that are being recorded. This allows the original message to be 137 left as-is, so it is always clear what it was. While CPIM could 138 be used for this, defining a new type will allow capturing other 139 necessary metadata. 141 o Need to further consider the need to track message timing. Can 142 the timing of messages received by the SRS on the RS MSRP stream 143 be considered a sufficient proxy for the timing of messages in the 144 CS, or should we explicitly pass timestamps of messages as 145 received on the CS? (The issue was raised but not decided.) 147 o We need to clarify that there is no guarantee that messages 148 received on the CS have been recorded. 150 o It was agreed that there is no need to record the MSRP URIs that 151 are used to establish the CS MSRP session. 153 o It is important that we maintain a 1:1 consistency between MSRP 154 MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used 155 in the RS. But we should not violate MSRP by using the same 156 MESSAGE-IDs. We came up with the idea of adding an SRC-specific 157 prefix to the CS message ids to create unique ones for the RS. 158 This should be done in a standard way so that the SRS can recover 159 the original CS message ids, in order to support correlation 160 across redundant SRCs. 162 o Will need to work out the details of what happens when a CS MSRP 163 session is terminated with an incomplete message. It will be 164 necessary to send the incomplete message to the SRS, but must it 165 appear to be incomplete within the SRS MSRP session? 167 o There are a variety of reasons why the SRC may not want, or be 168 able to, record individual messages in the CS session. (One 169 example is because the message size is greater than the maximum 170 indicated by the SRS. Another is because the mime type of the 171 message is a type that the SRS did not indicate support for.) 172 There should be a type of placeholder message that can be sent to 173 the SRS to indicate a message has been dropped, why, and some key 174 attributes about the message. The new SIPREC wrapper mime type 175 could be designed to serve this purpose. 177 o REPORT messages on the CS can't be sent directly on the RS. The 178 new SIPREC wrapper mime type could also serve as a way to 179 encapsulate those. 181 The primary change is to introduce a new wrapper MIME type 182 ("application/msrp-recording") that is used in RS MSRP sessions for 183 all CS MSRP messages that are to be recorded. This is used with SEND 184 messages whether they have a CPIM wrapper or not. It also allows 185 non-SEND messages from the CS to be sent intact in the RS for 186 recording. And it provides a vehicle for carrying other data as 187 needed. 189 Adding another layer of wrapper could substantially increase the 190 total amount of data send on the RS session, relative to what is 191 present on the CS. I've tried to mitigate that via the details of 192 the design. For SEND messages, only the body of the SEND message is 193 wrapped. And From and To headers in this wrapper can be omitted in 194 cases where that information is redundant. I've assumed that 195 messages other than SEND should in general be infrequent enough that 196 extra overhead when sending them isn't worth a lot of concern. 198 This wrapper can carry a DateTime header. This provides a mechanism 199 to address the timestamp issues. I've left it as optional to use. 201 I clarified the non-guarantee of recording in the architecture 202 section. 204 I've provided a special header in the wrapper to carry the MESSAGE-ID 205 from SEND messages in the CS. And SEND messages will get a separate 206 MESSAGE-ID on the RS MSRP session when sent to the SRS. This 207 provides the SRS with enough information to solve the correlation 208 problem when a message is incomplete in one CS MSRP session and is 209 resumed on another. (The problem of reassembly is left to the SRS.) 211 The wrapper format includes a mechanism for the SRC to report dropped 212 messages to the SRS. 214 The wrapper format also includes a mechanism for encapsulating CS 215 REPORT messages for sending to the SRS. 217 I realized that this level of wrapping provides an opportunity to 218 multiplex unrelated CS MSRP sessions on a single RS MSRP session. To 219 allow this I've provided a way to include the session-id from the 220 metadata, that identifies the particular CS MSRP session, as a value 221 in the wrapper of the message sent on the RS. But I also made that 222 optional when it is redundant. This gives a choice: multiplex but 223 make the messages bigger, or create a separate RS MSRP session for 224 each CS MSRP session and keep the messages smaller. I've included 225 this as a trial balloon for discussion. I'm undecided about it. 227 The formatting of all of this could be better. But for now I just 228 wanted to get the basic concepts down for review. Once the approach 229 is reasonably well worked out I'll try to improve the formatting. 231 There are many places here where I am uncertain what normative 232 strength to apply to individual requirements. I've indicated this 233 inline for many of those. Please comment on this. 235 2. Definitions 237 (TBD...) 239 3. MSRP Recording Architecture 241 For consistency with the SIPREC Architecture [RFC7245] and the SIPREC 242 Protocol [I-D.ietf-siprec-protocol] MSRP recording needs to deliver 243 duplicated MSRP message content from the SRC to the SRS, with 244 suitable descriptive metadata. The SRC may be associated with SIP UA 245 (endpoint) with an MSRP client, or with a SIP B2BUA that accesses the 246 media via an MRSP Relay. An SRC may also be associated with a SIP 247 conference focus and an MSRP switch. 249 Note: The decision to record or not is a policy decision on the part 250 of both the SRC and the SRS. Support for this specification provides 251 no guarantee that any particular MSRP session, or message within a 252 session, will be recorded. However MSRP recording is subject to the 253 notification requirements called out in Section 6.1.2 of 254 [I-D.ietf-siprec-protocol]. 256 3.1. MSRP Client acts as SRC 258 [RFC4975] and [RFC4976] describe how an MSRP client communicates to 259 another MSRP client via a SIP session. A MSRP client that has access 260 to the MSRP content to be recorded may act as SRC. The MSRP client 261 may send the replicated media to the SRS along with corresponding 262 metadata. 264 If the MSRP client/SRC is aware the MSRP session needs to be 265 recorded, it can initiate the establishment of a SIP RS by sending an 266 INVITE to SRS, or vice-versa. The MSRP client/SRC is responsible for 267 notifying the other MSRP client involved in the CS that the MSRP 268 session is being recorded. The MSRP client/SRC is responsible for 269 complying with request from recording aware UAs or through some 270 configured policies indicating that the CS should not be recorded. 272 +-------------+ 273 | MSRP CLIENT | 274 +-------------+ 275 ^ 276 | (Communication Session) 277 | 278 | SIP 279 v 280 +-------------+ (Recording Session) +-------------+ 281 | MSRP CLIENT |<---------------------->| Recorder | 282 | (SRC) | SIP/Metadata | (SRS) | 283 +-------------+ +-------------+ 285 Figure 1: MSRP Client Acts as SRC 287 3.2. MSRP Relay acts as SRC 289 (TBD... RFC4976) 291 +-------------+ 292 | MSRP CLIENT | 293 +-------------+ 294 ^ 295 | (Communication Session) 296 | SIP 297 +-------------+ (Recording Session) +-------------+ 298 | MSRP RELAY |<---------------------->| Recorder | 299 | (SRC) | SIP/Metadata | (SRS) | 300 +-------------+ +-------------+ 301 | 302 | 303 v 304 +-------------+ 305 | MSRP CLIENT | 306 +-------------+ 308 Figure 2: MSRP Relay Acts as SRC 310 3.3. MSRP Switch acts as SRC 312 (TBD... ietf-simple-chat) 313 +-------------+ +-------------+ 314 | MSRP CLIENT | | MSRP CLIENT | 315 +-------------+ +-------------+ 316 ^ ^ 317 \ SIP / (Communication Session) 318 \ / SIP 319 +-------------+ +-------------+ 320 | MSRP switch | (Recording Session) | Recorder | 321 | (SRC) |<------------------->| (SRS) | 322 +-------------+ SIP/Metadata +-------------+ 323 / \ 324 / SIP \ SIP 325 v v 326 +-------------+ +-------------+ 327 | MSRP CLIENT | | MSRP CLIENT | 328 +-------------+ +-------------+ 330 Figure 3: MSRP Switch Acts as SRC 332 4. MSRP Media Stream Mixing 334 [TODO: Revise this to cover multiplexing of unrelated media streams.] 336 Note: SIPREC metadata allows both the inclusion of multiple 337 participants within a single element, and the mapping of 338 multiple elements to a single MSRP m-line in the RS. 339 These provide two ways to do very similar things. 341 Mapping multiple participants to a single is natural for 342 a conference. It works well for MSRP chat sessions 344 By providing a way to specify the stream-id with an individual 345 message on the RS, I've introduced a way to demux messages from 346 multiple s that are mapped to the same MSRP m-line. This 347 provides a way reduce the number of MSRP sessions in the RS. It 348 also avoids confusion when an RS MSRP session is serially reused 349 for distinct CS MSRP sessions. 351 I'm still considering whether it is good to have both of these 352 mechanisms, or if one of them should be removed. Until I make a 353 decision I haven't updated all the text that pertains to this. 355 Feedback on this will be appreciated. 357 As with RTP-based media, CS MSRP media streams from different 358 participants may be mixed into a single RS media stream, or they may 359 be conveyed as separate MSRP streams. In RTP, when media from 360 different participants is mixed, it is distinguished by CNAME and 361 SSRC or CSRC. In MSRP, media from different participants is 362 distinguished by wrapping the the message in a CPIM body, with the 363 sender identified by the From header in the CPIM. If the SRC mixes 364 MSRP media from multiple senders, then each message that isn't 365 already in CPIM format SHOULD be embedded in a CPIM message, and the 366 From and To headers of that CPIM wrapper SHOULD identify the sending 367 and receiving participants for that message. 369 5. MSRP Session Usage by the SRC 371 [TODO: Revise this to cover multiplexing of unrelated media streams.] 373 When preparing to record a CS MSRP media stream, the SRC MUST choose 374 a corresponding RS MSRP session. CS MSRP sessions that are being 375 mixed share an RS MSRP session, while those that are not being mixed 376 are assigned to unique RS MSRP sessions. 378 The RS MSRP session MAY be newly created, or a pre-existing RS MSRP 379 session that is no longer in use MAY be repurposed. When an MSRP 380 session is repurposed, the SRC communicates this change to the SRS 381 via a change in the metadata. The SRC is responsible for ensuring 382 that messages for the new session are not sent until the SRS has 383 received the metadata describing this new session. 385 MSRP message flow on a RS MSRP session is always from the SRC to the 386 SRS. The SRC generates SEND messages, and may receive REPORT 387 messages. It does not receive SEND messages or send REPORT messages. 389 6. MSRP Session Usage by the SRS 391 [TODO: Revise this to cover multiplexing of unrelated media streams.] 393 The SRS MUST be able handle a case where an RS MSRP session if first 394 used to record one CS MSRP session and then is repurposed to record a 395 different CS MSRP session. The SRS is learns of this change via a 396 change in the metadata. 398 MSRP message flow on a RS MSRP session is always from the SRC to the 399 SRS. The SRS receives SEND messages, and sends REPORT messages. It 400 does not generate SEND messages or receive REPORT messages. 402 7. File Transfer 404 A mechanism for doing file transfer via MSRP is specified in 405 [RFC5547]. If this mechanism is used in the CS, then the SRC MAY use 406 it in the RS to record those files. In turn, the SRS MAY choose to 407 accept some or all of those file transfer requests, or MAY reject 408 them. 410 Both file push and file pull operations are defined. If the SRC 411 chooses to record a file transfer, whether it is initiated in the CS 412 via a push operation or a pull operation, within the RS the SRC MUST 413 initiate the transfer with a push operation in an SDP Offer. 415 (SRS initiation of a file transfer is out of scope of this document.) 417 It is possible that the SRC may support file transfer while the SRS 418 does not. If the SRC sends an SDP offer to the SRS containing an 419 m-line initiating a file transfer, and the SRS sends an answer 420 accepting the MSRP session, but fails to include a matching file- 421 transfer-id, then the SRC MUST NOT send the content of CS MSRP file 422 transfer session to the SRS. 424 8. Recording Chatrooms 426 An CS MSRP session might involve a chatroom. The SRC discovers this 427 by observing use of the features defined in [I-D.ietf-simple-chat] 429 When the CS MSRP session involves a chatroom, the SRC SHOULD [MUST?] 430 indicate this in the corresponding RS MSRP session. The key unique 431 features of chatrooms are nicknames and private messages. If either 432 of these features is indicated in an SDP 'chatroom' attribute in the 433 CS, then this MAY also be indicated in the RS SDP. 435 Requests for nickanmes in the CS via the NICKNAME message are 436 reported to the SRS using the mechanism described in Section 11.3. 438 When messages are sent by sources that have had a nickname assigned, 439 the nickname is conveyed to the SRS using the mechanism described in 440 Section 10.4. 442 Private messages used in a chatroom are identified in the CS via a 443 CPIM wrapper with a To header that identifies the intended 444 recipient(s) rather than the URI of the chatroom itself. This 445 information is retained when the message is forwarded to the RS, 446 while the chatroom URI is also conveyed using the "To" header of the 447 "application/msrp-recording" wrapper, as described in section 448 Section 11. 450 9. Metadata 452 The metadata defined in [I-D.ietf-siprec-metadata] can be used 453 without change to describe MSRP streams. 455 10. MIME Type for MSRP Recording 457 The document defines a new MIME type "application/msrp-recording" as 458 an extension to type "application/cpim". This type includes new 459 headers for carrying details about the wrapped message. The new 460 headers are all identified by a namespace prefix of "rs.". 462 [Note: I found the details of how to make an application-specific 463 extension to CPIM to be vague in RFC3862. I'm uncertain if 464 extension headers must be referenced with a prefix, but that is my 465 best guess. The details need more research.] 467 10.1. CPIM Extension Header - rs.Content 469 The value of the "rs.Content" header is a token identifying the sort 470 of content contained in the body of this message. The following 471 types of content are defined: 473 o send 475 o drop 477 o msrp 479 At most one "rs.Content" header may be present in a message. If no 480 "rs.Content" header is is present, then "rs.Content: send" is 481 implied. 483 The 'send' token indicates that the content of the message contains 484 all or a fragment of the body of an MSRP SEND message. 486 The 'drop' token indicates that the content of a SEND message in the 487 CS is not being sent to the RS for recording. 489 The 'msrp' token indicates that the body of the message contains a 490 complete MSRP message from the CS. This form MAY be used to convey 491 REPORT messages, NICKNAME messages, and transaction responses. 493 10.2. CPIM Extension Header - rs.Stream-ID 495 The value of the "rs.Stream-ID" header is the stream-id used in the 496 SIPREC metadata to identify the stream that this message belongs to. 497 This header MAY be omitted if the SIPREC metadata associates exactly 498 one stream with this MSRP session. If present, the value MUST match 499 the stream-id of exactly one of the streams associated with this MSRP 500 session. 502 10.3. CPIM Extension Header - rs.Message-ID 504 The value of the "rs.Message-ID" header carries the value of the 505 "Messsage-ID" from the MSRP SEND message. At most one "rs.Message- 506 ID" header may be present in a message. It MUST be present when the 507 "rs.Content" value is 'send' or 'drop', and MUST NOT be present in 508 other cases. 510 10.4. CPIM Extension Header - rs.Nickname 512 The value of the "rs.Nickname" header carries the nickname of the 513 sender of the MSRP SEND message. At most one "rs.Nickname" header 514 may be present in a message. It MAY be present when the "rs.Content" 515 value is 'send' or 'drop', and MUST NOT be present in other cases. 517 10.5. CPIM Extension Header - rs.Unsupported-Type 519 The value of the "rs.Unsupported-Type" header carries a content-type 520 from a CS MSRP SEND message that is not supported by the SRS. It may 521 be the outermost type, or the type of a component of a container 522 type. Any number of "rs.Unsupported-Type" headers may be present in 523 a message. It MAY be present when the "rs.Content" value is 'drop', 524 and MUST NOT be present in other cases. 526 10.6. CPIM Extension Header - rs.Size 528 The value of the "rs.Size" header carries the integer size of an CS 529 MSRP SEND message. At most one "rs.Size" header may be present in a 530 message. It MAY be present when the "rs.Content" value is 'drop', 531 and MUST NOT be present in other cases. 533 11. Representation of CS MSRP Messages in the RS 535 When CS MSRP messages are being recorded, the SRC encapsulates them 536 in the wrapper type "application/msrp-recording". This wrapper type 537 is used to encapsulate the basic MSRP SEND message content, and also 538 to send CS MSRP control messages that should be recorded. It also 539 provides the means for conveying per-message metadata. 541 The CPIM From and To headers of the wrapper are optional. They MUST 542 be supplied when the proper value cannot be determined by other 543 means: 545 o The From header may be omitted if the metadata for the stream 546 indicates that there is only one possible sender, or if the 547 message being encapsulated contains a CPIM From header with the 548 proper value. 550 o The To header may be omitted if the metadata for the stream 551 indicates that there is only one possible receiver, or if the 552 message being encapsulated contains a CPIM To header with the 553 proper value. 555 The CPIM DateTime header MAY be included. If included, it SHOULD 556 indicate the time that the corresponding CS message was sent or 557 received by the SRC. 559 11.1. Recording CS SEND Messages 561 When the SRC wishes to record a SEND message from the CS it rewraps 562 the message, taking body from the CS SEND message, placing that into 563 the body of a new "application/msrp-recording" message, and then 564 sending that with a SEND message in the corresponding RS MSRP 565 session. 567 The SRC MAY retain the fragmentation present in the CS, mapping one 568 CS SEND message to one RS SEND message. Or it MAY merge CS message 569 fragments and/or re-fragment CS SEND message fragments. If a 570 received fragment ends with a continuation-flag of "#", then last 571 fragment sent on the RS MUST also end with a continuation-flag of 572 "#". 574 Each SEND message fragment MAY, but need not, contain a "rs.Content: 575 send" header. 577 Each SEND message fragment MUST contain an "rs.Message-ID" header 578 identifying the Message-ID from the corresponding CS MSRP SEND 579 message. (The resulting RS MSRP SEND message will also contain a 580 Message-ID in the RS. This is a distinct value.) 582 If the SRC knows that the sender of the message on the CS has an 583 associated Nickname [I-D.ietf-simple-chat], then the SRC SHOULD 584 insert an "rs.Nickname" header containing the nickname. 586 11.2. Dropping CS SEND Messages 588 [QUESTION: Do we need a way for the SRS to indicate a desire (or not) 589 to receive indications of dropped messages?] 591 The SRC might decide not to record selected SEND messages from the CS 592 MSRP session. When doing so is MAY send a 'drop' message as a 593 indicator that a message has been dropped. The following 594 considerations apply when deciding whether to send a 'drop' message: 596 o While the SRC is honoring a request within the CS to disable 597 recording, it SHOULD [MUST?] NOT send 'drop' messages for CS SEND 598 messages. 600 o If the total size from the Byte-Range of the initial fragment of a 601 SEND message in the CS is acceptable for the CS, but exceeds the 602 max-size for the RS session, then the SRC SHOULD send a 'drop' 603 message, and SHOULD include an "rs.Size" header indicating the 604 total size of the message. 606 o If a SEND message in the CS contains a continuation fragment, with 607 a Byte-Range indicating that the total message will exceed the 608 max-size for the RS session, then the SRC SHOULD send a 'drop' 609 message, and SHOULD include an "rs.Size" header indicating the 610 total size of the message. 612 o If a SEND message has a content type accepted by the 'accept- 613 types' and 'accept-wrapped-types' attributes of the CS but is not 614 accepted by the 'accept-types' or 'accept-wrapped-types' 615 attributes of the RS, then the SRC SHOULD send a 'drop' message. 616 The 'drop' message SHOULD contain an "rs.Unsupported-Type" header 617 identifying the type that is not supported. (When a multipart 618 body is present, the SRC MAY include multiple "rs.Unsupported- 619 Type" headers identifying multiple types.) The SRC MAY choose to 620 send a limited number of 'drop' messages for particular stream - 621 either in total or per unacceptable type. 623 When a 'drop' message is sent: 625 o it MUST be terminated with a continuation-flag of "#"; 627 o additional fragments with the same CS Message-ID MUST NOT be sent 628 on the RS. 630 11.3. Recording NICKNAME Messages 632 The SRC SHOULD forward NICKNAME messages in the CS to the SRS. 634 [QUESTION: Do we need a way for the SRS to indicate a desire (or not) 635 to receive CS Transaction Error messages?] 637 To forward a NICKNAME message from the CS to the RS, the SRC places 638 the entire NICKNAME message into the body of of a new "application/ 639 msrp-recording" message, and then sends that with a SEND message in 640 the corresponding RS MSRP session. 642 11.4. Recording CS REPORT Messages 644 The SRC SHOULD [MUST?] forward CS Failure Report messages on the RS. 646 The SRC MAY [SHOULD?] forward CS Success Report messages on the RS. 648 [QUESTION: Do we need a way for the SRS to indicate a desire (or not) 649 to receive CS REPORT messages?] 651 To forward a REPORT message from the CS to the RS, the SRC places the 652 entire REPORT message into the body of of a new "application/msrp- 653 recording" message, and then sends that with a SEND message in the 654 corresponding RS MSRP session. 656 11.5. Recording CS Transaction Responses 658 The SRC SHOULD [MUST?] forward CS transaction responses indicating 659 errors to the SRS. 661 The SRC MAY, but SHOULD NOT forward CS transaction responses 662 indicating success to the SRS. An exception is success responses to 663 NICKNAME messages, which MAY [SHOULD?] be passed to the SRS. 665 [QUESTION: Do we need a way for the SRS to indicate a desire (or not) 666 to receive CS transaction response messages?] 668 To forward a transaction response from the CS to the RS, the SRC 669 places the entire transaction response message into the body of of a 670 new "application/msrp-recording" message, and then sends that with a 671 SEND message in the corresponding RS MSRP session. 673 12. Open Issues 675 13. IANA Considerations 677 [TODO: Register application/msrp-recording.] 679 14. Security Considerations 681 Not explicitly covered in this version. 683 15. References 685 15.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 693 A., Peterson, J., Sparks, R., Handley, M., and E. 694 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 695 DOI 10.17487/RFC3261, June 2002, 696 . 698 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 699 "The Message Session Relay Protocol (MSRP)", RFC 4975, 700 DOI 10.17487/RFC4975, September 2007, 701 . 703 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 704 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 705 DOI 10.17487/RFC4976, September 2007, 706 . 708 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 709 and P. Kyzivat, "A Session Description Protocol (SDP) 710 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 711 DOI 10.17487/RFC5547, May 2009, 712 . 714 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 715 "An Architecture for Media Recording Using the Session 716 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 717 2014, . 719 [I-D.ietf-siprec-metadata] 720 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 721 Protocol (SIP) Recording Metadata", draft-ietf-siprec- 722 metadata-18 (work in progress), August 2015. 724 [I-D.ietf-siprec-protocol] 725 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 726 Hutton, "Session Recording Protocol", draft-ietf-siprec- 727 protocol-17 (work in progress), July 2015. 729 [I-D.ietf-simple-chat] 730 Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party 731 Chat Using the Message Session Relay Protocol (MSRP)", 732 draft-ietf-simple-chat-18 (work in progress), January 733 2013. 735 15.2. Informative References 737 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 738 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 739 . 741 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 742 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 743 July 2006, . 745 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 746 RFC 4597, DOI 10.17487/RFC4597, August 2006, 747 . 749 Authors' Addresses 751 Michael Yan 752 Huawei 754 Email: michael.yan@huawei.com 756 Paul H. Kyzivat 757 Huawei 759 Email: pkyzivat@alum.mit.edu