Subject: [siprec] AD evaluation: draft-ietf-siprec-protocol-15

From: Alissa Cooper <[email-masked]>
Date: Fri, 17 Apr 2015 15:39:56 -0700

I have reviewed this document in preparation for IETF LC. Overall it is in good shape. I have a few substantive questions/comments I’d like to discuss before issuing the IETF LC and a bunch of nits.

Substantive issues:

General:
I think this document is missing a clear, concise explanation of why the protocol cannot be used for wiretapping. The pieces of this explanation are almost all there in sections 5, 6, and 7, but given the existence of RFC 2804 and general sensitivity towards this issue, I think the document needs to be more explicit about the expected mechanics of the recording indication and preference mechanisms in situations where all involved UAs are recording-aware and where they are not. A simple statement is missing about how it is not possible to use this protocol as standardized without the SRC sending an indication that recording is occurring to every participant in the session. Furthermore, it seems like there are some situations where if a user does not want to be recorded, his only option is to terminate the session. This arises when an SRC does not honor a UA's recording preference set to off, and also possibly when a UA is not recording-aware, right? Those two situations need to be described explicitly.

I would suggest adding the explanation to 5.3 and summarizing it in a sentence in the abstract and in the introduction.

Sec 6.1.2:
"For the communication session, the SRC MUST provide recording
   indication to all participants in the CS.  A participant UA in a CS
   can indicate that it is recording-aware by providing the "record-
   aware" option tag, and the SRC MUST provide recording indications in
   the new SDP a=record attribute described in the SDP Handling section.
   In the absence of the "record-aware" option tag, meaning that the
   participant UA is not recording-aware, an SRC MUST provide recording
   indications through other means such as playing a tone in-band, if
   the SRC is required to do so (e.g. based on policies)."

The requirements established in this paragraph are a little confusing. First it says the SRC MUST provide recording indication to all participants. Then later it says the SRC MUST provide recording indications through other means ... if required to do so by policy. That sounds like a conditional MUST, which doesn't make sense (since MUST means an absolute requirement), and it also contradicts the MUST in the first sentence. Shouldn't the if clause in the last sentence be dropped?

Section 6.3:
"A recording-aware UA MUST be prepared to provide a recording
   indication to the end user through an appropriate user interface"

"MUST be prepared to" is a strange construction. I think "MUST provide" is what is meant here.

Section 7.2:
"The SRS SHOULD NOT add recorded streams in the recording session when
   SRS sends a new SDP offer.  Similarly, when the SRS starts a
   recording session, the SRS SHOULD initiate the INVITE without an SDP
   offer to let the SRC generate the SDP offer with recorded streams."

I'm not clear on why these are SHOULD-level requirements, or what the exception cases are and what the SRC is expected to do in those exception cases. Could you explain?

Section 8.1:
Some of the text here seems like it boils down to saying "it's important to use RTP correctly," without really saying anything specific to siprec or explaining the rationale for a given recommendation as it relates to recording. This is particularly true for 8.1.3, 8.1.5, and 8.1.7.2. I would suggest adding recording-specific rationales or removing this text.

Nits:

Sec 5.2:

OLD
These metadata
   updates are normally incremental updates to the initial metadata
   snapshot to optimize on the size of updates, however, the SRC may
   also decide to send a new metadata snapshot anytime.

NEW
These metadata
   updates are normally incremental updates to the initial metadata
   snapshot to optimize on the size of updates. However, the SRC may
   also decide to send a new metadata snapshot any time.
   
OLD
such as the attributes of the recorded media stream
   are located in the SDP of the recording session.

NEW
such as the attributes of the recorded media stream,
   are located in the SDP of the recording session.
   
Sec 7.1.2 and 7.3.2:

The /= in the ABNF should be =/

Sec 8.1.2:
s/However, as this is not a requirement/However, as these are not requirements/

Sec 8.1.4:
s/when acting a mixer/when acting as a mixer/

Sec 8.2.1.1 and 8.2.1.2:

OLD
A Recording aware UA SHOULD be prepared to
   process the RTCP Receiver Reports from the SRS, whereas a recording
   unaware UA may discard such RTCP packets as not of relevance.

NEW
A UA SHOULD process the RTCP Receiver Reports from the SRS if it is recording-aware.

Sec 8.2.2:
s/from different UA/from different UAs/

Sec 8.3:
The text in this section seems duplicative of the packet loss text in the subsections of 8.2. It should only appear in one place or the other but not both.

Sec 8.4.2:
s/In doing to/In doing so/

Sec 8.5:
s/an video/a video/

Sec 10:
s/When there is no communication sessions/When there is no communication session/

Sec 11.1.1:

OLD
When present in a Require header in a request, it indicates that the UAS MUST be either a SRC or SRS

NEW
When present in a Require header in a request, it indicates that the UAS is either an SRC or SRS

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Apr 2015 15:43:54 -0400

Alissa,

Regarding notification of recording...

This is indeed a complex subject, especially in the case of participants 
that are not recording-aware. Some of the cases that were considered:

- typical automation scenarios, where there is a disclaimer given
   "this call *may* be recorded". That might happen before it is even
   decided whether to include a recorder.

- contractual cases, where participants are made aware separately
   from any particular call. For instance, a call center agent is
   well aware that recording will go on. And a call center agent
   cannot, in practice, be notified in the media, for each call.

- IIUC there isn't established law about *how* to notify in-band
   for media other than audio.

Much of this can be mitigated with recording-aware UAs with flexible UIs 
that can display recording status. But we can't assume that even call 
center agents will have recording-aware devices.

Ultimately this is a *legal* issue more than a technical issue. In band 
notification is not always required, or desirable.

So we tried to put in good mechanisms for the recording-aware, but for 
others ISTM that the ultimate answer is "consult your lawyer".

	Thanks,
	Paul

On 4/17/15 6:39 PM, Alissa Cooper wrote:
> I think this document is missing a clear, concise explanation of why the protocol cannot be used for wiretapping. The pieces of this explanation are almost all there in sections 5, 6, and 7, but given the existence of RFC 2804 and general sensitivity towards this issue, I think the document needs to be more explicit about the expected mechanics of the recording indication and preference mechanisms in situations where all involved UAs are recording-aware and where they are not. A simple statement is missing about how it is not possible to use this protocol as standardized without the SRC sending an indication that recording is occurring to every participant in the session. Furthermore, it seems like there are some situations where if a user does not want to be recorded, his only option is to terminate the session. This arises when an SRC does not honor a UA's recording preference set to off, and also possibly when a UA is not recording-aware, right? Those two situations need to be d
 e
scribed explicitly.
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 19 Apr 2015 14:06:13 -0700

Hi Paul,

What you say below is all fine, but is not clear in the document. My assumption is that this document is intended to align with RFC 6341, which left use cases where users are not informed about recording outside of its scope, and with RFC 7245, which claims that the intended use of the SIPREC architecture is "only for the case where the users are aware that they are being recorded.” In some cases the assumption may be that that awareness is gained through an out-of-band mechanism. But that needs to be explained in the document.

Alissa 

On Apr 18, 2015, at 12:43 PM, Paul Kyzivat <[email-masked]> wrote:

> This is indeed a complex subject, especially in the case of participants that are not recording-aware. Some of the cases that were considered:
> 
> Much of this can be mitigated with recording-aware UAs with flexible UIs that can display recording status. But we can't assume that even call center agents will have recording-aware devices.
> 
> Ultimately this is a *legal* issue more than a technical issue. In band notification is not always required, or desirable.
> 
> So we tried to put in good mechanisms for the recording-aware, but for others ISTM that the ultimate answer is "consult your lawyer".
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Apr 2015 18:19:01 -0400

Alissa,

> What you say below is all fine, but is not clear in the document. My assumption is that this document is intended to align with RFC 6341, which left use cases where users are not informed about rec…

OK. In any case, these were just my personal comments.I certainly don't 
object to having stuff similar to what I mentioned being included in the 
text. So I will wait for the chairs and authors to comment.

	Thanks,
	Paul

>>> I think this document is missing a clear, concise explanation of why the protocol cannot be used for wiretapping. The pieces of this explanation are almost all there in sections 5, 6, and 7, but given the existence of RFC 2804 and general sensitivity towards this issue, I think the document needs to be more explicit about the expected mechanics of the recording indication and preference mechanisms in situations where all involved UAs are recording-aware and where they are not. A simple statement is missing about how it is not possible to use this protocol as standardized without the SRC sending an indication that recording is occurring to every participant in the session. Furthermore, it seems like there are some situations where if a user does not want to be recorded, his only option is to terminate the session. This arises when an SRC does not honor a UA's recording preference set to off, and also possibly when a UA is not recording-aware, right? Those two situations need to be
  
d

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 20 Apr 2015 23:26:50 +0000

Hi Alissa, 

Thank for your thorough review and detailed comments. Please see how I
propose to address each comment inline.

On 4/17/15, 3:39 PM, "Alissa Cooper" <[email-masked]> wrote:

>I have reviewed this document in preparation for IETF LC. Overall it is
>in good shape. I have a few substantive questions/comments I¹d like to
>discuss before issuing the IETF LC and a bunch of nits.
>
>Substantive issues:
>
>General:
>I think this document is missing a clear, concise explanation of why the
>protocol cannot be used for wiretapping. The pieces of this explanation
>are almost all there in sections 5, 6, and 7, but given the existence of
>RFC 2804 and general sensitivity towards this issue, I think the document
>needs to be more explicit about the expected mechanics of the recording
>indication and preference mechanisms in situations where all involved UAs
>are recording-aware and where they are not. A simple statement is missing
>about how it is not possible to use this protocol as standardized without
>the SRC sending an indication that recording is occurring to every
>participant in the session. Furthermore, it seems like there are some
>situations where if a user does not want to be recorded, his only option
>is to terminate the session. This arises when an SRC does not honor a
>UA's recording preference set to off, and also possibly when a UA is not
>recording-aware, right? Those two situations need to be described
>explicitly.
>
>I would suggest adding the explanation to 5.3 and summarizing it in a
>sentence in the abstract and in the introduction.

Append the follow to the Abstract:

This document only considers active recording, where the SRC
   purposefully streams media to a SRS.  Passive recording, where a
   recording device detects media directly from the network (e.g., using
   port-mirroring techniques), is outside the scope of this document.
   In addition, lawful intercept is outside the scope of this document.

Change section 5.3 as follows:
OLD
The recording attribute is a declaration by
   the SRC in the CS to indicate whether recording is taking place.
The recording preference attribute is a declaration by the recording-
   aware UA in the CS to indicate the recording preference.

NEW
The recording attribute is a declaration by
the SRC in the CS to indicate whether recording is taking place.
The recording preference attribute is a declaration by the recording-
   aware UA in the CS to indicate the recording preference.
A UA that does not want to be recorded may still be notified recording
is occurring for a number of reasons (e.g. it was not capable of indicating
its preference, its preference was ignored, etc.) If this occurs, the UA¹s
only mechanism to avoid being recorded is to terminate its participation in
the session.

>The requirements established in this paragraph are a little confusing.
>First it says the SRC MUST provide recording indication to all
>participants. Then later it says the SRC MUST provide recording
>indications through other means ... if required to do so by policy. That
>sounds like a conditional MUST, which doesn't make sense (since MUST
>means an absolute requirement), and it also contradicts the MUST in the
>first sentence. Shouldn't the if clause in the last sentence be dropped?

I suggest changing to:

In the absence of the "record-aware" option tag, meaning that the
   participant UA is not recording-aware, an SRC MUST provide recording
   indications through other means, such as playing a tone in-band, having
a signed participant contract in place, etc.

>"MUST be prepared to" is a strange construction. I think "MUST provide"

Agreed.

>I'm not clear on why these are SHOULD-level requirements, or what the
>exception cases are and what the SRC is expected to do in those exception
>cases. Could you explain?

Me neither. We use tight language in section 9.2 already. Changing both
from SHOULD to MUST works for me.

>
>Section 8.1:
>Some of the text here seems like it boils down to saying "it's important
>to use RTP correctly," without really saying anything specific to siprec
>or explaining the rationale for a given recommendation as it relates to
>recording. This is particularly true for 8.1.3, 8.1.5, and 8.1.7.2. I
>would suggest adding recording-specific rationales or removing this text.

Sections 8.1.3 states,

   The SSRC may also be used to separate different sources of media
   within a single RTP session.  For this reason as well as for conflict
   resolution, it is important that the SRC, SRS, and Recording aware
   UAs handle changes in SSRC values and properly identify the reason of
   the change.  The CNAME values carried in RTCP facilitate this
   identification.

I think this is a compelling enough reason to call out SSRC handling here.

Section 8.1.5 states,

End systems send one SDES
   packet containing their own source identifier (the same as the SSRC
   in the fixed RTP header).  A mixer sends one SDES packet containing a
   chunk for each contributing source from which it is receiving SDES
   information, or multiple complete SDES packets if there are more than
   31 such sources.

How about I add,

The ability to identify individual contributing sources is important in
the content of SIPREC. This may sometimes be achieved at the signaling
level using metadata, as described in [I-D.ietf-siprec-metadata]. SDES
provides a mechanism at the RTP level.

Section 8.1.7.2 is one of the mechanism to recover from problems with the
video stream. How about I extend as follows:

Appropriate use of PLI and FIR is important to ensure with minimum
overhead that the recorded video is usable (e.g. the necessary reference
frames exist for a player to render the recorded video).

>The text in this section seems duplicative of the packet loss text in the
>subsections of 8.2. It should only appear in one place or the other but
>not both.

Good catch. It originally existed in section 8.3 only. We decided it would
be better to handle this in the previous subsections but forgot to remove
section 8.3.

>When present in a Require header in a request, it indicates that the UAS

These all look fine to me.

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Apr 2015 11:32:31 -0400

Comments on a few of these:

>     aware UA in the CS to indicate the recording preference.

perhaps "indicate *it's* recording preference"?

>> "MUST be prepared to" is a strange construction. I think "MUST provide"

I think the concern here is that this might be construed to require a 
real-time notification. A recording-aware UA could be configured by its 
user to manage recording policy on behalf of the user. For instance, the 
user may set policy that recording is ok at all times, or that recording 
is ok when connected to certain parties. In such cases it might not 
indicate this actively.

An extreme example is a special purpose UA for financial service 
workers. Calls are typically *required* to be recorded. The UA may 
itself *be* an SRC that records all calls, or a UA intended to be used 
where an SRC is in all calls. So the user doesn't expect or need an 
explicit indication.

Do we want to preclude such devices?

> from SHOULD to MUST works for me.

There was considerable discussion of cases where the SRS wants to take 
the initiative of connecting to an SRC for purposes of recording. We 
ultimately ruled it out of scope, because we couldn't figure out how the 
SRC could signal what calls should be recorded. But it was my impression 
that this is a valid use case in some environments, and so may be the 
subject of future work, or of proprietary extensions.

I *guess* that the SHOULD-level here was to provide a little wiggle room 
for extensions here.

Note that if this the SHOULD were violated the SRC still has the option 
of rejecting the added streams. Since in general it wouldn't know what 
to do with them that is probably what it would do. So IMO SHOULD is ok here.

	Thanks,
	Paul

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 22 Apr 2015 14:01:45 -0700

Thanks Charles. I’ll respond to the ones that Paul did not comment on and await further response from you to Paul on the others.

On Apr 20, 2015, at 4:26 PM, Charles Eckel (eckelcu) <[email-masked]> wrote:

>   purposefully streams media to a SRS.  

I would add “and all participating user agents are notified of the recording."

> Passive recording, where a

I would suggest repeating the above at the end of the introduction and adding “in accordance with RFC 2804” to the last sentence.

> only mechanism to avoid being recorded is to terminate its participation in

WFM. I like Paul’s suggestion too.

> a signed participant contract in place, etc.

WFM

>> "MUST be prepared to" is a strange construction. I think "MUST provide"

If this seems too constraining to capture the cases where the indication is provided out-of-band, I think you could drop “through an appropriate user interface."

> I think this is a compelling enough reason to call out SSRC handling here.

Ok, reading it again, I think this if fine.

> provides a mechanism at the RTP level.

WFM

> frames exist for a player to render the recorded video).

WFM

Thanks,
Alissa

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 24 Apr 2015 18:07:11 +0000

Hi Alissa,

Your additional clarifications all look fine to me. I will add your suggestion for section 6.3 to my response to Paul.

Cheers,
Charles

From: Alissa Cooper <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 22, 2015 at 2:01 PM
To: Charles Eckel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15

On Apr 20, 2015, at 4:26 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alissa,

On 4/17/15, 3:39 PM, "Alissa Cooper" <[email-masked]<mailto:[email-masked]>> wrote:

Substantive issues:

General:

NEW

Sec 6.1.2:

I suggest changing to:

WFM

Section 6.3:

"MUST be prepared to" is a strange construction. I think "MUST provide"
is what is meant here.

Agreed.

Section 7.2:

Section 8.1:

Sections 8.1.3 states,

Section 8.1.5 states,

How about I add,

WFM

WFM

Thanks,
Alissa

Nits:

Sec 5.2:

OLD
These metadata

NEW
These metadata

OLD

NEW

Sec 7.1.2 and 7.3.2:

Sec 8.1.2:
s/However, as this is not a requirement/However, as these are not
requirements/

Sec 8.1.4:

Sec 8.2.1.1 and 8.2.1.2:

OLD

NEW
A UA SHOULD process the RTCP Receiver Reports from the SRS if it is
recording-aware.

Sec 8.2.2:

Sec 8.3:

Sec 8.4.2:

Sec 8.5:
s/an video/a video/

Sec 10:
s/When there is no communication sessions/When there is no communication
session/

Sec 11.1.1:

OLD
When present in a Require header in a request, it indicates that the UAS
MUST be either a SRC or SRS

NEW
When present in a Require header in a request, it indicates that the UAS
is either an SRC or SRS

Cheers,
Charles

_______________________________________________
siprec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 24 Apr 2015 18:07:17 +0000

Hi Paul,

Please see inline.

>perhaps "indicate *it's* recording preference"?

Good idea.

>Do we want to preclude such devices?

I don’t think so. I see Alissa proposed dropping the “through an
appropriate user interface”, resulting in the following:

"A recording-aware UA MUST provide a recording indication to the end user"

The other alternative would be to expand on what is appropriate:

"Appropriate user interfaces may include real-time notification or
previously established agreement that use of the device is subject
recording.”

>to do with them that is probably what it would do. So IMO SHOULD is ok

The existing draft allows the SRS to initiate the recording, but restricts
it to doing so via an offerless invite. It seems to me that tightening
this from a SHOULD to a MUST is appropriate. Future extensions to give the
SRS more control over the recording could also update the RFC to define
the new exceptions and the corresponding proprietary extensions.

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Apr 2015 14:49:36 -0400

WFM

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 29 Apr 2015 13:12:30 +0000

Hi All,

I have been through Alissa's comments and the proposed changes and my take on it is that all the proposed changes are just clarifications of what was intended by the working group and none of the suggested updates the protocol.

Charles, Are you willing to do an update with the changes proposed?

Regards
Andy 

> -----Original Message-----
> From: siprec [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 24 April 2015 19:50
> To: Charles Eckel (eckelcu); [email-masked]
> >>> its preference, its preference was ignored, etc.) If this occurs,
> the
> >>> UA¹s
> > I don't think so. I see Alissa proposed dropping the "through an
> > appropriate user interface", resulting in the following:
> >
> > recording."
> >> to do with them that is probably what it would do. So IMO SHOULD is
> ok
> >> here.
> >

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 29 Apr 2015 15:20:58 +0000

Yes, I can make the corresponding changes. I was waiting a bit to see if
there were any additional comments. I will target getting an update out
before the end of the week.

Cheers,
Charles

On 4/29/15, 6:12 AM, "Hutton, Andrew" <[email-masked]> wrote:

>Hi All,
>
>I have been through Alissa's comments and the proposed changes and my
>take on it is that all the proposed changes are just clarifications of
>what was intended by the working group and none of the suggested updates
>the protocol.
>