Subject: [siprec] Metadata Open item : Communication Session Attributes

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 15 Oct 2010 19:24:05 +0530

Hi Team,

We got comments in alias as well as in the interim meeting from Leon to
have attributes like Direction, Initiator, call ID  as some of the
attributes for Communication Session.

Depending on where the SRC is located the direction may have some
significance. E.g SBC located at a edge of an Enterprise may know
whether is incoming/outgoing. Otherwise in a lot of 3PCC situations, the
UA is the recipient of the INVITE request, even if the user requested
the call. Also, if the call is established by transfer from somebody
else, it might always be incoming from the perspective of the local user
but might also be incoming from the perspective of the remote user. So
it may be tricky to find the direction.

Does the wider team see a value in having direction attribute ?

What about Initiator attribute?

Regarding Call ID I feel it may have issues in case there is a B2BUA. So
should we look to have call ID in the model  OR some other unique ID ?

What other attributes of CS can be put in the Metadata model  ? 

Regards,

Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 13:29:34 -0400

If we are to do this I think we need some changes to the model:

- we need relationships between Participant and CS
   (independent of media).
- one relationship might be "caller", another might be
   "callee".

Even so, we could not assume that every CS would have one caller. It 
might have several. And it might not have any callees, just callers. 
(E.g. a conference.) In a 3pcc case there might be a caller who is not a 
participant in any media streams.

I don't know if we "need" it. But it seems like info someone would want.

	Thanks,
	Paul

---

From: "Morgan, Dave" <[email-masked]>
Date: Fri, 15 Oct 2010 16:46:24 -0400

As a large enterprise user of call recording I just want to weigh in
briefly on this discussion.

There's a significant value to knowing if the call was inbound or
outbound.  Agents have different roles in inbound and outbound functions
and their managers search for and review these calls accordingly.
Whether the terminology is generalized to caller/callee to account for
conferencing is fine with me.

Regarding call ID, that is a valuable field that can be used in call
quality tool.  That allows the call that is being reviewed/scored to be
entered or referenced in the agent's review in another software package.

You asked for other attributes in the data model, so here are a few
suggestions:
* Destruction date: the date that the call is to be destroyed based on
the retention policy.  This also has to be kept with the recorded media
in case it is separated from the SRS.  
* Storage location: sometimes recorded calls are moved to different
media, consolidated, or taken off a system that is being decommissioned.
This field needs to be writeable over the duration of the retention
period.
* recording status: something along the lines of "do not record"
"recording in progress"  "recording complete."  Managers can pull calls
that are still in progress and would like to know the status.
* SRC ID: an identifier for the recording client, it's useful to know
what device the call was recorded from.
* recording notification: this indicates what message that was played by
the SRC, for example "message uri" "beep" or "none" so for legal reasons
you can validate what was played against the legal requirements for call
recording notification.
* termination reason: It's useful to know who terminated the call and
why.  We often ask the customer to stay on the line for a post-call
customer survey.  If the rep has a bad experience with the customer they
will stay on the line silently until the customer hangs up, so that the
customer doesn't get the survey.  Reps are savvy and we look for these
things.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Friday, October 15, 2010 1:30 PM
To: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes

	Thanks,
	Paul

> What other attributes of CS can be put in the Metadata model ?
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "De Villiers de Wet" <[email-masked]>
Date: Mon, 18 Oct 2010 14:47:25 +0200

Good day

Please see my comments inline.

De Villiers de Wet (DdW)

From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 15 October 2010 15:54
To: [email-masked]
Subject: [siprec] Metadata Open item : Communication Session Attributes

Hi Team,

[DdW] Yes, many clients of recording systems are interested in this
attribute.  Another related attribute is the call 'scope', i.e. whether
it is an internal call (all participating parties are internal) or an
'external' call, i.e. at least one party is an external party.  Of
course the Direction and Scope attributes cannot always be determined,
or determined reliably, but that should not prevent the standard from
making provision for it, including the provision for 'Unknown' values.
Be aware that many end-users mix the two concepts together and make a
distinction as follows:  incoming (from external party to an internal
party), outgoing (reverse of previous) and internal.  How to present the
two concepts to the end-user is the responsibility of the SRS in my
view, i.e. should not be part of the standard.

[DdW] I presume this is the same as identifying the Caller in
traditional telephony.  This attribute is even more important than the
above ones, and will almost always be known by the SRC.  First it is
important to enable the user to understand a complex scenario, e.g.
transfer and conference, properly, as well as a scenario of several
calls over time, e.g. emergency room scenario - the sequence of who
called who at what time and after/before other calls.  Secondly, the
attribute can be used when finding calls for performance evaluation
purposes, e.g. if a call center agent handles both inbound and outbound
call types, it is important to be able to find a selection of both
inbound and outbound calls with respect to the agent being evaluated.

[DdW] Some telephony systems have the concept of a globally unique call
ID, which becomes a central ID that multiple applications that integrate
with the telephony system use as a central 'hook', without integrations
having to be done *between* the applications to perform the real-time
linking of different kinds of data, e.g. a transaction in the CRM system
and a voice recording.  This is a powerful concept.  For example, both
the CRM system and recording system capture the unique call ID real-time
and store it.  Afterwards, if someone wants to play back the
recording(s) related to a particular transaction, the list of unique
call IDs stored by the CRM system can be used to find and play the
recordings tagged with these IDs. 

 I don't think the standard must specify that it must be a globally
unique identifier; it must just cater for such an ID, including the
'Unknown' value.

[DdW] See my comment about Call Scope above.

Call Termination Reason - for some customers knowing who terminated the
call (external party or internal) is very important, e.g. to check if
the correct end of call 'protocol' is followed.

Who was/is the participants in a given media recording and *at what
time* is very important, e.g. for proper access control to recordings
afterwards.  E.g., if A and B take part in a conference call, and B
drops out of the call halfway, B must NOT afterwards have access to the
audio of the call for the portion he/she was not taking part.  Only the
SRC can provide this info to the SRS, and if it does not, enforcing
proper access control in the SRS is a major problem.  So, an important
attribute of the participant of a CS/RS is Participation Start Time
(when started participating) and Participation Duration (how long did
he/she participate).  Of course the SRS can 'measure' these by capturing
the time of the events that indicate the start/end of participation
as/if they arrive in real-time.  So depending on what is agreed upon in
terms of events sent to the SRS, it will be the job of the SRC to
provide it or the SRS to 'figure it out' from the events.

Participant Name - often communication systems have a configured
friendly name for an endpoint, e.g. 'John Doe' for extension 2110, or
'Sally Smith' for [email-masked].  If this is available to the SRC
and passed to the SRS, it enriches the value and content of the RS.

Regards,

Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 Oct 2010 22:41:54 +0530

Hi De Villers,

Please see inline <Ram>

From: [email-masked] [mailto:[email-masked]] On Behalf
Of De Villiers de Wet
Sent: Monday, October 18, 2010 6:17 PM
Cc: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes

Good day

De Villiers de Wet (DdW)

Hi Team,

<Ram> Makes sense.  I am fine adding Direction and Initiator as CS
attributes to the model.

I am not yet clear on what value does 'Scope' can add to the model and
to SRS ? Do you have any examples on why we need to know the scope at
SRS ?

<Ram> I see a value in having a unique ID. But I don't think it should
be Call ID for various reasons. I will wait for inputs from wider team
to see what we can have as an unique Identifier.

<Ram> Call Termination reason along with who terminated the call seems a
useful attribute to have in CS block.  

<Ram> The current Metadata model facilitates recording participant
information [ in participant block] and associate it with the Received
Media Stream block that will have media properties.

This will have attributes like Start time/End time which you have
mentioned above.  Please let us know if that is sufficient.

Regarding your second comment on who can access what portions of stored
data,  I am not sure if it is in scope of SIPREC at this point and if
that needs to captured in the model.

I will wait for comments from wider team on this point.

Thanks,

Ram

Regards,

Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 21:07:09 -0400

Inline. There is some good stuff here, but still very ill defined.

On 10/18/2010 8:47 AM, De Villiers de Wet wrote:
> *From:* Ram Mohan R (rmohanr) [mailto:[email-masked]]
> *Sent:* 15 October 2010 15:54
> *To:* [email-masked]
> *Subject:* [siprec] Metadata Open item : Communication Session Attributes
>
> Hi Team,
>
> */[DdW] Yes, many clients of recording systems are interested in this
> attribute. Another related attribute is the call ‘scope’, i.e. whether
> ‘external’ call, i.e. at least one party is an external party. Of course
> the Direction and Scope attributes cannot always be determined, or
> determined reliably, but that should not prevent the standard from
> making provision for it, including the provision for ‘Unknown’ values.
> view, i.e. should not be part of the standard./*

We currently lack sufficient terminology to make these distinctions.

- internal vs. external:

Relative to what? Even if we classified the CS as internal or external, 
which participant(s) would be the internal ones and which the external ones?

- direction

If applied to a a CS, this is really an extension of the internal vs. 
external distinction.

- originating/terminating

I think this is being thought of in respect to the CS, not a particular 
media stream. Right now the only association we have for participant is 
with a media stream.

ISTM that the best we can do here is (optionally) associate participants 
with a CS, as initiating or terminating. Even then, nailing down what 
that means and how it is determined isn't necessarily going to be 
simple. And you might end up with more than one, or zero, of either type.

ISTM that internal vs. external (and by extension, direction) is an 
application distinction. We could define an attribute for it without any 
criterion for how it is determined. But I hate doing that. Or we could 
leave it to be an application-data.

> */[DdW] I presume this is the same as identifying the Caller in
> calls over time, e.g. emergency room scenario – the sequence of who
> inbound and outbound calls with respect to the agent being evaluated./*

OK. But I'm looking forward to a clear definition with enough normative 
teeth that you can tell if an SRC is making the classification correctly.

> */[DdW] Some telephony systems have the concept of a globally unique
> call ID, which becomes a central ID that multiple applications that
> integrate with the telephony system use as a central ‘hook’, without
> integrations having to be done *between* the applications to perform the
> real-time linking of different kinds of data, e.g. a transaction in the
> CRM system and a voice recording. This is a powerful concept. For
> example, both the CRM system and recording system capture the unique
> call ID real-time and store it. Afterwards, if someone wants to play
> back the recording(s) related to a particular transaction, the list of
> unique call IDs stored by the CRM system can be used to find and play
> the recordings tagged with these IDs. /*

Its easy to put in an attribute with a requirement that the SRC assign a 
globally unique value.

But what good is it if it can't be correlated to something else? Where 
does the correlation come from?

If you want some application (say an IVR) that is involved in the call, 
to produce other data keyed by the same ID, then it will need a way to 
either get this value, or provide it to the SRC. But I doubt we want the 
SRC pushing a value out into the CS signaling.

I suspect there is something significant here. But I need to hear a lot 
more about its properties and use.

> */ I don’t think the standard must specify that it must be a globally
> ‘Unknown’ value./*
> */[DdW] See my comment about Call Scope above./*
>
> */ /*
>
> */Call Termination Reason – for some customers knowing who terminated
> the call (external party or internal) is very important, e.g. to check
> if the correct end of call ‘protocol’ is followed./*

Same comments as initiator. This especially gets complicated when there 
are more than two parties.

Consider the case where a customer called in and is in conversation with 
two agents (conference). Eventually the customer is disconnected but the 
two agents continue to talk. What do you want to know in this case?
- who caused the customer to be dropped from the call?
- who was the last agent to leave?

Perhaps we need the notion of a participant leaving a CS, and a reason 
for that, which could include the participant leaving on their own, one 
of the other participants pulling the plug on them, or something else.

> */ /*
>
> */Who was/is the participants in a given media recording and *at what
> afterwards. E.g., if A and B take part in a conference call, and B drops
> out of the call halfway, B must NOT afterwards have access to the audio
> of the call for the portion he/she was not taking part. Only the SRC can
> provide this info to the SRS, and if it does not, enforcing proper
> access control in the SRS is a major problem. So, an important attribute
> of the participant of a CS/RS is Participation Start Time (when started
> participating) and Participation Duration (how long did he/she
> participate). Of course the SRS can ‘measure’ these by capturing the
> time of the events that indicate the start/end of participation as/if
> they arrive in real-time. So depending on what is agreed upon in terms
> of events sent to the SRS, it will be the job of the SRC to provide it
> or the SRS to ‘figure it out’ from the events./*

We need to be careful here about what we mean.

Are we talking about participation in the signaling of the CS, or 
participation by sending/receiving media?

Consider a voice-only participant in a call where other participants 
were also using video. If this participant had access to the audio 
recording while participating, should he also have access to the video 
for that period if he wasn't sending/receiving video?

IOW, are the access control decisions being made based on periods of 
signaling participation or based on participation in the specific media? 
(You can only play back the media if you received or sent it live.)

> */Participant Name – often communication systems have a configured
> friendly name for an endpoint, e.g. ‘John Doe’ for extension 2110, or
> ‘Sally Smith’ for [email-masked]. If this is available to the SRC
> and passed to the SRS, it enriches the value and content of the RS./*

The participant "object" is pretty vague right now. It has a URL and a 
display name, just like a To header could have. We can extend it as much 
as makes sense. But it only makes sense if we can explain how the SRC 
would get the information.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Oct 2010 09:49:25 +0200

> Sent: 18 October 2010 18:12
> To: De Villiers de Wet; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] Metadata Open item : Communication 
> Session Attributes
> 
> Hi De Villers,
> 
>  
> 
> Please see inline <Ram>
> 
>  
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of De Villiers de Wet
> Subject: Re: [siprec] Metadata Open item : Communication 
> Session Attributes
> 
>  
> 
> Good day
> 
>  
> 
> We got comments in alias as well as in the interim meeting 
> from Leon to have attributes like Direction, Initiator, call 
> ID  as some of the attributes for Communication Session.
> 
>  
> 
> Depending on where the SRC is located the direction may have 
> some significance. E.g SBC located at a edge of an Enterprise 
> may know whether is incoming/outgoing. Otherwise in a lot of 
> 3PCC situations, the UA is the recipient of the INVITE 
> request, even if the user requested the call. Also, if the 
> call is established by transfer from somebody else, it might 
> always be incoming from the perspective of the local user but 
> might also be incoming from the perspective of the remote 
> user. So it may be tricky to find the direction.
> 
>  
> 
> [DdW] Yes, many clients of recording systems are interested 
> in this attribute.  Another related attribute is the call 
> 'scope', i.e. whether it is an internal call (all 
> participating parties are internal) or an 'external' call, 
> i.e. at least one party is an external party.  Of course the 
> Direction and Scope attributes cannot always be determined, 
> or determined reliably, but that should not prevent the 
> standard from making provision for it, including the 
> provision for 'Unknown' values.  Be aware that many end-users 
> mix the two concepts together and make a distinction as 
> follows:  incoming (from external party to an internal 
> party), outgoing (reverse of previous) and internal.  How to 
> present the two concepts to the end-user is the 
> responsibility of the SRS in my view, i.e. should not be part 
> of the standard.
> 
>  
> 
> traditional telephony.  This attribute is even more important 
> than the above ones, and will almost always be known by the 
> SRC.  First it is important to enable the user to understand 
> a complex scenario, e.g. transfer and conference, properly, 
> as well as a scenario of several calls over time, e.g. 
> emergency room scenario - the sequence of who called who at 
> what time and after/before other calls.  Secondly, the 
> attribute can be used when finding calls for performance 
> evaluation purposes, e.g. if a call center agent handles both 
> inbound and outbound call types, it is important to be able 
> to find a selection of both inbound and outbound calls with 
> respect to the agent being evaluated.
> 
>  
> 
> <Ram> Makes sense.  I am fine adding Direction and Initiator 
> as CS attributes to the model.
> 
> I am not yet clear on what value does 'Scope' can add to the 
> model and to SRS ? Do you have any examples on why we need to 
> know the scope at SRS ?
[JRE] I think the problem with both direction indicator and scope is that this is application information not available in SIP. SIP might provide a clue, but in some cases that might be misleading. Perhaps we need to explore making provision in the metadata for application information, where this can be obtained by non-standardized means. I would like to hear the views of the rest of the group on this.

> 
>  
> 
> Regarding Call ID I feel it may have issues in case there is 
> a B2BUA. So should we look to have call ID in the model  OR 
> some other unique ID ?
> 
> [DdW] Some telephony systems have the concept of a globally 
> unique call ID, which becomes a central ID that multiple 
> applications that integrate with the telephony system use as 
> a central 'hook', without integrations having to be done 
> *between* the applications to perform the real-time linking 
> of different kinds of data, e.g. a transaction in the CRM 
> system and a voice recording.  This is a powerful concept.  
> For example, both the CRM system and recording system capture 
> the unique call ID real-time and store it.  Afterwards, if 
> someone wants to play back the recording(s) related to a 
> particular transaction, the list of unique call IDs stored by 
> the CRM system can be used to find and play the recordings 
> tagged with these IDs. 
> 
>  
> 
>  I don't think the standard must specify that it must be a 
> globally unique identifier; it must just cater for such an 
> ID, including the 'Unknown' value.
> 
>  
> 
> <Ram> I see a value in having a unique ID. But I don't think 
> it should be Call ID for various reasons. I will wait for 
> inputs from wider team to see what we can have as an unique 
> Identifier.
[JRE] There have been one or two initiatives to standardize a call identifier in SIP, most recently the session-id proposal (proposed SIPSCOTCH WG), which seems to have gone quiet recently. That proposal had a limited scope (troubleshooting), which may or may not make it unsuitable for SIPREC use. In fact there was discussion back in August of the use of session-id for SIPREC, largely in the context of allowing correlation between RSs from different SRC intances.

> Call Termination Reason - for some customers knowing who 
> terminated the call (external party or internal) is very 
> important, e.g. to check if the correct end of call 
> 'protocol' is followed.
> 
> <Ram> Call Termination reason along with who terminated the 
> call seems a useful attribute to have in CS block.  
[JRE] "Who terminated the call" is another example of application information that is not necessarily available (reliably) from SIP.

> 
>  
> 
> Who was/is the participants in a given media recording and 
> *at what time* is very important, e.g. for proper access 
> control to recordings afterwards.  E.g., if A and B take part 
> in a conference call, and B drops out of the call halfway, B 
> must NOT afterwards have access to the audio of the call for 
> the portion he/she was not taking part.  Only the SRC can 
> provide this info to the SRS, and if it does not, enforcing 
> proper access control in the SRS is a major problem.  So, an 
> important attribute of the participant of a CS/RS is 
> Participation Start Time (when started participating) and 
> Participation Duration (how long did he/she participate).  Of 
> course the SRS can 'measure' these by capturing the time of 
> the events that indicate the start/end of participation as/if 
> they arrive in real-time.  So depending on what is agreed 
> upon in terms of events sent to the SRS, it will be the job 
> of the SRC to provide it or the SRS to 'figure it out' from 
> the events.
> 
>  
> 
> Participant Name - often communication systems have a 
> configured friendly name for an endpoint, e.g. 'John Doe' for 
> extension 2110, or 'Sally Smith' for [email-masked].  
> If this is available to the SRC and passed to the SRS, it 
> enriches the value and content of the RS.
> 
>  
> 
> <Ram> The current Metadata model facilitates recording 
> participant information [ in participant block] and associate 
> it with the Received Media Stream block that will have media 
> properties.
> 
> This will have attributes like Start time/End time which you 
> have mentioned above.  Please let us know if that is sufficient.
> 
> Regarding your second comment on who can access what portions 
> of stored data,  I am not sure if it is in scope of SIPREC at 
> this point and if that needs to captured in the model.
> 
[JRE] I think it depends what we are talking about. Information that the SRC has regarding privacy of information to be recorded is, I believe, within the scope of SIPREC. Authorisation procedures for somebody trying to access a recording are outside the scope of SIPREC.

John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 20 Oct 2010 10:56:40 +0530

Please read inline. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Tuesday, October 19, 2010 1:19 PM
To: Ram Mohan R (rmohanr); De Villiers de Wet
Cc: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes

> Subject: RE: [siprec] Metadata Open item : Communication Session 
> Attributes
> 
> Hi De Villers,
> 
>  
> 
> Please see inline <Ram>
> 
>  
> 
> We got comments in alias as well as in the interim meeting from Leon 
> to have attributes like Direction, Initiator, call ID  as some of the 
> whether is incoming/outgoing. Otherwise in a lot of 3PCC situations, 
> the UA is the recipient of the INVITE request, even if the user 
> requested the call. Also, if the call is established by transfer from 
> somebody else, it might always be incoming from the perspective of the

> local user but might also be incoming from the perspective of the 
> remote user. So it may be tricky to find the direction.
> 
>  
> 
> attribute.  Another related attribute is the call 'scope', i.e. 
> whether it is an internal call (all participating parties are 
> internal) or an 'external' call, i.e. at least one party is an 
> external party.  Of course the Direction and Scope attributes cannot 
> always be determined, or determined reliably, but that should not 
> prevent the standard from making provision for it, including the 
> provision for 'Unknown' values.  Be aware that many end-users mix the 
> two concepts together and make a distinction as
> follows:  incoming (from external party to an internal party), 
> outgoing (reverse of previous) and internal.  How to present the two 
> concepts to the end-user is the responsibility of the SRS in my view, 
> i.e. should not be part of the standard.
> 
>  
> 

> calls over time, e.g.
> emergency room scenario - the sequence of who called who at what time 
> and after/before other calls.  Secondly, the attribute can be used 
> when finding calls for performance evaluation purposes, e.g. if a call

> center agent handles both inbound and outbound call types, it is 
> important to be able to find a selection of both inbound and outbound 
> calls with respect to the agent being evaluated.
> 
>  
> 
[JRE] I think the problem with both direction indicator and scope is
that this is application information not available in SIP. SIP might
provide a clue, but in some cases that might be misleading. Perhaps we
need to explore making provision in the metadata for application
information, where this can be obtained by non-standardized means. I
would like to hear the views of the rest of the group on this.
<Partha> Agreed. It is possible to provide the initiator and direction
in two party call using UA and B2BUA. It may be complicated in case of
conference. </Partha>

> inputs from wider team to see what we can have as an unique 
[JRE] There have been one or two initiatives to standardize a call
identifier in SIP, most recently the session-id proposal (proposed
SIPSCOTCH WG), which seems to have gone quiet recently. That proposal
had a limited scope (troubleshooting), which may or may not make it
unsuitable for SIPREC use. In fact there was discussion back in August
of the use of session-id for SIPREC, largely in the context of allowing
correlation between RSs from different SRC intances.
<Partha> This is the main reason, I was asking for session id. Session
id will use to correlate CS involved in the recording session
particularly when B2BUA acts as SRC. I'm not seeing SIPSCOTCH WG
discussed in dispatch during IETF-79. In case required, we will again
initiate the thread for more discussion during IETF-79. </Partha>
> call seems a useful attribute to have in CS block.  
[JRE] "Who terminated the call" is another example of application
information that is not necessarily available (reliably) from SIP.
<Partha> Reason header in BYE may provide the required information.
Direction of BYE may indicate "who terminated the call" in two party
call. Again, this is fuzzy in terms of conference or multi-party call.
</Partha>

> I will wait for comments from wider team on this point.
[JRE] I think it depends what we are talking about. Information that the
SRC has regarding privacy of information to be recorded is, I believe,
within the scope of SIPREC. Authorisation procedures for somebody trying
to access a recording are outside the scope of SIPREC.
<Partha> Agreed </Partha>

John

---

From: "De Villiers de Wet" <[email-masked]>
Date: Wed, 20 Oct 2010 16:55:55 +0200

Inline

From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 18 October 2010 19:12
To: De Villiers de Wet; Elwell, John
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session
Attributes

Hi De Villers,

Please see inline <Ram>

Good day

De Villiers de Wet (DdW)

Hi Team,

[DdW] Example:  a clients does not want to record internal calls, only
external calls.

[DdW] As long as a new Received Media Stream block is created the moment
the participants change, it would be sufficient to know only the Media
Stream Start/End time.  Another way to put this:  The media for any
participant associated with a Media Stream is/was by definition present
from the start of the Media Stream right up to the end.

[DdW] Agreed - this is an SRS implemention issue.

Thanks,

Ram

Regards,

Ram

---

From: "De Villiers de Wet" <[email-masked]>
Date: Wed, 20 Oct 2010 17:04:00 +0200

inline

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 20 October 2010 07:27
To: Elwell, John; Ram Mohan R (rmohanr); De Villiers de Wet
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session
Attributes

Please read inline. 

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

[DdW] The majority of recorded calls are simple calls where direction,
initiator,
termination reason, etc. are known and can be provided.  In my view its
best to cater for it in a standard
way, and not let the difficult cases like conferences prevent a standard
way being defined for the typical case.

[DdW] I did not mention that the concept of a globally 
unique call ID I referred is from the CTI world.  Since SIPREC, and SIP
in
general seems to be replacing CTI protocols and interfaces, users of 
recording systems and integrators have a need for an equivalent concept
in SIPREC.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Oct 2010 09:04:25 +0200

> From: De Villiers de Wet [mailto:[email-masked]] 
> Sent: 20 October 2010 16:04
> To: Parthasarathi R (partr); Elwell, John; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf
> Of Elwell, John
> from Leon 
> what time 
[JRE] But in some deployments the vast majority of calls are established using 3PCC, so that from a SIP point of view they all appear as incoming. I have no objection to providing this indicator, but it has to be understood there will be a sizeable proportion of cases where it will not work correctly. The group has to decide whether this leads to overall benefit or harm.

> call. Again, this is fuzzy in terms of conference or multi-party call.
[JRE] And fuzzy in terms of 3PCC too, where a third party application issues a BYE from a B2BUA.

John (as individual)

---

From: "De Villiers de Wet" <[email-masked]>
Date: Fri, 22 Oct 2010 13:18:10 +0200

Paul Kyzivat said:

	We currently lack sufficient terminology to make these
distinctions.

	- internal vs. external:

	Relative to what? Even if we classified the CS as internal or
external, 
	which participant(s) would be the internal ones and which the
external ones?

Response:

In the TDM world this was easy for most cases:  any telephone connected
to the PBX is an internal party
to a call, and any participant on the other side of a trunk to the PSTN
is an external party, so internal/external is relative to the PBX, 
so internal/external for the end-user is relative to his organization,
or local office
where the PBX resides.  It is easy to determine whether a trunk a call
was flowing over a trunk, so it is easy to determine internal/external. 
Of course inter-PBX tie-trunks in large organizations makes things more
complex.

In the VoIP world this is admittedly more difficult because of the
proliferation
of the use of trunks to connect equipment from different vendors on the
same site etc.
One needs to know for each trunk whether it carries calls to other parts
of
the same organization or to external parties, in order to classify calls
over that
trunk correctly.  This is possible, but if the environment is not
correctly set up,
e.g. a trunk is not correctly labelled in the system, it yields
incorrect 
results.  And in light of SIPREC, I think the SRC can only know this if
it's tightly integrated 
or part of a B2BUA that has all this information, probably not if it's
part of an UA.

ISTM, after all, its best left to SRC and SRS vendors to use the
application-data mechanism 
for this (i.e. not part of the standard), due to the many pitfalls in
this area.

De Villiers

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 19 October 2010 03:07
To: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes

> We got comments in alias as well as in the interim meeting from Leon
to
> whether is incoming/outgoing. Otherwise in a lot of 3PCC situations,
the
> 'external' call, i.e. at least one party is an external party. Of
course

- internal vs. external:

Relative to what? Even if we classified the CS as internal or external, 
which participant(s) would be the internal ones and which the external
ones?

- direction

with a CS, as initiating or terminating. Even then, nailing down what 
that means and how it is determined isn't necessarily going to be 
simple. And you might end up with more than one, or zero, of either
type.

OK. But I'm looking forward to a clear definition with enough normative 
teeth that you can tell if an SRC is making the classification
correctly.

> integrate with the telephony system use as a central 'hook', without

globally unique value.

> */ I don't think the standard must specify that it must be a globally
> 'Unknown' value./*
> */Call Termination Reason - for some customers knowing who terminated
> if the correct end of call 'protocol' is followed./*

> afterwards. E.g., if A and B take part in a conference call, and B
drops
> participate). Of course the SRS can 'measure' these by capturing the
> or the SRS to 'figure it out' from the events./*

> */Participant Name - often communication systems have a configured

	Thanks,
	Paul

---

From: "De Villiers de Wet" <[email-masked]>
Date: Fri, 22 Oct 2010 13:23:42 +0200

Paul Kyzivat said:

	I think this is being thought of in respect to the CS, not a
particular 
	media stream. Right now the only association we have for
participant is 
	with a media stream.

	ISTM that the best we can do here is (optionally) associate
participants 
	with a CS, as initiating or terminating. Even then, nailing down
what 
	that means and how it is determined isn't necessarily going to
be 
	simple. And you might end up with more than one, or zero, of
either type.

	...
	> What about Initiator attribute?
	...
	But I'm looking forward to a clear definition with enough
normative teeth that you can tell if an SRC is making the classification
correctly.

Response:

Why not have this as an attribute for the participant(s) associated with
each stream in the proposed model?  
They are associated with a single CS in any case indirectly via the
media stream(s), and this can handle the more complex cases where for
example there is more than 1 initiator like with a dial-in conference.
Having participants on both CS and media stream level seems
unnecessarily complex to me.

De Villiers

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 19 October 2010 03:07
To: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes

to
the
course

- internal vs. external:

- direction

globally unique value.

drops

	Thanks,
	Paul

---

From: "De Villiers de Wet" <[email-masked]>
Date: Fri, 22 Oct 2010 14:25:20 +0200

> if the correct end of call 'protocol' is followed./*

	Same comments as initiator. This especially gets complicated
when there 
	are more than two parties.

	Consider the case where a customer called in and is in
conversation with 
	two agents (conference). Eventually the customer is disconnected
but the 
	two agents continue to talk. What do you want to know in this
case?
	- who caused the customer to be dropped from the call?
	- who was the last agent to leave?

	Perhaps we need the notion of a participant leaving a CS, and a
reason 
	for that, which could include the participant leaving on their
own, one 
	of the other participants pulling the plug on them, or something
else.

Response:

The last paragraph seems like a sensible proposal.  

De Villiers

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 19 October 2010 03:07
To: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes

to
the
course

- internal vs. external:

- direction

globally unique value.

drops

	Thanks,
	Paul

---

From: "De Villiers de Wet" <[email-masked]>
Date: Fri, 22 Oct 2010 14:32:02 +0200

> provide this info to the SRS, and if it does not, enforcing
proper

	Are we talking about participation in the signaling of the CS,
or 
	participation by sending/receiving media?

	Consider a voice-only participant in a call where other
participants 
	were also using video. If this participant had access to the
audio 
	recording while participating, should he also have access to the
video 
	for that period if he wasn't sending/receiving video?

Response:

The issue is participation by sending/receiving media. For our example,
the voice-only participant
may only have access to the *voice* media *for the period he/she was
participating in the call*, i.e.
not any video media, and not for voice media before or after the period
he/she participated.

It is the job of the SRS implemenation to enforce this, but it will need
accurate who-had-access-to-what-at-what-time info to do this.

De Villiers

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 19 October 2010 03:07
To: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes

to
the
course

- internal vs. external:

- direction

globally unique value.

drops

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Oct 2010 08:52:33 -0400

This can be left to be entirely application specific, encoded as 
application-data. Or, we can model it in the metamodel but leave it to 
the SRC to determine in an application-dependent way.

Either is fine with me.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 22 Oct 2010 18:24:53 +0530

Inline <Ram>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of De Villiers de Wet
Sent: Friday, October 22, 2010 6:02 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes- participant start/end time

proper

Response:

<Ram> Start/End Time attributes is already present in Received Media
Stream block. Are you seeing the need for anything else there ?
Regarding Access of recorded data, Information that the SRC has
regarding privacy of information to be recorded is, I believe, within
the scope of SIPREC.  Other things like Authorization of users accessing
the stored data is outside scope of SIPREC.

De Villiers

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Oct 2010 09:02:45 -0400

inline

> unnecessarily complex to me.

I guess it depends on what you want.

I think *typically* each media stream sent by the SRC to the SRS will 
have one participant. (In a typical two party voice call there would be 
two streams, one for each participant.)

You could tag the participant for the stream as "originating" or 
"terminating", but that seems odd, because in every case the participant 
is originating the media stream.

I guess you could tag the participant of the media stream is 
"originating the containing CS" but that seems a bit weird too. But 
possible.

I think it would be clearer to have a separate, optional, "originator" 
relationship from CS to Participant. This could be the same participant 
as in some of the media streams, or different, or not present at all if 
unknown. How this is encoded when sending the metadata is a separate 
question. Hopefully it can be done in a way that avoids sending a lot of 
redundant data.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Oct 2010 09:14:16 -0400

> accurate who-had-access-to-what-at-what-time info to do this.

I think there is a distinction between being authorized to send/receive 
media and actually doing so.

The call may have been audio/video, but one participant had a voice-only 
phone and so was unable to participate in the video on the phone. (But 
would have been authorized to do so if his phone was capable.)

If he has some mechanism for accessing the recordings (e.g. from a PC 
during the call), I would think it would be reasonable that he be 
allowed to access the video recordings.)

But AFAIK we aren't explicitly dealing with authorization issues for the 
recordings right now. I think it should be sufficient for the SRC to 
indicate to the SRS which media each participant is sending and 
receiving. The SRS can use that as input to authorization decisions.

	Thanks,
	Paul

---

From: "De Villiers de Wet" <[email-masked]>
Date: Fri, 22 Oct 2010 16:59:15 +0200

As long as the participants don't change for the duration of a Received
Media Stream block.  If participants change, either a new Received Media
stream block must be provided, OR the model must provide Start/End times
for participations within a media block.

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 22 October 2010 14:55
To: De Villiers de Wet; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session

Inline <Ram>

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

proper

Response:

De Villiers

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 26 Oct 2010 12:07:21 +0530

Hi De Villiers,
Inline <Ram>

-----Original Message-----
From: De Villiers de Wet [mailto:[email-masked]] 
Sent: Friday, October 22, 2010 8:29 PM
To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session

As long as the participants don't change for the duration of a Received
Media Stream block.  If participants change, either a new Received Media
stream block must be provided, OR the model must provide Start/End times
for participations within a media block.
<Ram> Our intent in the proposed model is  the Received Media Stream
would change each time there was a participant change. So there would be
a new instance of Received Media stream

Thanks,
Ram

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 22 October 2010 14:55
To: De Villiers de Wet; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session

Inline <Ram>

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

proper

Response:

De Villiers

---

From: "De Villiers de Wet" <[email-masked]>
Date: Thu, 28 Oct 2010 16:14:46 +0200

Hi Ram

The intended model as you describe would be sufficient to enable a SRS
to provide the necessary access control mechanisms to recorded media.

Question:  should there not be a requirement in the SIPREC requirements
RFC about this?  Something like the following:

	The metadata model MUST provide sufficient information to enable
a SRS to determine accurately which participants generated and/or had
access (or authorization to access) to which Media Streams., for the
purpose of enforcing proper access control to RSs or parts of RSs
afterwards.

De Villiers

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 26 October 2010 08:37
To: De Villiers de Wet; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session

Hi De Villiers,
Inline <Ram>

-----Original Message-----
From: De Villiers de Wet [mailto:[email-masked]] 
Sent: Friday, October 22, 2010 8:29 PM
To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session

Thanks,
Ram

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 22 October 2010 14:55
To: De Villiers de Wet; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Metadata Open item : Communication Session

Inline <Ram>

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

proper

Response:

De Villiers

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Oct 2010 10:44:16 -0400

> purpose of enforcing proper access control to RSs or parts of RSs

The SRC will, in general, have limited information to provide.
Presumably it knows the *immediate* source(s) and destination(s) of 
media streams, as indicated of o/a exchanges. It may have some added 
information about conferencing and the related mixing and distribution 
of some media streams before they reach the SRC.

But that's about it. The rest is policy. Maybe the SRC will be 
responsible for adding policy info, or maybe not.

	Thanks,
	Paul

> Inline<Ram>
> Inline<Ram>