Subject: [siprec] WGLC on draft-ietf-siprec-architecture

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 16 Mar 2012 13:34:06 -0400

We would like to start working group last call on -architecture-04.  Normally, we would have a two week WGLC, but since the IETF meeting falls in the middle, we will extend it to April 6th.

Please review the draft, even if you have looked at it before.  Please send comments to the list as soon as possible.

Brian

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 23 Mar 2012 02:14:22 -0700

I think the draft is in pretty good shape. I do have the following
comments (mostly minor).

Globally replace:
- "UA's" with "UAs"
- "CSes" with "CSs"
- "the SIPREC" with SIPREC"

Section 1: Introduction
s/this information in outside/this information is outside

Section 2: Definitions
Recording Aware User Agent
s/
Such extensions may be used to notify the Recording aware UA that a
session is being recorded or to all the Recording aware UA to express
preferences .../
Such extensions may be used to notify the Recording aware UA that a
session is being recorded, or by a Recording aware UA to express
preferences ...

Recording unaware User Agent (UA)
s/or to express/or express
s/that out of scope of the SIPREC/that is out of scope for SIPREC

Replicated Media
s/Recordin Session/Recording Session

Section 3.1.1 reads,
"The B2BUA/SRC is responsible for honoring any indication from
recording aware UA's or through some configured policies that the
communication session must not be recorded."
This is not accurate. There is not a way for the UA to indicate that a
session MUST not be recorded. Instead, the UA indicates its preference,
and the SBC/B2BUA is not required to "honor" that preference.

Section 3.1.4, the second paragraph is hard to parse. I suggest breaking
it up a bit as follows:
"The Session Recording Client and Session Recording Server described
in this document may act as an application server as described in
[RFC5567]; and therefore, when further decomposed, may be made up of an
application server which uses a mediactrl interface to control a
media server for the purpose of recording the media streams. However,
this interface is considered outside the scope of this document."

Section 3.2, the last paragraph currently reads,
"Concerning media negotiation, regular SIP/SDP capabilities should be
used, and existing transcoding capabilities should not be precluded"
I suggest adding SRTP here as well, as follows:
"Concerning media negotiation, regular SIP/SDP capabilities should be
used, and existing transcoding capabilities and media encryption should
not be precluded."

Section 3.2.2, I think the reference to isfocus should be removed to
avoid confusion.
s/identification is depends/identification depends

The reference to the Join header should be removed as well, although I
think this comment was made already.

Section 3.2.5
s/the more capable/a more capable

Section 3.3.2, large paragraph,
s/"it is also possible/It is also possible

Section 4, IANA considerations.
The architecture draft mentions SIP/SDP extensions. I think it would be
useful to state that the associated IANA considerations will be
addressed in the protocol draft that defines them.

Section 5,
s/make use/makes use
s/are aware of that/are aware that
s/recorded and the architecture/recorded, and the architecture

Section 7, update the references to the protocol and metadata drafts

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rosen, Brian
> Sent: Friday, March 16, 2012 10:34 AM
> To: [email-masked]
> Subject: [siprec] WGLC on draft-ietf-siprec-architecture
> 
> We would like to start working group last call on -architecture-04.
> Normally, we would have a two week WGLC, but since the IETF meeting
> falls in the middle, we will extend it to April 6th.
> 
> Please review the draft, even if you have looked at it before.  Please
> send comments to the list as soon as possible.
> 
> Brian
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Leon Portman <[email-masked]>
Date: Fri, 23 Mar 2012 11:16:38 +0200

Charles Hi

Thank you very much for the comments.

Will update in the next version.

Regards

Leon

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 26 Mar 2012 15:44:02 +0530

Leon et al,

Here are my comments. The document is pretty good shape and most of the
comments are minor ones.

s/Media Recording Metadata /Recording Metadata  at all places in the
document.

We have not used Media Recording Metadata anywhere in the metadata
draft. I think we can have consistent naming across documents wherever
possible.

The definitions of SRC, SRS, CS in section 2 is all repetition of what
is already there in RFC 6341. Can we remove them ? In case you still
want to retain them please have the definition consistent with
definitions in requirement document.

Section 2: In the definition of Replicated Media-
s/Recordin s/Recording

Section 3.1.1 has,
"The B2BUA/SRC is responsible for honoring any indication from recording
aware UA's or through some configured policies that the communication
session must not be recorded."
IMO in the current protocol draft there is not a way for the UA to
indicate that a session MUST not be recorded. Instead, the UA indicates
its preference(a=recordpref attribute), and the SRC MAY "honor" that
preference. Are we going to always honor the request from the recording
aware UA ?. IMO SRC MUST have flexibility to honor or not depending on
its policies.

Why do we need section 3.1.3 ? There may be several devices that may not
be capable to act as SRC. Is there a reason to explicitly list only
proxy ?

In Figure 1, show RTCP also in the CS between UA-A and UA-B.

Figure 5 shows streams recorded separately for Centralized conferencing
case. We can add a note here that we may also have use-cases in
centralized conferencing where mixed stream gets recorded to SRS.

Update the references to metadata and protocol drafts to have the latest
versions.
Also add reference to Charles draft (draft-eckel-siprec-rtp-rec).

Regards,
Ram

> Sent: Friday, March 16, 2012 11:04 PM
> To: [email-masked]

---

From: Leon Portman <[email-masked]>
Date: Tue, 27 Mar 2012 13:33:20 +0200

Ram, Hi

Thank you very much for the comments. Regarding honoring recording preferences, this document is an architecture draft that describes possible flows. The actual protocol bits and behaviors are described in the protocol draft. I don't feel very comfortable stating in IETF draft that user preferences not be recorded can be overridden by policies.

Regards

Leon

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 27 Mar 2012 19:25:08 +0530

Leon,

> From: Leon Portman [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2012 5:03 PM
> To: Ram Mohan R (rmohanr)
> Cc: <[email-masked]>
> Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture
> 
> Ram, Hi
> 
> Thank you very much for the comments. Regarding honoring recording
> preferences, this document is an architecture draft that describes
> possible flows. The actual protocol bits and behaviors are described
in
> the protocol draft. I don't feel very comfortable stating in IETF
draft
> that user preferences not be recorded can be overridden by policies.

Ok. Fine with me.

Thanks,
Ram

> recording