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

[Paul Kyzivat <[e-mail]>]

On 7/9/14 6:48 PM, Brian Rosen wrote:
> Hopefully, we aren’t getting too deep in levels

I'll try to thin it out here.

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

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.

>>> Extending reports in some manner is a
>>> possibility.
>>
>> Yes, this is possible. But it would be nice to avoid modifying MSRP.
> 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.

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

>>>> 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.
> 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 reproduce what the SRC saw.

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.

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

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