Subject: [siprec] WGLC comments on siprec-req-06

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Jan 2011 17:25:20 +0100

My WGLC comments (as individual). 

I think the document is almost ready to go, but needs the following minor points and nits fixing.

Minor:
1. Abstract:
"This document specifies requirements for
   extensions to SIP that will manage delivery of RTP media from an end-
   point that originates media (or that has access to it) to a recording
   device."
The words "end-point" and "originates" are not really suitable where the SRC is at a B2BUA. I would suggest rewording as:
"This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device."

2. Section 3:
"An SRS is a logical
   function that typically archives media for extended durations of time
   and provides interfaces for search and retrieval of the archived
   media."
I don't think the SRS provides such interfaces. Such interfaces would be available, but I don't think they should be considered part of the SRS. Also I don't think the word "typically" is necessary. I would suggest a reword as follows:
"An SRS is a logical function that archives media for extended periods. Other functions can provide interfaces for searching and retrieving archived media."

3. Section 3:
"An SRS is typically implemented as a multi-port device that
   is capable of receiving media from several sources simultaneously."
The word "several" seems to suggest a small number. I would suggest we change "several" to "multiple".

4. Section 3:
"An SRS is typically also the sink of the recorded session metadata."
Delete the word "typically" - I don't think we have any other model in mind.

5. Section 3:
"Communication Session (CS): A session created between two or more SIP
   User Agents (UAs) that is the target for recording."
Change "target for recording" to "subject of recording".

6. Section 4:
As a general comment, there are several incomplete sentences, e.g.:
- Use case 3 "One or more Recording Sessions per Communication Session:"
 (no verb)
- Use case 9 "Record a call that is associated with another call." (no subject)
- Use case 12 "Recording and real-time analytics of trading floor interactions
   (including video and instant messaging)." (no verb)

7. Section 4, use case 4:
"or in
   parallel (Fig. 7)"
The figure number is wrong (should be figure 6), but I suggest we delete these words. The subject of parallel CSs is introduced in the paragraph immediately preceding figure 6, so we don't need to mention it here.

8. Section 4, use case 4:
"A Recording Session records continuously without interruption.
   Silent periods must be reproduced upon playback (e.g. by recording
   the silent period, by not recording the silent periods but marking
   them as metadata for a player to utilize, etc.)"
I think the point we are trying to make with use case 4 is that the RS exists even when there is no CS - so it is more than just a silent period. I would reword as:
"A Recording Session records continuously without interruption. Periods when there is no CS in progress must be reproduced upon playback (e.g. by recording silence during such periods or by not recording such periods but marking them by means of metadata for utilization on playback, etc.)."

9. Section 4, use case 4:
"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.  CS details
   and CS metadata will still be signaled, and can be correlated to the
   recorded media.  There will still need to be a means of correlating
   the recorded media connection/packets to the Communication Session."
I think the whole paragraph is getting into solution and could be omitted.

10. Section 4, use case 5:
"One solution is to not record a caller
   speaking their credit card information."
Why is not recording just one solution to "not capturing" (in the first sentence of the paragraph)? It seems to me it is the ONLY solution. Clearly you could record and then prevent playback, but then you have captured the information.

11. Section 4, use case 7:
"Many agents and enterprise workers are not located on company
   premises."
To make it clearer:
"Many agents and enterprise workers whose calls are to be recorded are not located on company
   premises."

12. Section 4, use case 8:
"Internal calls inside or between branches must be recorded."
Why do only internal calls need recording? Should it say:
"Internal calls inside or between branches must be recorded, as well as calls involving the central office and external calls."

13. Section 4, use case 8:
"Global banks with multiple branches up to thousands of small sites.
   o Only phones and network infrastructure in branches, no recording
   services.
   o Internal calls inside or between branches must be recorded.
   o Centralized recording system in data centers together with
   telephony infrastructure (e.g.  PBX)."
The three bullets don't seem to form a coherent set. The first and last describe the topology and the second describes recording needs.

14. Section 4, use case 9:
"Record a call that is associated with another call."
Apart from the fact this is not a complete sentence (see earlier comment), I think the point we should be making is that both calls are recorded, together with some means of associating them.

15. Section 4, use case 10:
"o The Communication Session must be terminated (or suitable
   notification) in the event of a recording failure."
Change "or suitable notification" to "or suitable notification given to parties".

16. Section 4, use case 11:
"In trading floors environments, in order to save resources, it may be
   preferable to mix multiple concurrent calls (Communication Sessions)
   on different handsets/speakers on the same turret into single
   recording session."
It is unclear what resources this really saves, unless you also mix the media from the several CSs into a single media stream on the RS. Some clarification would be useful.

17. Section 4, use case 12:
"Recorder must support real-time media processing, such as speech
   analytics."
I think this should say "It must be possible for a recorder to support...".

Nits:
18. Expand the following acronyms on first use: DTMF, ASR.

19. Section 4, use case 4:
"in sequence (Fig. 6)"
This should be figure 5.

20. Section 4, use case 4:
"The length of a Persistent Recording Sessions "
Change "Sessions" to "Session".

21. Section 4, use case 7:
"i.e. insurance agents,
   brokers, physicians."
Change "i.e." to "e.g.".

22. Section 4, use case 11:
"Media is synchronized"
Change "is" to "are".

23. Section 4, use case 12:
"(stopping interaction or alert)"
Change "alert" to "alerting".

John

---

From: Leon Portman <[email-masked]>
Date: Tue, 18 Jan 2011 09:10:06 +0200

John, Hello

Thank you for the very thorough comments
Please see below

Ken, what do you think?

Thanks

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Monday, January 17, 2011 6:25 PM
To: [email-masked]
Subject: [siprec] WGLC comments on siprec-req-06

Minor:
1. Abstract:
[leon] Ok

2. Section 3:
"An SRS is a logical
[leon] Ok

3. Section 3:
[leon] Ok

4. Section 3:
"An SRS is typically also the sink of the recorded session metadata."
Delete the word "typically" - I don't think we have any other model in mind.
[leon] ok, however there can be other sinks as well for the metadata (if we talking about dedicated metadata subscription session)

5. Section 3:
"Communication Session (CS): A session created between two or more SIP
   User Agents (UAs) that is the target for recording."
Change "target for recording" to "subject of recording".
[leon] Ok, however recording target is a common term for some SRS vendors (not us however)

6. Section 4:

[leon] Ok, how about following:
Use case 3: One or more Recording Sessions performed per Communication Session
Use case 9: Cradle to grave recording: Record a call that is associated with another call
Use Case 12: execution of Recording and real-time analytics of trading floor interactions
   (including video and instant messaging)

[leon] Ok

[Leon] we have actually two use cases here, silence during CS and between CSs. Between CSs is easy, because SRS will know that there is no call in progress. However if there is a silence during the call and no silence suppression in the original media stream, SRS will not know if it just loose packets or SRS should report silence periods either via silence suppression or metadata

[leon] what we tried to demonstrate here is the challenge of correlation between CS and metadata. I am ok to remove it, however it is just example

[leon] it depends on the business scenario. For some use cases playback is allowed for specific persons in the organization.

[Leon] Ok

[Leon] Yes

[leon] how about swapping 2 and 3?

[leon] yes, correct

[leon] ok

[leon] it saves recording channels by mixing multiple CSs into the same recording channel

[leon] Ok

Nits:
[Leon] Ok

[leon] ok

[leon] Ok

[leon] ok

[leon] ok

[leon] ok

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

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Tue, 25 Jan 2011 00:36:34 -0800

Draft of -07 attached, including changes noted below and in Leon's email
of 24 Jan.

Ken

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Elwell, John
> Sent: Monday, January 17, 2011 8:25 AM
> To: [email-masked]
> I think the document is almost ready to go, but needs the following
minor
> points and nits fixing.
> The words "end-point" and "originates" are not really suitable where
the
> SRC is at a B2BUA. I would suggest rewording as:
> "This document specifies requirements for extensions to SIP that will
> manage delivery of RTP media to a recording device."

[<krehor> ] done.
 
> I don't think the SRS provides such interfaces. Such interfaces would
be
> available, but I don't think they should be considered part of the
SRS.
> Also I don't think the word "typically" is necessary. I would suggest
a
> reword as follows:
> "An SRS is a logical function that archives media for extended
periods.
> Other functions can provide interfaces for searching and retrieving
> archived media."

[<krehor> ] I think this is too implementation-specific. I suggest we
just remove the sentences regarding archiving and retrieval of media.

> change "several" to "multiple".

[<krehor> ] done.
 
> Delete the word "typically" - I don't think we have any other model in

[<krehor> ] done.
 
> Change "target for recording" to "subject of recording".

[<krehor> ] done.
 
> - Use case 3 "One or more Recording Sessions per Communication
Session:"
[<krehor> ] This was actually supposed to be a description of the
diagram, but it doesn't read that way so I've fixed it.

> - Use case 9 "Record a call that is associated with another call." (no
[<krehor> ] cleaned up entire description of use case.

>    (including video and instant messaging)." (no verb)

[<krehor> ] cleaned up entire description of use case.
 
> The figure number is wrong (should be figure 6), but I suggest we
delete
> these words. The subject of parallel CSs is introduced in the
paragraph
> immediately preceding figure 6, so we don't need to mention it here.
[<krehor> ] done.

> I think the point we are trying to make with use case 4 is that the RS
> exists even when there is no CS - so it is more than just a silent
period.
> I would reword as:
Periods
> when there is no CS in progress must be reproduced upon playback (e.g.
by
> recording silence during such periods or by not recording such periods
but
> marking them by means of metadata for utilization on playback, etc.)."
> 

[<krehor> ] done.
 
> Why is not recording just one solution to "not capturing" (in the
first
> sentence of the paragraph)? It seems to me it is the ONLY solution.
Clearly
> you could record and then prevent playback, but then you have captured
the
> information.

[<krehor> ] PCI compliance is just one example of an application that
may require 
protecting customer information. Not capturing that information is one
way to protect it. Other possible solutions include encryption or
post-call redaction.
 
> "Many agents and enterprise workers whose calls are to be recorded are
not
> located on company

[<krehor> ] Done.
 
> "Internal calls inside or between branches must be recorded, as well
as
> calls involving the central office and external calls."
> 
> The three bullets don't seem to form a coherent set. The first and
last
> describe the topology and the second describes recording needs.

[<krehor> ] Reworded:

Enterprises such as banks, insurance agencies, and retail stores may
have many locations, 
    	possibly up to thousands of small sites. Frequently only phones
and network infrastructure are
    	installed in branches, without local recording services. In
cases where  calls inside or between 
    	branches must be recorded, a centralized recording system in
data centers together with
   	telephony infrastructure (e.g. PBX) me deployed.
 
> Apart from the fact this is not a complete sentence (see earlier
comment),
> I think the point we should be making is that both calls are recorded,
> together with some means of associating them.

[<krehor> ] reworded.

> Change "or suitable notification" to "or suitable notification given
to
> parties".

[<krehor> ] done.

> It is unclear what resources this really saves, unless you also mix
the
> media from the several CSs into a single media stream on the RS. Some
> clarification would be useful.

[<krehor> ] clarified that the resources are storage and recording
system resources.
 
> I think this should say "It must be possible for a recorder to
support...".

[<krehor> ] done.
 
> 18. Expand the following acronyms on first use: DTMF, ASR.

[<krehor> ] removed acronyms (unnecessary detail)
 
> 19. Section 4, use case 4:

[<krehor> ] fixed as part of earlier change (above)
 
> Change "Sessions" to "Session".

[<krehor> ] done.
 
> 21. Section 4, use case 7:

[<krehor> ] done.
 
> 22. Section 4, use case 11:

[<krehor> ] done.
 
> Change "alert" to "alerting".

[<krehor> ] done.

================================================================

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 25 Jan 2011 10:07:41 +0100

Looks good to me and ready to go.

Regards
Andy 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ken Rehor (krehor)
> Sent: 25 January 2011 08:37
> To: Elwell, John; [email-masked]
> Subject: Re: [siprec] WGLC comments on siprec-req-06
> 
> > The word "several" seems to suggest a small number. I would 
> suggest we
> > change "several" to "multiple".
> 
> [<krehor> ] done.
>  
> > 4. Section 3:
> > Delete the word "typically" - I don't think we have any 
> other model in
> > mind.
> 
> [<krehor> ] done.
>  
> > 5. Section 3:
> > - Use case 9 "Record a call that is associated with another 
> call." (no
> > subject)