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

From: Brian Rosen <[email-masked]>
Date: Tue, 1 Jul 2014 17:34:10 -0400

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

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?

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

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

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

Yes, I think we have to extend Participant to handle nicks.  Probably also to handle the SIP session URI vs the MSRP URIs

Brian

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

---

From: "Simon Farrow" <[email-masked]>
Date: Wed, 2 Jul 2014 14:45:08 -0700

Paul

Sorry for the delay in getting to the document.

Is encryption out scope for this document (as it is mentioned in the Siprec
Protocol document). If so I think that should be stated but we might need to
take into consideration RFC 5547 (File Transfer) mentions secured MIME
(S/MIME) RFC 3851 while the protocol document only mentions RFC 3711, 5124
and 4568.

Once again thanks to you and Michael on preparing this document.

Simon Farrow
Director of Engineering

Stancil Corporation
2644 South Croddy Way
Santa Ana
CA 92704

Tel: 1-714-546-2002 ext 4311
http://www.stancilcorp.com
[email-masked]

-----Original Message-----
From: siprec [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, June 26, 2014 9:32 AM
To: [email-masked]
Subject: Re: [siprec] New Version Notification for

On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>> 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
>>
>>
>> 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:
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Jul 2014 12:08:40 -0400

On 7/2/14 5:45 PM, Simon Farrow wrote:
> Protocol document).

It isn't out of scope. See the Security Considerations of the protocol 
document.

> If so I think that should be stated but we might need to

File transfer may be a special case, but maybe not.

If the file content is secured with S/MIME, then it is my expectation 
that this protection would be retained in the recording. That may well 
mean that the SRS can't understand the content of the recorded file.

Do you think that we need additional language about this case?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Jul 2014 12:55:39 -0400

On 7/1/14 5:34 PM, Brian Rosen wrote:
> 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…

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.

> 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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 3 Jul 2014 15:25:28 -0400

> I guess CS and RS need to be swapped in the above line, right?
Yeah doh!
> 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 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

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

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

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

> 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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jul 2014 18:22:39 -0400

Brian - inline

On 7/3/14 3:25 PM, Brian Rosen wrote:
>
> On Jul 3, 2014, at 12:55 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> 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.
>>>
>>> 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,
>>> 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.
>>
>> getting RTCP reports indicating packet loss of RTP media. We don't
>> talk about 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.
>
>>
>> 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 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.

Yes we could. If we feel that we must.

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

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.

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

>>> The URIs in the original to/from need to be captured, but they will
>>> be different in the RS.  Need to fix that.
>>
> 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.

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

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

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.

> That one leaped out at me, have to look harder to see if there are
> others.   Interaction of the term “Participant” for example.
>
>>

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.

>         6.5.1
>         <http://tools.ietf.org/html/draft-ietf-siprec-metadata-15#section-6.5.1>.
>         Attributes
>
>
>
>        [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 <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>>>> tweaking,
>>>>>> From: [email-masked] <mailto:[email-masked]>
>>>>>> To: Michael Yan <[email-masked]
>>>>>> <mailto:[email-masked]>>,        "Paul H. Kyzivat"
>>>>>> <[email-masked] <mailto:[email-masked]>>,
>>>>>>        "Michael Yan" <[email-masked]
>>>>>> <mailto:[email-masked]>>,
>>>>>>        "Paul Kyzivat" <[email-masked]
>>>>>> <mailto:[email-masked]>>
>>>>>>
>>>>>>
>>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 9 Jul 2014 15:48:47 -0700

Hopefully, we aren’t getting too deep in levels
On Jul 9, 2014, at 3:22 PM, Paul Kyzivat <[email-masked]> wrote:

> 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.
Right, my bad.  The SRS knows, it can record it.

> This is the case you were talking about.
Yeah

> 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.
Understand, but encapsulation in MSRP would use a lot of BW also

> Yes, this is possible. But it would be nice to avoid modifying MSRP.
Yeah, but might be lesser of evils

> Does introducing a CPIM wrapper where there was none (making explict what had been implicit) prevent reproducing what the SRC got?
Because the SRS can’t distinguish between the SRC receiving a wrapped message from a case where the SRC did the wrapping on the RS.

> 
> 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.
I think this is substantively different but YMMV

> This is a matter of taste. I could go either way. It would be nice to not have to extend CPIM.
Something has to give.  Probably a good topic for the meeting

> 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.
Yeah, I understand.  If the SRC adds a prefix, it could be different from the prefix the redundant SRC uses and the SRS could figure it out.

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

> 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.
Yes, and probably more.

> 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.
The SRS has to be able to derive what was MSRP To/From in the CS was.  It’s recording what the SRC saw.

> Why do we need the MSRP To/From at all? Those are just artificial things used to identify particular sessions.
I think the recording has to record what the SRC got.  I don’t think it’s good enough to derive a notion of session, create new session IDs and then just use them.  The recording has to be able to reproduce what the SRC saw.

> 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.
> 
> 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.
Looks like we have to just have a discussion on the issue in the doc.  The limitation is that the SRC doesn’t know the SRS max until after the CS is established, so it can’t do something like reflect the RS max into the CS.  As you point out, that’s not really desirable in the first place.  So, probably just point out the issues and say it’s a system design issue to make sure the RS can handle what could occur on the CS or recording will be impaired.  I’m okay with SHOULD NOT on the RS.
 
> 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.
Again, I think we have to record what is in the CS.  If the CS identifies a participant by an MSRP AoR, we need to record that.  We can use whatever we want in the RS itself, so long as we can reproduce what was in the original CS.

> 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.
Hmmm, lots to think about.  Probably want to consult the chat authors.

> 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.
Happy to be of service as more than a co-chair :)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jul 2014 18:00:21 -0400

> Hopefully, we aren’t getting too deep in levels

I'll try to thin it out here.

> Understand, but encapsulation in MSRP would use a lot of BW also

Really?

I guess for small messages, if getting success reports, the traffic 
could double, or more. Certainly putting it into metadata wouldn't be 
better in that case.

In any case, this is probably much less bandwidth that audio, much less 
video.

One question is whether it is necessary to record success reports. 
Leaving them out would help.

> Yeah, but might be lesser of evils

ISTM that we have a variety of extra stuff that we might need to send. 
So a consistent way to do so might be appropriate.

I think that one or more special content types would serve the purpose. 
And we wouldn't have to send those in CPIM wrappers. That would make it 
clear that they are "special".

In addition to Reports, there is a need to send indications when an MSRP 
send failed. And maybe to send a place holder for messages that exceed 
the max-size declared by the SRS.

> Because the SRS can’t distinguish between the SRC receiving a wrapped message from a case where the SRC did the wrapping on the RS.

And AFAICT it doesn't matter.

I will bring this up in Toronto.

> Something has to give.  Probably a good topic for the meeting

I looked at CPIM again. It has its own extensibility mechanism built in, 
that we could use. But it has a price. You have to declare the extension 
(with a URI) in every message where it is used. That is in addition to 
the extension header itself. So it will be expensive for passing what is 
fundamentally one bit of information.

I will bring this up in Toronto.

> The SRS has to be able to derive what was MSRP To/From in the CS was.  It’s recording what the SRC saw.

...

> I think the recording has to record what the SRC got.  I don’t think it’s good enough to derive a notion of session, create new session IDs and then just use them.  The recording has to be able to…

I don't get it. The MSRP To/From are just artifacts. They aren't 
interesting in a recording.

If I wanted to "reenact" the session, I would expect that the new one 
would have different MSRP URIs. And that would not affect the fidelity 
of the reenactment.

I'll bring it up in Toronto - *what* we aim to capture in the recording, 
and what is not needed.

> Hmmm, lots to think about.  Probably want to consult the chat authors.

I sent a query to the authors, and to the simple list (if anybody still 
on it), asking for them to please help with this. Will see if we get any 
response.

	Thanks,
	Paul