Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.]

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 5 Jan 2012 17:16:05 +0000

Hi all,

Associate/disassociate time helps to understand how long CS is associated with RS. Initial association time shall be considered  as start time and final disassociation time shall be considered as stop time. As we could not conclude this open item during IETF-82, I'm starting this mail thread for discussion.

I could not see any other strong reason for having start/stop time for CS apart from associate/disassociate time. Please provide usecase for including start/stop time attribute in CS.

In case we could not see the proper usecase, it is better to remove from metadata draft.

Thanks
Partha

Note: "Relevant IETF-82 notes"

There was a comment to include start/Stop time also. Is it needed ?
Start time seems to makes since RS may have started only after CS was started. Stop time seems to be problematic in case of missing association. Problem to define start/stop time since a CS may include multiple SIP dialogs.

Leon: start is useful, but there is a problem with stop - how is stop sent?
Ram: Are there any use cases?
Paul: Can do it for a dialog, but not for a CS which can be many dialogs, so not clear how you would define when the start time was but can identify when participants join and leave.
Brian: What do we need this for?

Is there a need to track the times a CS is part of CS-Group ?
Leon: This is needed for snapshot
Paul: Example could be supervisor who joins a call center call to listen or whisper might need to now when this happens. - might need this.
Chairs: Need more discussion on use cases and whether this needs to be specified or whether it is an extension.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To: [email-masked]
Subject: [siprec] IETF 82 Minutes.

SIPREC IETF82 minutes can be found at http://www.ietf.org/proceedings/82/minutes/siprec.txt.

Any issues with these then please let me know and I will check against the audio and correct if necessary.

Lets kick start some discussion on the open issues since we have all had a few weeks now to recover after Taipei.

Regards
Andy

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 9 Jan 2012 17:20:04 +0000

Hi all,

Even though CNAME attribute is used to find the multiplex RTP in some deployments, it is possible to have multiple CNAME and not a generic attribute in SIPREC metadata as per discussion in IETF-82. Based on these discussion, I think that CNAME attribute has to be considered as part of the extension data of Metadata. Please let me know in case anybody have difference of opinion with this approach.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: Friday, December 23, 2011 10:46 PM
To: Hutton, Andrew; [email-masked]
Subject: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.]

Hi all,

As per IETF-82 meeting, we need to discuss in detail whether CNAME attribute has to be part of participant metadata element. The initial idea is to map CNAME to participant id but it is complicated in some of the cases as mentioned in IETF-82. I attached the relevant IETF-82 discussion as a note of this mail. Let us discuss in this mail thread for the need of CNAME attribute and the issues related to it.

Thanks
Partha

Note:
Open Item: Metadata Model: Participant / Carry CNAME as participant attribute
Any objections to having a new attribute in Participant class to represent CNAME? This could be useful, but might not work in more complicated cases (e.g. recordings of conferences).

Paul: You need something.
Magnus: It is a good idea but maybe not the main use case at the moment.
Hadriel: Could have two different CNAMEs for the same endpoint if they are not sync so not a participant identifier.
Ram: Useful for correlation
Charles: We are not using it as participant ID, but could be used to map to a participant.
Paul: It can get complicated
Brian: Doesn't mean we can't try
Hadriel: Can hurt if people expect this information
Brian: We aren't chartered to come up with identifier for multiple devices or users
Hadriel: This is not really a solution to this problem
Paul: Defer this as it needs more investigation
Charles:
Andy: Needs more discussion

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [siprec] IETF 82 Minutes.

Regards
Andy

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 9 Jan 2012 09:40:41 -0800

Hi Partha,

I think it will be useful for the SRC to be able to inform the SRS for
any CNAME values it knows are associated with a participant. This
information may often make it through the SRC to the SRS via RTCP, but
in some cases, it may not. Ideally there will always be a single CNAME
per participant; however, as discussed at IETF 82, there are times when
there may be multiple different CNAMES for media associated with a
single participant.
For now, I am okay with leaving the CNAME as extension data. As we
continue to work through the media flows in more detail, we can adjust
if necessary.

Cheers,
Charles

> -----Original Message-----
> Sent: Monday, January 09, 2012 9:20 AM
> Subject: Re: [siprec] CNAME attribute in participant metadata element
> [was RE: IETF 82 Minutes.]
> 
> Hi all,
> 
> 
> 
> Even though CNAME attribute is used to find the multiplex RTP in some
> deployments, it is possible to have multiple CNAME and not a generic
> attribute in SIPREC metadata as per discussion in IETF-82. Based on
> these discussion, I think that CNAME attribute has to be considered as
> part of the extension data of Metadata. Please let me know in case
> anybody have difference of opinion with this approach.
> 
> 
> 
> Thanks
> 
> Partha
> 
> 
> 
> 
> 
> 
> 
> As per IETF-82 meeting, we need to discuss in detail whether CNAME
> attribute has to be part of participant metadata element. The initial
> idea is to map CNAME to participant id but it is complicated in some
of
> the cases as mentioned in IETF-82. I attached the relevant IETF-82
> discussion as a note of this mail. Let us discuss in this mail thread
> for the need of CNAME attribute and the issues related to it.
> 
> 
> 
> Thanks
> 
> Partha
> 
> 
> 
> 
> 
> Note:
> 
> Any objections to having a new attribute in Participant class to
> represent CNAME? This could be useful, but might not work in more
> complicated cases (e.g. recordings of conferences).
> 
> 
> 
> Hadriel: Could have two different CNAMEs for the same endpoint if they
> are not sync so not a participant identifier.
> 
> SIPREC IETF82 minutes can be found at
> http://www.ietf.org/proceedings/82/minutes/siprec.txt.
> 
> 
> 
> Lets kick start some discussion on the open issues since we have all
> had a few weeks now to recover after Taipei.
> 
> 
> 
> Regards
> 
> Andy
> 
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 9 Jan 2012 23:54:57 +0000

Hi Charles,

Thanks for the quick closure of this open item in Metadata draft. 

Hi all,

Charles had request for this attribute initially. As discussed below, the authors will update metadata draft in the next revision in case we didn't hear any objection for a week time.

Thanks
Partha

>From: Charles Eckel (eckelcu) [mailto:[email-masked]]
>Sent: Monday, January 09, 2012 11:11 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; [email-masked]
>Subject: RE: [siprec] CNAME attribute in participant metadata element

---

From: Leon Portman <[email-masked]>
Date: Tue, 10 Jan 2012 16:39:44 +0200

I am ok with that as well (representing SRS side).

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: Tuesday, January 10, 2012 1:55 AM
To: Charles Eckel (eckelcu); Hutton, Andrew; [email-masked]
Subject: Re: [siprec] CNAME attribute in participant metadata element [was RE: IETF 82 Minutes.]

Hi Charles,

Hi all,

Thanks
Partha

>> these discussion, I think that CNAME attribute has to be considered 
>> as part of the extension data of Metadata. Please let me know in case 
>> Subject: [siprec] CNAME attribute in participant metadata element 
>> [was
>> RE: IETF 82 Minutes.]
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Hadriel: Could have two different CNAMEs for the same endpoint if 
>> they are not sync so not a participant identifier.
>>
>> Any issues with these then please let me know and I will check 
>> against the audio and correct if necessary.
>>
>>
>>

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

---

From: Leon Portman <[email-masked]>
Date: Tue, 10 Jan 2012 16:45:54 +0200

First couple of comments:

1.       We need it also on the media level - for example when video or text sharing started/ended and not only complete CS

2.       Same for participants - joining/leaving CS

For the scenarios where RS covers on part of CS - like record on demand, how SRS will know when CS have started?

It is import from compliance recording point of view to indicate that RS does not cover complete CS.

Hope it helps

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: Thursday, January 05, 2012 7:16 PM
To: [email-masked]
Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.]

Hi all,

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Hutton, Andrew
Sent: Friday, December 09, 2011 5:28 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [siprec] IETF 82 Minutes.

Regards
Andy

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 11 Jan 2012 17:09:20 +0000

Leon,

In case media level, it is possible to find the start/stop time using participantstream association or SDP attribute change for a specific stream. In case of participant to CS, association & disassociation  attribute helps to identify how long participant is associated with CS during the recording.

Please read inline for more comments.

Thanks
Partha

From: Leon Portman [mailto:[email-masked]]
Sent: Tuesday, January 10, 2012 8:16 PM
To: Ravindran, Parthasarathi; [email-masked]
Subject: RE: Start & stop time for CS [was RE: IETF 82 Minutes.]

For the scenarios where RS covers on part of CS - like record on demand, how SRS will know when CS have started?
<partha> SRC has to maintain the dialog history information like Call Detail records (CDR) then only, this requirement will be solved. This requirement is not required to be mandated in all SRC </partha>

It is import from compliance recording point of view to indicate that RS does not cover complete CS.
<partha> Could you please provide the name of compliance which mandate CS start/stop time </partha>

Hope it helps

Leon

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: Thursday, January 05, 2012 7:16 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.]

Hi all,

Thanks
Partha

Regards
Andy

---

From: Leon Portman <[email-masked]>
Date: Thu, 12 Jan 2012 11:47:48 +0200

Partha, Hi

So based on below, participant and media association times are related to
CS and not RS? In such case SRS can know when somebody joined conversation
and not only when somebody got started to be recorded.

Back to the question for specific regulations.They do not state explicitly
to have distinction between recording and communication times - they are
very high level and talking about keeping records of all communication and
electronic interactions. But customer requirements that we have is to be
able to search and view actual communications times and not only recording
times. And current SRS implementations distinguish between these two.

Regards

Leon

On Wed, Jan 11, 2012 at 7:09 PM, Ravindran, Parthasarathi <
[email-masked]> wrote:

>  Leon,****
>
> ** **
>
> In case media level, it is possible to find the start/stop time using
> participantstream association or SDP attribute change for a specific
> stream. In case of participant to CS, association & disassociation
> attribute helps to identify how long participant is associated with CS
> during the recording. ****
>
> ** **
>
> Please read inline for more comments.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* Leon Portman [mailto:[email-masked]]
> *Sent:* Tuesday, January 10, 2012 8:16 PM
> *To:* Ravindran, Parthasarathi; [email-masked]
> *Subject:* RE: Start & stop time for CS [was RE: IETF 82 Minutes.]****
>
> ** **
>
> First couple of comments:****
>
> **1.       **We need it also on the media level – for example when video
> or text sharing started/ended and not only complete CS****
>
> **2.       **Same for participants – joining/leaving CS****
>
> ** **
>
> For the scenarios where RS covers on part of CS – like record on demand,
> how SRS will know when CS have started? ****
>
> <partha> SRC has to maintain the dialog history information like Call
> Detail records (CDR) then only, this requirement will be solved. This
> requirement is not required to be mandated in all SRC </partha>****
>
> ** **
>
> It is import from compliance recording point of view to indicate that RS
> does not cover complete CS.****
>
> <partha> Could you please provide the name of compliance which mandate CS
> start/stop time </partha>****
>
> ** **
>
> Hope it helps****
>
> ** **
>
> Leon****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Ravindran, Parthasarathi
> *Sent:* Thursday, January 05, 2012 7:16 PM
> *To:* [email-masked]
> *Subject:* [siprec] Start & stop time for CS [was RE: IETF 82 Minutes.]***
> *
>
> ** **
>
> Hi all,****
>
> ** **
>
> Associate/disassociate time helps to understand how long CS is associated
> with RS. Initial association time shall be considered  as start time and
> final disassociation time shall be considered as stop time. As we could not
> conclude this open item during IETF-82, I’m starting this mail thread for
> discussion.****
>
> ** **
>
> I could not see any other strong reason for having start/stop time for CS
> apart from associate/disassociate time. Please provide usecase for
> including start/stop time attribute in CS.****
>
> ** **
>
> In case we could not see the proper usecase, it is better to remove from
> metadata draft.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> Note: “Relevant IETF-82 notes”****
>
> ** **
>
> There was a comment to include start/Stop time also. Is it needed ?****
>
> Start time seems to makes since RS may have started only after CS was
> started. Stop time seems to be problematic in case of missing association.
> Problem to define start/stop time since a CS may include multiple SIP
> dialogs.****
>
> ** **
>
> ****
> Ram: Are there any use cases?****
>
> Paul: Can do it for a dialog, but not for a CS which can be many dialogs,
> so not clear how you would define when the start time was but can identify
> when participants join and leave.****
>
> Brian: What do we need this for?****
>
> ** **
>
> Is there a need to track the times a CS is part of CS-Group ?****
>
> Leon: This is needed for snapshot****
>
> Paul: Example could be supervisor who joins a call center call to listen
> or whisper might need to now when this happens. - might need this.****
>
> Chairs: Need more discussion on use cases and whether this needs to be
> specified or whether it is an extension.****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Hutton, Andrew
> *Sent:* Friday, December 09, 2011 5:28 PM
> *To:* [email-masked]
> *Subject:* [siprec] IETF 82 Minutes.****
>
> ** **
>
> http://www.ietf.org/proceedings/82/minutes/siprec.txt*.*****
>
>  ****
>
> Any issues with these then please let me know and I will check against the
> audio and correct if necessary.****
>
>  ****
>
> Lets kick start some discussion on the open issues since we have all had a
> few weeks now to recover after Taipei.****
>
>  ****
>
> Regards****
>
> Andy****
>
>  ****
>