Subject: [siprec] Comments on req-03

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Oct 2010 18:54:41 +0200

Some further comments. If any of these prove controversial we will need to open tickets.

1. Section 2:
"The recorded sessions can be any RTP media sessions including ..."
Previously we have talked about recorded media, not recorded sessions. Also "RTP media sessions" isn't quite correct, since from a SIP and SDP perspective the entire set of media for a call comprise a session - each medium is not regarded as a session in its own right. Therefore:
NEW:
"The recorded media can be any RTP media including ..."

2. Section 2:
"..including voice,
   video, and text (as defined by [RFC4103])"
We should also include DTMF:
"including voice,
   video, DTMF and text (as defined by [RFC4103])"

3. Section 3, figure 1:
I have commented before that the figure does not convey a very realistic picture. It suggests that the SRC enclose the entire CS, including both UAs. Typically the SRC will be located at one particular point (at A, at B or somewhere between the two). I would prefer to see something like the following:

  +-------------+                                            +-----------+
  |             |     +-----------+  Communication Session   |           |
  |     A       |<----+-----------+------------------------->|   B       |
  |             |     |  Session  |                          |           |
  +-------------+     | Recording |                          +-----------+
                      |   Client  |
                      +-----------+
                             |
                             | Recording
                             | Session
                             |
                             v
                      +------------+
                      |   Session  |
                      |  Recording |
                      |   Server   |
                      +------------+

4. Section 3:
"Pause and Resume during a Communication Session: "
Delete these words - just the definitions of pause and resume are sufficient.

4. Section 4:
"Example Deployment Architectures"
I am not sure why this is just an example architecture - it is our only architecture. Also the section is not really related to deployment (it doesn't show physical servers etc., only the logical entities SRC and SRS). Finally, it is the job of the architecture document to show architecture, so do we really need section 4 at all? Can we delete section 4?

5. Section 5:
"Record every call"
NEW:
"Record every CS"

6. REQ-007:
"REQ-007 The mechanism MUST support the recording of IVR sessions."
We need to be more explicit about what we mean by IVR sessions. If we just mean DTMF, it should be covered by the next requirement, so REQ-007 can be deleted. If it means something else, we need to say so.

7. REQ-012:
"REQ-012 The mechanism MUST support the ability for an SRC to
   deliver mixed audio streams ..."
Do we really need to limit REQ-012 (and similarly REQ-012bis) to the mixing of audio? Video can be mixed, in its own way (e.g., by arranging a number of sources into a larger frame).

8. REQ-019 and REQ-020
We already had consensus to delete these.

9. Section 6
Earlier in the document we specifically mention audio, video and IM, yet I don't find any requirements stating what media types we are required to be able to record (except for REQ-012/REQ-012bis, but they are specifically on mixing.

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Sun, 17 Oct 2010 11:05:02 +0200

My comments for the below

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, October 14, 2010 6:55 PM
To: [email-masked]
Subject: [siprec] Comments on req-03

1. Section 2:

[LP]  Agree

2. Section 2:
"..including voice,

[LP] Agree

3. Section 3, figure 1:

[LP] The diagram now will look very B2BUA oriented. The original intent was just to show not location of SRC but was it CS and RS. 

4. Section 3:

[LP] Agree

4. Section 4:
[LP] Agree

5. Section 5:
"Record every call"
NEW:
"Record every CS"
[LP] Agree

6. REQ-007:
"REQ-007 The mechanism MUST support the recording of IVR sessions."
We need to be more explicit about what we mean by IVR sessions. If we just mean DTMF, it should be covered by the next requirement, so REQ-007 can be deleted. If it means something else, we need to say so.
[LP] The original intent was that we should also support recording of the voice of IVR session (where customer is talking to machine) and not only DTMF part. It is important part of self-service analytics. It can be used for dispute resolution and emotion detection for example. It probably will not have influence on the protocol itself

7. REQ-012:
"REQ-012 The mechanism MUST support the ability for an SRC to
   deliver mixed audio streams ..."
Do we really need to limit REQ-012 (and similarly REQ-012bis) to the mixing of audio? Video can be mixed, in its own way (e.g., by arranging a number of sources into a larger frame).
[LP] Agree, we should not limit it

8. REQ-019 and REQ-020

9. Section 6

John (as individual)

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Oct 2010 10:05:31 +0200

> We need to be more explicit about what we mean by IVR 
> sessions. If we just mean DTMF, it should be covered by the 
> next requirement, so REQ-007 can be deleted. If it means 
> something else, we need to say so.
> [LP] The original intent was that we should also support 
> recording of the voice of IVR session (where customer is 
> talking to machine) and not only DTMF part. It is important 
> part of self-service analytics. It can be used for dispute 
> resolution and emotion detection for example. It probably 
> will not have influence on the protocol itself
[JRE] So you think there is some value in keeping REQ-007 as is, without being more explicit as to what it means? If others agree, I don't really object, although it probably means nothing more than the need to be able to record both audio and DTMF, which should be covered elsewhere.

John

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 18 Oct 2010 22:51:59 -0700

[DS] inputs below.

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Monday, October 18, 2010 1:06 AM
To: Leon Portman; [email-masked]
Subject: Re: [siprec] Comments on req-03

> will not have influence on the protocol itself
[JRE] So you think there is some value in keeping REQ-007 as is, without
being more explicit as to what it means? If others agree, I don't really
object, although it probably means nothing more than the need to be able
to record both audio and DTMF, which should be covered elsewhere.
[DS] I agree that there is a need to record everything heard/said in an
IVR interaction (i.e., what customer said, DTMF tones, what IVR script
said, etc.).  I assumed that recording IVR sessions are somewhat
different from recording agent sessions (e.g., may require an
integration to a different box/application to collect metadata) and so
might require a separate req't and more in the arch/design/protocol in
order to be supported.  But maybe that is irrelevant.  REQ-001 talks
about "...ability to record all CSs in their entirety.", and the defn of
CS is (defn:  A session created between two or more SIP User Agents
(UAs) ), so as long as an IVR session can be considered a CS then we are
probably covered by REQ-001 and so don't require REQ-007.  But I'd like
others to my conclusion.
But I still don't quite understand the need for REQ-007bis1 and bis2.  

John

-------------------------------------------------------------------------------------------------------------------
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: "Elwell, John" <[email-masked]>
Date: Tue, 19 Oct 2010 10:18:27 +0200

Dave,

> But I still don't quite understand the need for REQ-007bis1 
[JRE] I think we need a statement about DTMF (or more generally, a statement on media types to be supported, DTMF being one). I agree we don't need both 007bis1 and 007bis2.

John

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 28 Oct 2010 01:12:58 -0700

Updated in draft-ietf-siprec-req-04.

Ken

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Elwell, John
> Sent: Tuesday, October 19, 2010 1:18 AM
> To: Dave Smith; Leon Portman; [email-masked]
> [JRE] I think we need a statement about DTMF (or more generally, a
statement
> on media types to be supported, DTMF being one). I agree we don't need
both
> 007bis1 and 007bis2.