Subject: [siprec] Updated draft-ram-siprec-metadata for review

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 Oct 2010 15:12:39 +0530

Hi All,

We have updated the draft based on the comments received  so far and
posted a updated version. The draft is available at

https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/

Kindly review the same and provide your inputs

Also the below mail thread has the open issues that I have sent some
time back.  Please let us know your comments on the open issues.

Ram / Partha/ Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ram Mohan R (rmohanr)
Sent: Thursday, September 30, 2010 5:12 PM
To: [email-masked]
Subject: [siprec] Discuss open items on draft-ram-siprec-metadata-00

Hi Team,

These are some of the open items on draft-ram-siprec-metadata-00
(http://www.ietf.org/id/draft-ram-siprec-metadata-00.txt).

 We would like get thoughts from folks to get the discussion moving on
these items. 

Also we would like to hear from folks on what additional things they
would like to see in the metadata model.

Metadata Model: Recording Session Group

These is optional and is Used when multiple RS need to be related (e.g.
recording initiated by multiple participants.)

Do we need this element ? if yes What attributes it should have ?
(type/usage/reason ? )

The Recording Session in the model currently has following attributes.
What other attributes does  the team like to see ? 

*        Recording Requestor ID  (SRC/SRS)

*       Recording Reason

*       Recording Type  (Selective/Persistant)

Metadata Model: Communication Session

What are the attributes we need to CS ?

Also please look at Metadata Model: Recorded Media Stream and Metadata
Model: Received Media Stream and comment on what additional attributes
are needed

Application data

The model intends to allow any number of application data objects
attached to any of the others elements

*       We need a type identifier.

-      What namespace?

-      What assignment rules?

*       Do we need a data encoding type separate from type id?

*       How do we represent / transmit the opaque data?

-      Text/binary

Please give your inputs

Regards,

Ram

---

From: Leon Portman <[email-masked]>
Date: Thu, 7 Oct 2010 13:23:02 +0200

Hi,

Following my initial comments:

1.    Introduction

a.    Typo: metadata modelas -> model as

2.    Metadata model

a.    As it is presented, the model describes both communication session and recording session including recorded media. Actually may be we even should have to separate models, one for communication session and second that describes recording session. Because for example we always should have communication  session description, but there are lot of implementation where recording session, request, recorded media is completely internal for SRS.

b.    Recording Session - we also should have indication what media was requested to be recorded. Currently model have only actually recorded media, but if for example Video was also requested to be recorded but for some reason was not, there is no representation of the request

c.    I think the order between Recorded Media Stream and Received Media stream should be reversed. It is very confusing as it is now for reading. Because, if I understand correctly, SRS first receives Received Media Streams and then stores (may be including summation and transcoding) Recorded media stream. May be we even instead of Received Media Stream user term like Original Media Stream or Source Media Stream

d.    We should support both options SRC Initiated recording and SRS initiated recording. Why do we need to state the "MUST" for in second paragraph?

3.    Recording metadata elements

a.    Recording Session - as I stated above, we should add following elements: requested media as well

b.    Communication Session . I think we need at least following elements: Call Id, Initiator, Direction. I need to think more about it.

c.    Recorded media Streams - if the streams are stored encrypted (usually they are), we also should have some kind of KeyID here

d.    Participant - we also should include status: active, on hold, etc. and role: initiator, participant etc.
Regards

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Thursday, October 07, 2010 11:43 AM
To: [email-masked]
Subject: [siprec] Updated draft-ram-siprec-metadata for review

Hi All,

We have updated the draft based on the comments received  so far and posted a updated version. The draft is available at
https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/

Also the below mail thread has the open issues that I have sent some time back.  Please let us know your comments on the open issues.

Ram / Partha/ Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Thursday, September 30, 2010 5:12 PM
To: [email-masked]
Subject: [siprec] Discuss open items on draft-ram-siprec-metadata-00

Hi Team,

These are some of the open items on draft-ram-siprec-metadata-00 (http://www.ietf.org/id/draft-ram-siprec-metadata-00.txt).
 We would like get thoughts from folks to get the discussion moving on these items.

Also we would like to hear from folks on what additional things they would like to see in the metadata model.

Metadata Model: Recording Session Group
These is optional and is Used when multiple RS need to be related (e.g. recording initiated by multiple participants.)
Do we need this element ? if yes What attributes it should have ?  (type/usage/reason ? )

The Recording Session in the model currently has following attributes. What other attributes does  the team like to see ?
*        Recording Requestor ID  (SRC/SRS)
*       Recording Reason
*       Recording Type  (Selective/Persistant)

Also please look at Metadata Model: Recorded Media Stream and Metadata Model: Received Media Stream and comment on what additional attributes are needed

Application data
The model intends to allow any number of application data objects attached to any of the others elements
*       We need a type identifier.
-      What namespace?
-      What assignment rules?
*       Do we need a data encoding type separate from type id?
*       How do we represent / transmit the opaque data?
-      Text/binary

Please give your inputs

Regards,
Ram

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Oct 2010 15:16:24 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: 07 October 2010 12:23
> To: Ram Mohan R (rmohanr); [email-masked]
> Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review
> 
> Hi,
> 
>  
> 
> a.    As it is presented, the model describes both 
> communication session and recording session including 
> recorded media. Actually may be we even should have to 
> separate models, one for communication session and second 
> that describes recording session. Because for example we 
> always should have communication  session description, but 
> there are lot of implementation where recording session, 
> request, recorded media is completely internal for SRS.
[JRE] I don't understand why we would need two separate models. It should be possible to have a single model that will be applicable to a wide range of deployments.

> 
> b.    Recording Session - we also should have indication what 
> media was requested to be recorded. Currently model have only 
> actually recorded media, but if for example Video was also 
> requested to be recorded but for some reason was not, there 
> is no representation of the request
> 
> c.    I think the order between Recorded Media Stream and 
> Received Media stream should be reversed. It is very 
> confusing as it is now for reading. Because, if I understand 
> correctly, SRS first receives Received Media Streams and then 
> stores (may be including summation and transcoding) Recorded 
> media stream. May be we even instead of Received Media Stream 
> user term like Original Media Stream or Source Media Stream
[JRE] Order is not relevant in such a model. What is important is whether it is Received Media Stream or Recorded Media stream that should have a direct relationship with CS, and from that point of view you might have a valid concern. In fact the CS could have n1 media streams. Some could be mixed by the SRC before sending on the SRS, resulting in n2 media streams delivered to the SRS, and the SRS could do further mixing resulting in n3 streams being recorded, where n1>=n2>=n3. I imagine the present model assumes no mixing at the SRC (n1==n2). If my understanding is correct, it makes more sense to reverse the positions of the two object types in the model.

> 
> d.    We should support both options SRC Initiated recording 
> and SRS initiated recording. Why do we need to state the 
> "MUST" for in second paragraph?
[JRE] We have been having this debate outside the context of metadata model - is it relevant to the metadata model?

> a.    Recording Session - as I stated above, we should add 
> following elements: requested media as well 
> 
> b.    Communication Session . I think we need at least 
> following elements: Call Id, Initiator, Direction. I need to 
> think more about it.
[JRE] I am not sure whether direction is necessarily meaningful. In a lot of 3PCC situations, the UA is the recipient of the INVITE request, even if the user requested the call (e.g., through a web page). 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.

> 
> c.    Recorded media Streams - if the streams are stored 
> encrypted (usually they are), we also should have some kind 
> of KeyID here
[JRE] Storage is out of scope. Or are you saying the SRC should be able to supply a key that will be used for recording, in which case I guess it would be in scope.

> 
> d.    Participant - we also should include status: active, on 
> hold, etc. and role: initiator, participant etc.
[JRE] Concerning "initiator", my comment above on "direction" applies, unless you mean something different.

John (as individual)

> 
> Regards
> 
>  
> 
>  
> 
> Leon
> 
>  
> 
>  
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> We have updated the draft based on the comments received  so 
> far and posted a updated version. The draft is available at
> 
> Also the below mail thread has the open issues that I have 
> sent some time back.  Please let us know your comments on the 
> open issues.
> 
>  
> 
> Ram / Partha/ Paul
> 
>  
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Also we would like to hear from folks on what additional 
> things they would like to see in the metadata model.
> 
>  
> 
> These is optional and is Used when multiple RS need to be 
> related (e.g. recording initiated by multiple participants.)
> 
> The Recording Session in the model currently has following 
> attributes. What other attributes does  the team like to see ? 
> 
> Also please look at Metadata Model: Recorded Media Stream and 
> Metadata Model: Received Media Stream and comment on what 
> additional attributes are needed
> 
>  
> 
> Application data
> 
> The model intends to allow any number of application data 
> objects attached to any of the others elements
>

---

From: Leon Portman <[email-masked]>
Date: Thu, 7 Oct 2010 15:47:33 +0200

Please see below

I also remembered that we also need retention parameters for the recording request: Retention (minimum time for storage) and Force Delation (maximum time for storage). It should be per media type

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, October 07, 2010 3:16 PM
To: Leon Portman; Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

[LP] OK, agree

[JRE] Order is not relevant in such a model. What is important is whether it is Received Media Stream or Recorded Media stream that should have a direct relationship with CS, and from that point of view you might have a valid concern. In fact the CS could have n1 media streams. Some could be mixed by the SRC before sending on the SRS, resulting in n2 media streams delivered to the SRS, and the SRS could do further mixing resulting in n3 streams being recorded, where n1>=n2>=n3. I imagine the present model assumes no mixing at the SRC (n1==n2). If my understanding is correct, it makes more sense to reverse the positions of the two object types in the model.
[LP] If I remember correctly, currently it is also out of scope when SRC mixes media from different CSs (like for trading floor turret scenario)

[JRE] We have been having this debate outside the context of metadata model - is it relevant to the metadata model?
[LP] Now, when we don't have REQ-5 and 6, we should not state it here either. 

[JRE] I am not sure whether direction is necessarily meaningful. In a lot of 3PCC situations, the UA is the recipient of the INVITE request, even if the user requested the call (e.g., through a web page). 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.
[LP] So if we will have Initiator indication on participant level, we can correctly represent logic direction (it is important for contact centers)

[JRE] Storage is out of scope. Or are you saying the SRC should be able to supply a key that will be used for recording, in which case I guess it would be in scope.
[LP] It is back to my first comment, that representing of Recorded Media Stream is somewhat internal for SRS. SRS keeps lots of additional data for each recorded media - encryption keys (for storage), handles, paths, retention attributes etc.

John (as individual)

> *       How do we represent / transmit the opaque data?
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Oct 2010 09:53:59 -0400

Leon,

Thank you for the thoughtful input. Finally we can get down to 
discussing what all this stuff really means. I have a number of comments 
and questions below in an attempt to refine this.

	Thanks,
	Paul

On 10/7/2010 7:23 AM, Leon Portman wrote:
> a. As it is presented, the model describes both communication session
> and recording session including recorded media. Actually may be we even
> should have to separate models, one for communication session and second
> that describes recording session. Because for example we always should
> have communication session description, but there are lot of
> implementation where recording session, request, recorded media is
> completely internal for SRS.

I don't understand your point.

In the abstract you could imagine independent CS and RS, and then some 
linkage between them. But at least as we have been discussing this, its 
the SRC that knows about the CS. The SRS only knows about CS to the 
extent that the SRC communicates that information to the SRS.

Are you suggesting that the SRC might send to the SRS information about 
media streams in the CS that the SRS is not being asked to record?

> b. Recording Session – we also should have indication what media was
> requested to be recorded. Currently model have only actually recorded
> media, but if for example Video was also requested to be recorded but
> for some reason was not, there is no representation of the request

Does that mean you want to have Received Media Streams with no 
corresponding Recorded Media Stream?

Or do you want a way to describe streams that are not even received (by 
the SRS)? (Then the SRC would require a way to communicate that info too.)

Do you need a way to record the *reason* that the stream was not recorded?

> c. I think the order between Recorded Media Stream and Received Media
> stream should be reversed. It is very confusing as it is now for
> reading. Because, if I understand correctly, SRS first receives Received
> Media Streams and then stores (may be including summation and
> transcoding) Recorded media stream. May be we even instead of Received
> Media Stream user term like Original Media Stream or Source Media Stream

I don't care about the names very much, as long as they don't generate 
confusion. We should be careful about the perspective from which the 
names are understood. In my mind this model is drawn from the 
perspective of the SRS. From that perspective "received" "original" and 
"source" all seem equally good to me. If someone is not clear on the 
perspective that might not be so.

In terms of the "order", I could see Recorded Media Stream and Received 
Media Stream both being connected (children?) of CS, and then also 
having a relationship to each other. (That also relates to your earlier 
point.)

> d. We should support both options SRC Initiated recording and SRS
> initiated recording. Why do we need to state the “MUST” for in second
> paragraph?

I think Ram was just reflecting the group decisions. But I see no need 
for that MUST in this document.

> a. Recording Session – as I stated above, we should add following
> elements: requested media as well
>
> b. Communication Session . I think we need at least following elements:
> Call Id, Initiator, Direction. I need to think more about it.

I understand need for such things. Nailing down the details requires 
sorting out ambiguities about what a CS includes. It sounds like you 
consider a CS to consist of a single sip dialog. In that case the 
attributes you suggest are well defined.

But I think a CS will sometimes (maybe always) consist of more than one 
dialog.

- most are expecting the SRC to be a B2UA. If so then there are at least
   two dialogs, so two Call IDs.

- it could be that the SRC was the initiator (called both parties into
   a CS.) (E.g. if the SRC was a conference focus and called out to all
   the participants.)

- What do you mean by Direction? Of the signaling, or the media?

- I think some are expecting that in a call center scenario, if the
   agent has a side consultation with a supervisor, which is a separate
   dialog with no shared media, that is also part of the same CS.

*In principle* we might need a connectivity matrix among all the 
participants, indicating who heard whom. But that seems hard. Maybe we 
can find something simpler.

> c. Recorded media Streams – if the streams are stored encrypted (usually
> they are), we also should have some kind of KeyID here

Sure. What is the type/namespace for such a thing? Is it just a string?

> d. Participant – we also should include status: active, on hold, etc.
> and role: initiator, participant etc.

Well, I think dynamic status should not be part of the Participant, but 
rather should be reflected in other objects or their relationship to the 
participant.

So it would be the received media stream that is on hold, or the fact 
that it is on hold is reflected by there not being a received media 
stream while the participant is on hold.

There's a better case for the role being an attribute of the 
participant. But I guess that depends on how you see things. Consider if 
you were recording a CS that is a conference. Perhaps initially a given 
participant calls in to the conference, and so is an "initiator" (of his 
particular stream anyway, if not the entire CS.) Then he may hang up and 
be called back by the focus. If so, and if role is an attribute of 
Participant, then this user will be treated as two different 
participants, rather than just one.

That also points out another issue. Is role (initiator/participant) with 
respect to a CS, or a Received Media Stream?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Oct 2010 10:21:34 -0400

> I also remembered that we also need retention parameters for the recording request: Retention (minimum time for storage) and Force Delation (maximum time for storage). It should be per media type

Are these things that are passed from SRC to SRS?
Or are these *policies* at the SRS?

Or is it both? (SRC can pass request. SRS may or may not honor, based on 
policy.)

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Thu, 7 Oct 2010 17:28:12 +0200

Usually it is a policy on SRS side, however it is also can be part of the recording request. The reason that I proposed that, that if we are trying to model REQUEST->CS->ResMS->RecMS it is definitely part of RecMS (Recorded media stream information)

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, October 07, 2010 4:22 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Thu, 7 Oct 2010 17:32:46 +0200

Paul, welcome

Please see below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, October 07, 2010 3:54 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

Leon,

	Thanks,
	Paul

[LP] Usually not, however we have use cases where it is the case. 
However my point was that representation of Recorded Media Streams for example, is not always exposed outside of SRS.

> b. Recording Session - we also should have indication what media was

Or do you want a way to describe streams that are not even received (by 
the SRS)? (Then the SRC would require a way to communicate that info too.)
[LP] Actually it is another use case, my example was that somebody requested video to be recorded and it is not in Received Media Stream

[LP] Probably yes

> initiated recording. Why do we need to state the "MUST" for in second
> paragraph?

- it could be that the SRC was the initiator (called both parties into
   a CS.) (E.g. if the SRC was a conference focus and called out to all
   the participants.)
[LP] Correct, and if SRC do not know relation between them, they will be reported as multiple CS, however in Contact Center Environment, SRC usually know that they belong to one logical session, 
So if it  knows that, it can report the Id.

- What do you mean by Direction? Of the signaling, or the media?
[Lp} Inbound, outbound. At least who was the originator of the CS.

> c. Recorded media Streams - if the streams are stored encrypted (usually

Sure. What is the type/namespace for such a thing? Is it just a string?
[LP] usually it is a GUID, some unique ID. So string will be OK.

[LP] Good point, we need both. We need to know participation in CS but also for media (Rx or TX)
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Oct 2010 17:35:57 +0200

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 07 October 2010 14:48
> To: Elwell, John; Ram Mohan R (rmohanr); [email-masked]
> Subject: RE: Updated draft-ram-siprec-metadata for review
> 
> Please see below
> 
> I also remembered that we also need retention parameters for 
> the recording request: Retention (minimum time for storage) 
> and Force Delation (maximum time for storage). It should be 
> per media type
> 
> Regards
> 
> Leon
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> [JRE] I don't understand why we would need two separate 
> models. It should be possible to have a single model that 
> will be applicable to a wide range of deployments.
> [LP] OK, agree
> 
> > 
> [JRE] Order is not relevant in such a model. What is 
> important is whether it is Received Media Stream or Recorded 
> Media stream that should have a direct relationship with CS, 
> and from that point of view you might have a valid concern. 
> In fact the CS could have n1 media streams. Some could be 
> mixed by the SRC before sending on the SRS, resulting in n2 
> media streams delivered to the SRS, and the SRS could do 
> further mixing resulting in n3 streams being recorded, where 
> n1>=n2>=n3. I imagine the present model assumes no mixing at 
> the SRC (n1==n2). If my understanding is correct, it makes 
> more sense to reverse the positions of the two object types 
> in the model.
> [LP] If I remember correctly, currently it is also out of 
> scope when SRC mixes media from different CSs (like for 
> trading floor turret scenario)
[JRE] Yes, it is out of scope, but I was just trying to understand the whole picture, not trying to suggest we extend the model. So the original streams are those that the SRC sends (after possible mixing in the SRC), and the recorded streams are what the SRS records (after possible mixing by the SRS). But perhaps that too is outside the scope of SIPREC - the most important thing is awareness of the streams transmitted over the SIPREC interface.

> [JRE] We have been having this debate outside the context of 
> metadata model - is it relevant to the metadata model?
> [JRE] I am not sure whether direction is necessarily 
> meaningful. In a lot of 3PCC situations, the UA is the 
> recipient of the INVITE request, even if the user requested 
> the call (e.g., through a web page). 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.
> [LP] So if we will have Initiator indication on participant 
> level, we can correctly represent logic direction (it is 
> important for contact centers)
[JRE] My concern is whether the SRC necessarily has access to information as two who is logically the initiator. It might only know whether it is sent or received the initial INVITE request, and I am not yet convinced this is something worthy of recording.

> [JRE] Storage is out of scope. Or are you saying the SRC 
> should be able to supply a key that will be used for 
> recording, in which case I guess it would be in scope.
> [LP] It is back to my first comment, that representing of 
> Recorded Media Stream is somewhat internal for SRS. SRS keeps 
> lots of additional data for each recorded media - encryption 
> keys (for storage), handles, paths, retention attributes etc.
[JRE] Yes, so it depends on the scope of the metadata model. Since the metadata model is primarily there for determining what needs to be conveyed over the SIPREC interface, we should try to avoid putting too much in there that is essentially internal to the SRS or the stored recording.

John (as individual)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 Oct 2010 22:57:25 +0530

Leon,

Thanks a lot for your valuable comments. Please see inline <Ram> for
some of my questions/comments on top of Paul's comments.

Regards,
Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Thursday, October 07, 2010 9:03 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

Paul, welcome

Please see below

-----Original Message-----
Of Paul Kyzivat

Leon,

	Thanks,
	Paul

[LP] Usually not, however we have use cases where it is the case. 
However my point was that representation of Recorded Media Streams for
example, is not always exposed outside of SRS.

<Ram> Our visualization is SRS needs to know both about CS and RS and it
needs to be associated and that's what the model tries to depict by
showing them together. Please note not all blocks of the model are
mandatory. We can have zero or more instances. So for implementations
where RS is internal for SRS these blocks need not be present in the
model. Please let me know if that is fine or you see a need for a change

Or do you want a way to describe streams that are not even received (by 
the SRS)? (Then the SRC would require a way to communicate that info
too.)
[LP] Actually it is another use case, my example was that somebody
requested video to be recorded and it is not in Received Media Stream

<Ram> Are you talking about a case where SRC offers certain types
(audio, video) of media in offer which it plans to send and SRS choose
to record only part of them (like only Audio) and responds back in
answer with the same (e.g by setting m-line to 0 for those streams for
which SRS does not wish to record media)  ? 
If we see a value in representing this information in metadata model I
can add it.
We still need to see where to add this information though. I am not yet
convinced if Recording Session is the right place to add this
information

Do you need a way to record the *reason* that the stream was not
recorded?
[LP] Probably yes
<Ram> Along with the above information SRS can even insert the reason
why it choose not to record that media stream. 
I suppose the decision to record OR not a stream will reside with SRS
right ? 

I think Ram was just reflecting the group decisions. But I see no need 
for that MUST in this document.
<Ram>  As per my understanding we have agreed that in the first phase
only SRC can initiate recording. So I have mentioned "MUST"
Please correct me if my understanding is wrong

- it could be that the SRC was the initiator (called both parties into
   a CS.) (E.g. if the SRC was a conference focus and called out to all
   the participants.)
[LP] Correct, and if SRC do not know relation between them, they will be
reported as multiple CS, however in Contact Center Environment, SRC
usually know that they belong to one logical session, 
So if it  knows that, it can report the Id.
<Ram> I think we still need to see if it make sense to report  two call
IDs or some other unique ID taking in to consideration B2BUA that can
act as SRC

- What do you mean by Direction? Of the signaling, or the media?
[Lp} Inbound, outbound. At least who was the originator of the CS.
<Ram> Leon, I am still not clear with initiator and Direction. In cases
where SRC is B2BUA, originator of the CS would be one of the end points.
How do we determine what is the direction w.r.t Recording Session ? And
What should be the initiator ? should it be the end point's information
? if so what ?

participant.

[LP] Good point, we need both. We need to know participation in CS but
also for media (Rx or TX)
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 Oct 2010 23:16:55 +0530

Leon,
Thanks for bringing this up.

I feel these are good parameters to have in the Metadata model:
Retention (minimum time for storage) and Force Delation (maximum time
for storage).

There may be cases where an SRC might want to delete a stream that is
being recorded and it could send a request with Retention value set to 0

Ram
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Thursday, October 07, 2010 8:58 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

Usually it is a policy on SRS side, however it is also can be part of
the recording request. The reason that I proposed that, that if we are
trying to model REQUEST->CS->ResMS->RecMS it is definitely part of RecMS
(Recorded media stream information)

Leon

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

On 10/7/2010 9:47 AM, Leon Portman wrote:
> Please see below
>
> I also remembered that we also need retention parameters for the
recording request: Retention (minimum time for storage) and Force
Delation (maximum time for storage). It should be per media type

policy.)

	Thanks,
	Paul

> [JRE] I don't understand why we would need two separate models. It
should be possible to have a single model that will be applicable to a
wide range of deployments.
> [JRE] Order is not relevant in such a model. What is important is
whether it is Received Media Stream or Recorded Media stream that should
have a direct relationship with CS, and from that point of view you
might have a valid concern. In fact the CS could have n1 media streams.
Some could be mixed by the SRC before sending on the SRS, resulting in
n2 media streams delivered to the SRS, and the SRS could do further
mixing resulting in n3 streams being recorded, where n1>=n2>=n3. I
imagine the present model assumes no mixing at the SRC (n1==n2). If my
understanding is correct, it makes more sense to reverse the positions
of the two object types in the model.
> [LP] If I remember correctly, currently it is also out of scope when
SRC mixes media from different CSs (like for trading floor turret
scenario)
> [JRE] We have been having this debate outside the context of metadata
model - is it relevant to the metadata model?
> [JRE] I am not sure whether direction is necessarily meaningful. In a
lot of 3PCC situations, the UA is the recipient of the INVITE request,
even if the user requested the call (e.g., through a web page). 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.
> [LP] So if we will have Initiator indication on participant level, we
can correctly represent logic direction (it is important for contact
centers)
> [JRE] Storage is out of scope. Or are you saying the SRC should be
able to supply a key that will be used for recording, in which case I
guess it would be in scope.
> [LP] It is back to my first comment, that representing of Recorded
Media Stream is somewhat internal for SRS. SRS keeps lots of additional
data for each recorded media - encryption keys (for storage), handles,
paths, retention attributes etc.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 Oct 2010 23:21:43 +0530

A typo in my previous mail. See below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ram Mohan R (rmohanr)
Sent: Thursday, October 07, 2010 11:17 PM
To: Leon Portman; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

Leon,

I feel these are good parameters to have in the Metadata model:
Retention (minimum time for storage) and Force Deletion (maximum time
for storage).

There may be cases where an SRC might want to delete a stream that is
being recorded and it could send a request with *Force Deletion* value
set to 0

Ram
-----Original Message-----

Leon

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

policy.)

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Fri, 8 Oct 2010 10:51:55 +0200

Ram, hi

Please see below

Regards

Leon

> model. Please let me know if that is fine or you see a need for a change

[LP] yes, I am ok

> [LP] yes, but it can also be external to SRS , like SRC does not support video forking, or it was declined by one of the participants
> 

[LP] yes, but even for the first phase nothing actually limits to implement it other way around.

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 8 Oct 2010 09:25:07 -0700

>    dialog with no shared media, that is also part of the same CS.
[[hlum]] I think side conversations would contribute to a separate
received media stream as part of the same CS.
 
> can find something simpler.

[[hlum]] Yes, using a matrix seems to be the most natural way to
describe a complex call center scenario if the SRC mixes the recorded
media. As a different example than side conversation, the supervisor can
be listening to a customer-agent conversation but can whisper to the
agent only. If SRC mixes the customer-agent-supervisor conversation then
the received media stream will have 3 participants but has no way of
explaining how media is joined between the participants. I see that we
consider adding a direction in participant but that is not enough to
describe the whisper conversation to the agent with
ReceivedMediaStream->Participant relationship. I think we will have to
introduce an association in Participant listing the set of other
Participants this participant can hear. This can be an optional
association meaning the participants hears everyone else if this is not
defined.

It would also be interesting to figure out the modeling for active
speaker mixes where typically a conference mixer only mixes audio
sources from the N-loudest speakers (N usually being a fairly small
number). Assuming the Received Media Stream includes all the
Participants for the conference, how do we model the view that only the
few loudest speakers made it to the mixed stream. Presumably we don't
remove the participants from the association so we may need a flag in
the Participant to show that is the active participant.

Regards,
Henry

-------------------------------------------------------------------------------------------------------------------
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: Fri, 08 Oct 2010 14:10:27 -0400

> received media stream as part of the same CS.

Yes, me too. But that then introduces the matrixing issues discussed below.

> association meaning the participants hears everyone else if this is not

This could get very complex. Lets understand the scope of the problem, 
and then propose some solutions. I suspect we may have to make a bunch 
of simplifying assumptions to make practical progress.

A matrix of all the participants, giving (for voice) the percentage 
volume heard would cover it. But I don't know how we would transmit all 
that. And its different depending on the medium.

(For video, do you want to know how big the image was shown? Or the 
resolution? Or if it was partially occluded?)

And of course there is then a time series of these matrices.

> the Participant to show that is the active participant.

Unless the mixer is the SRC I think there is slim chance of getting this 
information. You are lucky to get the roster of participants.

And this information changes very rapidly. I would think the only 
feasible way would be tracking the sources of the media in RTP and RTCP, 
if that stuff is correct and can be correlated with the other roster 
information.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 13 Oct 2010 06:51:47 +0530

As discussed below, The matrix of participants relationship is not the right approach. The default behavior for media is "all" the participant receive the media from "sender" participant. The selective  "receiving" participants for a "sender" participant looks better approach w.r.t metadata but we have to be clear with the architecture for the same as there is an overlap between conference and whisper calls.
 
Thanks
Partha

________________________________

From: [email-masked] on behalf of Paul Kyzivat (pkyzivat)
Sent: Fri 10/8/2010 11:40 PM
To: Henry Lum
Cc: [email-masked]; Leon Portman
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

        Thanks,
        Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 13 Oct 2010 09:49:35 +0200

Partha, Hi

So if I understand correctly what you are suggesting is to have for each CS media stream, a list in the metadata that contains participants, and for each participant indication if he receives it or transmits into it? It can work.

Leon

From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: Wednesday, October 13, 2010 3:22 AM
To: Paul Kyzivat (pkyzivat); Henry Lum
Cc: [email-masked]; Leon Portman
Subject: RE: [siprec] Updated draft-ram-siprec-metadata for review

Thanks
Partha

        Thanks,
        Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 14 Oct 2010 20:09:14 +0530

Leon,
 
As you expect, we can classify participant as sender or receiver for
each received stream in the metadata. It may be prefer to create new
optional metadata block "receiving" participant to represent the list of
receiving participants which is linked to the current participant. The
optional "receiving" participant metadata block helps to articulate this
whisper call service easily from the normal data. I'm interested in
hearing your opinion here.
 
Also, I'm interested in wider audience for the acceptance of including
whisper call handling in SIPREC. 
 
Thanks
Partha

From: Leon Portman [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 1:20 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Henry Lum
Cc: [email-masked]
Subject: RE: [siprec] Updated draft-ram-siprec-metadata for review

Partha, Hi

So if I understand correctly what you are suggesting is to have for each
CS media stream, a list in the metadata that contains participants, and
for each participant indication if he receives it or transmits into it?
It can work.

Leon

As discussed below, The matrix of participants relationship is not the
right approach. The default behavior for media is "all" the participant
receive the media from "sender" participant. The selective  "receiving"
participants for a "sender" participant looks better approach w.r.t
metadata but we have to be clear with the architecture for the same as
there is an overlap between conference and whisper calls.

Thanks

Partha

> received media stream as part of the same CS.

Yes, me too. But that then introduces the matrixing issues discussed
below.

        Thanks,
        Paul

> Henry
------------------------------------------------------------------------
-------------------------------------------
> 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: Leon Portman <[email-masked]>
Date: Thu, 14 Oct 2010 17:06:49 +0200

Partha, Hi

Yes, I think it will be right approach to represent for each participant which participant receives the media (per media type of course).

Regards

leon

From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: Thursday, October 14, 2010 4:39 PM
To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum
Cc: [email-masked]
Subject: RE: [siprec] Updated draft-ram-siprec-metadata for review

Leon,

As you expect, we can classify participant as sender or receiver for each received stream in the metadata. It may be prefer to create new optional metadata block "receiving" participant to represent the list of receiving participants which is linked to the current participant. The optional "receiving" participant metadata block helps to articulate this whisper call service easily from the normal data. I'm interested in hearing your opinion here.

Also, I'm interested in wider audience for the acceptance of including whisper call handling in SIPREC.

Thanks
Partha

Leon

Thanks
Partha

        Thanks,
        Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Oct 2010 11:35:07 +0200

I can't help wondering whether we need to cope with two different views, let's call them user-centric and conference-centric.

The user-centric view would apply when recording takes place on behalf of a particular user (e.g., on request from the user, enterprise policy for a class of user, etc.). That user's view of the CS is recorded. 
The SRC would be located at the user's end device, or on the path to that end device. Where the two users are in different domains, the SRC would be in the domain of the user whose view is to be recorded. Even when the user is engaged in a conference, only that user's view of the conference is recorded.

With conference-centric view, a participant-neutral view of the CS is recorded. The SRC would typically be collocated with the focus/mixer.

The approach of representing for each participant, which participant receives a given medium, seems to work for the conference-centric view. It also happens to work for the user-centric view in the case of a two-party CS. It doesn't seem to work too well for the user-centric view when the user is part of a conference. The view will probably not be able to capture what other users are receiving from each other, only what the local user is receiving from other users and sending to other users. Do we need a different model for this case, or can we keep the proposed model and treat the conference as a single user? In that case it could be viewed as a two-party CS and the model would kind of work.

John (as individual)

> Sent: 14 October 2010 16:07
> Yes, I think it will be right approach to represent for each 
> participant which participant receives the media (per media 
> type of course).
> 
>  
> 
> Regards
> 
>  
> 
> leon 
> 
>  
> 
> As you expect, we can classify participant as sender or 
> receiver for each received stream in the metadata. It may be 
> prefer to create new optional metadata block "receiving" 
> participant to represent the list of receiving participants 
> which is linked to the current participant. The optional 
> "receiving" participant metadata block helps to articulate 
> this whisper call service easily from the normal data. I'm 
> interested in hearing your opinion here.
> 
>  
> 
> Also, I'm interested in wider audience for the acceptance of 
> including whisper call handling in SIPREC. 
> 
>  
> 
> Thanks
> 
> Partha
> 
>  
> 
> So if I understand correctly what you are suggesting is to 
> have for each CS media stream, a list in the metadata that 
> contains participants, and for each participant indication if 
> he receives it or transmits into it? It can work.
> 
>  
> 
> Leon
> 
>  
> 
> As discussed below, The matrix of participants relationship 
> is not the right approach. The default behavior for media is 
> "all" the participant receive the media from "sender" 
> participant. The selective  "receiving" participants for a 
> "sender" participant looks better approach w.r.t metadata but 
> we have to be clear with the architecture for the same as 
> --------------------------------------------------------------
> -----------------------------------------------------
> > 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: Fri, 15 Oct 2010 08:46:06 -0400

Is there a requirement to track the *volume* at which the media is 
received by the participant? That might be so if not all participants 
receive the stream at the same volume.

I'm thinking of this with whisper coaching from supervisor to agent in 
mind. But in that case I think the agent is the only recipient, and so 
the "whisper" volume can perhaps be considered the only volume. I guess 
that depends on whether the volume is reduced before sending, or when it 
is mixed with the customer audio for the agent. IOW, will the media from 
the supervisor be delivered to the SRS at the volume that the agent 
hears it?

It would be simpler if we didn't have to track volume for audio streams 
and could just let the SRS assume the volume is whatever is delivered in 
the media it receives.

	Thanks,
	Paul

On 10/14/2010 11:06 AM, Leon Portman wrote:
> Partha, Hi
>
> Yes, I think it will be right approach to represent for each participant
> which participant receives the media (per media type of course).
>
> Regards
>
> leon
>
> *From:* Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* Thursday, October 14, 2010 4:39 PM
> *To:* Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum
> *Cc:* [email-masked]
> *Subject:* RE: [siprec] Updated draft-ram-siprec-metadata for review
>
> Leon,
>
> *From:* Leon Portman [mailto:[email-masked]]
> *Sent:* Wednesday, October 13, 2010 1:20 PM
> *To:* Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Henry Lum
> *Cc:* [email-masked]
> *Subject:* RE: [siprec] Updated draft-ram-siprec-metadata for review
>
> Partha, Hi
>
> *From:* Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* Wednesday, October 13, 2010 3:22 AM
> *To:* Paul Kyzivat (pkyzivat); Henry Lum
> *Cc:* [email-masked]; Leon Portman
> *Subject:* RE: [siprec] Updated draft-ram-siprec-metadata for review
>
> *From:* [email-masked] on behalf of Paul Kyzivat (pkyzivat)
> *Sent:* Fri 10/8/2010 11:40 PM
> *To:* Henry Lum
> *Cc:* [email-masked]; Leon Portman
> *Subject:* Re: [siprec] Updated draft-ram-siprec-metadata for review
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 10:58:48 -0400

> The approach of representing for each participant, which participant receives a given medium, seems to work for the conference-centric view. It also happens to work for the user-centric view in the…

ISTM a single model can work for all these situations.

In case of individual user who is participant in a conf, he might know 
the participants, and associate them all with the one mixed stream he is 
receiving. He just doesn't know as much about them. (They might all be 
sendonly.) It seems like that can be handled just by having some 
information be optional - not provided if not known.

OTOH, its possible that having a few different "models" of a CS, and 
identifying one of them, might simplify the representation. (I think it 
would still need to be possible to change the model for different 
periods during the CS.)

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Oct 2010 17:18:30 +0200

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 15 October 2010 15:59
> To: Elwell, John
> Cc: Leon Portman; Parthasarathi R (partr); Henry Lum; [email-masked]
> > I can't help wondering whether we need to cope with two 
> different views, let's call them user-centric and conference-centric.
> >
> > The user-centric view would apply when recording takes 
> place on behalf of a particular user (e.g., on request from 
> the user, enterprise policy for a class of user, etc.). That 
> user's view of the CS is recorded.
> > The SRC would be located at the user's end device, or on 
> the path to that end device. Where the two users are in 
> different domains, the SRC would be in the domain of the user 
> whose view is to be recorded. Even when the user is engaged 
> in a conference, only that user's view of the conference is recorded.
> >
> > With conference-centric view, a participant-neutral view of 
> the CS is recorded. The SRC would typically be collocated 
> with the focus/mixer.
> >
> > The approach of representing for each participant, which 
> participant receives a given medium, seems to work for the 
> conference-centric view. It also happens to work for the 
> user-centric view in the case of a two-party CS. It doesn't 
> seem to work too well for the user-centric view when the user 
> is part of a conference. The view will probably not be able 
> to capture what other users are receiving from each other, 
> only what the local user is receiving from other users and 
> sending to other users. Do we need a different model for this 
> case, or can we keep the proposed model and treat the 
> conference as a single user? In that case it could be viewed 
> as a two-party CS and the model would kind of work.
> 
[JRE] Right, I am open to going in either direction, as long as we can take care of these different cases.

John

---

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

I never saw any requirements for that. I agree on simple solution

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, October 15, 2010 2:46 PM
To: Leon Portman
Cc: [email-masked]; Henry Lum
Subject: Re: [siprec] Updated draft-ram-siprec-metadata for review

	Thanks,
	Paul