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

[Brian Rosen <[e-mail]>]

On Jul 3, 2014, at 12:55 PM, Paul Kyzivat <[e-mail]> wrote:

> 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?
Yeah doh!
> 
>> 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.
Yeah, but it has to send reports it got on the CS somehow

> 
> 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.
No, I think if the SRC gets a report of a problem on the CS it must record that.  

I think if we neglected to record known problems detected in RTCP reports then we need to fix that too at some point — if the SRC knows about a problem, that has to be recorded.

> 
> 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.
Yeah, I think that’s right, and I think it’s messy.  Sending them in metadata is a possibility.  Extending reports in some manner is a possibility.

> 
>> 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 recording is what the SRC got.  If you can’t effectively reproduce what the SRC gets, the mechanism is not adequate.

> 
> 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.
Yeah, I’d prefer not to do that

> 
> 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.
There is always a way.  We can extend CPIM if we need to.

> 
> 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.
I’d rather just extend CPIM

> 
>> 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?
No, i don’t think so.  Message ID is much more of a real id then anything you find in an RTP header.  You can derive wall time, which might be similar, but not really.

> 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?
MSRP To/From in the RS is SRS/SRC.  If there wasn’t any CPIM, we could add it, in which case MSRP To/From in CS becomes CPIM To/From in RS.  If there is CPIM already, we need to preserve it, and then we need to solve sending CS MSRP To/From 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.)
Yeah, something.  Basically, to avoid problems, CS max has to be at least as big as RS max.  I think that’s just a MUST as a by-the-way.

> 
>> 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.)
Depends on how we solve some of these other issues.
That one leaped out at me, have to look harder to see if there are others.   Interaction of the term “Participant” for example.

> 
>> 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.
Would have to be labeled in some way

> 
> (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.
I’m missing something, but it’s probably lack of clue on how metadata works.  
And, I spotted another metadata change problem:

6.5.1.  Attributes

   Participant has a single defined attribute:

   o  AoR / Name pair list - This attribute is a list of Name/AoR
      tuples.  An AoR MAY be a SIP/SIPS/TEL URI.  Name represents
      Participant name(SIP display name) or dialed number (DN) (when
      known).  Multiple tuples are allowed for cases where a participant
      has more than one AoR.  (For example a P-Asserted-identity header
      [RFC3325] can have both SIP and TEL URIs.)

Have to add msrp/msrps to the list.  Does the MSRP To/From HAVE to be an msrp/msrps scheme, or can it be a sip AoR?  If the latter, we could have a corner case where the SIP AoR and the MSRP AoR were both SIP but different.

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