Subject: [siprec] A model of recording metadata

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Jul 2010 16:53:43 -0400

I'd like to propose a data model for metadata as viewed by the SRS.
(This is the result of discussions between Ram, Partha, and I.)

IMO we need a model such as this as part of the architecture.
Establishing such a model will help to nail down the implications of 
many of the requirements that have now been gathered. The model is 
conceptual - there is no requirement for the SRS to instantiate this in 
any literal way. And in fact for now there will be no way to verify if 
the SRS collects *anything* about the sessions it is recording. At some 
time in the future I expect that there will probably be work on some 
sort of query interface against the recording metadata. At that point it 
should become possible to verify that this information has indeed been 
captured.

For now, the purpose of this model is as a basis for evaluating 
mechanisms for transporting metadata from the SRC to the SRS: those 
mechanisms must provide the means to convey the information that the SRS 
MAY then use to populate an instance of this model for each RS.

This should probably have been submitted as a draft, but we didn't 
manage to get to that in time. So I'm taking the easy way out of sending 
it as a message to the list. (If it seems appropriate, we can probably 
have a document ready to submit with submissions are opened up again on 
the first day of the upcoming meeting.)

This model is a straw horse - I have no allusions that it is "right". I 
expect people to want to make at least tweaks, and perhaps major revisions.

I'm using UML notation here.

        +-------------------------------+
        | Recording Session Group       |
        +-------------------------------+
                 | 0..*
                 |
                 | 1..*
        +-------------------------------+
        | Recording Session (RS)        |
        +-------------------------------+
                 | 1..*
                 |
                 | 0..*
        +-------------------------------+
        |   Communication Session (CS)  |
        +-------------------------------+
                 | 1
                 |
                 | 0..*
        +-------------------------------+
        |   Recorded Media Stream       |
        +-------------------------------+
        |  Type (audio/video/...)       |
        |  Recorded Encoding            |
        |  Recorded Bits                |
        +-------------------------------+
                 | 1
                 |
                 | 1..*
        +-------------------------------+
        |   Received Media Stream       |
        +-------------------------------+
        |  Start Time                   |
        |  End Time                     |
        |  Codec                        |
        |  Media Stream Reference       |
        +-------------------------------+
                 | 1..*
                 |
                 | 1..*
        +-------------------------------+
        |   Participant                 |
        +-------------------------------+
        |  AoR                          |
        |  Name                         |
        +-------------------------------+

    The model described above provides:

    o  One or more CS per RS, due to private side conversations e.t.c
    o  Multiple RS per CS, due to redundancy or whatever
    o  An optional grouping of multiple RS that are related in some way
    o  Information that describes the participants of Communication
       Session(s)
    o  Information to associate multiple media streams sent for a given
       Communication Session over separate Recording Sessions to the SRS.
    o  Information to associate multiple media streams for a given
       Communication Session over a single Recording Session to the SRS.
    o  Information to associate participants and their associated media
       streams.
    o  Information about media type(mixed or separate), time for each
       media stream.
    o  Received Media Streams will have one participant unless mixed
       before being sent to RS, in which case they can have several.  A
       Participant can of course supply multiple Received Media Streams.
    o  There could be one Received Media Stream per Recorded Media Stream
       if mixing is done before recording, or several if a separate
       unmixed stream per participant is supplied.  Or there could be
       multiple per source (with disjoint time intervals) due to codec
       changes.
    o  Communication Session can have multiple Recorded Media Streams for
       various reasons.  Distinct media might have theiir own.  (Or not -
       maybe audio/video together.)  Independent sources might be
       recorded separately.

The "Media Stream Reference" attribute of a Received Media Stream is a 
place holder. In an implemented mechanism this would be a reference to a 
particular m-line in SDP from the SRC to the SRS, identifying a 
particular media stream. This is clearly essential to the SRS so that it 
might record the stream, and get properties of it. But it isn't anything 
interesting once the recording is complete. So its transient metadata.

The Recording Session Group has been added to model correlation between 
multiple RSs, but I think that concept requires a lot more work. Its far 
from clear to me how the need to associate one RS with another can be 
denoted. And if two RSs to be correlated are captured by different SRSs, 
they might end up in different databases, so even referencing them can 
be problematic. So consider this to be simply a place holder for further 
work.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 7 Jul 2010 15:18:03 +0300

Paul, Hi

Very good start.

Generic comment:

This data model represents CS and RS more like "CDR" like approach where we have list of sessions, times, participants etc. However we also need "event based" model as well, where CS events will be reported: call started, participant put on hold, retrieved, ringing, agent busy/not busy etc.

Additional comment: why do we need codec info? We have it in SDP.

Please see additional comments below.

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, July 06, 2010 11:54 PM
To: [email-masked]
Subject: [siprec] A model of recording metadata

[LeonP] Recording Session should not be root of this model as well, because we need to use it also for the case of SRS initiated recording, where only CS are reported from SRC to SRC.

[LeonP] We should introduce additional information element like "Recording Initiator" and "RecordingRequestId" that will hold recording reason "OnDemand, Persistant, Selective" and identity of who initiated the recording request.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jul 2010 10:09:05 -0400

Leon,

Thanks for the feedback. Comments/questions inline.

After a bit more discussion I'll try to create a revised model.

	Thanks,
	Paul

Leon Portman wrote:
> Paul, Hi
> 
> Very good start.
> 
> Generic comment:
> 
> This data model represents CS and RS more like "CDR" like approach where we have list of sessions, times, participants etc.

Yup.

> However we also need "event based" model as well, where CS events will be reported: call started, participant put on hold, retrieved, ringing, agent busy/not busy etc.

I don't have any first hand experience with what is "needed" here.
This model is based on what I have observed from following the 
discussion on this list.

I am entirely open to adding additional stuff that is needed.
My goal was to elicit such requests.

BUT, I think there are limits to what is "knowable".
I'm not certain, but it sounds like some of the things you would like to 
capture are records of "feature invocations". But we typically don't 
signal "features" in sip, so often the awareness that a particular 
feature is in use is limited to a single participant.

(E.g. the participant that pushes the HOLD button knows he is invoking 
the "hold" feature. But unless the SRC is embedded in that device, all 
it will know is that the participant made a new offer with "a=sendonly". 
And "a=sendonly" is used for many things, not just hold.

Also, there is no taxonomy for "features" in sip, so it would be hard to 
capture them in a standard way, even in cases where they are known.

But capturing more of the information that does travel in the signaling 
is certainly possible. For instance, the information about participants 
in a Received Media Stream could include whether the participant is 
sendrecv/sendonly/recvonly/inactive.

> Additional comment: why do we need codec info? We have it in SDP.

My intent here was to record what the SRS is expected to capture as part 
of the recorded session. I'm not concerned with whether it comes "for 
free" as part of the SDP, or requires something new to be added as part 
of the SRC->SRS messaging.

> I'm using UML notation here.

I did not intend the model to say anything about who/how the recording 
session was initiated. But maybe it should.

At this point, the model has no unique "root".

Its quite possible that the model should also represent the "store" or 
DB that contains the collection of recordings that one or more SRSs collect.

> [LeonP] We should introduce additional information element like "Recording Initiator" and "RecordingRequestId" that will hold recording reason "OnDemand, Persistant, Selective" and identity of who…

Sure, stuff like that sounds good.

How would you identify the "Recording Initiator"? As a sip URI?

I don't "in principle" have any problem with RecordingRequestID. But it 
will take a bit of effort to define it. Who assigns it, and what format 
does it take? How is uniqueness guaranteed?

I thought about that a bit. I'm thinking that maybe each Recording 
Session should have a URL. Eventually that will probably be an HTTP URL 
that could be used to query the session. But that is out of scope for 
now. It could be modeled simply as a URL, to be elaborated later.

(Using a URL makes it possible to cross reference two related recording 
sessions, even if they are managed by different servers.)

---

From: "Morgan, Dave" <[email-masked]>
Date: Wed, 7 Jul 2010 11:02:48 -0400

As a heavy user of call recording equipment in the highly-regulated
financial industry I have been following this working group with
interest.  

I prefer having a data model for the recording metadata rather than have
the data stuffed in the UUI field, which is what I've seen so far in the
industry.  In addition, the data model could contain valuable
information about what was recorded, when, and why.  I see the data
model as an important factor in searching for and retrieving calls.  If
the data model is adopted across vendors it would provide a single
non-proprietary mechanism for third-party vendors to retrieve calls that
meet certain criteria, such as recorded in a specific location, serviced
by a specific agent, or made by a specific customer.  An application
such as speech analytics or a first call resolution application would
benefit from a standardized recording data model.

As Paul points out, the Recording Session Group, which contains the list
of recording sessions associated with a call is a very important
requirement.  For example, a customer calls in, speaks to one agent at
one site and is transferred to another agent at another site creating
two call segments.  Now suppose that agent puts the customer on hold and
calls their supervisor creating another call segment.  Then the agent
conferences in the supervisor to the second call segment.  We need to
associate all three call segments with one call.  Hence Leon's comment
about a Recording Session Group which has the structure of a CDR, with
call segments that are event based.  I also  agree that the recording
session group needs an ID, or a URL, as Paul pointed out. 
 
As far as the features that need to be passed, in practice there is a
trade-off between what is stored in the CTI solution and what is
retained in call recording.  This is particularly important when the
call has first been treated by an IVR system (potentially a network or
hosted IVR) which creates an initial CTI record for the call (these
scenarios where not well addressed in siprec-req).  Ideally the IVR
system would then insert a CTI identifier in the UUI.  In the TDM world,
most people do DNIS-based routing and use the DNIS as the identifier to
associate the call with the CTI identifier.  But when using SIP trunking
and performing call recording off the enterprise's SBC, one way the SBC
can associate the call with the existing CTI record is to pull the CTI
identifier out of the UUI field.  It would pass this to the SRS to
retrieve the information from the CTI record to determine if the call
should be recorded.  And finally the SRS can pass the recording session
group ID to the CTI system to populate it in the CTI record so that the
call can be located from the CTI system.

Without a CTI system, more data will need to be populated in the
recording data model.  In addition to the items Paul has listed, in
practice many people use an IVR system to authenticate a caller and for
other call treatment prior to the call being passed to an agent and
being recorded.  The key call variables are often the originating and
destination phone numbers, customer identifier, and the customer's
authentication status.  When these variables are extracted, they could
be used in a decision as to whether to record the call, or in retrieving
the call at a later date.

Paul says "the purpose of this model is as a basis for evaluating
mechanisms for transporting metadata from the SRC to the SRS."  But I
believe it is more important that any system that provides call
treatment prior to the call being sent to an agent would use the
recording data model to insert metadata into the call prior to it being
recorded.  This is the dilemma that enterprises face today, vendors that
provide upstream call treatment don't have a standard way of inserting
metadata into the SIP session that can be retrieved by the call
recording solution.   This is especially true for those that are trying
to have a hosted IVR system deliver the calls to the enterprise using
SIP trunking and perform selective call recording off the SBC at their
perimeter.  

Dave

------------------------------------------------------------------------

David P. Morgan, PhD
Vice President
Enterprise Infrastructure
Fidelity Investments Technology Group
Phone: (617) 563-2178
Fax:     (617) 385-2122
Mailing: 82 Devonshire Street, MZ Z3B
Boston, MA 02109-3614
NEW Office: 200 WTC, 164 Northern Ave, Boston 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Wednesday, July 07, 2010 10:09 AM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] A model of recording metadata

Leon,

	Thanks,
	Paul

Leon Portman wrote:
> Paul, Hi
> 
> Very good start.
> 
> Generic comment:
> 
> This data model represents CS and RS more like "CDR" like approach
where we have list of sessions, times, participants etc.

Yup.

> However we also need "event based" model as well, where CS events will
be reported: call started, participant put on hold, retrieved, ringing,
agent busy/not busy etc.

> [LeonP] Recording Session should not be root of this model as well,
because we need to use it also for the case of SRS initiated recording,
where only CS are reported from SRC to SRC.

Its quite possible that the model should also represent the "store" or 
DB that contains the collection of recordings that one or more SRSs
collect.

> [LeonP] We should introduce additional information element like
"Recording Initiator" and "RecordingRequestId" that will hold recording
reason "OnDemand, Persistant, Selective" and identity of who initiated
the recording request.

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 7 Jul 2010 08:32:19 -0700

Hi Paul,

I have a slight modification to the model since recorded media stream
should be directly related to the recording session. I took out the
attributes from the objects for simplicity and I think what you already
have is quite reasonable.

 +-------------------------------+
 | Recording Session Group       |
 +-------------------------------+
          | 0..*
          |
          | 1..*
 +-------------------------------+
+-------------------------------+          
 | Recording Session (RS)        |-----------|   Recorded Media Stream
|          
 +-------------------------------+ 1
0..*+-------------------------------+          
          | 1..*                                            | 1
          |                                                 |  
          | 0..*                                            | 1..* 
 +-------------------------------+
+-------------------------------+
 |   Communication Session (CS)  |-----------| Communication Media
Stream    |
 +-------------------------------+ 1
0..*+-------------------------------+
                                                            | 1..*
                                                            |
                                                            | 1..*
 
                                             |   Participant
|

> of the SRC->SRS messaging.

[[hlum]] It is important to emphasize that not all metadata described in
this model may be provided by a single entity in the SRC. For example,
if you use the SRC B2BUA model, metadata may be provided by different
application servers such as CTI within the SRC. The metadata model will
need to be able to have a way to correlate the different parts of the
model so that the SRS can combine the metadata from different sources to
get the full picture.

> > sort of query interface against the recording metadata. At that
point
> it
> > This model is a straw horse - I have no allusions that it is
"right".
> I
> >     o  Communication Session can have multiple Recorded Media
Streams
> for
> > particular media stream. This is clearly essential to the SRS so
that
> it

-------------------------------------------------------------------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jul 2010 12:13:22 -0400

Henry,

I think your picture was garbled, at least as viewed from my mail app.
I gather you had some boxes side by side, but they've been folded into 
incomprehensibility.

So I won't attempt to comment on what you were trying to say.

	Sorry,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 7 Jul 2010 09:17:47 -0700

Oops I must have extra whitespace that wraps around. Let me try again...

+-------------------------------+
| Recording Session Group       |
+-------------------------------+
         | 0..*
         |
         | 1..*
+-------------------------------+
+----------------------------+
| Recording Session (RS)        |-----------|   Recorded Media Stream
|
+-------------------------------+ 1
0..*+----------------------------+
         | 1..*                                            | 1
         |                                                 |  
         | 0..*                                            | 1..* 
+-------------------------------+
+----------------------------+
|   Communication Session (CS)  |-----------| Communication Media Stream
|
+-------------------------------+ 1
0..*+----------------------------+
                                                           | 1..*
                                                           |
                                                           | 1..*
 
+----------------------------+
                                            |   Participant
|
 
+----------------------------+

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, July 07, 2010 12:13 PM
> To: Henry Lum
> Cc: Leon Portman; [email-masked]
> > [[hlum]] It is important to emphasize that not all metadata
described
> in
> > model so that the SRS can combine the metadata from different
sources
> to
> >>> conceptual - there is no requirement for the SRS to instantiate
> this
> >> in
> >>> any literal way. And in fact for now there will be no way to
verify
> >> if
> >>> mechanisms must provide the means to convey the information that
> the
> >> SRS
> >>> have a document ready to submit with submissions are opened up
> again
> >> on
> >>>     o  An optional grouping of multiple RS that are related in
some
> >> way
> >> I don't "in principle" have any problem with RecordingRequestID.
But
> >>>        Communication Session over separate Recording Sessions to
> the
> >> SRS.
> >>>        Communication Session over a single Recording Session to
the
> >> SRS.
> >>>        before being sent to RS, in which case they can have
> several.
> >> A
> >>>        various reasons.  Distinct media might have theiir own.
(Or
> >> not -
> >>> The "Media Stream Reference" attribute of a Received Media Stream
> is
> >> a
> >>> place holder. In an implemented mechanism this would be a
reference
> >> to a
> >>> multiple RSs, but I think that concept requires a lot more work.
> Its
> >> far
---------------------------------------------------------------------
> ----------------------------------------------
> > 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: "Henry Lum" <[email-masked]>
Date: Wed, 7 Jul 2010 09:28:14 -0700

I think it wrapped again; Outlook keeps fooling me that it looks good.
Sorry for the spam.

+----------------------------+
| Recording Session Group    |
+----------------------------+
         | 0..*
         |
         | 1..*
+----------------------------+        +----------------------------+
| Recording Session (RS)     |--------|   Recorded Media Stream    |
+----------------------------+ 1  0..*+----------------------------+
         | 1..*                                      | 1
         |                                           |  
         | 0..*                                      | 1..* 
+----------------------------+        +----------------------------+
| Communication Session (CS) |--------| Communication Media Stream |
+----------------------------+ 1  0..*+----------------------------+
                                                     | 1..*
                                                     |
                                                     | 1..*
                                      +----------------------------+
                                      |   Participant              |
                                      +----------------------------+

> My intent here was to record what the SRS is expected to capture as 
> part of the recorded session. I'm not concerned with whether it comes 
> "for free" as part of the SDP, or requires something new to be added 
> as part

> > >>> From: [email-masked] [mailto:[email-masked]]
On
> > >> Behalf Of Paul Kyzivat
> > >>> Establishing such a model will help to nail down the
implications
> > of
> > >>> the SRS collects *anything* about the sessions it is recording.
> At
> > >> some
> > >>> should become possible to verify that this information has
indeed
> > >> been
> > >> Its quite possible that the model should also represent the
> "store"
> > or
> > >> Session should have a URL. Eventually that will probably be an
> HTTP
> > > URL
> > >>>     o  Information to associate multiple media streams sent for
a
> > >> given
> > >>>     o  Information to associate participants and their
associated
> > >> media
> > >>>     o  There could be one Received Media Stream per Recorded
> Media
> > >> Stream
> > >>>        unmixed stream per participant is supplied.  Or there
> could
> > > be
> > >>> from clear to me how the need to associate one RS with another
> can
> > > be
> > >>> denoted. And if two RSs to be correlated are captured by
> different
> > >> SRSs,
> > >>> they might end up in different databases, so even referencing
> them
> > >> can
-----------------------------------------------------------------------
> --------------------------------------------
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jul 2010 13:05:32 -0400

Dave,

I'm really happy to be seeing comments from people in a position to know 
what is needed. The job here is to come up with the mechanisms to record 
that which needs recording. The model is a way to concisely describe 
what needs recording.

Morgan, Dave wrote:
> industry. 

A goal of mine here is to distinguish the data that is collected from 
the manner in which it is conveyed. The UUI field is just a transport 
mechanism, as are new SIP headers and xml bodies in sip messages.

> In addition, the data model could contain valuable
> information about what was recorded, when, and why. 

The "why" part is going to be hard.
Does the SRC know why? If not, who does?
What are the possible values for "why"?

> I see the data
> model as an important factor in searching for and retrieving calls.

For the moment, any access to the data after it has been recorded is out 
of scope for this WG, though clearly it is important. That is going to 
make it difficult to call out stuff to be added for the purpose of later 
retrieval. I guess we either need to expand the scope, or just rely on 
you users to call out what you need included.

> If the data model is adopted across vendors it would provide a single
> associate all three call segments with one call. 

I think there may be a difference of opinion here.
IMO all of what you describe above *could* be captured in a single RS.
If it were, then there would be no need for grouping multiple RSs together.

OTOH, capturing all that in a single RS requires that a single SRC have 
visibility to all those pieces. If it does not, then there will be 
multiple RSs that need to be linked up.

If there is a need to link up multiple RSs, then there is the issue of 
who/what knows enough to associate all those pieces.

> Hence Leon's comment
> system would then insert a CTI identifier in the UUI. 

Can that be translated into more neutral, or sip-centric, terms rather 
than TDM-centric terms?

I think you are saying that the IVR, which terminated the incoming call 
for a period of time, should insert some sort of reference to data it 
collected, into the the new call when the IVR transfers the call for 
handling.

> In the TDM world,

Here I presume the SBC you reference is acting as an SRC. Right?

> identifier out of the UUI field. 

IIUC, there are no meaningful standards for how UUI information is 
formatted. That stands in the way of the SRC extracting anything 
specific from it unless it is customized for each deployment.

I fear that sort of thing is going to be a problem here.

> It would pass this to the SRS to
> should be recorded. 

Why would that decision not be made sooner, so the SRS need not be 
involved, or given the data for the decision? Couldn't the IVR make the 
decision? Or the SRC?

> And finally the SRS can pass the recording session

Such interactions between the CTI system and the SRS will require more 
standards.

An alternative is for the CTI and Recording systems to pretty much do 
their own things independently, but arrange for them to have some unique 
identifying information in common that can be used by a higher level 
system, that knows how to interact with both, to correlate the data in each.

> mechanisms for transporting metadata from the SRC to the SRS." 

I guess I should have said "My intended purpose for this model ...".

> But I
> recorded. 

There has been ongoing tension here regarding where the decision to 
record or not record should be made.

I think we made a decision that the metadata we have been talking about 
is data that is to be captured with a recording. If there is *other* 
data that is to be used to make a decision to record, that is out of 
scope of the current effort. IIRC that was focused on data to be used to 
decide whether to establish a RS when there was none. We wanted to 
restrict the metadata to that which could be transmitted to the SRS from 
the SRC.

But I may be wrong about that. I'm sure somebody will correct me if I am.

I don't have a problem with adding data to the model, as long as its in 
the context of an RS. If the SRS uses that to decide not to actually 
record, that is fine with me.

> This is the dilemma that enterprises face today, vendors that

This seems like a new problem that has not been discussed in this group 
before. Has it?

If its important (and it sounds like it is) then it should be captured 
as part of the requirements list.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jul 2010 14:42:24 -0400

Henry,

Ahh - this one I can read!!!

> I think it wrapped again; Outlook keeps fooling me that it looks good.

Yeah, I'm ok with that.

(But its a lot easier to draw diagrams that are only one box wide. :-)

> model so that the SRS can combine the metadata from different sources to

While what you say may well be true, I don't know if its important to 
this effort. Its only relevant if we have need to decompose the SRC. As 
long as we can view it as a single black box then we don't care about 
this. Can you explain why we would need to decompose the SRC for this work?

OTOH, I think it is important to recognize that not all the metadata 
described will be delivered from the SRC to the SRS at once. Rather it 
will be "dribbled" to it in a series of transactions over the lifetime 
of the RS.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 7 Jul 2010 13:16:34 -0700

described
sources
> this. Can you explain why we would need to decompose the SRC for this

 [[hlum]] I don't think the model needs to explain how the SRC is
decomposed, but rather to recognize that the different components of the
metadata model can be provided from multiple sources within the SRC. As
REQ-021 pointed out, the metadata is transport agnostic, it is possible
to deliver different parts of the metadata through CTI and SIP
separately. In order to deliver metadata outside of the recording
session (on CTI), this is implicitly saying that metadata is coming from
a different source in SRC than the recording session itself.

> will be "dribbled" to it in a series of transactions over the lifetime

[[hlum]] Agreed, and as I mentioned above the events can be delivered
outside of the RS as well.

> >>>>>> manage to get to that in time. So I'm taking the easy way out
of
> >>>>> sending
> >>>>>> expect people to want to make at least tweaks, and perhaps
major
> >>>>> revisions.
> >>>>> that could be used to query the session. But that is out of
scope
> >>>>>>     o  Information about media type(mixed or separate), time
for
> >>>> each
> >>>>>>        multiple per source (with disjoint time intervals) due
to
> >>>>> codec
> >>>>>> be problematic. So consider this to be simply a place holder
for
> >>>>> further
--------------------------------------------------------------------
> -
> >>> refraining from acting, on any information contained in this
e-mail
> --
> contain

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jul 2010 17:10:59 -0400

Henry - inline

> metadata model can be provided from multiple sources within the SRC. As

Does it matter? Isn't it sufficient to say that the SRC, as a sip UA, 
can communicate this information to its peer UA?

> separately.

A problem with this is *addressing*. As long as we view this as 
communication between two UAs we can count on SIP addressing to get all 
the info to the same place. Especially so if its all in-dialog. But even 
out-of-dialog is ok if the dialog yields a contact for the SRS that has 
gruu properties.

If you start mixing protocols, then it will be necessary to do added 
stuff to ensure proper addressing to get the stuff to the right place. 
This is not impossible, but its certainly added complexity.

> In order to deliver metadata outside of the recording

No point in commenting further here as long as above stuff is still 
under discussion.

But as much as possible it would be good to try to nail down the 
metadata model without concern for these issues of delivery.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 7 Jul 2010 15:55:12 -0700

Please see inline.

> Sent: Wednesday, July 07, 2010 5:11 PM
> To: Henry Lum
> Cc: [email-masked]; Leon Portman
> >> this effort. Its only relevant if we have need to decompose the
SRC.
> > As
> >> this. Can you explain why we would need to decompose the SRC for
> this
> >> work?
> >

[[hlum]] It matters if the metadata model requires that all the relevant
information about a single CS needs to be described in a single blob of
metadata. I want to make sure that different components of SRC is not
required to consolidate the metadata about a CS in order to send over to
the peer. Let's say the SRC establishes 2 recording sessions for a
single CS, each RS can provide part of the metadata about each recorded
media stream. We should not need to consolidate the metadata from both
RS to describe the relationship to the single CS. As long as the
metadata has some way of referencing the CS, it should be possible for
the SRS to consolidate the metadata without the need for the SRC to do
so.

> This is not impossible, but its certainly added complexity.

[[hlum]] I am just using CTI to illustrate the issue where metadata
about a CS can be generated from different sources in SRC. As long as
CTI can find a way to address to the SRS (which is out of the scope of
this WG), I think it should be the responsibility of the SRS to
consolidate the metadata.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jul 2010 19:39:02 -0400

I trimmed this down to the pertinent points and commented further:

Henry Lum wrote:

> the peer.

My comment about the metadata being dribbled from the SRC to SRS was 
about this point.

My assumption is that the SRC (or some part of it) learns this stuff a 
little bit at a time, and communicates it to the SRS, probably via some 
in-dialog mechanism using the RS dialog. Its the SRS, not the SRC, that 
is responsible for assembling that stuff into a coherent data structure.

The stuff that is dribbled needn't all be encoded the same way either.
Some of it will most certainly be extracted from SDP or various sip 
headers. Other parts might be body parts in sip messages, encoded in a 
way defined as part of this work.

> Let's say the SRC establishes 2 recording sessions for a

While I suppose the SRC could do that, why would it?
If its got an RS for this CS, and has more metadata to report, why would 
it not just reuse the one it has?

Might what you are talking about be otherwise described as two different 
SRCs involved in (parts of) the same CS, each establishing their own RS?

> We should not need to consolidate the metadata from both

If the same CS is reported in two different RSs, it may be tricky to 
recognize that they are the same. I suppose callid could be sufficient 
to recognize the identity. But that only works if a CS always has a 
single callid. And that depends on whether you consider a call that is 
transfered to be one CS or two.

The main reason I can see for an SRC to establish two different RS for 
the same CS is for redundancy, where they are to different SRSs. And 
then the data should be redundant, so there should be no need to 
correlate or merge the data, except possibly after a failure.

> consolidate the metadata.

A lot of "if"s there. I think what you say is true, but it all sounds 
out of scope for this WG to consider.

For purposes of this WG the metadata model need only be about the data 
that we are going to provide machinery to manage. If there is "other" 
data that the SRS learns "by magic", we can provide extensibility hooks 
to allow it to be grafted on. And if there are other, unspecified, 
mechanisms by which stuff defined by the WG might reach the SRS, that is 
ok too.

But I think we go out on a limb if we try to define stuff to go into the 
model without defining at least *one* was to deliver that stuff to the 
SRS. IMO that should be out of scope.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 8 Jul 2010 08:39:37 -0700

Hi Paul,

Please see inline.

Henry

> is responsible for assembling that stuff into a coherent data

[[hlum]] Okay, we are in agreement here. I am also thinking whether we
should allow some pieces of metadata to be transported over PUBLISH or a
subscription, or do we always have to require SRC to establish an RS
dialog to transport metadata? Of course this has to depend on what kind
of information we want SRC to provide, and some types of CS events that
Leon mentioned seemed more natural to deliver over a
publish/subscription.

> way defined as part of this work.

[[hlum]] Agreed.

> SRCs involved in (parts of) the same CS, each establishing their own

[[hlum]] I am looking at a decomposed B2BUA SRC where there is an
application server and a media server. For all CS that routes through
the SRC, the app server may establish an RS to the SRS to provide some
basic metadata about the CS and let the SRS to decide based on the
business rules whether or not to record the call. If the call should be
recorded, then the SRC would involve the media server to relay media,
and that's when the SRC can establish separate RS that provides the
actual recorded media.
> correlate or merge the data, except possibly after a failure.

[[hlum]] Some solutions would establish a separate RS for each
participant in the CS, so I wouldn't think this is purely for the
purpose of redundancy. This means SRS would need to consolidate data
outside of a failure, and we could use something like a common call-id
to consolidate the RS as a group. I believe this is what the Recording
Session group in the metadata diagram is about.

> mechanisms by which stuff defined by the WG might reach the SRS, that
 
[[hlum]] We should definitely leave the non-SIP stuff out of scope of
this WG. I just want to make sure the metadata is extensible so that we
are not stuck with defining every metadata we can think of right now,
and any additional metadata that can be transported over other types of
transport can relate to the CS.

> >>> session (on CTI), this is implicitly saying that metadata is
coming
> >> from
> >>>> described will be delivered from the SRC to the SRS at once.
> Rather
> >> it

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Jul 2010 18:16:10 +0200

> consolidate the metadata.
[JRE] I would prefer to say that the SRS might obtain metadata from multiple sources. One source is the SRC, and that metadata is delivered by some to-be-selected SIP mechanism. Other sources might be CTI, for example, but that is outside the scope of SIPREC in my opinion, and I am not even sure that we need to define the content and format of metadata obtained only by non-SIP means.

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Jul 2010 18:23:05 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 08 July 2010 00:39
> To: Henry Lum
> >>> decomposed, but rather to recognize that the different 
> components of
> >> the
> >>> metadata model can be provided from multiple sources 
> within the SRC.
> >> As
> >>
[JRE] I tend to agree with Paul.

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Jul 2010 18:27:03 +0200

Dave,

Thanks for your useful input. I think others have already responded to most points, but one question. If I read between the lines correctly, you are suggesting the need to convey some metadata between SIP entities involved in the Communication Session, e.g., between an IVR and an entity where the SRC is located. Is that correct?

John

> [mailto:[email-masked]] On Behalf Of Morgan, Dave
> Sent: 07 July 2010 16:03
> To: Paul Kyzivat; Leon Portman
> Cc: [email-masked]; Morgan, Dave
> implications of
> > sort of query interface against the recording metadata. At
> that point
> it
> indeed been
> > This model is a straw horse - I have no allusions that it
> is "right".
> I
> "store" or
> >     o  Communication Session can have multiple Recorded
> Media Streams
> for
> reference to
> > particular media stream. This is clearly essential to the
> SRS so that
> it

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jul 2010 14:20:24 -0400

> Leon mentioned seemed more natural to deliver over a

While my personal mental model is that this stuff is all transferred 
within the RS dialog, I am content to leave that an open question until 
we have nailed down exactly what needs to be conveyed.

> and that's when the SRC can establish separate RS that provides the

AFAIK, the RS is a SIP session with associated media sessions.
Why would this case establish one sip session, but with no media,
and then a separate sip session with the media is to be included?

If an RS is being established but initially there is no decision about 
whether to include the media, the session could be established without 
any media streams. Later, when there is a decision to include the media, 
there can just be a reINVITE to add the media streams that are to be 
recorded. That doesn't require two RSs.

> participant in the CS,

Yes, I guess that could be so. In that case, there is a fair chance that 
those RSs don't know about each other either

> so I wouldn't think this is purely for the

If you had case above - both caller and callee have policy to record the 
call, so each establishes an RS. But suppose there is an SBC between 
them. In that case, they won't have same callid. So it will be very 
difficult to recognize that these RSs are related. (Especially so if its 
two different SRSs, each with its own database.)

OTOH, in this case is it even important to link these RSs?

> transport can relate to the CS.

As long as its just a conceptual model, with no means to verify its 
implemented, its totally extensible. :-)

It will start to get nailed down if/when there is effort to define 
queries on it. If we then end up with something like an XML schema, some 
care will be required to allow optional ANYs at strategic places.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 8 Jul 2010 11:55:59 -0700

> recorded. That doesn't require two RSs.

[[hlum]] I don't think the mechanism should prevent SRC from using a
separate RS to deliver the recorded media if it wants to do so. If you
want to handle failover of SRC by establishing a new RS to the SRS, then
we should be allowed to do so rather than using reINVITE. I am also
thinking of cases where the media server may be establishing the RS
itself so that it can provide additional metadata about relevant media
events when the caller is interacting with an IVR.
 
> OTOH, in this case is it even important to link these RSs?

[[hlum]] In this case, you are probably looking at SRSs that are not
related to each other. Let's say caller's PBX is recording and at the
same time the callee's contact center is recording as well, and I don't
think we would care about these SRSs to correlate the RSes together even
though the RSes are all referring to the same CS. 

What I am looking at is a more localized case where one SRS is receiving
media from multiple RSes, like when the contact center is decomposing
the caller and callee media streams as separate RSes. It would be the
job of the contact center SRS to consolidate the RSes of the caller and
callee as a single CS (or customer interaction). Using a common call-id
may still be difficult if the SRC generates the call-id for the RSes in
a distributed fashion; perhaps we may need to create some form of group
identifier (like a conference id).

> >>> CTI can find a way to address to the SRS (which is out of the
scope
> >> mechanisms by which stuff defined by the WG might reach the SRS,
> that
> >> is
> >> ok too.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jul 2010 15:15:25 -0400

inline

> though the RSes are all referring to the same CS. 

OK. That is what I was thinking.

> identifier (like a conference id).

Hmm. Are you supposing that there is a special "contact center SRS" that 
has different functionality from some other RS? Or is it just that we 
have a contact center that has incorporated a "generic SRS"?

ISTM it would be better if contact centers didn't require a "special" 
SRS. (But I don't know if that is realistic or not.)

A key distinction to make here is whether the SRS is *obligated* (by the 
specifications we make) to recognize this correlation and establish the 
implied linkage. Or is making such a correlation something that an SRS 
might do if it feels like it, but might not? Or is it something that a 
client of the SRS, using a yet to be designed query interface, might do?

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 8 Jul 2010 12:46:33 -0700

> client of the SRS, using a yet to be designed query interface, might

Even though we are not designing the query/search part of the SRS, I
think the metadata model should recognize the correlation between the RS
to CS so that you can build useful applications on top of the SRS (ie.
speech analytics); otherwise we are just dumping raw data onto a server.
A generic SRS is not required to make the implied correlation efficient
for querying or searching, but at least the information about the
correlation needs to exist as a model so that the correlation provided
by the SRC is not lost when stored on the SRS.

Thanks
Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jul 2010 16:12:17 -0400

> by the SRC is not lost when stored on the SRS.

I'm fine with recognizing that "higher level applications" may be using 
the data in this model to do useful correlations - basically "data mining".

And to some extent the data incorporated into the model can take that 
sort of need into account. That should be no issue as long as it is 
naturally occurring stuff.

It will be more questionable if we find ourselves calling for the 
fabrication of new "correlation ids" to support unspecified needs for 
correlation. Hopefully we won't get into that.

	Thanks,
	Paul

---

From: "Morgan, Dave" <[email-masked]>
Date: Thu, 8 Jul 2010 17:41:13 -0400

It's critical that an enterprise's call recording infrastructure MUST be
able to find all the call segments associated with a call even though
they may be recorded at different locations and on different servers.
In the SIP domain this translates into one CS where transfers and
sidebar conversations (such as between the agent and supervisor) results
in multiple RSs that occur between different SRCs and SRSs.  

Paul threw out the idea earlier of a Recording Session Group, and below
he mentioned "higher level applications," both of which could solve
this.  Either way, there needs to be a reference or pointer to each RS
associated with a call.  A particular piece of meta data could be used
to correlate the RSs.  For example it could be a customer ID, ANI (AOR),
or CTI ID that is persistent with the CS and can be populated into the
sidebar conversations.  

One reason why this would be valuable is that calls within an enterprise
can (and do) have different retention periods.  When the retention
period expires, we want all call segments (RSs) associated with the call
to be deleted (it may be worth discussing if "retention expiration date"
is a valid tag to be included in the SRS).  You want to manage the
expiration date at the SRS level and not at the SRC.  Suppose calls
escalated to a supervisor have a 12 month retention while other calls
have a six-month retention.  It's not until the call is escalated will
the 12-month retention tag be placed on all the associated RSs.  

A worst-case scenario would be that only calls escalated to supervisors
would be retained.  I don't have that requirement, but I'm suspect it's
out there (Leon might be able to comment on that).  In that case, all
RSs are "temporarily" recorded.  If the call is not escalated, the RSs
are deleted.

Dave

I'm fine with recognizing that "higher level applications" may be using 
the data in this model to do useful correlations - basically "data
mining".

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 8 Jul 2010 15:08:51 -0700

Hi Dave,

This is an excellent use case to explain why it is important for the
metadata model to recognize the correlation between the RS and CS.
Basically SRC provide the correlation of the sessions to SRS to store
them; there is no business logic behind the correlation so that we can
achieve basic interoperability between SRC and SRS. The business logic
behind the SRS can do all kinds of things to the stored correlations and
it's entirely up to the SRS to deal with additional business attributes
like the retention period that you described. 

The supervisor model also explains the decomposed B2BUA SRC model where
CS can have multiple RS coming from potentially coming from different
sites when transfers happen. However, when you use the endpoint SRC
model, correlating transfers can be quite tricky when the transferring
endpoint is recording the call and needs to transfer the call to another
party with 1PCC REFER; in fact, I think call transfers with 1PCC should
be considered as separate CS.

I also echo Paul's comment that we should be looking to reuse existing
SIP attributes for correlation rather than creating new identifiers.

Regards,
Henry

> From: Morgan, Dave [mailto:[email-masked]]
> Sent: Thursday, July 08, 2010 5:41 PM
> To: Paul Kyzivat; Henry Lum
> Cc: [email-masked]; Leon Portman; Morgan, Dave
> Subject: RE: [siprec] A model of recording metadata
> 
> >> A key distinction to make here is whether the SRS is *obligated*
(by
> >> might do if it feels like it, but might not? Or is it something
that
> a
> >> client of the SRS, using a yet to be designed query interface,
might
> >> do?
> > think the metadata model should recognize the correlation between
the
> RS

---

From: "Morgan, Dave" <[email-masked]>
Date: Fri, 9 Jul 2010 16:23:00 -0400

Comments inserted inline as [Dave]:

>> I prefer having a data model for the recording metadata rather than
>> have the data stuffed in the UUI field, which is what I've seen so >>
far in the industry. 

> What are the possible values for "why"?

[Dave] 
Why some calls should be recorded and others not are mostly issues of
selective recording.  The possible values for "why" allow us to search
for those calls later.  Here are a couple of examples: 
1) To enable call quality scoring for the agents.  Assume there is an
external system that performs selective recording logic that dictates
that each agent have 5 calls a day recorded.  The SRC would have to pass
the call variables (indicative of the agent) to an external system and
receive back the instruction to record the call.  The "why" (or "reason
code") for the call being recorded would be "call quality."
2) Agent-initiated call recording is another use case.  In the instance
where an agent is empowered to record a call, the reason code would be
"agent initiated."
3) Another common reason to record a call is if it was part of a certain
campaign, or if you wanted to capture a fraction of calls from a
campaign.  The reason code would be "x-campaign."   

Whether or not we want to make a "reason code" an attribute of the call
or store it in an external system is open to discussion. 

Of course another way to solve the selective recording issue is to have
the upstream IVR system that initially terminates the call query the
external selective recording logic and then set a "record" variable
which the SRC will then see.  But not all call centers have calls that
are initially terminated by IVRs.

>For the moment, any access to the data after it has been recorded is 
>out of scope for this WG, though clearly it is important. That is     
> going to make it difficult to call out stuff to be added for the     
> purpose of later retrieval. I guess we either need to expand the 
> scope, or just rely on you users to call out what you need included.

[Dave] 
Agreed, access after recording is out of scope, but we need to
anticipate what's needed for retrieval.  If the retrieval problem is not
accommodated, no one will use the data model in practice.  It would be
nice to see a Use Case in siprec-req that addresses retrieval.

>> If the data model is adopted across vendors it would provide a 
>>single non-proprietary mechanism for third-party vendors to retrieve 
>>calls that meet certain criteria, such as recorded in a specific
>> location, serviced
>> such as speech analytics or a first call resolution application 
>> would  benefit from a standardized recording data model.
> 
>> As Paul points out, the Recording Session Group, which contains the 
>>list of recording sessions associated with a call is a very important
>> conferences in the supervisor to the second call segment.  We need 
>> to associate all three call segments with one call. 

>who/what knows enough to associate all those pieces.

[Dave]
In practice an enterprise is going to have geographically dispersed call
centers, SIP trunks, SBCs, and consequently SRCs, to reduce the impact
of potential outages.  The multiple RSs will have to be linked up (this
has been discussed on more recent threads).

Another alternative is to pin the CS at the SRC for the duration of the
call.  So even if the call were transferred it would still flow through
the first SRC.  An element in the data model could indicate that the
call is already being recorded (to avoid multiple recordings).  I'm not
an expert on the SIP signaling required to achieve this, but I think it
would overly complicate what we are trying to achieve. 

>> call segments that are event based.  I also  agree that the 
>> recording session group needs an ID, or a URL, as Paul pointed out. 
>>  
>> As far as the features that need to be passed, in practice there is 
>> a trade-off between what is stored in the CTI solution and what is
>> call has first been treated by an IVR system (potentially a network 
>> or hosted IVR) which creates an initial CTI record for the call 
>> (these

>collected, into the new call when the IVR transfers the call for 
>handling.

[Dave]
Correct, this new reference could be the CTI ID.  The problem is when
the agent calls a supervisor when handling the customer call (the
sidebar conversation) there's no call context from the originating call
at the SRC that's recording the sidebar.  So one solution is to slip the
CTI ID into the sidebar call.  The supervisor needs it anyway to do the
customer screen pop.  Another approach is to have the SRC insert a "call
recording ID" into the recorded call.  Then the call control logic will
have to extract this from the call the agent is taking and insert this
into the sidebar the agent is making so the SRC recording the sidebar
can pick it up and it can be used to correlate the calls.  I think
supporting both a CTI ID and a call recording ID in the recording data
model is prudent.  

>Here I presume the SBC you reference is acting as an SRC. Right?

[Dave]
Yes, that's the logical place when using SIP trunking.

>I fear that sort of thing is going to be a problem here.

[Dave]
Exactly, UUI is enabling customized deployments.  I haven't explored yet
whether I can use the SBC to parse the UUI (in the role of the SRC) or
even rewrite the UUI if I have to convert the metadata so another
vendor's system can read it.

>involved, or given the data for the decision? Couldn't the IVR make 

[Dave]
See my previous comments.  A key thing though is our agents have direct
extensions off the ACD, so you can call them back directly.  We don't
have any IVR treatment in front of this extension dialing, so in the
case of selective recording, the SRC would have to get the decision to
record from an external source.

>system, that knows how to interact with both, to correlate the data in

[Dave]
I think we should try to avoid the "trail of breadcrumbs" approach to
retrieving calls.  

<< remainder snipped >>

One last thing that I want to mention is the requirement for "encryption
in transit" and "encryption at rest."  I think that siprec-cc-rec and
siprec-req both address the issues with encryption in transit in their
security sections.  "Encryption at rest" means that when the file is
stored it has to be encrypted.  So the SRS will have to manage
encryption of the files.  If we are dealing with removable media from
the SRS then the recorded session should contain information about the
identity of the SRS on which it was stored and whatever encryption key
information is needed to eventually decode the call when it is
retrieved.  I think it's prudent to add both an SRC and SRS identifier
to the siprec data model.

David P. Morgan, PhD
Vice President

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, July 07, 2010 1:06 PM
To: Morgan, Dave
Cc: Leon Portman; [email-masked]
Subject: Re: [siprec] A model of recording metadata

Dave,

I think there may be a difference of opinion here.
IMO all of what you describe above *could* be captured in a single RS.
If it were, then there would be no need for grouping multiple RSs
together.

identifying information in common that can be used by a higher level 
system, that knows how to interact with both, to correlate the data in
each.

the SRC.

But I may be wrong about that. I'm sure somebody will correct me if I
am.

	Thanks,
	Paul

> My intent here was to record what the SRS is expected to capture as
part

>> place holder. In an implemented mechanism this would be a reference
to

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jul 2010 20:46:52 -0400

Dave,

(lots of "snipping")

> are initially terminated by IVRs.

I see what you are after, and it seems reasonable to me.
 From a data modeling perspective, I'm concerned about the namespace for 
the values of "why". This could simply be treated as an opaque string 
(which is what you seem to have in mind), and that will be fine as long 
as all those that supply values for "why" are coordinated by the same 
administration. But if there are uncoordinated SRCs then the values for 
"why" may become just babble.

Typical resolutions to such a problem would include:
- define all the "why" values as an enumeration as part of the standard
- define a public (i.e. IANA) registry of "why" values
- use URNs as "why" values (variant on the registry approach)
- segment the "why" value into a two parts: "namespace" and "reason".
   Require the namespace to be unique (e.g. reverse FQDN such as java
   uses for package names) and "reason" to be an opaque string within
   the scope of the namespace.

Or it could be left as simply an opaque string and punt the issues.

> nice to see a Use Case in siprec-req that addresses retrieval.

I depend on you guys who actually use this stuff to supply the use 
cases. :-)

> would overly complicate what we are trying to achieve. 

Do you consider a call from Joe to agent-Alice which is subsequently 
transferred to agent-Bob *one* CS, or *two* CSs?

Assuming you count it as one, I would agree its overly restrictive to 
pin that to one SRC. (Some deployments might do it that way, but we 
shouldn't assume they must do it that way.)

But that does raise the question of who knows enough to do the 
correlation. Maybe whoever initiates the transfer does. It would be good 
if that were so. But ISTM that there should be some thought given to 
what needs to be in the metadata to support the correlation, and who 
knows enough to put it there. You could fall back on trying to correlate 
common participants within a time window, but that seems very cumbersome 
and imprecise.

> at the SRC that's recording the sidebar. 

This part would be straightforward if the agent phone were the SRC for 
both the customer call and the sidebar.

I gather you don't expect that to be the case?

> So one solution is to slip the
> CTI ID into the sidebar call. 

I trust you realize that "CTI ID" is not part of the sip vocabulary.

So "slipping" it into another call requires consideration.

> The supervisor needs it anyway to do the
> customer screen pop. 

*That* is *really* out of scope for siprec. (This is not the 
sip-call-center WG.)

But assuming the supervisor has some way to get this information, then 
it could potentially ask the SRC to send some metadata to its RC.

> Another approach is to have the SRC insert a "call

Similar comments to above.
These terms you are coining (or rather importing from another domain) 
need to be redefined in the context of siprec. And questioned as to 
their well-definedness and orthogonality to other things. We are already 
swimming in redundant data in sip.

> Yes, that's the logical place when using SIP trunking.

Unless your own employees might call your contact center. Then they 
might not get recorded.

(E.g. sitting in my Cisco office I use my internal Cisco phone to call 
for support on the Linksys router I have at home.)

> vendor's system can read it.

Customization can be both the cause and the effect of a lack of 
interoperability standards.

Its clearly necessary in some places. The trick is distinguishing the 
places where it belongs from those where we standardizing is feasible 
and will eliminate the need for customization.

"Metadata" here is presumably going to become a schema for a bunch of 
data we *do* know the format of. For siprec it probably will not be 
transported as "UUI". Or maybe it will, but the UUI will be formatted 
according to that schema. (Hard if its limited to 128 bytes or so.)

> I think we should try to avoid the "trail of breadcrumbs" approach to

Its not lovely. But it may be preferable to embedding too much call 
center specific stuff into SIP. But the jury is still out.

> to the siprec data model.

Why would you assume that *identity* of the SRC and/or SRS is 
deterministic for keying the encryption of the data?

I'm not a security guy, but that seems pretty restrictive.
At the least I would think you would want an identifier for the 
decryption key. THere might be several SRSs using the same one and/or 
one SRS might use several. Really need to talk to a security guy about 
the possibilities.

BUT making something that existing systems can adapt to may limit the 
possible solutions.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Sun, 11 Jul 2010 10:43:12 +0300

I completely agree with Henry below that we need to have a good XML representation of the metadata that currently available from CTI interfaces.
And we also should support reporting of metadata information that is available in the original CS INVITE as part of RS INVITE and also support in call updates (like KPLM DTMF data) during the call.

The correlation between different RS session is also very important. Today we are usually using Customer information (like ANI or SIP/TDM trunk information) in order to do this correlation

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, July 08, 2010 9:20 PM
To: Henry Lum
Cc: [email-masked]; Leon Portman
Subject: Re: [siprec] A model of recording metadata

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 13 Jul 2010 11:52:21 -0700

[lots of snipping]

> SIP trunking and perform selective call recording off the SBC at their

[[hlum]] RFC5552 does provide a standard mechanism for SIP-based VXML
media services (IVR) to insert and return application data between SIP
entities. Of course the notion of application data is generic and it
does not mention anything related to recording. This means the SIP
applications need to interpret specific application data before deciding
whether recording should be performed, however, I believe this is
business logic that should be performed on the SRS side. If we allow the
recording metadata model to insert application data, then an SRC would
be able to pipe what you retrieved from the IVR to the SRS? 

Thanks
Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jul 2010 15:13:23 -0400

I am not "getting" this. Are you saying that you expect a mechanism for 
transporting any- and everything about the call or the caller that 
something might possibly apply business logic to in order to decide if 
this call should be recorded?

E.g. should the caller's resume be a valid form of metadata? The 
caller's blood pressure and temperature?

If so, then I think you are asking to reinvent the web.

IMO you must be able to clearly define what is in scope for inclusion in 
metadata, and more importantly, what is *out* of scope. (And there had 
damned well better be more that is out of scope than is in scope.)

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 13 Jul 2010 13:24:37 -0700

Since the metadata is expected to be extensible, I believe the SRC
should be able to extend the metadata to include application data to the
SRS so that the SRS can apply business logic based on application data.
What kind of application data is doesn't matter and it's out of scope;
what I am pointing out is that there are standard ways for passing
application data such as SIP based VXML services, so it is possible to
define a way to transport the application data as part of metadata
without defining them what they actually are. 

Henry

> Sent: Tuesday, July 13, 2010 3:13 PM
> To: Henry Lum
> Cc: Morgan, Dave; Leon Portman; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jul 2010 17:26:39 -0400

Henry,

As described below, this sounds a lot like "legacy" INFO.
(I send you a bunch of stuff with no way of knowing if you are 
interested in it or can understand it.) In fact, the SRC could use INFO 
to send arbitrary data to the SRS this way.

(But of course Info Packages will soon be approved and then we won't be 
able to use INFO that way. :-)

Practically speaking, if you are going to push arbitrary data, it will 
need to be identified in some way in order to be understandable. (Just 
saying "here are a bunch of bits to include with this recording session 
isn't very helpful.) At the least it will need to be identified by a 
content-type or xml element type, or some such thing. I actually think 
it needs more than that.

Can you recommend some extensions to the data model I proposed, for 
inclusion of this arbitrary data, with some sort of tagging that will 
make it possible for someone reading the it to understand what it is 
looking at?

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 14 Jul 2010 12:54:53 -0700

I would pick something like JSON as a content type so that I can place
structured data and it is quite compact to transport over SIP (the RS I
assume). We can also consider XML, but we'll probably end up defining a
specific schema then we are forced to be too specific about application
data.

This application content can simply be an attribute of CS so that it
describes application information about the entire call session, or as
Leon mentioned, provide additional hints to the cradle-to-grave
information for a customer interaction. If there are multiple RS in a
CS, any RS may attach application data on behalf of the CS to make
things simple overall. I don't think we need to structure application
data beyond the CS and attach application data to other things like a
participant in the metadata model.

Regards,
Henry

> Sent: Tuesday, July 13, 2010 5:27 PM
> To: Henry Lum
> >> IMO you must be able to clearly define what is in scope for
> inclusion
> >> in
> >>>> recorded.  This is the dilemma that enterprises face today,
> vendors
> >>>> that
> >>> business logic that should be performed on the SRS side. If we
> allow
> >> the

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jul 2010 16:23:08 -0400

Henry,

There are many ways to handle flexible content types.
The part I'm missing is how the result is understandable without 
implicit context.

For instance, for body handling in sip we have Content-Type and also 
Content-Disposition. In some cases it may appear that Content-Type is 
sufficient to understand how to process, but it turns out that it really 
isn't, so Content-Disposition provides context for how to understand it. 
And the Content-Disposition values are standardized.

Similarly, with INFO, the original assumption was the Content-Type was 
enough. But now we have settled that the Info-Package name, along with 
the Content-Type provides the context for understanding INFO body part. 
And the Content-Disposition distinguishes which body part is the INFO 
body part. The Info-Package names need to be registered with IANA.

I would be thinking that something like this might need to be used, with 
the possibility of both standardized types of data and others that are 
at least identified with a guaranteed unique identifier that provides 
context for understanding the content.

In terms of where to attach:

An attribute of the CS seems a bit simplistic.
Presumably there may be many pieces coming in. And some may be 
associated with a CS, some with a Participant, some with a media stream, 
etc. There needs to be a way to associate several with each of those 
places. And I suppose you might want info on the order in which they 
were received, perhaps when they were received, etc.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 14 Jul 2010 14:19:44 -0700

Hi Paul, 

Since we are looking at recording the call, could the disposition be
something like "record"? However, this may not be very meaningful if we
want an application on top of SRS to understand the context of the
information for processing, so just like you said we will probably end
up with an additional qualifier to describe the disposition is for
application processing.

If we allow application data to attach with a participant, media stream,
etc and allow the order and timing to be recorded, then this is starting
to look like the event stream that others have mentioned about earlier
in this thread. This means application data becomes an event rather than
an attribute, and an application will end up needing to parse through a
timeline to find simple data such as "customerLevel=VIP" so that it can
apply policies for permanent storage. Perhaps we should allow events to
attach application data rather than making application data as an event?

Thanks
Henry

> Sent: Wednesday, July 14, 2010 4:23 PM
> To: Henry Lum
> > structured data and it is quite compact to transport over SIP (the
RS
> I
> > assume). We can also consider XML, but we'll probably end up
defining
> >> (But of course Info Packages will soon be approved and then we
won't
> >>> should be able to extend the metadata to include application data
> to
> >> the
> >>> application data such as SIP based VXML services, so it is
possible
> >>>> I am not "getting" this. Are you saying that you expect a
> mechanism
> >>> for
> >>>> something might possibly apply business logic to in order to
> decide
> >> if
> >>>> metadata, and more importantly, what is *out* of scope. (And
there
> >> had
> >>>>>> recording data model to insert metadata into the call prior to
> it
> >>>>> being
> >>>>>> recording solution.   This is especially true for those that
are
> >>>>> trying
> >>>>>> SIP trunking and perform selective call recording off the SBC
at
> >>>> their
> >>>>> media services (IVR) to insert and return application data
> between
> >>>> SIP
> >>>>> entities. Of course the notion of application data is generic
and
> >>>> refraining from acting, on any information contained in this e-
> mail
> >> is

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jul 2010 17:54:22 -0400

> attach application data rather than making application data as an event?

Now we are getting somewhere.

I don't have the answers to most of the questions you pose - they need 
to be resolved around those who need this. I understand that more 
structure means harder analysis. OTOH, insufficient structure means 
limitations in what can be represented.

If the goal is to look up the value of "customerLevel", I guess the 
first thing to ask is: where is the meaning of customerLevel defined? 
Does everyone involved agree on that name? If so, how did that agreement 
come about? Do we assume that everything using the system was 
consistently *configured* to know the name "customerLevel" and its 
semantics? What if that is all carefully configured in the call center 
software, but the conferencing systems in the same enterprise use the 
same recording infrastructure but use "customerLevel" to mean something 
entirely different?

What I have in mind is that all the extensible stuff is first tagged 
with some unique name for the context within which it is understandable. 
So perhaps all the call center stuff is tagged with the context 
"callcenter.mycompany.example.com", with suitable conventions so 
applications or end users can define their own contexts without stepping 
on each other's toes.

Then within such a context you could use "customerLevel" in whatever way 
makes sense in that context. Using "customerLevel" within 
conferencing.mycompany.example.com would mean something entirely different.

Once you have a unique way of referencing the "customerLevel" you mean, 
there is that question of whether it is multivalued (event) or not. If 
not, then if it is supplied more than once, either the first one wins, 
the last one wins, or there is an error. That at least needs to be 
defined. The "easy" way would be to treat everything as multivalued and 
depend on the query language to provide an easy way to get what you want.

Anyway, this is non-trivial to get defined so that it is sufficient 
without being any more complex than it needs to be. I can listen, ask 
dumb or leading questions, and maybe act as scribe. But those with the 
requirements need to argue them out.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 15 Jul 2010 15:23:28 -0700

I want to spin off a separate discussion about this topic as it looks
like we have been focusing on one specific aspect of the application
data. It seems that so far we have been talking about one specific class
of use cases with application data to apply business rules or policies
on the decision to record or data retention. Some of us has suggested to
introduce the idea of a new logical sub-component called Policy Server
as part of the SRS. 

As a logical component, the policy server can either be separate or as
part of the SRS. The goal of having a policy server allows the SRS to
focus on the recording aspect of the protocol which is what is in the
scope of this WG. The policy server may use other mechanism outside of
SIP to determine the business logic part, but they would be out of the
scope of this WG. In a way this is similar to the speech analytics
discussion we had in the last interim meeting where we acknowledge a
class of applications that would use the SRS to provide analytical
functionality but we don't put them in the scope of this WG. What's
different in this case is that there may be additional information that
the SRC knows about that would affect the actual recording and the
information may need to come from applications (such as IVR
applications) on the SRC side. We need the SRC to pass such data to the
SRS for the Policy Server to process, so there should be a way to
standardize the mechanism of which the information is sent. One thing
Paul has suggested is that we can call out these types of metadata with
a content disposition with something like "record-policy", so that the
SRS understands it needs to deal with the content using the policy
server.

Since this is introducing something new to the architecture draft, I
would like to get your feedback on this. We still have a bunch of
unanswered questions around where/when does the data appear and the
context of which the data apply, but as a start we can decide whether
separating a logical entity would simplify the issue.

Regards,
Henry 

> Sent: Wednesday, July 14, 2010 5:54 PM
> To: Henry Lum
> > an attribute, and an application will end up needing to parse
through
> >> isn't, so Content-Disposition provides context for how to
understand
> >> it.
> >>> describes application information about the entire call session,
or
> >> as
> >>> information for a customer interaction. If there are multiple RS
in
> >>> data beyond the CS and attach application data to other things
like
> >>>> interested in it or can understand it.) In fact, the SRC could
use
> >>> INFO
> >>>> isn't very helpful.) At the least it will need to be identified
by
> >>>>> SRS so that the SRS can apply business logic based on
application
> >>>>>>>> to have a hosted IVR system deliver the calls to the
> enterprise
> >>>>>> using
> >>>>>>> [[hlum]] RFC5552 does provide a standard mechanism for SIP-
> based
> >>>>> VXML
> >>>>>>> applications need to interpret specific application data
before
> >>>>>> deciding
> >>>>>>> recording metadata model to insert application data, then an
> SRC
> >>>>>> would
> >>>>>> and/or its affiliated entities. Access by the intended
recipient
> >>>> only
> >>>>>> attachments and do not disclose the contents to any other
> person,
> >>>> use
> >>>>>> Copyright in this e-mail and any attachments belongs to
Alcatel-
> >>>> Lucent

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Jul 2010 11:16:43 +0200

Henry,

Thanks for raising this. I believe it would be a good idea to identify Policy Server (PS) as a separate logical entity in the architecture. The PS will require interfaces to various sources of information about CSs that are being established / taking place. For want of a better name at present, let's call it metadata type 1. Typically these sources of metadata type 1 will be SIP entities involved in a CS, e.g., an IVR, a B2BUA or UA that might eventually become the SRC if the PS decides to record a particular CS. We need to determine whether the interface between a SIP entity and a PS for uploading metadata type 1 to the PS is within the scope of SIPREC. Note that this interface would not necessarily be SIP-based.

Metadata send from the SRC to the SRS to describe the CS being recorded would then be called metadata type 2 (for want of a better term). Note that there may be some overlap between metadata type 1 and metadata type 2, but also there are likely to be some differences. I would expect the metadata discussions to take this into account.

Secondly, the PS needs to have an interface with either the SRC or the SRS in order to instruct the SRC or SRS to record a CS. The simple solution would be to have an interface with the SRC to instruct the SRC to record the CS, and then the SRC establishes the RS to the SRS (if not already established). It could, of course, be done the other way round, whereby the PS instructs the SRS to record and the SRS might need to establish a RS to the SRC, which might not be so straightforward. It is not clear we need both options, so let's assume for the time being that the PS instructs the SRC to record. We would then need to determine whether the interface between the SRC and the PS for the purpose of instructing the SRC to record a CS is within the scope of SIPREC. Again, note that this interface would not necessarily be SIP-based.

John (as individual)

> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 15 July 2010 23:23
> To: [email-masked]; Paul Kyzivat
> Subject: [siprec] (draft-ietf-siprec-achitecture) Introducing
> policy server on the SRS
>
> > > something like "record"? However, this may not be very
> meaningful if
> > we
> > > in this thread. This means application data becomes an
> event rather
> > than
> > > timeline to find simple data such as "customerLevel=VIP"
> so that it
> > can
> > > apply policies for permanent storage. Perhaps we should
> allow events
> > to
> > >> Content-Disposition. In some cases it may appear that
> Content-Type
> > is
> > >> Similarly, with INFO, the original assumption was the
> Content-Type
> > was
> > >> I would be thinking that something like this might need
> to be used,
> > >> with
> > >> the possibility of both standardized types of data and
> others that
> > are
> > >>> This application content can simply be an attribute of
> CS so that
> > it
> > >>>> Practically speaking, if you are going to push
> arbitrary data, it
> > >> will
> > >>>> need to be identified in some way in order to be
> understandable.
> > >> (Just
> > >>>> content-type or xml element type, or some such thing.
> I actually
> > >> think
> > >>>> it needs more than that.
> > >>>>
> > >>>> inclusion of this arbitrary data, with some sort of
> tagging that
> > >> will
> > >>>> make it possible for someone reading the it to
> understand what it
> > > is
> > >>>> looking at?
> > >>>>
> > >>>>        Thanks,
> > >>>>        Paul
> > >>>>
> > >>>> Henry Lum wrote:
> > >>>>> What kind of application data is doesn't matter and
> it's out of
> > >>>> scope;
> [mailto:[email-masked]]
> > On
> > >>>>>> Behalf Of Paul Kyzivat
> > >>>>>>>> treatment prior to the call being sent to an agent
> would use
> > > the
> > >>>>>>>> provide upstream call treatment don't have a
> standard way of
> > >>>>>> inserting
> > >>>>>>> does not mention anything related to recording.
> This means the
> > >> SIP
> > >>>>>>> whether recording should be performed, however, I
> believe this
> > > is
> > >>>>>> hereby excluded. If you are not the intended
> recipient, please
> > >>>> notify
> > >>>> attachments and do not disclose the contents to any
> other person,
> > >> use
> > >>>> Copyright in this e-mail and any attachments belongs
> to Alcatel-
> > >> Lucent
> > >> refraining from acting, on any information contained in
> this e-mail
> > is
> recipient only
> person, use
> Alcatel-Lucent
> --------------------------------------------------------------
> -----------------------------------------------------
> 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
> 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: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jul 2010 18:45:43 -0400

John,

I largely agree with what you say.

I *hope* this PS can be out of scope for the current effort, because it 
seems complex in its own right, and distracting.

ISTM that it is important in call center scenarios, but perhaps not so 
much in other applications of recording. And conversely, the same PS 
mechanics could be important for some non-recording functions.

But just because I *hope* it can be that way, I don't *know* it can be.

	Thanks,
	Paul

Elwell, John wrote:
>> this e-mail is

---

From: Leon Portman <[email-masked]>
Date: Sun, 18 Jul 2010 18:25:09 +0300

I agree that specific aspects of PS is outside of this WG scope: like definition of different recording policies, white/black lists, QA recording schedules etc.

However from architecture point of view we should define that PS could communicate either with SRS or SRC for recording decision.

 I also agree with separation of metadata into CS level (Type 1) and Recording Descriptions (type 2)

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Saturday, July 17, 2010 1:46 AM
To: Elwell, John
Cc: [email-masked]; Henry Lum
Subject: Re: [siprec] (draft-ietf-siprec-achitecture) Introducing policy server on the SRS

John,

        Thanks,
        Paul