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

[Paul Kyzivat <[e-mail]>]

On 11/10/14 9:06 PM, Brian Rosen wrote:
> 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.

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

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.

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

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.

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

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 cover that, and probably should be explicitly noted elsewhere.

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.

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

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