Subject: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt

From: Henry Lum <[email-masked]>
Date: Thu, 4 Jul 2013 04:32:31 +0000

Hi - this is an initial draft about recording IVR sessions. I want to see if there is interest in working out more details about IVR recording

I'd be happy to present for the meeting if there is time for this.

Thanks
Henry

________________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, July 04, 2013 12:28 AM
To: Henry Lum
Subject: New Version Notification for draft-lum-siprec-vxml-00.txt

A new version of I-D, draft-lum-siprec-vxml-00.txt
has been successfully submitted by Henry Lum and posted to the
IETF repository.

Filename:        draft-lum-siprec-vxml
Revision:        00
Title:           Recording VoiceXML sessions with SIPREC
Creation date:   2013-07-04
Group:           Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-lum-siprec-vxml-00.txt
Status:          http://datatracker.ietf.org/doc/draft-lum-siprec-vxml
Htmlized:        http://tools.ietf.org/html/draft-lum-siprec-vxml-00

Abstract:
   This document addresses the use case of recording Interactive Voice
   Response (IVR) VoiceXML applications using the SIPREC protocol.  This
   document also provides a potential solution for capturing additional
   information about the call flow within the VoiceXML application from
   a recording perspective.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Jul 2013 14:50:34 -0400

> Hi - this is an initial draft about recording IVR sessions. I want to see if there is interest in working out more details about IVR recording

I'm interested in hearing what you have in mind.
At one level these should already be covered. You must want to capture 
some additional information. Is it that you want to record the VXML?

	Thanks,
	Paul

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

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Sun, 7 Jul 2013 19:04:57 +0000

Yes, there are many use cases for recording the IVR portion of a call.

FYI I worked out a lot of design ideas several years ago when we were
still working on VoiceXML 3.0 in the W3C. I'll dig up my proposal and
forward to the group.

Ken

On 7/7/13 11:50 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> Hi - this is an initial draft about recording IVR sessions. I want to
>>see if there is interest in working out more details about IVR recording
>
>> URL:            
>>http://www.ietf.org/internet-drafts/draft-lum-siprec-vxml-00.txt

---

From: Henry Lum <[email-masked]>
Date: Mon, 8 Jul 2013 20:00:17 +0000

Beyond the additional controls available in the VXML session itself, one use case for additional metadata collection is important waypoints and data in the VXML session. While it's possible to simply log all forms and fields entered but that can be way too much detail for a complex VXML application. Instead, it would be useful on the recording side to know whether the session have arrived at a certain point in the application and whether certain pieces of data has been collected. I mentioned the use of <exit> namelist which is a standard mechanism in RFC5552 for passing parameters at the end of the session.

Regards,
Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: July-07-13 2:51 PM
To: [email-masked]
Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt

	Thanks,
	Paul

---

From: "Yanqiang (Michael)" <[email-masked]>
Date: Wed, 17 Jul 2013 07:42:14 +0000

Hi Henry,

	I went through your draft draft-lum-siprec-vxml-00 and rfc5552 (haven't read the details before) and got several questions. Can you help to figure them out? :)

1. 	 Definition of vxml application(IVR), vxml media server, vxml interpreter?
The 1.2 section says that "The IVR in this case can be a SIPREC-aware SIP UA and relies on a separate SRC to provide recording capabilities". Does it mean that SIPREC-aware SIP UA runs the vxml application(IVR application), and the vxml media server acted as the SRC to provide recording capabilities? Rfc5552 has defined the vxml media server(vxml interpreter as well?) and vxml application which offers the IVR (as a service). Rfc5552 says vxml application can be deployed on an application server, a separated one or the vxml media server directly. Do we need to make a definition in this draft to conform to 5552?

2. 	The communication mechanism in IVR recording. 
The draft talks about how the vxml media server or IVR itself respond the actions like start/stop/pause/resume as the SRC via 5552. If I didn't make a wrong understanding, here means IVR can communicate with vxml media server via 5552, and vxml media server can be the SRC via current SIPREC mechanism. Maybe a simple draw can help to understand it better.

3.	 How to support tuning IVR performance via essential metadata ?
As the Use Case 6 says in 6341, tuning IVR performance is one of the case about IVR recording. But obviously, it seems to be a bit complicated to record the entire IVR trace. This draft's REQ6 says, " Define additional metadata to provide detailed information about the application executed." But what kind of waypoints or nodes of IVR would be used for tuning? The <exit> namelist is good but it is enough for IVR tuning?
 
Thanks,
Michael

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henry Lum
> Sent: Tuesday, July 09, 2013 4:00 AM
> To: Paul Kyzivat; [email-masked]
> Beyond the additional controls available in the VXML session itself, one use
> case for additional metadata collection is important waypoints and data in the
> VXML session. While it's possible to simply log all forms and fields entered but
> that can be way too much detail for a complex VXML application. Instead, it
> would be useful on the recording side to know whether the session have
> arrived at a certain point in the application and whether certain pieces of data
> has been collected. I mentioned the use of <exit> namelist which is a standard
> mechanism in RFC5552 for passing parameters at the end of the session.
> 
> Regards,
> Henry
> 
> > Hi - this is an initial draft about recording IVR sessions. I want to see if there is
> interest in working out more details about IVR recording
>

---

From: Henry Lum <[email-masked]>
Date: Wed, 17 Jul 2013 15:52:10 +0000

Hi Michael - please see inline.

Henry

-----Original Message-----
From: Yanqiang (Michael) [mailto:[email-masked]] 
Sent: July-17-13 3:42 AM
To: Henry Lum; Paul Kyzivat; [email-masked]
Subject: RE: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt

Hi Henry,

[hlum] I think there are options in terms of implementation of the VXML media server as a SIP UA. It can either be a SIPREC-aware UA that relies on a separate SRC to perform the recording, the VXML media server can be the SRC itself and provide recording directly. The VXML application itself does not perform recording so this draft is not making changes to this definition; perhaps we can just refer to 5552 for the definition.

[hlum] Agreed - a drawing would help to explain the difference in implementation types for the media server and how the mechanics can work. Let me start with slides first and then translate that into the next draft revision.

[hlum] IVR tuning can mean a lot of things, it can be either tuning your speech grammar to catch more phrases that users actually speak, tuning the application to help users complete their transactions, or even tuning input-to-prompt latencies. In general I think the more information available the better but we don't want to turn SIPREC into a logging or debug facility. That's why I think we can provide some suggestions for the IVR to provide some useful but not excessive information in addition to the audio itself to address the tuning use case.

Thanks,
Michael

> Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jul 2013 17:52:49 -0400

Henry,

I read this draft. It does seem natural that siprec work well with IVRs. 
Some questions for you:

Recording indication & pause/resume:

This is trivial when the IVR acts as an SRC. But when there is a 
separate SRC, we have defined the UA control over recording to be 
strictly advisory. So the IVR could *request* that recording stop. Then 
it must simply wait to see if it gets a signal back that recording has 
stopped, which may or may not be coming. Is that good enough for the IVR 
application needs? How long will it wait? And of course the indication 
that recording has stopped could be a lie. Is that OK?

Metadata:

When the SRC is separate from the IVR, how would the SRC obtain this 
additional information that is to be included in the metadata?

Coordination of SRCs:

(You don't have a section on this.) If the IVR acts as its own SRC, do 
we care if there is another SRC? If so, do we expect them to coordinate 
so that they use the same identifiers? Some cases where this may be the 
case:

- a call center recording all calls coming in, and then using an
   IVR for part of the call handling.

- a PBX that handles some incoming calls via an IVR and then eventually
   transfers them to a phone hanging off the pbx.

We made the *provision* in the metadata for multiple SRCs to coordinate, 
but left the coordination out of scope. Does adding explict support here 
require putting that back in scope?

	Thanks,
	Paul

---

From: Henry Lum <[email-masked]>
Date: Thu, 18 Jul 2013 21:24:09 +0000

Hi Paul, please see inline.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: July-17-13 5:53 PM
To: Henry Lum
Cc: [email-masked]
Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt

Henry,

application needs? 

[hlum] Since request to pause is advisory, the same problem exists for a contact center agent needing to manually pause the recording before taking sensitive information. The only feedback for the agent to proceed with taking the sensitive information is by observing the recording indicator that it is currently paused. For an IVR application this can be harder since the protocol does not define how long must an SRC provide a change in recording indication, so it will have to be up to the IVR to determine how long to wait before proceeding to a form or field taking sensitive information. Perhaps when something times out or the request is not honoured, the interpreter can throw an event so you can get out of the form without taking the information. 

How long will it wait? And of course the indication 
that recording has stopped could be a lie. Is that OK?

[hlum] I guess an IVR can't do anything about an SRC lying about the recording indication. If the deployment needs the IVR to be absolutely sure about this, then the IVR must have to become the SRC itself or at least own the SRC policy.

Metadata:

[hlum] That's a good point since there is no such communication for transporting additional metadata for SIPREC-aware UA. I wonder if it makes sense to define additional communication to tunnel metadata to SRC and send over to SRS. In this case perhaps the IVR will have to provide the metadata to SRS through other mechanisms.

Coordination of SRCs:

[hlum] It's likely we want some form of coordination, since it typical that an agent gets involved with IVR applications. If the contact center is served by a different SRC and the SRC for the IVR, then it makes sense to provide some form of coordination so that the SRS can figure out which portion of a customer call is related to IVR and which portion is related to agents. The latest protocol revision added the statement that the SRS allows such coordination, but I don't see how we can mandate all SRCs coordinate if the SRCs happen to record the same CS. 

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jul 2013 19:43:06 -0400

Henry,

Thanks for the clarifications here. I don't have any answers. But these 
sorts of considerations should probably make it into the draft in some form.

	Thanks,
	Paul

---

From: "Yanqiang (Michael)" <[email-masked]>
Date: Fri, 19 Jul 2013 08:27:19 +0000

Hi All,

Please check inline.

> [hlum] Since request to pause is advisory, the same problem exists for a contact
> center agent needing to manually pause the recording before taking sensitive
> information. The only feedback for the agent to proceed with taking the
> sensitive information is by observing the recording indicator that it is currently
> paused. For an IVR application this can be harder since the protocol does not
> define how long must an SRC provide a change in recording indication, so it will
> have to be up to the IVR to determine how long to wait before proceeding to a
> form or field taking sensitive information. Perhaps when something times out
> or the request is not honoured, the interpreter can throw an event so you can
> get out of the form without taking the information.
> 
> [hlum] I guess an IVR can't do anything about an SRC lying about the recording
> indication. If the deployment needs the IVR to be absolutely sure about this,
> then the IVR must have to become the SRC itself or at least own the SRC policy.
> 
Maybe a better way is to discuss them separately, 
1) IVR is the SIPREC-aware SIP UA, and need a separate SRC to record its session
2) IVR is the SRC itself with certain media ability? 
Especially if IVR is #1 case, do we need to make a rule in SIPREC for the mechanism about how SRC receives or answers with IVR(SIP UA)? The 5552 might be one way to do it. If I don't make a mistake, the CSTA standard might also support the recording indication & pause/resume between IVR/agent and the SRC in #1 case (might be a media server or ACD, the feedback mechanism would be some events notification). We can check http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-269.pdf for details on section 26.1.9/26.2.9.

> [hlum] That's a good point since there is no such communication for transporting
> additional metadata for SIPREC-aware UA. I wonder if it makes sense to define
> additional communication to tunnel metadata to SRC and send over to SRS. In
> this case perhaps the IVR will have to provide the metadata to SRS through
> other mechanisms.
> 
I *think* current draft tried to use 5552 mechanism (maybe not enough) to transport certain information from IVR (also as vxml application) to SRC. There might be a good way or others better as what you said at last. What I more care about is what will be those additional metadata? Will it make the metadata standard become a logging one, after we accept cases and requirements like IVR recording for tuning and conference recording for training. No matter how, I agree SIPREC need to define the format and content of additional metadata for the cases above if we would accept, which could be used for implementing SRC/SRS which follow SIPREC.

> [hlum] It's likely we want some form of coordination, since it typical that an
> agent gets involved with IVR applications. If the contact center is served by a
> different SRC and the SRC for the IVR, then it makes sense to provide some form
> of coordination so that the SRS can figure out which portion of a customer call is
> related to IVR and which portion is related to agents. The latest protocol
> revision added the statement that the SRS allows such coordination, but I don't
> see how we can mandate all SRCs coordinate if the SRCs happen to record the
> same CS.
> 
For a call center handling with incoming calls would have agents and IVR together working in general time. The full recording requirement in this case would ask to record media from different SRCs, and might record the same CS (the call transferred from IVR to agent, and session based on customer side). I notice draft-ietf-siprec-metadata-12 section 6.10 talks about the ID for multiple SRCs coordination, and draft-ietf-siprec-protocol-10 section 7.3.1 says in multiple SRCs case the endpoint only knows that the call is being recorded via recording indication. So I still don't get the answer or what need to be added if we need to coordinate the SRCs for IVR and other UAs.

Thanks,
Michael

---

From: "Yanqiang (Michael)" <[email-masked]>
Date: Fri, 19 Jul 2013 08:37:41 +0000

Hi Henry,

	Please check inline.

> 	I went through your draft draft-lum-siprec-vxml-00 and rfc5552 (haven't
> read the details before) and got several questions. Can you help to figure them
> out? :)
> 
> The 1.2 section says that "The IVR in this case can be a SIPREC-aware SIP UA and
> relies on a separate SRC to provide recording capabilities". Does it mean that
> SIPREC-aware SIP UA runs the vxml application(IVR application), and the vxml
> media server acted as the SRC to provide recording capabilities? Rfc5552 has
> defined the vxml media server(vxml interpreter as well?) and vxml application
> which offers the IVR (as a service). Rfc5552 says vxml application can be
> deployed on an application server, a separated one or the vxml media server
> directly. Do we need to make a definition in this draft to conform to 5552?
> 
> [hlum] I think there are options in terms of implementation of the VXML media
> server as a SIP UA. It can either be a SIPREC-aware UA that relies on a separate
> SRC to perform the recording, the VXML media server can be the SRC itself and
> provide recording directly. The VXML application itself does not perform
> recording so this draft is not making changes to this definition; perhaps we can
> just refer to 5552 for the definition.
> 
Agreed. It will be appreciated we could mention these definitions when discussing this draft on 87th.

> The draft talks about how the vxml media server or IVR itself respond the
> actions like start/stop/pause/resume as the SRC via 5552. If I didn't make a
> wrong understanding, here means IVR can communicate with vxml media server
> via 5552, and vxml media server can be the SRC via current SIPREC mechanism.
> Maybe a simple draw can help to understand it better.
> 
> [hlum] Agreed - a drawing would help to explain the difference in
> implementation types for the media server and how the mechanics can work.
> Let me start with slides first and then translate that into the next draft revision.
> 
Definitely. Looking forward to your slide.

> As the Use Case 6 says in 6341, tuning IVR performance is one of the case about
> IVR recording. But obviously, it seems to be a bit complicated to record the
> entire IVR trace. This draft's REQ6 says, " Define additional metadata to provide
> detailed information about the application executed." But what kind of
> waypoints or nodes of IVR would be used for tuning? The <exit> namelist is
> good but it is enough for IVR tuning?
> 
> [hlum] IVR tuning can mean a lot of things, it can be either tuning your speech
> grammar to catch more phrases that users actually speak, tuning the application
> to help users complete their transactions, or even tuning input-to-prompt
> latencies. In general I think the more information available the better but we
> don't want to turn SIPREC into a logging or debug facility. That's why I think we
> can provide some suggestions for the IVR to provide some useful but not
> excessive information in addition to the audio itself to address the tuning use
> case.
> 
I don't want the SIPREC become a logging standard, especially for metadata part. And my opinion is we should discuss the IVR recording cases carefully to find what it need in minimum. 
Similarly, I'd like you to give some help to the conference recording draft, which also faces the issue about additional metadata choosing.

Thanks,
Michael

---

From: Henry Lum <[email-masked]>
Date: Thu, 25 Jul 2013 14:57:39 +0000

Henry

-----Original Message-----
From: Yanqiang (Michael) [mailto:[email-masked]] 
Sent: July-19-13 4:27 AM
To: Henry Lum; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt

Hi All,

Please check inline.

Maybe a better way is to discuss them separately, 
1) IVR is the SIPREC-aware SIP UA, and need a separate SRC to record its session
2) IVR is the SRC itself with certain media ability? 
[hlum] It looks like these solution do diverge a little bit so it may be worthwhile to talk about them separately

[hlum] Since we are focused on SIPREC and SIP only, I think 5552 is the only specification that talks about integration with VXML with SIP. I am not sure how to tie that with CSTA interface as we are only focusing on SIP only.

[hlum] Perhaps we should find out what pieces of information we need for the different types of use cases. This can help us specify the metadata format.

[hlum] We added that statement in the protocol draft to allow the SRC to define some sort of common identifier to link a call session when the SRCs are sending to the same SRS, and your contact center example is one of the use cases. I don't know how we can standardize on the coordination of the between SRCs as they can be independent systems to different SRSs; all we can say is that the SRCs can have a way to coordinate among themselves.

Thanks,
Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 12:22:02 -0400

Henry,

I'd like to hear more of your thinking regarding using 5552 (or some 
other standard) for communicating extra information between the IVR and 
the SRC.

Are you imagining something like section 1.1.1 of 5552, where the AS is 
also acting as an SRC? (That seems hard, since the AS doesn't have 
access to the media.)

ISTM that for our purposes we would consider the AS+VXML server as an IVR.

	Thanks,
	Paul

---

From: Henry Lum <[email-masked]>
Date: Sat, 27 Jul 2013 03:13:52 +0000

I am thinking that the AS can be the SRC as it can be a contact center
that executes VXML page for IVR portion. The AS as a SIP B2BUA will have
to use another media server to access the media path to record.

It's true that we can also see AS+VXML as the IVR itself, or the SIP User
Agent is the SRC; in this case the interface to AS as per RFC5552 doesn't
really apply here and there are no standard application data to be passed
outside of the AS.

Regards,
Henry

On 2013-07-25 12:22 PM, "Paul Kyzivat" <[email-masked]> wrote:

>> [hlum] It looks like these solution do diverge a little bit so it may
>>be worthwhile to talk about them separately
>>
>> Especially if IVR is #1 case, do we need to make a rule in SIPREC for
>>the mechanism about how SRC receives or answers with IVR(SIP UA)? The
>>5552 might be one way to do it. If I don't make a mistake, the CSTA
>>standard might also support the recording indication & pause/resume
>>between IVR/agent and the SRC in #1 case (might be a media server or
>>ACD, the feedback mechanism would be some events notification). We can
>>check 
>>http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-269.pdf
>> for details on section 26.1.9/26.2.9.
>>
>> [hlum] Since we are focused on SIPREC and SIP only, I think 5552 is the
>>only specification that talks about integration with VXML with SIP. I am
>>not sure how to tie that with CSTA interface as we are only focusing on
>>SIP only.
>>
>>>
>>> Metadata:
>>>
>> I *think* current draft tried to use 5552 mechanism (maybe not enough)
>>to transport certain information from IVR (also as vxml application) to
>>SRC. There might be a good way or others better as what you said at
>>last. What I more care about is what will be those additional metadata?
>>Will it make the metadata standard become a logging one, after we accept
>>cases and requirements like IVR recording for tuning and conference
>>recording for training. No matter how, I agree SIPREC need to define the
>>format and content of additional metadata for the cases above if we
>>would accept, which could be used for implementing SRC/SRS which follow
>>SIPREC.
>>
>> [hlum] Perhaps we should find out what pieces of information we need
>>for the different types of use cases. This can help us specify the
>>metadata format.
>>
>>> Coordination of SRCs:
>>>
>> For a call center handling with incoming calls would have agents and
>>IVR together working in general time. The full recording requirement in
>>this case would ask to record media from different SRCs, and might
>>record the same CS (the call transferred from IVR to agent, and session
>>based on customer side). I notice draft-ietf-siprec-metadata-12 section
>>6.10 talks about the ID for multiple SRCs coordination, and
>>draft-ietf-siprec-protocol-10 section 7.3.1 says in multiple SRCs case
>>the endpoint only knows that the call is being recorded via recording
>>indication. So I still don't get the answer or what need to be added if
>>we need to coordinate the SRCs for IVR and other UAs.
>>
>> [hlum] We added that statement in the protocol draft to allow the SRC
>>to define some sort of common identifier to link a call session when the
>>SRCs are sending to the same SRS, and your contact center example is one
>>of the use cases. I don't know how we can standardize on the
>>coordination of the between SRCs as they can be independent systems to
>>different SRSs; all we can say is that the SRCs can have a way to
>>coordinate among themselves.
>>
>> Thanks,
>> Michael
>>
>