Subject: [siprec] Comments on draft-ietf-siprec-req-01

From: "Elwell, John" <[email-masked]>
Date: Tue, 7 Sep 2010 15:55:22 +0200

(as individual, as are all my postings via the tracker today)

I have read the document again, and I think it needs a certain amount of work before it can be considered ready for WGLC. There are lots of issues still open on the tracker - I don't think 01 closes many of these. I have responded separately on a few of those issues. In addition I have the following comments:

1. Section 2:
"It should be noted that the requirements for the protocol between a
   Session Recording Server and Session Recording Client have very
   similar requirements (such as codec and transport negotiation,
   encryption key interchange, firewall traversal) as compared to
   regular SIP media sessions.  The choice of SIP for session recording
   provides reuse of an existing protocol."
This doesn't make sense before introducing SRS, SRC and SIP later in the paragraph. I would suggest moving these sentences to the end of the paragraph, i.e., after "The Session Recording Server is the sink of recorded media."

2. Section 2:
In the same paragraph:
"This document specifies
   requirements for using SIP [RFC3261] to record a media session
   between a Session Recording Client and a Session Recording Server,"
In fact SIP is used for control of the recording. I would proposes rewording as follows:
"This document specifies requirements for using SIP [RFC3261] between a Session Recording Client and a Session Recording Server to control the recording of media that has been transmitted in the context of a communication session."

3. Section 2:
"The recorded sessions can be any SIP-based RTP media sessions
   including voice, video, and text (as defined by [RFC4103])."
The RTP media sessions are not SIP-based (although SIP might have been used to establish the sessions). Also, when talking about individual media, it is perhaps better to talk about media, rather than sessions. I propose rewording as:
"The recorded media can be any RTP-based media, including voice...."

4. Section 2:
"The session metadata allows
   recording archives to be searched and filtered at a later time."
It might be worth adding:
"and allows a session to be played back in a meaningful way, e.g., with correct synchronization between the media".

5. Section 2:
"The
   conveyance of session metadata from the Session Recording Client to
   the Session Recording Server may or may not be over SIP.  The
   requirements for session metadata delivery will be specified in a
   future revision of this document or in a separate document."
I think all we need to say is:
"Session metadata needs to be conveyed from the SRC to the SRS."

6. Section 2:
"In some situations it may be advantageous to correlate the
   Communication Session with other information, such as an IM or other
   text chat session."
It is not clear that we have requirements to cause us to address this, so can we remove this statement?

7. Section 3:
"Note that the term "Server" does not imply the SRS is the server side
   of a signaling protocol - the SRS may be the initiator of recording
   requests, for example."
I don't think this is helpful - too much detail for a requirements document.

8. Section 3, figure 1:
This is confusing, since it shows the SRC spanning both UAs involved in the CS, but typically the SRC will be located only at one UA or at an intermediary. Since figure 1 is not referenced, can it be removed (covered by the architecture document)?

9. Section 3:
"Metadata: Data that describes the Communication Session and Recording
   Session.."
I think we have had this discussion before, but I don't recall the outcome. I don't think metadata necessarily needs to describe the RS. I think it could be defined as "Information that describes recorded media and the CS to which they relate".

10. Section 3:
"Pause/Resume recording: Pause: Temporarily discontinue capture and
   storage of the incoming media stream.  Recording may continue via the
   Resume command.  Resume: Continue capture and storage of the incoming
   media stream into the same recording session."
Several comments on this:
- This definition does not define Pause/Resume recording, but just contains separate definitions of Pause and Resume. I think we should indeed split into two definitions and not both trying to define "Pause/Resume recording".
- Tracker issue #14 already questions whether "pause" is the right term. One proposal is "hold". Another would be "suspend" (which I prefer).
- The terms pause and resume are defined as verbs. We should define only nouns.
- "incoming media stream" - this presumably refers to a media stream associated with a CS.
- "Resume command" - we should not talk about "commands" - sounds like a UI or API function.
- Does "resume" necessarily need to use the same RS as that used prior to "pause"? I think that is a solution matter.
- I think we should make it clear that the CS continues during pause.
I would propose the following:
"Suspend:  The action of temporarily discontinuing the recording of media during a CS.
Resume: The action of recommencing the recording of media for a CS following a suspend."

11. Section 3:
"from the RC to RS."
Change to:
"from the SRC to the SRS".

12. Section 5:
This seems to use the terms "call" and "communication session" (or "CS") at random. Be consistent.

13. Section 5:
The style of this is rather mixed, but a lot of it is in note form, rather than proper sentences. I don't know whether the RFC editor will accept it like this.

14. Section 5, use case 1:
"One Recording
   Session is created per Communication Session."
This effectively is a repetition of the first sentence of this use case.

15. Section 5, use case 2:
"Start a Recording Session when a
   Communication Session is established."
and then:
"A Communication Session
   may or may not have a Recording Session (record only specific calls)."
These can be interpreted as being in conflict. The first suggests we always start an RS, whereas the second says we do so only when a call is to be recorded.
Perhaps the first sentence should say:
"Start a Recording Session when a Communication Session to be recorded is established."
Then the other sentence is not needed.

16. Section 5, used case 3:
"Use Case 3: Dynamic Recording: Start/Stop a Recording Session during
   a Communication Session."
Is this intentionally different from pause/resume (or suspend/resume)?

17. Section 5, use case 3:
"Enterprise back office recording where only specific calls (based
   on privacy) have to be recorded"
This would seem to be covered by used case 2, so can it be deleted from use case 3?

18. Section 5, use case 4:
"The recording session is a single RTP stream,
   therefore consists of a single offer/answer exchange.  There may be
   mid-session RE-INVITE offer/answer exchanges for codec changes or for
   moving the RTP streams to handle failure scenarios."
- Saying it is a single RTP stream might not work for multiple media. Perhaps "single RTP stream per medium"?
- The first sentence is contradicted by the second sentence, which says that there can be further offer/answer exchanges. - Furthermore, this is getting too far into solution.
I would suggest we delete these sentences.

19. Section 5, used case 4:
"A Recording Session records continuously without interruption."
Yes, but only as long as there are media to record. It will clearly stop recording when not receiving any media.

20. Section 5, use case 4:
"Call details
   and metadata will still be signaled, but can be post- correlated to
   the recorded media."
Why "post-correlated"? Why can't they be correlated at the time?

21. "however this may be on a permanent filter-type
   basis, such as based on a SIP AoR of an agent that is always
   recorded."
This presumably is referring to correlation, but I don't understand it, particular the expression "filter-type basis".

22. Section 5, use case 5:
"Mute/Unmute"
These terms are undefined. Are they any different from suspend/resume?

23. Section 5, use case 8:
"Obtain media by forking:
   o In data centers (inbound/outbound): fork media in gateway.
   o At branch locations (internal): fork from end points or from site
   level gateways."
Is this getting too solution-specific?

24. Section 6:
"The following are requirements for the Session Recording Protocol"
This is the first use of the term "Session Recording Protocol"

25. REQ-006:
"REQ-006 The mechanism MUST support establishing Recording Sessions
   from the SRS to the SRC (SRS initiates recording).  This requirement
   typically applies when the decision about whether a session should be
   recorded or not resides in the SRS."
Do we really need this? We have decided it is the policy server that decides, and of course the policy server can be collocated with the SRS. This doesn't necessarily mean the SRS establishes the session. The policy server instructs the SRC to record and the SRC establishes the session. In fact, I could also question why we need REQ-005. Both REQ-005 and REQ-006 seem to be solution.

26. REQ-019/020:
"o REQ-019 The mechanism MUST support the ability to transport the
   metadata in the same SIP dialog as the Recording Session.

   o REQ-020 The mechanism MUST support the ability to transport the
   metadata outside of the Recording Session SIP dialog."
This is calling for two separate mechanisms. I am sure we must have discussed this in the past, but do we really want to make interoperability harder by having two mechanisms?

27:
"REQ-022: The mechanism MUST support a means to cancel and discard a
   Recording Session during a Communication Session."
Do we need to make it clear what decides on this? Is it a UA involved in a CS (as for REQ-023)?

28: REQ-023:
"REQ-023 The mechanism MUST support a means for a SIP UA to request
   that a Communication Session is not recorded prior to recording."
We should make it clear this is a SIP UA involved in the CS (the SRC and SRS are also SIP UAs). Proposed words:
"REQ-023 The mechanism MUST support a means for a SIP UA involved in a CS to request, prior to the start of recording, that the CS not be recorded".

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 22 Sep 2010 09:17:18 +0200

I pretty much agree with all Dave's responses (as modified by our discussion on figure 1 during Monday's call).

John

________________________________
From: Dave Smith [mailto:[email-masked]]
Sent: 21 September 2010 20:51
To: Elwell, John; [email-masked]; [email-masked]
Subject: RE: [siprec] Comments on draft-ietf-siprec-req-01

My inputs to the remaining points provided below.

Regards,
Dave

From: Dave Smith
Sent: Monday, September 20, 2010 8:00 AM
To: Elwell, John; [email-masked]; [email-masked]
Subject: RE: [siprec] Comments on draft-ietf-siprec-req-01

Pls see below....I've added my inputs to the first half of John's comments.

Regards,

Dave

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John

Sent: Tuesday, September 07, 2010 6:55 AM

To: [email-masked]

Subject: [siprec] Comments on draft-ietf-siprec-req-01

1. Section 2:

[DS] OK.  That should work better.

2. Section 2:

In the same paragraph:

"This document specifies

[DS] OK.  I agree.

3. Section 2:

[DS] OK.  I agree.

4. Section 2:

[DS] I agree, this addition adds more meaning...

5. Section 2:

"The

[DS] This does simplify, OK w/ me.

6. Section 2:

   text chat session."

[DS] I agree...I don't see the purpose of this sentence.

7. Section 3:

   requests, for example."

[DS] I agree to delete this sentence; which is consistent with comments in Tracker Ticket # 24.

8. Section 3, figure 1:

[DS] We discussed this diagram before and after our debate agreed to what is shown, which I believe is very helpful in understanding the terms/definitions presented just before it in the writing.  I recommend to leave the diagram as is.  I agree that we could however reference it in the definitions.

9. Section 3:

   Session.."

[DS] I agree.

10. Section 3:

[DS]  I prefer Pause/Resume and don't see a reason to change "Pause" to "Suspend" (it doesn't change anything in the original argument).

11. Section 3:

"from the RC to RS."

Change to:

[DS] I agree.  Also in section 3 change this:

"Session Recording Client (SRC): A Recording Client (SRC)"

To this:

"Session Recording Client (SRC): A Session Recording Client (SRC)"

12. Section 5:

[DS] OK.

13. Section 5:

[DS] I agree, the writing needs some grammar work there.

"One Recording

[DS] I agree, and think that the first sentence should include the term "is created" also.

and then:

"A Communication Session

[DS] I recommend to be consistent and use (or include) the new wording that is recommended for REQ-002 ("Record selected communication sessions in their entirety") here for Use Case 2.

Also, I recommend to use (or include) the new wording that is recommended for REQ-001 ("record all communication sessions in their entirety") in Use Case 1, and REQ-003 ("record selected parts of selected communication sessions.") in Use Case 3.

[DS] Yes it is different (Pause/Resume is functionality that could be used during Dynamic Recording, or during any of the other types of recording as well).

See recommendations above.  And consider this re-write:
Use Case 3: Dynamic Recording:
Dynamic Recording is used for recording a selected part of a selected communication session.
For example, a decision may be made to start a Recording Session (RS) during (e.g., in the middle of) a Communication Session (CS).  This could be done either manually via a user-controlled mechanism (e.g. button on user's desktop) or automatically via an application (e.g., a Contact Center customer service application) due to a business event.  The RS may be terminated during the CS or when the CS ends.  A diagram depicting this example is shown below in Figure 5.

   CS  |------------- Communication Session -----------|

   RS            |---- Recording Session -----|

  Figure 5 - Dynamic Recording

 Note that Dynamic Recording is also known as Mid-session or Mid-call Recording.

 Applications include:

   o Enterprise back office recording for business liability needs where only a specific part of a specific call is recorded.

   O Only the sales transaction part of a call is recorded for business compliance needs.

[DS] See changes recommended above.

[DS] I agree.

Also, "without interruption" is not always true - you could possibly use Pause/Resume.

Therefore, I recommend a rewrite as follows:

Use Case 4: Persistent Recording:

Persistent Recording involves a single Recording Session that captures

   one or more Communication Sessions, in series (Fig. 6) or in

   parallel (Fig. 7).

             |--- CS 1 ---|      |--- CS 2 ---|     |--- CS 3 ---|

   RS  |---------------------- Recording Session ---------------------|

                  Figure 6 - Persistent Recording in Series

Applications include financial trading desks......

[DS] See my input above on this subject also.

"Call details

   the recorded media."

   recorded."

[DS] I also don't understand this sentence/statement.

Can we delete this paragraph (or else simplify/consolidate/rewrite)?

   The connection and attributes of media in the Recording Session are

   not dynamically signaled for each Communication Session before it can

   be recorded; however, codec re-negotiation is possible.  Call details

   the recorded media.  There will still need to be a means of

   correlating the recorded media connection/packets to the

   Communication Session, however this may be on a permanent filter-type

   recorded.

"Mute/Unmute"

[DS] My input is to consider to remove Mute/Unmute; also consider to add Start/Stop (but then would need to define them as well).

   level gateways."

[DS] I would agree that it is inconsistent with all other use cases (which do not seem to include solutions).

Although it does add meaning to the use case; so could also keep it but reword it with "Possible solutions include obtaining media by...."

24. Section 6:

[DS] I agree....so we'd want to change to "The following are the requirements for SIP-based Media Recording"

25. REQ-006:

[DS] I agree that REQ-000 is the requirement, and REQ-005/006 are providing more detail about HOW it should be done....and so 5/6 could be removed.

26. REQ-019/020:

[DS] REQ-19/20 are about HOW REQ-017 should be done....and so they could be removed.

27:

[DS] I agree, that is:  "REQ-022:  The mechanism MUST support a means for a SIP UA involved in a CS to cancel and discard the RS during the CS."

28: REQ-023:

[DS] I agree.

John

_______________________________________________

siprec mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/siprec

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Tue, 28 Sep 2010 00:56:48 -0700

From: Dave Smith [mailto:[email-masked]] 
Sent: Monday, September 20, 2010 8:00 AM
To: Elwell, John; [email-masked]; Ken Rehor (krehor)
Subject: RE: [siprec] Comments on draft-ietf-siprec-req-01

Pls see below....I've added my inputs to the first half of John's
comments.

Regards,

Dave

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John

To: [email-masked]

I have read the document again, and I think it needs a certain amount of
work before it can be considered ready for WGLC. There are lots of
issues still open on the tracker - I don't think 01 closes many of
these. I have responded separately on a few of those issues. In addition
I have the following comments:

1. Section 2:

This doesn't make sense before introducing SRS, SRC and SIP later in the
paragraph. I would suggest moving these sentences to the end of the
paragraph, i.e., after "The Session Recording Server is the sink of
recorded media."   

[<krehor> ] Fixed.

2. Section 2:

In the same paragraph:

"This document specifies

In fact SIP is used for control of the recording. I would proposes
rewording as follows:

"This document specifies requirements for using SIP [RFC3261] between a
Session Recording Client and a Session Recording Server to control the
recording of media that has been transmitted in the context of a
communication session."

[DS] OK.  I agree. 

[<krehor> ] Fixed.

3. Section 2:

The RTP media sessions are not SIP-based (although SIP might have been
used to establish the sessions). Also, when talking about individual
media, it is perhaps better to talk about media, rather than sessions. I
propose rewording as:

[DS] OK.  I agree.

[<krehor> ] Fixed.

4. Section 2:

"and allows a session to be played back in a meaningful way, e.g., with
correct synchronization between the media".

[<krehor> ] Fixed.

5. Section 2:

"The

[<krehor> ] Fixed.

6. Section 2:

   text chat session."

It is not clear that we have requirements to cause us to address this,
so can we remove this statement?

[<krehor> ] Fixed.

7. Section 3:

   requests, for example."

I don't think this is helpful - too much detail for a requirements
document.

[DS] I agree to delete this sentence; which is consistent with comments
in Tracker Ticket # 24.

[<krehor> ] Fixed. (note ticket #24 deferred to version 2)

8. Section 3, figure 1:

This is confusing, since it shows the SRC spanning both UAs involved in
the CS, but typically the SRC will be located only at one UA or at an
intermediary. Since figure 1 is not referenced, can it be removed
(covered by the architecture document)?

[DS] We discussed this diagram before and after our debate agreed to
what is shown, which I believe is very helpful in understanding the
terms/definitions presented just before it in the writing.  I recommend
to leave the diagram as is.  I agree that we could however reference it
in the definitions.  

[<krehor> ] Added reference to diagram in text.

9. Section 3:

   Session.."

I think we have had this discussion before, but I don't recall the
outcome. I don't think metadata necessarily needs to describe the RS. I
think it could be defined as "Information that describes recorded media
and the CS to which they relate".

[DS] I agree.

[<krehor> ] Fixed.

10. Section 3:

- This definition does not define Pause/Resume recording, but just
contains separate definitions of Pause and Resume. I think we should
indeed split into two definitions and not both trying to define
"Pause/Resume recording".

- Tracker issue #14 already questions whether "pause" is the right term.
One proposal is "hold". Another would be "suspend" (which I prefer).

[<krehor> ] lots of discussion but I believe the consensus is to keep
"Pause"

- The terms pause and resume are defined as verbs. We should define only
nouns.

- "incoming media stream" - this presumably refers to a media stream
associated with a CS.

[<krehor> ] Reworded. See below.

- "Resume command" - we should not talk about "commands" - sounds like a
UI or API function.

[<krehor> ] removed "command"

- Does "resume" necessarily need to use the same RS as that used prior
to "pause"? 

[<krehor> ] Yes, I believe it does.    That's the difference between
Pause/Resume and Stop/Start.

I think that is a solution matter.

[<krehor> ] Let's discuss...

[<krehor> ] Good point.

"Suspend:  The action of temporarily discontinuing the recording of
media during a CS.

[<krehor> ] Used this definition for "Pause"

Resume: The action of recommencing the recording of media for a CS
following a suspend."

[<krehor> ] Used this definition for "Resume"

[DS]  I prefer Pause/Resume and don't see a reason to change "Pause" to
"Suspend" (it doesn't change anything in the original argument).  

[<krehor> ] I also prefer Pause vs. Suspend since the use here is
consistent with common usage.

11. Section 3:

"from the RC to RS."

Change to:

[DS] I agree.  

[<krehor> ] Fixed.

Also in section 3 change this:

To this:

[<krehor> ] Fixed.

12. Section 5:

This seems to use the terms "call" and "communication session" (or "CS")
at random. Be consistent.

[DS] OK. 

[<krehor> ] Fixed.

13. Section 5:

The style of this is rather mixed, but a lot of it is in note form,
rather than proper sentences. I don't know whether the RFC editor will
accept it like this.

[<krehor> ] TBD in a future version beyond -02.

"One Recording

[DS] I agree, and think that the first sentence should include the term
"is created" also.  

[<krehor> ] Fixed.

and then:

"A Communication Session

   may or may not have a Recording Session (record only specific
calls)."

These can be interpreted as being in conflict. The first suggests we
always start an RS, whereas the second says we do so only when a call is
to be recorded.

"Start a Recording Session when a Communication Session to be recorded
is established."

[<krehor> ] Fixed.

[<krehor> ] Yes. Pause/Resume assumes a Recording Session has already
Started.  Maybe this should be "Initiate" vs. "Start"

This would seem to be covered by used case 2, so can it be deleted from
use case 3?

[<krehor> ] Not the same... Use Case 2 covers RS initiation at CS
initiation.  Use Case 3 is RS initiation at some point during a CS.

However both examples starting with "Applications include..." are
redundant with other examples so I removed them.

- Saying it is a single RTP stream might not work for multiple media.
Perhaps "single RTP stream per medium"?

[<krehor> ] Good point, but the reworded part isn't quite right either. 

- The first sentence is contradicted by the second sentence, which says
that there can be further offer/answer exchanges. - Furthermore, this is
getting too far into solution.

[<krehor> ] Let's discuss...

Yes, but only as long as there are media to record. It will clearly stop
recording when not receiving any media.

[<krehor> ] Should it record silence during those periods?

"Call details

   the recorded media."

[<krehor> ] Let's discuss...

   recorded."

This presumably is referring to correlation, but I don't understand it,
particular the expression "filter-type basis".

[<krehor> ] Let's discuss...

"Mute/Unmute"

[<krehor> ] Yes, Mute/Unmute refers to zeroing the media. Should add
blank/unblank for video... or defer to v2.

Reworded to remove Mute/Unmute.

   level gateways."

[<krehor> ] Agreed... removed.

24. Section 6:

[<krehor> ] Changed to "SIP-based Media Recording" to be consistent with
the document title.

Also changed other reference to "Session Recording Protocol" under
"Security Considerations"

Reworded sentence:  "Session recording has substantial security
implications, for the

       SIP UA's being recorded, the SRC, and the SRS."

25. REQ-006:

Do we really need this? We have decided it is the policy server that
decides, and of course the policy server can be collocated with the SRS.
This doesn't necessarily mean the SRS establishes the session. The
policy server instructs the SRC to record and the SRC establishes the
session. In fact, I could also question why we need REQ-005. Both
REQ-005 and REQ-006 seem to be solution.

[<krehor> ] Generally agree but let's discuss...

26. REQ-019/020:

This is calling for two separate mechanisms. I am sure we must have
discussed this in the past, but do we really want to make
interoperability harder by having two mechanisms?

[<krehor> ] Let's discuss...

27:

Do we need to make it clear what decides on this? Is it a UA involved in
a CS (as for REQ-023)?

[<krehor> ] Good question... I was assuming -022 meant via some sort of
application (not the same as -023).

28: REQ-023:

We should make it clear this is a SIP UA involved in the CS (the SRC and
SRS are also SIP UAs). Proposed words:

"REQ-023 The mechanism MUST support a means for a SIP UA involved in a
CS to request, prior to the start of recording, that the CS not be
recorded".

[<krehor> ] Fixed.

John

 

siprec mailing list

[email-masked]

 

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.