[siprec] Review of draft-yan-siprec-msrp-recording-02

[Brian Rosen <[e-mail]>]

I have reviewed -02 and have the following comments
1. I don’t see value in multiplexing separate CSs in one RS.  We don’t do that for other media, we need completely separate metadata, and generally I don’t think session state is very meaningful.  The applications I have in mind would not see any significant advantage and the complexity I think outweighs it.  I could imagine a large investment company needing a huge number of sessions and maybe they would think it was worth it.

2. In section 3.1 it says “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.”  “or vice-versa” is confusing as is.  The SRS would have to either have knowledge of the CS or set up the RS in advance of a CS.  
Please expand this sentence (or maybe refer to another doc that explains how an SRS can initiate the RS.

3. Just beyond that, the text says “is responsible” (2 places).  Should that be a normative MUST?

4. In Section 4, it says “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.

 Is SHOULD correct?  What circumstance would it not CPIM wrap?

5. The last paragraph in Section 6 is replicated from Section 5.  Do we need that?

6. In Section 8, I think it’s MUST.  Can’t come up with a reason why it shouldn’t do that.

7. Re the note about prefixes in the extension.  Even if it doesn’t require them, it seems to me that it’s helpful here, so I think you can just do it and not question it.

8. In Section 10.1 it says “The 'drop' token indicates that the content of a SEND message in the
   CS is not being sent to the RS for recording.

This confused me.  There wouldn’t be a body in this case, right?  This is the case where the SRS doesn’t support, say file transfer, and we’re recording that fact  Seems like we need more text here, perhaps just a reference to Section 11.2.

9. Since the SRC can reassemble a fragmented message, it can also fragment it.  Therefore, it may be able to not drop a large message on the CS by fragmenting on the RS.  The text in 11.2 doesn’t cover that, and probably should be explicitly noted elsewhere.

10. I don’t think this text:
When a 'drop' message is sent:

   o  it MUST be terminated with a continuation-flag of "#";

is correct.  I think that is only true if the SRC sent a prior fragment.  You are telling me that if you were fragmenting, and you dropped, that that is the end of the message, 
so we ended continuatiuon.  Fine, but that’s only if you were fragmenting.

11. I don’t know why SHOULD is not MUST in 11.3

12. Generally, I think the recording should record failures at the SRC, so I think we need a way to record them, and I don’t think they are optional (assuming its a CS error).


Brian