Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt

[Paul Kyzivat <[e-mail]>]

On 7/1/14 5:34 PM, Brian Rosen wrote:
> I’ve reviewed this document.  I think it is a very good start, and think we can get it ready to ship quite quickly.
>
> I have the following comments:
>
> We need to specify a way to send and save REPORTS that are sent/received on the CS to the SRS.  If, for example, a message sent by a party to another is not received completely,
> and a REPORT js generated on the RS,  we need to somehow record than in the CS.

I guess CS and RS need to be swapped in the above line, right?

> You have a note about reports, but it isn’t clear if you mean reports in the CS or the RS.  Both have to be recorded, but at least in the RS, the SRS has all the info needed.

I just have a placeholder, because I haven't thought much about it yet.

I especially hadn't thought about reports on the RS. Note that the SRS 
won't be sending anything except reports to the SRC, so there is no 
reason for the SRC to be sending reports to the SRS about the RS msrp 
session.

Conversely, suppose the SRC gets a report from the SRS that something 
hasn't made it successfully. What should it do? (I can't think of 
anything useful for it do do.) I guess this is analogous to the SRC 
getting RTCP reports indicating packet loss of RTP media. We don't talk 
about that.

But reports on the CS are significant information that could be 
important to record. I think they can't be sent as MSRP reports. I 
suspect we must find a way to encapsulate them as regular MSRP messages. 
But that seems messy. Ideas are welcome.

> I think there is a problem with the text about adding a CPIM wrapper if there isn’t one.  I think the recording has to know if the original message was sent by some entity other than the one in the CPIM From (that is, we have to preserve the MSRP From).  The SRS has to know whether the original message had a CPIM header, and its contents.   If the SRC changes the message (by adding the wrapper) I think the SRS has to be able to figure that out, and record that fact in some way.

I hear you, though I'm not yet convinced how important it is for the SRS 
to be able to make this distinction.

I think the only way to be *certain* that the SRS can distinguish these 
is to wrap *every* message, even those that already contain CPIM 
headers. Then the SRS would know that the outer wrapper was always from 
the SRC, and that if there was another cpim wrapper inside then it was 
from the CS. But that seems like overkill.

If we only put CPIM wrappers on messages that don't already have them, 
then we could put something *special* in them. But there would be no 
guarantee that the CS didn't use that.

We could also introduce a new mime type similar to CPIM, but specially 
for recording. If we constrained the usage of that then we might be able 
to claim that it could never appear on the CS. But I would prefer to 
avoid this.

> When we echo a message from the RS to the CS, we’re going to lose the MESSAGE-ID from the RS.  That’s a problem.  We have to save that info in the recording.  A hack would be to use the same message ID in both the CS and the RS, possibly with some prefix.
>
> I worry a bit about chunking in the RS differently from chunking in the CS. I may be mistaken, but if the chunking is different, will that affect the byte-range response in a failure report?

Don't the above issues have analogs for RTP/RTCP?
Do we have any more requirement to solve them here than we did there?

> The URIs in the original to/from need to be captured, but they will be different in the RS.  Need to fix that.

I assume you are talking about the to/from in CPIM, right? Why do they 
need to be different in the RS?

> Do we need to say something about max-size issues between CS and RS?

Probably. Seems like a policy issue in the SRS. If the SRS doesn't want 
to record large messages. Maybe we want to specify that the SRC MUST 
honor the SRS's max-size, bypassing recording of messages that are too 
big. (Or perhaps inserting special small messages as placeholders for 
the bypassed messages.)

> You can’t possibly not change -metadata.  As an example. you have to allow an msrp AoR for a participant

Hmm. I guess so. I was thinking that we were lenient in the AoR type, 
but I guess not.

Since the metadata isn't done yet, maybe we can change it before it is 
done, to allow this. (Allow any URI.)

> Yes, I think we have to extend Participant to handle nicks.

A participant can already have multiple AoR/Name pairs. So we could add 
the nickname as one of those.

(We really did try to plan ahead with the metadata.)

> Probably also to handle the SIP session URI vs the MSRP URIs

Note that the metadata associates participants with both the CS and 
individual media streams. So the SIP session URIs are already covered there.

	Thanks,
	Paul

> Brian
>
> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat <[e-mail]> wrote:
>
>> Trying one more time. Please!!!
>>
>> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>>> Can I get some people in the wg to review and comment on this version?
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>>> I've submitted a revised version of the msrp recording draft.
>>>> This one is substantially fleshed out. It certainly needs more tweaking,
>>>> but is complete enough that you should be able to make meaningful
>>>> comments on the approach.
>>>>
>>>>      Thanks,
>>>>      Paul
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: New Version Notification for
>>>> draft-yan-siprec-msrp-recording-01.txt
>>>> Date: Wed, 28 May 2014 15:03:24 -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-01.txt
>>>> has been successfully submitted by Paul H. Kyzivat and posted to the
>>>> IETF repository.
>>>>
>>>> Name:        draft-yan-siprec-msrp-recording
>>>> Revision:    01
>>>> Title:        Overview for MSRP Recording based on SIPREC
>>>> Document date:    2014-05-28
>>>> Group:        Individual Submission
>>>> Pages:        9
>>>> URL:
>>>> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt
>>>>
>>>> Status: https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>> Htmlized: http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>>>
>>> _______________________________________________
>>> siprec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
>
>