Subject: Re: [siprec] Declaring desired MSRP recording status within MSRP

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 13:32:18 -0400

Adrian,

I am inclined to view the mechanism you describe below as *another* way 
to indicate desires regarding recording. The SRC is free to honor such 
mechanism if it wishes.

But I see no reason to forbid the media-neutral mechanism that is 
already defined by siprec.

Even if we didn't mention your mechanism at all, it would still be ok 
for an SRC to honor it. I guess the main issue here is whether that 
mechanism should be mentioned in the msrp recording draft.

Is that mechanism formally specified anywhere than can be referenced by 
an ietf draft? Or would we need to take on the job of standardizing it?

	Thanks,
	Paul

On 9/27/14 1:53 PM, Adrian Georgescu wrote:
>
> On 27 Sep 2014, at 14:25, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> On 9/27/14 7:39 AM, Adrian Georgescu wrote:
>>>
>>> On 26 Sep 2014, at 13:54, Paul Kyzivat <[email-masked]
>>> <mailto:[email-masked]>
>>> <mailto:[email-masked]>> wrote:
>>
>>>>>> Are you familiar with the base siprec drafts? (Particularly
>>>>>> draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to
>>>>>> indicate a preference for recording, or for *not* recording. It
>>>>>> applies to audio and video, and with the msrp-recording draft it will
>>>>>> apply also to that.
>>>>>
>>>>> This requires a re-INVITE, which may fail later in the middle of the
>>>>> session, or be out of sync with media plane, while the media continues
>>>>> to flow. It is a bad strategy as signalling and data are disconnected.
>>>>
>>>> Well, this is what was mandated for audio and video. For those, AFAIK
>>>> there is no way to carry the signaling for this in the media.
>>>
>>> MSRP is different as each message can carry by design any type of media
>>> described by its content-type inside the CPIM envelope.
>>>
>>>>
>>>>> So mandating to use SIP packet that may get lost to control MSRP chat
>>>>> messages in progress, is not gonna work properly. I want to know
>>>>> deterministically that my next MSRP message is not going to be stored
>>>>> (or fail to send at all), regardless of the SIP signalling or other
>>>>> middle box protocols that helped setup the MSRP media in the first
>>>>> place.
>>>>
>>>> With the current siprec mechanism, the do-not-record indication on the
>>>> CS is a *request* from a UA to the SRC. The SRC doesn't have to honor
>>>> it. However it is required to signal its actual
>>>> recording/not-recording state. So the requesting UA can decide not to
>>>> transmit sensitive information (or terminate the session) if it
>>>> doesn't get an indication that recording has stopped. And similarly if
>>>> the re-INVITE fails.
>>>
>>> For RTP sounds reasonable. For MSRP however is not ideal as it is much
>>> safer and reliable to send a MSRP message for which there is end-to-end
>>> integrity, sequencing and delivery reporting capability.
>>
>>>> So how do you do this? Have you defined an MSRP or CPIM extension? Or
>>>> have you defined a special MIME type for a body that communicates this?
>>>
>>> I just send a CPIM message like these:
>>>
>>> content_type='application/history-on'
>>>
>>> or
>>>
>>> content_type='application/history-off'
>>>
>>> The support for this feature is negotiated in the SDP of the MSRP media
>>> block, e.g.:
>>>
>>> Offer:
>>>
>>> o=- 3620806345 3620806345 IN IP4 192.168.8.3
>>> s=Blink 4.7.4 (MacOSX)
>>> m=message 2855 TCP/TLS/MSRP *
>>> c=IN IP4 192.168.8.3
>>> a=path:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp
>>> a=accept-types:message/cpim text/* application/im-iscomposing+xml
>>> a=accept-wrapped-types:*
>>> a=setup:active
>>> a=features:history-control icon
>>>
>>> Answer:
>>>
>>> o=- 3620806346 3620806347 IN IP4 10.0.0.139
>>> s=SylkServer-2.6.0
>>> c=IN IP4 10.0.0.139
>>> m=message 51634 TCP/TLS/MSRP *
>>> a=path:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp
>>> a=accept-types:message/cpim
>>> a=accept-wrapped-types:*
>>> a=setup:passive
>>> a=chatroom:nickname private-messages com.ag-projects.screen-sharing
>>
>> IIUC, a message with content type of application/history-off would not
>> be valid within the MSRP session negotiated above. (Unless it was sent
>> within a CPIM wrapper.)
>
> It is within the CPIM.
>
>
>> Ignoring that, what are the semantics? Are you sending an *empty*
>> message with this content type, to set a mode? Or is this the type of
>> a message containing a body that is to be displayed but not added to
>> the history?
>
> It asks the remote party to toggle its save to history on or off. Is a
> switch that can be toggled remotely (if the recipient want to honour it).
>
>
>>
>> If the latter, then how do you know the actual type of the content?
>>
>> How normative is this? Is it advisory to the recipient? Or binding?
>> Doe it need to be acknowledged?
>
> It is advisory as there is no way for force the other recipient to
> comply with such directive. You cannot control what a remote party will
> really save in its history database, is a gentlemen's agreement.
>
>>
>> Thanks,
>> Paul
>>
>
> --
> Adrian
>
>
>

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 1 Oct 2014 17:18:42 -0300

On 01 Oct 2014, at 14:32, Paul Kyzivat <[email-masked]> wrote:

> Adrian,
> 
> I am inclined to view the mechanism you describe below as *another* way to indicate desires regarding recording. The SRC is free to honor such mechanism if it wishes.
> 
> But I see no reason to forbid the media-neutral mechanism that is already defined by siprec.

> Even if we didn't mention your mechanism at all, it would still be ok for an SRC to honor it. I guess the main issue here is whether that mechanism should be mentioned in the msrp recording draft.
> 
> Is that mechanism formally specified anywhere than can be referenced by an ietf draft?

Not that I know of.

> Or would we need to take on the job of standardizing it?

I believe that this would be a great addition to MSRP specs!

Adrian

--
Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 17:00:22 -0400

On 10/1/14 4:18 PM, Adrian Georgescu wrote:
>
> On 01 Oct 2014, at 14:32, Paul Kyzivat <[email-masked]
>> I am inclined to view the mechanism you describe below as *another*
>> way to indicate desires regarding recording. The SRC is free to honor
>> such mechanism if it wishes.
>>

Would you still think so if, hypothetically, we started working on it 
and in the process decided that we had to change it in some way, or if 
we decided that the SIPREC SDP-based mechanism was sufficient?

	Thanks,
	Paul