Subject: [siprec] SIP Recording Metadata :Received vs Recorded Media Streams

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

Hi Team,

>From the last interim meeting we had the following open items on
Received and Recorded Media Streams

Need for  Recorded Media Stream block in the metadata model:

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

Open Item  1: 

We received comments  in the list/interim meeting that  certain aspects
of media like  how SRS stores media, keys used e.t.c  may be outside the
scope of SIPREC.   I agree that what SRS does once it receives media may
be outside SIPREC scope.

We may still need Recorded Media Stream block and have attributes like
retention time, force deletion as these values may be passed from SRC
via SIPREC interface in the metadata. SRS can store the these attributes
in the model and can apply them to media. 

I would like to get the opinion from wider audience on whether we need a
Recorded Media Stream block before we decide to one way or other

Open item 2: 

We discussed on whether the model should include all media from CS, only
those media for which recording was requested, or only those media for
which recording was requested and accepted.

Is this really needed ? Does the wider team sees a value in having this
information  ( about all media from CS)  in the model ?

When we say all the media from CS I suppose we are referring to all the
media that is accessible to SRC ?

If we see a value in having it in the model,  I think we can represent
the same in the model .

For e.g An SRC may offer to record audio/video streams for a CS, however
SRS may choose to accept only Audio.  This information can be modeled by
having Received Media Stream block  for each offered media from SRC and
Recorded media Stream block for only those that were accepted by SRS. In
this case the presence/absence of  Recorded Media Stream block in the
model corresponding to a Received Media Stream can indicate whether
media was recorded or not.

Please let me  know your comments/opinion on these open items.

Regards,

Ram

---

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: 14 October 2010 17:54
> To: [email-masked]
> Subject: [siprec] SIP Recording Metadata :Received vs 
> Recorded Media Streams
> 
> Hi Team,
> 
>  
> 
> From the last interim meeting we had the following open items 
> on Received and Recorded Media Streams
> 
>  
> 
> --------------------------------------------------------------
> ---------------
> 
> Open Item  1: 
> 
>  
> 
> We received comments  in the list/interim meeting that  
> certain aspects of media like  how SRS stores media, keys 
> used e.t.c  may be outside the scope of SIPREC.   I agree 
> that what SRS does once it receives media may be outside SIPREC scope.
> 
> We may still need Recorded Media Stream block and have 
> attributes like retention time, force deletion as these 
> values may be passed from SRC via SIPREC interface in the 
> metadata. SRS can store the these attributes in the model and 
> can apply them to media. 
[JRE] I would agree that we need the sort of attributes you mention here, but they can be associated with the objects representing the media delivered to the SRS. Call these objects Recorded Media Streams if you wish, as long as it is clear that they represent what the SRC delivers to the SRS, and not what might eventually get recorded.

John (as individual)

> 
> I would like to get the opinion from wider audience on 
> whether we need a Recorded Media Stream block before we 
> decide to one way or other
> 
>  
> 
> Open item 2: 
> 
> We discussed on whether the model should include all media 
> from CS, only those media for which recording was requested, 
> or only those media for which recording was requested and accepted.
> 
>  
> 
> Is this really needed ? Does the wider team sees a value in 
> having this information  ( about all media from CS)  in the model ?
> 
>  
> 
> When we say all the media from CS I suppose we are referring 
> to all the media that is accessible to SRC ?
> 
> If we see a value in having it in the model,  I think we can 
> represent the same in the model .
> 
> For e.g An SRC may offer to record audio/video streams for a 
> CS, however SRS may choose to accept only Audio.  This 
> information can be modeled by having Received Media Stream 
> block  for each offered media from SRC and Recorded media 
> Stream block for only those that were accepted by SRS. In 
> this case the presence/absence of  Recorded Media Stream 
> block in the model corresponding to a Received Media Stream 
> can indicate whether media was recorded or not.
> 
>  
>

---

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

Inline <Ram>

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, October 15, 2010 2:41 PM
To: Ram Mohan R (rmohanr); [email-masked]
Subject: RE: [siprec] SIP Recording Metadata :Received vs Recorded Media
Streams

> Need for  Recorded Media Stream block in the metadata model:
[JRE] I would agree that we need the sort of attributes you mention
here, but they can be associated with the objects representing the media
delivered to the SRS. Call these objects Recorded Media Streams if you
wish, as long as it is clear that they represent what the SRC delivers
to the SRS, and not what might eventually get recorded.
John (as individual)
<Ram> We already have Received Media Streams to represent the properties
of the media delivered to SRS.  I am ok with having these attributes in
Received Media Streams in case the wider forum agrees.   

we may still need Recorded Media Stream block which can just be a
pointer to a file having raw bits as far as this model is concerned
without really worrying about how SRS stores it. The reason being we
need to have Recorded Media Stream block to map to each Received Media
Stream block so that the SRS can use the information in Received Media
Stream block and operate on the Recorded Media Stream. 

In case the wider team does not see a need for this information in the
model we will remove it

Ram

---

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

inline

On 10/14/2010 12:53 PM, Ram Mohan R (rmohanr) wrote:
> -----------------------------------------------------------------------------
>
> Open Item 1:
>
> We received comments in the list/interim meeting that certain aspects of
> media like how SRS stores media, keys used e.t.c may be outside the

Model will be simpler if we get rid of recorded media stream.
But it seems we need some home for the attributes you suggest.
Could they be placed on the received media stream? I think we need a 
better understanding of how the SRC will view things and attempt to 
attach attributes such as retention time.

> media was recorded or not.

If the SRC offers the media, and the SRS refuses it, then maybe no more 
need be done. The SRS knows about it and chose to refuse it. It can 
record that info if it wants.

I guess the issue would be if the SRS then gets a full complement of 
metadata for it, or if having refused the stream, it no longer gets 
metadata. I guess we could cover that my requiring that metadata be 
transmitted even for refused streams.

I wonder if Leon was talking about a case where the media isn't even 
available to the SRC. But in that case I'm not sure we can expect the 
SRC to provide information about it.

	Thanks,
	Paul

---

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

Couple of comments:

I still see use cases, where SRC has access to signaling thus able to extract metadata but does not have access to specific media types: like video is handled by special gateway.

Regarding retention parameters: it definitely belongs to Received Media because it is the resolution that SRS receives it. So for example SRS will not mix two Received Media streams into one Recorded Media stream if they have different retention attributes

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, October 15, 2010 3:17 PM
To: Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: Re: [siprec] SIP Recording Metadata :Received vs Recorded Media Streams

inline

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

---

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

Leon, Paul,
Thanks for comments. Please see inline <Ram>

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Sunday, October 17, 2010 2:47 PM
To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: RE: [siprec] SIP Recording Metadata :Received vs Recorded
MediaStreams

Couple of comments:

I still see use cases, where SRC has access to signaling thus able to
extract metadata but does not have access to specific media types: like
video is handled by special gateway.
<Ram> As I understand from requirements SRC is a logical entity that has
access to the media. Will we have a case that you have mentioned above ?

Also I would want suggestions on how we represent a Received Media
Stream block with no Recorded Media in the model for cases where SRS
choose not to record offered media from SRC? 
May be by having start Time/End time as  same value ? OR do we need a
new attribute in Received Media Stream that can point to Recorded Media
? 

Regarding retention parameters: it definitely belongs to Received Media
because it is the resolution that SRS receives it. So for example SRS
will not mix two Received Media streams into one Recorded Media stream
if they have different retention attributes
<Ram> Agreed. I will add Retention/force deletion as attributes to
Received Media Stream block of the metadata model. But we still need to
understand from where these attributes will be populated. Should SRC
send them always via SIPREC interface? if so based on what ? or can we
have policies in SRS ?

Thanks,
Ram

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Friday, October 15, 2010 3:17 PM
To: Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: Re: [siprec] SIP Recording Metadata :Received vs Recorded Media
Streams

inline

> We received comments in the list/interim meeting that certain aspects
of

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 10:11:44 -0400

> I still see use cases, where SRC has access to signaling thus able to extract metadata but does not have access to specific media types: like video is handled by special gateway.

Do you expect that the SRC would have access to all the same info as for 
a received media stream except for the media itself?

Could we model that as a received media stream that is permanently 
paused? Or do we need to make provision in the model for a "Non-Received 
Media Stream"?

> Regarding retention parameters: it definitely belongs to Received Media because it is the resolution that SRS receives it. So for example SRS will not mix two Received Media streams into one Record…

Makes sense.

	Thanks,
	Paul

---

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

below

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 18 October 2010 16:12
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] SIP Recording Metadata :Received vs RecordedMedia
Streams

Media Stream"?

> Regarding retention parameters: it definitely belongs to Received
Media because it is the resolution that SRS receives it. So for example
SRS will not mix two Received Media streams into one Recorded Media
stream if they have different retention attributes

Makes sense.

[DdW] The first part makes sort of sense ("belongs to Received Media
because it is the resolution that SRS receives it"), but the second part
of the sentence does not make sense to me: "SRS will not mix two
Received Media streams into one Recorded Media stream if they have
different retention attributes" (although the latter is probably an SRS
implementation issue).

[DdW] If retention periods can be set per user, retention periods can
differ between participants, and is therefore not an attribute of CS as
a whole. BUT is it then not rather an attribute more closely associated
with a participant than with the media of his/her speech?  Should an SRS
keep the recording of one side/direction of a SIP telephone call for a
shorter period than the other if the retention attributes differ? This
would render the recording unintelligible and useless after applying the
retention rule to the 1 recorded media stream.  

[DdW] For example, let's say the requested retention period for user A's
recordings is 1 year and for user B's recordings it is 5 years, and A
and B are involved in a CS that is recorded.  It would not make sense to
delete the recording for A's media after 1 year, but keep the recording
of user B's media for 5 years.  The SRS should have a rule (or
configurable option) on what to do if required retention periods differ
for the participants in a call, e.g. the most natural rule will be to
retain all the media for the CS for the longest of the required
retention periods OR (my preference) to create two Recording Sessions
for a CS - one for each (internal, monitored) participant.  Then
participant A's recording of the CS can be managed separately and
independently from participant B's recording.  

[DdW] In summary I think user-associated retention parameters are better
associated with a participant than with a media stream, while the
implementation of retention (rules to handle conflicts, RS copies for
each participant, etc.) falls outside the scope of the standard.  

[DdW] Having said that, it could be the case that retention periods are
based on some application-dependent classification, e.g. whether it's a
Sales, Support or New Contract call, in which case retention also DOES
apply on the CS level and not (only) on the participant or media stream
level, and it must probably be taken into account in conjunction with
user-associated retention periods.

[DdW] Even though retention is very relevant for recording systems, the
question could be asked whether retention parameters really belong
explicitly in the SIPREC metadata model.

	Thanks,
	Paul

of

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Oct 2010 15:48:59 +0200

(Chair hat on) It's getting hard to figure out who said what in some of these threads.

(Chair hat off) To me having a retention period applying to the entire rocording of a CS makes sense. Any smaller degree of granularity (whether it be party-based, media-type-based, or whatever) does not make a lot of sense. I would want to see very strong justification for anything other than per-CS.

John

> [mailto:[email-masked]] On Behalf Of De Villiers de Wet
> Sent: 20 October 2010 15:49
> To: Paul Kyzivat; Leon Portman
> Cc: [email-masked]
> Subject: Re: [siprec] SIP Recording Metadata :Received vs 
> RecordedMedia Streams
> 
> below
> 
> ----------
> certain aspects
> >> SRS may choose to accept only Audio. This information can 
> be modeled
> by
> >> Recorded media Stream block for only those that were 
> accepted by SRS.
> In
> block in the

---

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

We currently allow multiple CS per RS. ISTM that it makes a lot of sense 
to have a retention period per RS, and it *might* make sense to have 
separate retention periods per CS within and RS. After that, I guess the 
question is whether it makes sense to have separate retention period per 
received media stream. While its technically possible, I'm with John in 
questioning the utility.

A lot of the other discussion about per-participant retention periods 
may just be application specific policy stuff about how to choose the 
retention periods for the things we will standardize.

	Thanks,
	Paul

On 10/21/2010 9:48 AM, Elwell, John wrote:
>> RecordedMedia

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Oct 2010 17:55:47 +0200

Paul,

I am not convinced of the need for a retention period on the RS. The RS is just a means of delivering  recording material from for one or more CSs to the SRS, but thereafter it can be forgotten. It makes no difference when you try to replay, analyse or search recordings what RS it arrived over - it is only the CS that is important. I see no need for retaining information about an RS.

One use case is the persistent recording case, where the RS is more or less permanent and used to record multiple CSs. For this reason too, I don't think a retention time makes sense for an RS.

John (as individual)

> Sent: 21 October 2010 15:08
> To: Elwell, John
> Cc: De Villiers de Wet; Leon Portman; [email-masked]
> > (Chair hat off) To me having a retention period applying to 
> the entire rocording of a CS makes sense. Any smaller degree 
> of granularity (whether it be party-based, media-type-based, 
> or whatever) does not make a lot of sense. I would want to 
> see very strong justification for anything other than per-CS.
> >
> > John
> >
> >
> >>>> scope of SIPREC. I agree that what SRS does once it 
> receives media
> >> may
> >>>> be outside SIPREC scope.
> >>>>
> >>>> We discussed on whether the model should include all 
> media from CS,
> >> only
> >>>> those media for which recording was requested, or only 
> those media
> >> for
> >>>> Is this really needed ? Does the wider team sees a value 
> in having
> >> this
> >>>> When we say all the media from CS I suppose we are 
> referring to all
> >> the
> >>>> having Received Media Stream block for each offered 
> media from SRC
> >> and

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Oct 2010 12:19:24 -0400

> One use case is the persistent recording case, where the RS is more or less permanent and used to record multiple CSs. For this reason too, I don't think a retention time makes sense for an RS.

OK, I get your point. But it then puts further emphasis on the proper 
definition of CS. I'll reference the same example I have used multiple 
times:

- customer in call with agent
- agent puts customer on hold
- agent makes consultation call with expert
- consultation call ends
- agent resumes call with customer

Question is whether above is one CS or two.
Assuming the consultation call pertained to the customer call, then they 
should probably be treated as a unit for recording, playback, retention 
purposes.

If these are one CS then there is no issue (on this point).
If they are two CSs, then currently the only thing we have to tie them 
together is the RS, and we would need to invent something else.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Oct 2010 18:46:59 +0200

But the RS would not necessarily tie those together. In some cases it might, but in other cases the CSs might be recorded using separate RSs, and in yet other cases a single RS might include some related CSs and many additional CSs. Perhaps we need the concept of a CS Group. Note that we used to have an RS Group object, but we were not convinced of its benefit. However, a CS Group might have some value in some circumstances. One word of caution however, is that this again is an application concept, and SIP will not necessarily give us sufficient information to group together related CSs reliably, particularly where 3PCC is used.

John

> Sent: 21 October 2010 17:19
> To: Elwell, John
> > I am not convinced of the need for a retention period on 
> the RS. The RS is just a means of delivering  recording 
> material from for one or more CSs to the SRS, but thereafter 
> it can be forgotten. It makes no difference when you try to 
> replay, analyse or search recordings what RS it arrived over 
> - it is only the CS that is important. I see no need for 
> retaining information about an RS.
> >
> > One use case is the persistent recording case, where the RS 
> is more or less permanent and used to record multiple CSs. 
> For this reason too, I don't think a retention time makes 
> sense for an RS.
> 
> [mailto:[email-masked]] On
> >>>> Behalf Of Paul Kyzivat
> >>>>> Subject: Re: [siprec] SIP Recording Metadata :Received 
> vs Recorded
> >>>> Media Streams
> >>>>>
> >>>>> inline
> >>>>>
> attributes
> >>>> like
> whether we
> >>>> need a
> >>>>>> For e.g An SRC may offer to record audio/video streams 
> for a CS,
> >>>> however
> >>>>> If the SRC offers the media, and the SRS refuses it, 
> then maybe no
> >>>> more

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Oct 2010 13:48:01 -0400

On 10/21/2010 12:46 PM, Elwell, John wrote:
> But the RS would not necessarily tie those together. In some cases it might, but in other cases the CSs might be recorded using separate RSs, and in yet other cases a single RS might include some related CSs and many additional CSs.

Yeah, all of that is possible.

> Perhaps we need the concept of a CS Group. Note that we used to have an RS Group object, but we were not convinced of its benefit. However, a CS Group might have some value in some circumstances. One word of caution however, is that this again is an application concept, and SIP will not necessarily give us sufficient information to group together related CSs reliably, particularly where 3PCC is used.

Yes, perhaps CS Group is needed. Or maybe all of my case is actually one 
CS. We need to figure this out once and for all.

Clearly identifying which CSs need to be grouped, or which dialogs 
belong to the same CS, is in some sense an application problem.
I guess the choice is where this application logic resides:
- in the SRC
- in the SRS
- in some backend client of the recorded data

If the logic is to be in the SRC, then we don't need to know how it 
decides, but we need the proper metadata for it to record its decision. 
And if done in the SRC it can only be done when the SRC has visibility 
to all the things that need to be grouped.

If the logic is in the SRS, or further back, then we probably don't have 
this kind of grouping representation in our metadata, but we need more 
raw data for the backend processes to use to make that determination.

	Thanks,
	Paul

---

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

Paul

>Yes, perhaps CS Group is needed. Or maybe all of my case is actually
one CS. We need to figure this out once and for all.

Here also it depends from what perspective one wants to view a CS - from
the perspective of the customer (external party in a typicall call
center scenario), or from the perspective of the organization, or from
the perspective of a each particular monitored party - each one gives a
different answer, and each one is correct, depending on what you're
interested in in a given situation.

In general I think trying to force your case and similar cases into a
single CS is asking for trouble.  A similar case is for example:

- A in call with B
- C phones A - (call waiting feature enabled)
- A puts B on hold and speaks to B (conversation is not related to the
A<->B conversation at all)
- A<->C call ends
- A resumes call with B

This should NOT be modeled as one CS, but on a SIP level it is very
similar to your case, except for the direction of the second call.  And
in your example case, what if the content of the "consultation" call has
nothing to do with the original call?  On a SIP signalling level the SRC
would have nothing to be able to distinguish it from others.

Now for transfer scenarios and conferences.  even here we have problems:

Blind transfer:
	- A in call with B (segment 1)
	- A puts B on hold and performs a BLIND transfer to C (never
speaks to C)
	- C in call with B (segment 2)
This arguably the best case for having a single CS for a non-simple call
from the organization's and B's perspective, but even here the
individual participant C was not involved in the CS during segment 1.

Consult transfer
- A in call with B (segment 1)
- A puts B on hold, calls C and speaks to C (segment 2)
- A transfers call to C
- C in call with B (segment 3)

What to do?  Instead of trying to create a combined entity (which one is
correct), perhaps the SRC must just provide LINKING information BETWEEN
separate CSs for a SUCCESFUL transfer as above:
- have 3 separate CSs - CS1, CS2 and CS3
CS1 is linked to CS2 (A's perspective)
CS1 is linked to CS3 (B's perspective)
CS2 is linked to CS3 (C's perspective)

What about a failed transfer: 

Failed Consult transfer
- A in call with B (CS1)
- A puts B on hold, calls C and speaks to C (CS2)
- C refuses to take the call
- C in call with B (CS3)

If the system knows the intention of the call to C was a transfer (e.g.
transfer button was pressed on phone to start a transfer sequence), then
it could still link CS1 to CS2, and CS1 to CS3.

Linking info for conference call segments could be provided in a similar
manner as above.  Conferences have the added complexity of what to do
when participants leave the conference - create a new CS or not? 

Providing such LINKING information (as is done by some PBXs currently in
CTI info) leaves it up to the SRS to decide how to group CSs together
during recording or at playback time.

De Villiers

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 21 October 2010 19:48
To: Elwell, John
Cc: De Villiers de Wet; Leon Portman; [email-masked]
Subject: Re: [siprec] SIP Recording Metadata :Received vs RecordedMedia
Streams

On 10/21/2010 12:46 PM, Elwell, John wrote:
> But the RS would not necessarily tie those together. In some cases it
might, but in other cases the CSs might be recorded using separate RSs,
and in yet other cases a single RS might include some related CSs and
many additional CSs.

> Perhaps we need the concept of a CS Group. Note that we used to have
an RS Group object, but we were not convinced of its benefit. However, a
CS Group might have some value in some circumstances. One word of
caution however, is that this again is an application concept, and SIP
will not necessarily give us sufficient information to group together
related CSs reliably, particularly where 3PCC is used.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Oct 2010 12:25:55 -0400

inline

> A<->B conversation at all)

I'm glad you brought up this case - I was going to.

> would have nothing to be able to distinguish it from others.

Agreed. It would require some overt indication to distinguish these 
cases. Or else it might just be inferred after the fact.

> CS2 is linked to CS3 (C's perspective)

I'm certainly open to this as a solution.

> when participants leave the conference - create a new CS or not?

My original intent was that the CS would continue, but that the Received 
Media Stream would change each time there was a participant change.

> during recording or at playback time.

The linking info would be a reasonable way to accomplish this.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 27 Oct 2010 14:50:27 -0700

I think De Villers suggestion using a CS Link gives more flexibility to
the SRC than using a CS Group. A CS Group implies that the SRC have to
tie multiple CSes to a single RS, whereas a Link is more a loosely
defined construct that allows the SRC to link different CSes across
RSes.

Taking the same consultation example below with A/B/C; if party C
resides on separate site it is likely to require a separate RS to record
party C. Using CS link, we now have a mechanism for the SRC to link the
relationship between the different segments of the call but are not
forced to group the CSes into a single RS.

An SRC can still model the same thing using a single CS out of the 3
parties with different received media streams and participants, but then
you are forced to use a single CS to model the parties and this is
undesirable when the parties are spread across sites. Having a link
between CSes allows the SRC to have the flexibility to define what is a
CS (from 3pcc perspective normally), and that seems to be a reasonable
solution to this problem.

Regards,
Henry 

> Sent: Friday, October 22, 2010 12:26 PM
> To: De Villiers de Wet
> Cc: [email-masked]; Leon Portman
> Subject: Re: [siprec] SIP Recording Metadata :Receivedvs RecordedMedia
> Streams
> 
> inline
> 
> > the perspective of a each particular monitored party - each one
gives
> a
> > What to do?  Instead of trying to create a combined entity (which
one
> is
> > Providing such LINKING information (as is done by some PBXs
currently
> in
> one
> >>>>>>>>> via SIPREC interface in the metadata. SRS can store the
these
> >>>>>>>> SRC to provide information about it.

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2010 20:10:35 -0400

> defined construct that allows the SRC to link different CSes across

Well, since the link is still hypothetical, I guess it depends on how it 
is defined. And of course we can also define a CS-Group that can span 
CSs in different RSs.

ISTM the main problem is getting enough information to establish the 
link, or the group membership. As long as a single SRC is involved in 
all the CS's to be linked its not a big deal. But if it is not, then it 
gets hard.

If we talk about CSs in different RSs, then there is also the 
possibility that they are with different SRSs, different databases, etc.

But I'm entirely open to different ways of representing the linkage - as 
long as it works.

	Thanks,
	Paul