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

From: Brian Rosen <[email-masked]>
Date: Mon, 10 Nov 2014 21:06:42 -1000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Nov 2014 00:23:34 -1000

> I have reviewed -02 and have the following comments

Thanks. Obviously this draft *needed* a review!

> 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.

I brought it up because I was uncertain. I'll take your comment as one 
data point.

The advantage is that you need less MSRP sessions on the RS.

There is an analogy to audio/video: we do allow a single RS media 
session to be multiplexed *serially* for multiple CS media sessions. 
This mechanism for MSRP could be used that way.

>     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.
>

This is unchanged from -01, but I agree it is messed up and needs to be 
reworked.

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

Same comment as above.

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

I screwed up here. The text is unchanged from -01, but it should have 
been changed. This comment is wrong - the new wrapper type replaces this.

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

Yet another thing that was wrong in -01. :-(

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

I was thinking there might be an SRC that has a policy of not disclosing 
this. But I'm not sure why. But in general I think an SRC should be 
allowed to censor as much as it wants.

> 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.

I was mostly not sure if I fully understood how the extension mechanism 
was intended to be used. It just needs a bit more research to be sure it 
is being done right.

> 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…

This message gets used in multiple circumstances. If a CS message is 
being dropped because the SRS doesn't want that type, then yes, there 
will be no body from the CS message. The MSRP message on the RS will 
still have the "wrapper" body, but it won't be wrapping anything. All 
the info will be in the wrapper headers.

> 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 c…

The negotiated size is not the limit on *fragments* - it is a limit on 
the unfragmented message.

One challenge is that when the SRC receives the first fragment it may 
not be able to tell how big the complete message will be. (That info is 
optional.) So it may send one or a few fragments before it discovers 
that the message in total will be too big. At *that* time it sends a 
drop message.

> so we ended continuatiuon.  Fine, but that’s only if you were fragmenting.

Yeah, this needs a bit more work. If some fragments have been sent, and 
then the SRC discovers the message is too big, it can't send the drop as 
part of the fragmented message. It needs to send a last (empty?) 
fragment with a "#", and *then* it can send a drop message with the same 
rs.Message-ID. And then the drop message can end with "$".

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

In some sense they are redundant, since the nickname is sent to the SRS 
in the wrapper with each message. It might be interesting for the SRS to 
see the requests for nicknames, and especially denials of those. But it 
the general spirit of giving the SRC discretion, I thought it can be 
allowed to drop based on policy.

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

I would expect that would be the normal case. I just can't think of a 
strong reason to *insist* that the SRC do so.

	Thanks,
	Paul