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

[Paul Kyzivat <[e-mail]>]

Brian - inline

On 7/3/14 3:25 PM, Brian Rosen wrote:
>
> On Jul 3, 2014, at 12:55 PM, Paul Kyzivat <[e-mail]
> <mailto:[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.

That is a different case. I was specifically talking about the case 
where the SRC gets a report from the *SRS*. There is nothing useful it 
can do. Obviously the SRS knows about the problem (it sent the report), 
so it can record an indication of the problem without the SRC having to 
tell it.

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

This is the case you were talking about.

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

I don't think we can bound the rate that these occur. So I am very 
reluctant to use the metadata mechanism to deal with them.

> Extending reports in some manner is a
> possibility.

Yes, this is possible. But it would be nice to avoid modifying MSRP.

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

Does introducing a CPIM wrapper where there was none (making explict 
what had been implicit) prevent reproducing what the SRC got?

Consider that we allow the SRC to transcode media before sending it to 
the SRS. And we permit the SRC to transcode media before recording it. 
In both of those cases we can't reproduce *exactly* what the SRC got.

What is so different here?

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

Yes we could. If we feel that we must.

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

This is a matter of taste. I could go either way. It would be nice to 
not have to 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.

After studying 4975 awhile I think we could do this. It *should* be ok 
to use the old message-ids as-is - they are supposed to be globally 
unique, across sessions. (Of course if we reuse them then they won't be 
globally unique.)

If we are hyper, we could allow the SRC to add a prefix. But that 
introduces complications if we are doing redundant SRCs sending to the 
same SRS, because we won't recognize when we get the same message on 
both paths.

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

The whole point of reporting byte ranges is that they are independent of 
the chunking. I don't think this is an issue.

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

I guess what is different about message id is that its scope encompasses 
multiple MSRP sessions. If the CS participants drop one session and 
start another, and resend messages with the same ids, then I guess we do 
want the SRS to understand that they were updating the same message.

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

OK.

> If there wasn’t any CPIM, we could
> add it, in which case MSRP To/From in CS becomes CPIM To/From in RS.

Why? It doesn't have to be if we don't want that. I would expect the SRC 
to insert URIs that it knows from the CS for the participants in this 
MSRP session. These would probably be the SIP URIs from the CS SIP 
session of the sender and receiver of the MSRP session in the CS.

> If
> there is CPIM already, we need to preserve it, and then we need to solve
> sending CS MSRP To/From in the RS.

Why do we need the MSRP To/From at all? Those are just artificial things 
used to identify particular sessions.

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

I don't think so. We give the SRS a lot of lattitude about what it 
records. If it wants to bound its resources by refusing to record small 
messages, then that is its business.

We can't expect the CS to change its behavior to suit the RS. And IIUC 
max-size is not negotiated, it is declared by the receiver. So there is 
no way to communicate the max-size from the CS to the RS.

Also, max-size is only a hint - the sender need not honor it.

We *could* specify that the SRC SHOULD NOT forward messages on the RS 
that exceed the SRS's max-size. I don't think there is much else we can 
or should do.

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

Based on my own comments above, I don't know why we need to have an msrp 
AOR for a participant. I think we would identify participants in an MSRP 
media session by sip URI.

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

I went back to review the chat stuff that defines Nickname. (It still 
isn't an RFC!) I remembered wrong - the nickname isn't represented as a 
URI. Ideally we would manage it in-band in the MSRP. But the way 
nicknames are managed doesn't work very well for us. An msrp session is 
bound to at most one nickname at any point in time.

We could work with that, sending NICKNAME requests on the RS msrp 
session as needed to set the nickname to match that of the message we 
want to send. But that would be unpleasant.

An alternative would be to define the use of Use-Nickname with a SEND 
message. It currently isn't defined, but draft-ietf-simple-chat-18 
leaves it open to be defined in the future.

We would want to specify that the SRS will be especially lenient 
(promiscuous) in approving the use of nicknames.

>> (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
>         <http://tools.ietf.org/html/draft-ietf-siprec-metadata-15#section-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  <http://tools.ietf.org/html/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.

The MSRP From/To URIs must be MSRP URIs.

But, I still don't see why we need to care about preserving those in the 
recording.

I must say that this is the kind of discussion I have been hoping to 
have - to nail down the nitty-gritty details.

	Thanks,
	Paul

>> Thanks,
>> Paul
>>
>>> Brian
>>>
>>> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat <[e-mail]
>>> <mailto:[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] <mailto:[e-mail]>
>>>>>> To: Michael Yan <[e-mail]
>>>>>> <mailto:[e-mail]>>,        "Paul H. Kyzivat"
>>>>>> <[e-mail] <mailto:[e-mail]>>,
>>>>>>        "Michael Yan" <[e-mail]
>>>>>> <mailto:[e-mail]>>,
>>>>>>        "Paul Kyzivat" <[e-mail]
>>>>>> <mailto:[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] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>
>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>>
>>
>