Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2011 08:36:15 -0500

On 2/1/2011 12:13 AM, Dave Smith wrote:
> The user can have an indication that the recording isn't happening b/c
> of REQ-018:
> 	REQ-018 The mechanism MUST provide a means of indicating to the
> participants involved in a CS that their session is being recorded.
>
> For example, the indicator on the phone set/desktop or the "beep"
> indicator would go away.

The user can have an indicator that *says* recording isn't being done.

Its all a matter of trust here. I trust you not to record me with 
telling me first, and I trust that if I ask you to stop recording and 
you agree, that you then will actually stop recording.

IIUC, there are (at least in some jurisdictions) laws that say you can't 
record me without informing me. You could of course violate the law, but 
then I can hold that against you.

Maybe there are also laws that obligate you to stop recording if I ask 
you to do so. (I suspect that is less likely, but I have no expertise in 
this area.)

We certainly don't want to get hung up on points of law here. Its more a 
matter of what users want and are willing to trust.

If we are to go this way, we will need to get very specific:
- can I ask that the media I send not be recorded?
- can I ask that media others send not be recorded?
   (If so, how are disagreements among participants settled?)
- can I ask that signaling about me not be recorded?
- can I ask that signaling about others not be recorded?
- how is signaling partitioned for purposes of recording?

I know this gets complex. In some states in the US all parties must be 
informed before a call can be recorded. In other states only a single 
party need be aware. I don't know if/how that would translate into 
honoring requests to cease recording, or into rules for partial recording.

That means that just honoring these requests will require policy 
decisions. Is that policy to be enforced by the SRC, or by the SRS? I 
suspect the SRC may not be an ideal place. But if its the SRS that will 
enforce the policy, then everything needs to be sent to the SRS so that 
it *can* record if it decides to. Or perhaps we must allow the policy to 
be enforced by either the SRC or the SRS.

	Thanks,
	Paul

> Regards,
> Dave
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, January 31, 2011 6:25 PM
> To: Dave Smith
> Cc: [email-masked]; Alissa Cooper; Elwell, John
> Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation
>
> I agree that all of this *can* be done.
> My main question is whether any real user would believe it is *actually*
>
> being done? There really is no way to *verify* that the recording isn't
> happening.
>
> But if this is thought to be useful it certainly can be done.
>
> 	Thanks,
> 	Paul
>
> On 1/31/2011 6:25 PM, Dave Smith wrote:
>> I agree that we do not need to consider Discarding the recording file
>> since Discarding is a policy matter, is about SRS functionality, and
> is
>> outside our scope.
>> However, I do think we should include functionality to support an
>> autonomous UA request to Stop recording (and BTW, probably even a UA
>> request to Start recording could be supported as well).
>>
>> As Alissa said, and I agree that REQ-001 to REQ-011 could be used to
>> Stop a recording.  For example, in the Contact Center use case,  if
>> developed appropriately, a Customer could verbally ask an Agent to
> stop
>> the recording and the Agent could then send a signal to the SRC to
> Stop
>> recording.  And probably similar functionality could be done by an IVR
>> (e.g., "Select 3 to terminate recording").  However, I believe this
>> could/should be done more elegantly by allowing a UA to request to
> Stop
>> recording autonomously.
>>
>> If you disagree, then it makes no sense to keep REQ-017 at all.
>> If REQ-017 is going to be kept, then it should include "during" as
> well
>> as "prior to the start of recording."
>>
>> Regards,
>> Dave
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
>> Of Paul Kyzivat
>> Sent: Thursday, January 27, 2011 5:30 AM
>> To: [email-masked]
>> Subject: Re: [siprec] Proposed change to REQ-017 concerning
> cancellation
>>
>> Inline
>>
>> On 1/27/2011 8:02 AM, Alissa Cooper wrote:
>>> As written, I think this use case (and the revised REQ-017) is still
>>> slightly ambiguous. There seem to be three cases:
>>>
>>> (1) Recording starts. Customer requests that recording be stopped.
>>> Recording stops.
>>> (2) Recording starts. Customer requests that recording be stopped and
>>> discarded. Recording stops. Recording is discarded.
>>> (3) Recording starts. Customer requests that recording be stopped and
>>> discarded. Recording stops but recording is not discarded.
>>>
>>> I think (1) is already covered between REQ-001 and REQ-011.
>>>
>>> I think (2) is by and large what we were discussing when we were
>> talking
>>> about ditching REQ-015 and REQ-016. As noted during the virtual
>> interim
>>> day 1, whether the SRS actually discards the recording depends on
>> policy
>>> set by the SRC, which we had said was out of scope.
>>>
>>> BUT it sort of sounded like case (3) might be of interest -- i.e.,
>> that
>>> having the ability for an SRC to send an indication to the SRS of the
>>> customer's preference that the recording be discarded, even if that
>>> preference will not always be honored, is something that we may want
>> to
>>> support. If that's the case, it might merit its own requirement ("The
>>> mechanism MUST provide a means for an SRC to indicate to an SRS a
>>> preference to discard a recording" or something like that).
>>
>> There is a fundamental difference between 1 and 2/3.
>>
>> The customer (I assume this to be a participant not in control of the
>> SRC) can *ask* that the recording be discarded. But he can not be
>> certain that is has been.
>>
>> Similarly, the agent (or any participant that *is* in control of the
>> SRC) could (if we provide a suitable mechanism) *ask* the SRS to
> discard
>>
>> the recording. But again he cannot be certain it has been.
>>
>> We could even provide a mechanism to ACK/NACK a request to discard a
>> recording. That could allow the SRC a bit more knowledge, but the SRS
>> could still by lying.
>>
>> Only the SRS *knows* if the recording has been discarded. Whether it
>> does so when asked will depend upon its operating policies, which
> could
>> include policies that violate the law.
>>
>> So, given all of that, is it worth the trouble to include a mechanism
> to
>>
>> request the discard of a recording, and to ACK/NACK that request???
>>
>> If that is felt to be important, then it will be a bit of work,
> because
>> we will need to define *what* is to be discarded, and that is
>> non-trivial.
>>
>> I mentioned on the list the mechanism that exists in some email
> systems
>> to "retract" an email. AFAIK this very rarely "works" - it often
> results
>>
>> in all the recipients getting another email saying "John Smith would
>> like to recall email xyz", but *does not* result in the intended
> result.
>>
>> I think requesting that a recording be discarded falls into he same
>> category. If you seriously want to ensure that a recording has been
>> discarded, then I suggest you hire a lawyer and file a lawsuit.
>>
>> 	Thanks,
>> 	Paul
>>
>>> Alissa
>>>
>>> On Jan 27, 2011, at 7:03 AM, Elwell, John wrote:
>>>
>>>> Just changed the subject line so that people concerned will notice
>> it.
>>>>
>>>> John
>>>>
>>>>> -----Original Message-----
>>>>> From: Dave Smith [mailto:[email-masked]]
>>>>> Sent: 26 January 2011 21:22
>>>>> To: Elwell, John; [email-masked]
>>>>> Subject: RE: [siprec] Minutes day 1
>>>>>
>>>>> Hi,
>>>>> Here is my input to my Action Item related to REQ-015/016 -
>>>>> to raise on
>>>>> the list any fresh requirements concerning what CS
>>>>> participants might be
>>>>> able to request regarding "canceling" and/or "discarding"
> recording.
>>>>>
>>>>> It seems that REQ-017 already covers the basic idea; however,
>>>>> REQ-017 is
>>>>> only valid " prior to the start of recording ". My concern
>>>>> was for the
>>>>> mechanism to also work "during" recording.
>>>>> Therefore, my proposal is to consider to update REQ-017 as follows:
>>>>>
>>>>> Currently it reads:
>>>>> o REQ-017 The mechanism MUST support a means for an authorized
>>>>> participant involved in a CS to request, prior to the start of
>>>>> recording, that the CS not be recorded
>>>>>
>>>>> Change to:
>>>>> o REQ-017 The mechanism MUST support a means for an authorized
>>>>> participant involved in a CS to request, during or prior
>>>>> to the start
>>>>> of
>>>>> recording, that the CS not be recorded
>>>>>
>>>>>
>>>>> Use Case supporting this change:
>>>>> 1. Customer calls a contact center
>>>>> 2. Agent answers the phone
>>>>> 3. Customer starts discussing their issue with the Agent
>>>>> 4. Customer realizes that the call is being recorded (e.g.,
>>>>> they hear a "beep" tone indicating that the call is currently being
>>>>> recorded)
>>>>> 5. Customer decides that they do not want the call to be
>>>>> recorded
>>>>> 6. Customer requests that the call not be recorded (e.g.,
>>>>> customer phone application is used to send a signal within the CS
>> that
>>>>> can be received/interpreted by the SRC)
>>>>> 7. The SRC stops the recording
>>>>> Also note the following that could further be done, if an
>>>>> implementation
>>>>> desires (no req'ts needed):
>>>>> Optional: 8. The SRC sends metadata to the SRS indicating that
>>>>> the Customer requested that the call NOT be recorded
>>>>> Optional: 9. The SRS uses its internal policy procedures and
>>>>> decides to delete the recorded audio file from the Customer
>> recording
>>>>>
>>>>>
>>>>>
>>>>> Let me know your inputs and if this change makes sense.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf
>>>>> Of Elwell, John
>>>>> Sent: Tuesday, January 25, 2011 2:24 PM
>>>>> To: [email-masked]
>>>>> Subject: [siprec] Minutes day 1
>>>>>
>>>>> Minutes of the SIPREC WG Interim Virtual Meeting
>>>>> 2011-01-25, 15.00-17.00 GMT/UTC and
>>>>> 2011-01-25, 14.00-16.00 GMT/UTC
>>>>> ===============================================
>>>>> Meeting chaired by Brian Rosen and John Elwell.
>>>>>
>>>>> Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon
>>>>> Portman, Henry Lum, Ram
>>>>> Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul
>>>>> Kyzivat, Dave
>>>>> Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel
>>>>>
>>>>> Minutes produced by John Elwell.
>>>>>
>>>>> Webex chat: See end of these minutes. Jabber was not used.
>>>>>
>>>>> Recording day 1:
>>>>> https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID=
>>>>> 8263017&rK
>>>>> ey=19329980a044b45b
>>>>>
>>>>> Meeting started at 15.02.
>>>>>
>>>>> Topic - Administrivia (chairs)
>>>>> ==============================
>>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf
>>>>>
>>>>> No changes to published agenda.
>>>>>
>>>>>
>>>>> Topic - Requirements (Ken Rehor)
>>>>> draft-ietf-siprec-req-06
>>>>> ================================
>>>>> Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/
>>>>> Slides:
>>>>> http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req-
>>>> 2011-01-25
>>>>> .pdf
>>>>>
>>>>> Slide 4 - proposal to delete REQ-015/016. It was noted that these
>>>>> requirements talk about "cancel and discard". After some
> discussion,
>>>>> there seemed to be agreement that the "cancel" part was
>>>>> covered by other
>>>>> requirements (e.g., you can pause and not resume, effectively
>>>>> cancelling). So the main issue concerned the "discard" part. It was
>>>>> noted that previous agreements relating to privacy had reached the
>>>>> conclusion that the retention of recordings is an issue for
>>>>> the SRS, and
>>>>> outside the scope of SIPREC. There was no objection to
>>>>> deleting the two
>>>>> requirements.
>>>>>
>>>>> Although the main focus of the requirements is on what happens on
>> the
>>>>> SRC-SRS interface, Dave Smith brought up the question of whether a
>>>>> participant, whose SIP UA might not be collocated with the SRC, can
>>>>> request the pausing / stopping of a recording, or even
>>>>> request deletion
>>>>> of the recording. This would be a requirement impacting the CS, as
>>>>> opposed to the RS, and it was noted that none of the solution work
>> has
>>>>> touched on that (although the earlier draft from Alan
>>>>> Johnston did have
>>>>> provision for an indication on the CS signalling path that
>>>>> recording is
>>>>> taking place, but this was not brought forward into the
>>>>> present protocol
>>>>> draft). Dave was invited to raise on the list any fresh
> requirements
>>>>> concerning what CS participants might be able to request.
>>>>>
>>>>> Slide 5 - proposed new requirement on multiple media streams for
> the
>>>>> same media type. It was observed that REQ-010 was probably intended
>> to
>>>>> cover this case, and Ken will propose words to enhance REQ-010 to
>> make
>>>>> it clearer.
>>>>>
>>>>> Slide 6 - removal of REQ-021. There was no objection to removal.
>>>>>
>>>>> Ken will try to seek resolution of the issues above and then
> publish
>>>>> -07, which should be very close to being ready to submit to the
>> IESG.
>>>>>
>>>>>
>>>>> Topic - Metadata model (Ram Mohan)
>>>>> draft-ram-siprec-metadata-03
>>>>> ================================================
>>>>> Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/
>>>>> Slides: ????
>>>>>
>>>>> Slide 4: Ram explained why an association between Media Stream and
>> CS
>>>>> had been introduced, because of the injection of things like music
>> on
>>>>> hold, leading to a media stream without participant. Charles
>> wondered
>>>>> why music on hold could not be considered a participant. Ram and
>> Paul
>>>>> explained there were also conference cases where a participant
> might
>>>>> host a conference on his device, but those behind the conferencing
>>>>> device might not be considered CS participants. Charles asked why
>> the
>>>>> conference focus could not be considered a participant. Paul
>> explained
>>>>> that the SRC could obtain, using the conference event
>>>>> package, a list of
>>>>> participants from the focus, and those participants would
>>>>> contribute to
>>>>> the media stream, but those participants would not be part of the
> CS
>> -
>>>>> that would be the role of the focus. Henry thought a mixer might be
>>>>> considered a participant, but Paul explained that if you can obtain
>> a
>>>>> roster of people behind the mixer, those might be considered
>>>>> participants rathe
>>>>> r than the mixer. So there can be participants in the media that
> are
>>>>> not participants in the CS. Charles was worried that some
>>>>> media streams
>>>>> might not have any identified participants who are generating the
>>>>> stream. Paul explained that, assuming the media from the
>> participants
>>>>> are mixed, you would see one media stream and a list of
>> participants.
>>>>> One participant might be joined to the CS and the others would not
>> be.
>>>>> Paul thinks we need to explore some use cases and see how
>>>>> they would be
>>>>> represented using this model. So if people have particular use
>> cases,
>>>>> make them known and we check how they would be represented. Ram
> will
>>>>> solicit use cases. Partha also had concerns similar to those
>>>>> of Charles,
>>>>> but Charles was beginning to see how the present model might
>>>>> work if you
>>>>> can get information about non-CS participants who are
>>>>> generating a media
>>>>> stream. Paul pointed out that the model does cater for a
> participant
>>>>> that is not part of a CS. Charles was invited to post his
>>>>> continued conc
>>>>> erns / scenarios to the list, but Paul thinks the use cases
>> concerned
>>>>> are already covered by the model.
>>>>>
>>>>> Slide 6 (CS Group): Nobody on list had come up with a reason
>>>>> for having
>>>>> more than one CSG associated with a single CS, and the conclusion
>>>>> reached on the list seems to stand.
>>>>>
>>>>> Slide 7 (CS): No comments on CS slide, except that forced
>>>>> deletion is to
>>>>> be removed in line with the requirements discussion.
>>>>>
>>>>> Slide 8 (Participant): Clarified that the multiple AORs are
>>>>> aliases, in
>>>>> the sense of P-Asserted-Identity being able to carry aliases.
>>>>>
>>>>> Concerning the issue of whether participant role is needed as an
>>>>> attribute, Leon suggested it could be done in application data, but
>>>>> asked whether we would then publish some application data
>> dictionary.
>>>>> Paul suggested that application data is just some additional
>>>>> XML in some
>>>>> other namespace, so some other group could get together and define
>> it.
>>>>> Leon was concerned that without some sort of standardization,
>>>>> different
>>>>> vendors would implement it differently. John suggested we
>>>>> need to decide
>>>>> what things are needed by 80% of deployments and standardize those
>> in
>>>>> this group, so if that is the case for participant role, we should
>>>>> standardize it. Partha wanted to include participant role, even
>> though
>>>>> there might be some cases where it is not available. Paul pointed
>> out
>>>>> that we had had considerable list discussion on the difficulties of
>>>>> figuring out the role: UAC/UAS is transaction specific,
>>>>> inbound/outbound
>>>>> is problematic, and incoming/outgoing, whilst it might work in some
>>>>> cases, it w
>>>>> ill not always work. Perhaps those focused on call centres
>>>>> can say what
>>>>> might/might not work. In conclusion, this has to be taken back to
>> the
>>>>> list. Without repeating the old arguments, those wanting to include
>>>>> participant role should indicate what are the likely mechanisms
> that
>>>>> might support it.
>>>>>
>>>>> Slide 10 (Media Stream): How to model media streams that are not
>>>>> recorded (rejected by SRS or no capability at SRS). Dave thought
> was
>>>>> important that you have some information in the metadata that
>>>>> there was
>>>>> media that was available for recording but couldn't be recorded,
> but
>>>>> there are two cases: where you don't want to record, or where
>>>>> because of
>>>>> a temporary limitation you are unable to record but might
>>>>> want to record
>>>>> later. Paul agreed, but was concerned about the details, although
>> that
>>>>> is very much down to the mechanism, e.g., does the SRC need to keep
>>>>> offering the stream?
>>>>>
>>>>> Partha asked a question on start time and end time. Ram clarified
>> this
>>>>> is these are start and end times of the CS media. It was pointed
> out
>>>>> that we have wall clock time in the metadata, and other times can
> be
>>>>> relative. Leon suggested there may be a need to retransmit wall
>> clock
>>>>> time occasionally, to compensate for drift.
>>>>>
>>>>> Henry asked whether media stream reference should be part of the
>>>>> mechanism rather than an attribute.
>>>>>
>>>>> Slide 10 (Application data): Leon agreed with the extensible
>> approach,
>>>>> based on different namespaces. Paul said that he would be tempted
> to
>>>>> stop calling it application data and call it extension data.
>>>>> John (from
>>>>> the floor) questioned whether it really is an object, or just
>>>>> attributes
>>>>> of other objects. Paul said it was just an artefact of how
>>>>> the model is
>>>>> drawn, but in the solution it would just be extensibility data. The
>>>>> authors will rework this with these comments in mind.
>>>>>
>>>>> On next steps, people are asked to review and submit further
>>>>> comments on
>>>>> -03, and -04 will be produced in due course, after which we might
> be
>>>>> consider adoption as a WG item. In particular, we need closure on
>> the
>>>>> long discussion of media stream relationships.
>>>>>
>>>>>
>>>>> Topic - Protocol (Henry Lum / Leon Portman)
>>>>> draft-portman-siprec-protocol-02
>>>>> ================================================
>>>>> Draft:
>> https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
>>>>> Slides:
>> http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-
>>>>> %20virtual%20interim%20Dec%2016%202010.pdf
>>>>>
>>>>> Slide 4 (Persistent recording): Leon pointed out that the
>>>>> whole idea of
>>>>> persistent recording is not to spend time negotiating m-lines
>>>>> when a CS
>>>>> starts - so he prefers the second option on the slide. For SRCs
> that
>>>>> support a large number of parallel CSs, the SRC could pre-negotiate
>> a
>>>>> large number of m-lines (perhaps based on licensing), rather like
>>>>> provisioning trunks. Paul felt that the other option should
>>>>> be kept open
>>>>> - a slight delay in negotiating a new m-line could be handled by
>>>>> transmitting the data slightly delayed, without losing any. Henry
>> also
>>>>> mentioned the possibility of the offer-answer failing. It was
>>>>> questioned
>>>>> whether there needs to be something in the protocol to indicate the
>>>>> delay. This issue should be brought to the list.
>>>>>
>>>>>
>>>>> Day 1 wrap-up
>>>>> ================================
>>>>>
>>>>> It was agreed that on the second day we will start by completing
> the
>>>>> Protocol topic and then do the metadata format topic.
>>>>>
>>>>> The meeting was closed at 17.00.
>>>>>
>>>>>
>>>>> Day 1 chat log
>>>>> ===============================
>>>>> January 25, 2011 3:19:58 PM from Alissa Cooper
>>>>> to Everyone: I'm not in a place where I can speak in the audio, but
>> I
>>>>> think we decided not to have requirements related to what
>>>>> happens to the
>>>>> recording after it has been made.
>>>>>
>>>>> January 25, 2011 3:30:32 PM from Alissa Cooper
>>>>> to Everyone: it seems like there are cases where the hints are
>>>>> valuable even if they aren't always honoured
>>>>>
>>>>> January 25, 2011 3:39:51 PM from Alissa Cooper
>>>>> to Everyone: it's old, I'll take it to the list
>>>>>
>>>>> January 25, 2011 4:59:32 PM from Kenneth Rehor
>>>>> to Everyone: Unfortunately I have to drop off now. TTY tomorrow.
>>>>>
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>
>>>>>
>>>>> --------------------------------------------------------------
>>>>> -----------------------------------------------------
>>>>> 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.
>>>>>
>>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>>>
>>>
>>> _______________________________________________
>>> siprec mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
>>
>> 					
>>
> ------------------------------------------------------------------------
> -------------------------------------------
>> 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.
>> 					
>>
>
> 					
> -------------------------------------------------------------------------------------------------------------------
> 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: "Dave Smith" <[email-masked]>
Date: Tue, 1 Feb 2011 21:14:55 -0800

I think that's way more complex then we need to consider.
I believe we need to keep it as simple as this:

o REQ-017 The mechanism MUST support a means for an authorized
participant involved in a CS to request, during or prior to the start of
recording, that the CS not be recorded.

If we can't agree to that, or something just as simple, then maybe this
concept is not appropriate for us to include.  
I can think of use cases where this would be very useful.  But I believe
it's more of a "nice to have" then a "mandatory" item at this point.  

Regards,
Dave

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, February 01, 2011 5:36 AM
To: Dave Smith
Cc: [email-masked]; Alissa Cooper; Elwell, John
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

this area.)

I know this gets complex. In some states in the US all parties must be 
informed before a call can be recorded. In other states only a single 
party need be aware. I don't know if/how that would translate into 
honoring requests to cease recording, or into rules for partial
recording.

	Thanks,
	Paul

cancellation

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 2 Feb 2011 09:20:01 +0100

I agree we need to try to keep it simple, and the words proposed by Dave below seem good enough to me.

John (as individual).

> Sent: 02 February 2011 05:15
> To: Paul Kyzivat
> Subject: RE: [siprec] Proposed change to REQ-017 concerning
> cancellation
>
> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/
> >>>>> Slides: ????
> >>>>>
> ----------
> person, use
> it
> ----------
> may contain
> person, use it
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 2 Feb 2011 10:15:43 +0000

I like the proposal below as well. It still leaves some ambiguity  
about whether a recording that is stopped will be discarded, but it's  
not clear that we are likely to arrive at requirements language  
covering discarding in any event.

Alissa

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Feb 2011 08:47:59 -0500

> I agree we need to try to keep it simple, and the words proposed by Dave below seem good enough to me.

I'm fine (prefer) simplicity if it meets the needs.
But simplicity doesn't equal vagueness. So we should be very clear what 
it is that you are requesting not be recorded. So far we have not been 
very explicit about the definition of a CS - leaving it up to the SRC to 
define. But here it becomes very important that the user asking to block 
recording know what is (and isn't) being blocked.

For instance, if one participant in a conference (who might not even 
know he is in a conference) requests that the CS not be recorded, then 
is it the entire conference, his individual leg of that conference? Note 
that we currently could represent that conference as a single CS or as a 
CS Group with a separate CS between the focus and each participant.

	Thanks,
	Paul

---

From: "Dave Smith" <[email-masked]>
Date: Wed, 2 Feb 2011 11:20:30 -0800

I don't think our req't changes for a conference.  
The req't is just about being able to "send a request."  It is up to the
implementation to decide how to handle the request.  
The request can be sent, but the implementation (associated with a
conference) does not have to comply....and the user can hang up if they
don't like it.  Or the implementation can accept the request and stop
recording (the SRC ceases/stops sending the RS).  

Regards,
Dave

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2011 5:48 AM
To: Elwell, John
Cc: Dave Smith; [email-masked]; Alissa Cooper
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Feb 2011 17:07:04 -0500

> recording (the SRC ceases/stops sending the RS).

If the intent is to ack this request with a "the call is not being 
recorded", then its important that there be agreement about *what* is 
not being recorded.

For instance, is it ok that only the media *from* the requester is not 
recorded, while all the media *to* his still is? Or is it ok if all the 
media containing bits to/from him are not recorded, but other media 
involving other participants is?

Its a matter of truth in advertising, and having what you promise mean 
something. I'm fine with this being as minimal as people can tolerate.

	Thanks,
	Paul

---

From: "Dave Smith" <[email-masked]>
Date: Wed, 2 Feb 2011 18:23:20 -0800

Paul - See In line below ( [DS] ).  Hopefully that philosophy will work.

Ken - By the way, REQ-018 never did get updated as I recommended.....now
it's becoming important.  I'm not sure why this was missed.  
That is, I requested to change REQ-018 from this:
	o REQ-018 The mechanism MUST provide a means of indicating to
the
   participants involved in a CS that their session is being recorded.

To this:
	o REQ-018 The mechanism MUST provide a means of indicating to
the
   participants involved in a CS that their session is currently being
recorded.

Regards,
Dave

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2011 2:07 PM
To: Dave Smith
Cc: Elwell, John; [email-masked]; Alissa Cooper
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

If the intent is to ack this request with a "the call is not being 
recorded", then its important that there be agreement about *what* is 
not being recorded.[DS]  The idea is that any
conversation/conference/call that includes this participant would not be
recorded.  Regardless of whether it is 2 participants or more, there is
a request to "do NOT record."  The SRC then can make a decision on
whether to act on it or not. [DS]  

For instance, is it ok that only the media *from* the requester is not 
recorded, while all the media *to* his still is? Or is it ok if all the 
media containing bits to/from him are not recorded, but other media 
involving other participants is?[DS] No, we're not considering bits and
pieces of a call or a conference....keep it simple, all or
nothing...we're talking about all of the conversation between the
participants of a call where one of them does not want the conversation
to be recorded.  None of the conversation/conference/call that that
participant is a member of is to be recorded.  [DS]

Its a matter of truth in advertising, and having what you promise mean 
something. I'm fine with this being as minimal as people can
tolerate.[DS]  We have a req't to support a Request to "do not record."
We have a req't to "indicate that recording is occurring currently"
(although the "currently" part that I recommended seems to not have been
added, yet).....and an implementer has the option to use these if they
wish.  So they can implement them both and support the request to "do
not record" and then remove the signal that "indicates that recording is
occurring currently" and the agent/UA would notice a change in the
Indication subsequent to their Request.   [DS] 

	Thanks,
	Paul

cancellation
>>>>>>>> that would be the role of the focus. Henry thought a mixer
might
>>>>>>>> that we had had considerable list discussion on the
difficulties
entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Feb 2011 22:00:10 -0500

Dave,

While I have *personal* opinions of what *I* would like around this, 
they don't really matter. If the simple approach you advocate is viewed 
as sufficient then I'm fine with that. Its then a matter of documenting 
exactly what behavior is expected.

Around the "currently being recorded" indication, I have similar issues 
of precision in stating what is intended. It sounds like you are 
advocating something like the periodic "beep" that is sometimes inserted 
in audio that is being recorded. But are you talking about something in 
the media, or something in the signaling? There has been much discussion 
about something in the signaling, but concern that unaware endpoints 
will not relay this to the user. (OTOH, *aware* endpoints can do nice 
indications.)

Obviously the indication can't be delivered *continuously*. At best it 
will be intermittently. So, if there is only a positive indication of 
recording, you can't be certain if lack of reinforcement means the 
recording stopped or not. Or, we could have an indication about 
recording status, that could be either positive or negative. Then you 
might be able to assume that one reported it remains unchanged until 
notified otherwise. That might be better.

	Thanks,
	Paul

---

From: "Sid Rao" <[email-masked]>
Date: Thu, 3 Feb 2011 22:06:38 -0500

Without doing something in the media, this specification will be
significantly hampered in several markets (notably California), which
have legal requirements for notification.

Consider the scenario of a outbound PSTN call, there is very little to
no guarantee that signaling will be passed on, especially on legacy
interconnects.

Best Regards,

Sid Rao
CTI Group, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Thursday, February 03, 2011 10:00 PM
To: Dave Smith
Cc: [email-masked]
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

Dave,

	Thanks,
	Paul

On 2/2/2011 9:23 PM, Dave Smith wrote:
> Ken - By the way, REQ-018 never did get updated as I 
> recommended.....now it's becoming important.  I'm not sure why this
was missed.
the
the
>     participants involved in a CS that their session is currently 
> being recorded.
>
>
> Regards,
> Dave
>

> conversation/conference/call that includes this participant would not 
> be recorded.  Regardless of whether it is 2 participants or more, 
> there is a request to "do NOT record."  The SRC then can make a 
> decision on whether to act on it or not. [DS]
>

> recorded, while all the media *to* his still is? Or is it ok if all 
> the media containing bits to/from him are not recorded, but other 
> media involving other participants is?[DS] No, we're not considering 
> bits and pieces of a call or a conference....keep it simple, all or 
> participants of a call where one of them does not want the 
> conversation to be recorded.  None of the conversation/conference/call

> that that participant is a member of is to be recorded.  [DS]
>

> (although the "currently" part that I recommended seems to not have 
> been added, yet).....and an implementer has the option to use these if

> they wish.  So they can implement them both and support the request to

> "do not record" and then remove the signal that "indicates that 
> recording is occurring currently" and the agent/UA would notice a
change in the
>> it is that you are requesting not be recorded. So far we have not 
>> been very explicit about the definition of a CS - leaving it up to 
>> the SRC
> to
>>
>> know he is in a conference) requests that the CS not be recorded, 
>> then is it the entire conference, his individual leg of that
conference?
> Note
>>
>> that we currently could represent that conference as a single CS or 
>> as
> a
>>
>>>> participant involved in a CS to request, during or prior to the 
>>>> start of recording, that the CS not be recorded.
>>>>
>>>> If we can't agree to that, or something just as simple, then maybe 
>>>> this concept is not appropriate for us to include.
>>>> Maybe there are also laws that obligate you to stop recording if I 
>>>> ask you to do so. (I suspect that is less likely, but I have no 
>>>> expertise in
>>>>
>>>> this area.)
>>>>
>>>> I know this gets complex. In some states in the US all parties must

>>>> be informed before a call can be recorded. In other states only a
> single
>>>> suspect the SRC may not be an ideal place. But if its the SRS that 
>>>> will enforce the policy, then everything needs to be sent to the 
>>>> SRS so that it *can* record if it decides to. Or perhaps we must 
>>>> allow the policy to
>>>>

>>>>>> recording.  And probably similar functionality could be done by 
>>>>>> an
>>>> IVR
>>>>>>> (2) Recording starts. Customer requests that recording be 
>>>>>>> stopped
>>>> and
>>>>>>> (3) Recording starts. Customer requests that recording be 
>>>>>>> stopped
>>>> and
>>>>>>> having the ability for an SRC to send an indication to the SRS 
>>>>>>> of
>>>> the
>>>>>>> mechanism MUST provide a means for an SRC to indicate to an SRS 
>>>>>>> a preference to discard a recording" or something like that).
>>>>>>

>>>>>>>>> Here is my input to my Action Item related to REQ-015/016 - to

>>>>>>>>> raise on the list any fresh requirements concerning what CS 
>>>>>>>>> participants might be able to request regarding "canceling" 
>>>>>>>>> and/or "discarding"
>>>>> recording.
>>>>>>>>>
>>>>>>>>> only valid " prior to the start of recording ". My concern was

>>>>>>>>> for the mechanism to also work "during" recording.

>>>>>>>>> participant involved in a CS to request, during or prior to 
>>>>>>>>> the start of recording, that the CS not be recorded
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. Customer calls a contact center 2. Agent answers the phone 
>>>>>>>>> 3. Customer starts discussing their issue with the Agent 4. 
>>>>>>>>> Customer realizes that the call is being recorded (e.g., they 
>>>>>>>>> hear a "beep" tone indicating that the call is currently
>>>> being
>>>>>>>>> recorded)
>>>>>>>>> recorded 6. Customer requests that the call not be recorded 
>>>>>>>>> (e.g., customer phone application is used to send a signal
>>>> within the CS
>>>>>> that
>>>>>>>>> can be received/interpreted by the SRC) 7. The SRC stops the 
>>>>>>>>> recording Also note the following that could further be done, 
>>>>>>>>> if an implementation desires (no req'ts needed):

>>>>>>>>> [mailto:[email-masked]] On Behalf Of Elwell, John
>>>>>>>>> Minutes of the SIPREC WG Interim Virtual Meeting 2011-01-25, 
>>>>>>>>> 15.00-17.00 GMT/UTC and 2011-01-25, 14.00-16.00 GMT/UTC 
>>>>>>>>> Kyzivat, Dave Smith, Parthasarathi, Dan Romascanu, Alissa 
>>>>>>>>> Cooper,
>>>> Charles Eckel
>>>>>>>>>
>>>>>>>>> Topic - Administrivia (chairs) ==============================
>>>>>>>>> covered by other requirements (e.g., you can pause and not 
>>>>>>>>> resume, effectively cancelling). So the main issue concerned 
>>>>>>>>> the "discard" part. It
>>>> was
>>>>>>>>> the SRS, and outside the scope of SIPREC. There was no 
>>>>>>>>> objection to deleting the two requirements.
>>>>>>>>>
>>>>>>>>> participant, whose SIP UA might not be collocated with the 
>>>>>>>>> SRC,
>>>> can
>>>>>>>>> request the pausing / stopping of a recording, or even request

>>>>>>>>> deletion of the recording. This would be a requirement 
>>>>>>>>> impacting
>>>> the CS, as
>>>>>>>>> touched on that (although the earlier draft from Alan Johnston

>>>>>>>>> did have provision for an indication on the CS signalling path

>>>>>>>>> that recording is taking place, but this was not brought 
>>>>>>>>> forward into the present protocol draft). Dave was invited to 
>>>>>>>>> raise on the list any fresh
>>>>> requirements
>>>>>>>>> that the SRC could obtain, using the conference event package,

>>>>>>>>> a list of participants from the focus, and those participants 
>>>>>>>>> would contribute to the media stream, but those participants 
>>>>>>>>> would not be
>>>> part of the
>>>>> CS
>>>>>> -
>>>>>>>>> participants rathe r than the mixer. So there can be 
>>>>>>>>> participants in the media
> that
>>>>> are
>>>>>>>>> media streams might not have any identified participants who 
>>>>>>>>> are
>>>> generating the
>>>>>>>>> Paul thinks we need to explore some use cases and see how they

>>>>>>>>> would be represented using this model. So if people have 
>>>>>>>>> particular use
>>>>>> cases,
>>>>>>>>> of Charles, but Charles was beginning to see how the present 
>>>>>>>>> model might work if you can get information about non-CS 
>>>>>>>>> participants who are generating a media stream. Paul pointed 
>>>>>>>>> out that the model does cater for a
>>>>> participant
>>>>>>>>> continued conc erns / scenarios to the list, but Paul thinks 
>>>>>>>>> the use cases
>>>>>> concerned
>>>>>>>>> for having more than one CSG associated with a single CS, and 
>>>>>>>>> the
>>>> conclusion
>>>>>>>>> deletion is to be removed in line with the requirements 
>>>>>>>>> discussion.
>>>>>>>>>
>>>>>>>>> aliases, in the sense of P-Asserted-Identity being able to 
>>>>>>>>> carry aliases.
>>>>>>>>>
>>>>>>>>> attribute, Leon suggested it could be done in application 
>>>>>>>>> data,
>>>> but
>>>>>>>>> XML in some other namespace, so some other group could get 
>>>>>>>>> together
>>>> and define
>>>>>> it.
>>>>>>>>> different vendors would implement it differently. John 
>>>>>>>>> suggested we need to decide what things are needed by 80% of 
>>>>>>>>> deployments and
>>>> standardize those
>>>>>> in
>>>>>>>>> inbound/outbound is problematic, and incoming/outgoing, whilst

>>>>>>>>> it might work in
>>>> some
>>>>>>>>> cases, it w
>>>>>>>>> ill not always work. Perhaps those focused on call centres can

>>>>>>>>> say what might/might not work. In conclusion, this has to be
>>>> taken back to
>>>>>> the
>>>>>>>>> there was media that was available for recording but couldn't 
>>>>>>>>> be
> recorded,
>>>>> but
>>>>>>>>> because of a temporary limitation you are unable to record but

>>>>>>>>> might want to record later. Paul agreed, but was concerned 
>>>>>>>>> about the
>>>> details, although
>>>>>> that
>>>>>>>>> attributes of other objects. Paul said it was just an artefact

>>>>>>>>> of how the model is drawn, but in the solution it would just 
>>>>>>>>> be extensibility data.
>>>> The
>>>>>>>>> comments on -03, and -04 will be produced in due course, after
>>>> which we might
>>>>> be
>>>>>>>>> whether there needs to be something in the protocol to
indicate
>>>>>>>>> to Everyone: I'm not in a place where I can speak in the
audio,

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 4 Feb 2011 08:22:33 +0100

Paul,

Some of this will certainly need to be looked at again as part of the solution work, but in order to try to complete the requirements document, can you possibly propose some revised words that you think will be adequate for guiding us in our future endeavours?

Thanks,

John (as chair)

> Sent: 04 February 2011 03:00
> To: Dave Smith
> Cc: Ken Rehor (krehor); Elwell, John; [email-masked]; Alissa Cooper
> recommended.....now
> >> The req't is just about being able to "send a request."
> It is up to
> > the
> conversation
> >>> I agree we need to try to keep it simple, and the words
> proposed by
> >> Dave below seem good enough to me.
> >>
> >> very explicit about the definition of a CS - leaving it up
> to the SRC
> > to
> >>
> >> that we currently could represent that conference as a
> single CS or as
> > a
> >>
> >>>> the start of
> >>>>>        REQ-018 The mechanism MUST provide a means of
> indicating to
> > the
> >>>> decisions. Is that policy to be enforced by the SRC, or
> by the SRS?
> > I
> >>>>> being done? There really is no way to *verify* that the
> recording
> >>>> isn't
> >>>>> happening.
> >>>>>
> >>>>>> recording.  And probably similar functionality could
> be done by an
> >>>> IVR
> >>>>>>> (2) Recording starts. Customer requests that
> recording be stopped
> >>>> and
> >>>>>>> (3) Recording starts. Customer requests that
> recording be stopped
> >>>> and
> >>>>>>> having the ability for an SRC to send an indication
> to the SRS of
> >>>> the
> >>>>>>> support. If that's the case, it might merit its own
> requirement
> >>>> ("The
> >>>>>>>>> they hear a "beep" tone indicating that the call is
> currently
> >>>> being
> >>>>>>>>> recorded)
> >>>>>>>>> Participants (session 1): Brian Rosen, John Elwell,
> Ken Rehor,
> >>>> Leon
> >>>>>>>>> Portman, Henry Lum, Ram
> https://datatracker.ietf.org/doc/draft-ietf-siprec-req/
> >>>>>>>>> Slides:
> >>>>>>>>>
> >>>>>>>>> cancelling). So the main issue concerned the
> "discard" part. It
> >>>> was
> >>>>>>>>> participant, whose SIP UA might not be collocated
> with the SRC,
> >>>> can
> >>>>>>>>> Concerning the issue of whether participant role is
> needed as
> > an
> >>>>>>>>> attribute, Leon suggested it could be done in
> application data,
> >>>> but
> >>>>>>>>> is problematic, and incoming/outgoing, whilst it
> might work in
> >>>> some
> >>>>>>>>> cases, it w
> >>>>>>>>> is very much down to the mechanism, e.g., does the
> SRC need to
> >>>> keep
> >>>>>>>>> offering the stream?
> >>>>>>>>>
> >>>>>>>>> drawn, but in the solution it would just be
> extensibility data.
> >>>> The
> >>>>>>>>> - a slight delay in negotiating a new m-line could
> be handled
> > by
> >>>>>>>>> whether there needs to be something in the protocol
> to indicate
> >>>> the
> >>>>>>>>> to Everyone: I'm not in a place where I can speak
> in the audio,
> >>>> but
> >>>>>> I

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 4 Feb 2011 10:39:32 +0100

I don't think it is the intention to prevent notification by media, and I agree in most countries that will be required. It is just that it is outside the scope of SIPREC work. There are already sufficient standards for SIP/SDP to allow injection of tones / announcements, and the nature of the tone/announcement cannot be subject to standardization.

John

> [mailto:[email-masked]] On Behalf Of Sid Rao
> Sent: 04 February 2011 03:07
> To: Paul Kyzivat; Dave Smith
> Cc: [email-masked]
> single CS or
> >>>> IIUC, there are (at least in some jurisdictions) laws
> that say you
> >>>> can't
> >>>>
> >>>>>> developed appropriately, a Customer could verbally ask
> an Agent
> >>>>>> to
> >>>>> stop
> >>>>>> the recording and the Agent could then send a signal
> to the SRC
> >>>>>> to
> >>>>> Stop
> be done by
> >>>>>> could/should be done more elegantly by allowing a UA
> to request
> >>>>>> to
> >>>>> Stop
> >>>>>> recording autonomously.
> >>>>>>
> >>>>>> If REQ-017 is going to be kept, then it should include
> "during"
> >>>>>> as
> >>>>> well
> >>>>>>> day 1, whether the SRS actually discards the
> recording depends
> >>>>>>> on
> >>>>>> policy
> to the SRS
> 2011-01-25,

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Feb 2011 11:40:25 -0500

> Some of this will certainly need to be looked at again as part of the solution work, but in order to try to complete the requirements document, can you possibly propose some revised words that you…

I'll try.
Here is the existing related bunch of requirements, and my attempt to 
re-spin them:

    o REQ-015: The mechanism MUST support a means to cancel and discard
    the recording and associated metadata for a CS.

Perhaps we replace those with:

    * REQ-015a: The mechanism MUST support a means for the SRC to
      request the SRS to cancel and discard all recorded media and
      associated metadata for a CS.

    * REQ-015b: The mechanism MUST support a means for the SRS to
      notify the SRC that all recorded media and associated metadata
      for a CS has been discarded.

Similarly, replace

    o REQ-016: The mechanism MUST support a means to cancel and discard
    the recording but not the associated metadata for a CS.

with:

    * REQ-016a: The mechanism MUST support a means for the SRC to
      request the SRS to cancel and discard all recorded media but not
      the associated metadata for a CS.

    * REQ-016b: The mechanism MUST support a means for the SRS to
      notify the SRC that all recorded media but not the associated
      metadata for a CS has been discarded.

Note that the above are only about SRC to SRS communication. Presumably 
it can all be done in the signaling channel. The remainder are (as I 
understand this) about communication between a CS participant and the SRC:

This clearly has problems if there is a pre-established RS. It also 
doesn't address the distinction between media and metadata. So perhaps 
replace with:

    * REQ-017a: The mechanism MUST support a means for an authorized
    participant involved in a CS to request, prior to the start of
    recording, that an RS not be established for this CS.

    (This is only applicable to CSs where an RS has not yet been
    established. Not clear if its worth the trouble.)

    * REQ-017b: The mechanism MUST support a means for an authorized
    participant involved in a CS to request that any existing RS for
    this CS be terminated, and that all recorded media and associated
    metadata for the CS be discarded.

    * REQ-017c: The mechanism MUST support a means for an authorized
    participant involved in a CS to request that further recording of
    media and associated metadata for this CS be terminated.

    * REQ-017d: The mechanism MUST support a means for an authorized
    participant involved in a CS to request that further recording of
    media, but not associated metadata, for this CS be terminated.

None of that provides any confirmation. The following is what we have on 
that:

    o REQ-018 The mechanism MUST provide a means of indicating to the
    participants involved in a CS that their session is being recorded.

    Examples include: inject tones into the CS from the SRC, play a
    message at the beginning of a session, a visual indicator on a
    display, etc.

We have been dancing around this one because of concerns about the 
capabilities of participants to recognize an indication in signaling, 
and conversely an inability to nail down how this might be dealt with 
generically without that. This also doesn't address what might have 
happened in response to requests to delete already recorded media and/or 
metadata.

I think we need to split this into two parts. One concerns signaling 
from the SRC to the "authorized particpant" the outcome of a request it 
made.

The other is the indicating recording, indicating of non-recording, or 
not indicating of recording, to all participants. I despair coming up 
with a reasonable requirement on this. To be complete it would need to 
include media-only participants, and work for all media. (What if a 
participant has only video but you only send the indication in audio?) 
Also, exactly what is required here is based on laws that vary by locale.

    * REQ-018 The mechanism MUST provide a means of indicating to a
    participant in a CS if recording of media is currently enabled,
    if recording of metadata is currently enabled, if any media has
    been recorded for this CS, if any metadata has been recorded for
    this CS.

    (Its expected that this be a signaling mechanism, not a media
    mechanism. Hence it will only reach to signaling participants in
    the CS, and only to those that understand it.)

Given that, I think we have to leave the media-based indication to 
implementations. Where required by business or legal reasons, an 
implementation can ensure that there is a sufficiently capable 
participant in each CS, that can receive the indications and render them 
in the media.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Sun, 6 Feb 2011 17:59:38 +0200

Paul, Hi

Please see below my comments

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, February 04, 2011 6:40 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

> Some of this will certainly need to be looked at again as part of the solution work, but in order to try to complete the requirements document, can you possibly propose some revised words that you…

I'll try.
Here is the existing related bunch of requirements, and my attempt to re-spin them:

[Leon] I have no problem with wording however still think that these flows are outside of SIPREC protocol. Because for some configurations SRS exposes such functionality directly (and not via SRS) to agent desktop applications. And also confirmation of the removal of the recording can be asynchronous (department of defence deletion takes time for example) and better to be implemented outside RS session (web services for example)

Similarly, replace

with:

Note that the above are only about SRC to SRS communication. Presumably it can all be done in the signaling channel. The remainder are (as I understand this) about communication between a CS participant and the SRC:

[Leon] I agree that it is belongs to outband signaling channel

This clearly has problems if there is a pre-established RS. It also doesn't address the distinction between media and metadata. So perhaps replace with:

We have been dancing around this one because of concerns about the capabilities of participants to recognize an indication in signaling, and conversely an inability to nail down how this might be dealt with generically without that. This also doesn't address what might have happened in response to requests to delete already recorded media and/or metadata.

I think we need to split this into two parts. One concerns signaling from the SRC to the "authorized particpant" the outcome of a request it made.

The other is the indicating recording, indicating of non-recording, or not indicating of recording, to all participants. I despair coming up with a reasonable requirement on this. To be complete it would need to include media-only participants, and work for all media. (What if a participant has only video but you only send the indication in audio?) Also, exactly what is required here is based on laws that vary by locale.

Given that, I think we have to leave the media-based indication to implementations. Where required by business or legal reasons, an implementation can ensure that there is a sufficiently capable participant in each CS, that can receive the indications and render them in the media.

[Leon] I agree

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 06 Feb 2011 21:50:10 -0500

Just one comment back to you

> [Leon] I have no problem with wording however still think that these flows are outside of SIPREC protocol. Because for some configurations SRS exposes such functionality directly (and not via SRS)…

Well, either its in scope or its not.
If its in scope then we need a mechanism to standardize.
I think you are saying that this should be out of scope.
I can't answer whether it should or shouldn't.
(AFAIK the *only* communication with the SRS that is in scope is the RS.)

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 7 Feb 2011 09:19:03 +0200

Paul, Hi

The reason why I am think that is out of scope because all use cases of retention, canceling and discarding of the media and metadata is more about policy of managing recording and not actual recording session establishment. Sometimes it can be part of RS between SRC and SRS but more generically it is between participants and Policy Server.

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, February 07, 2011 4:50 AM
To: Leon Portman
Cc: Elwell, John; [email-masked]
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 7 Feb 2011 13:17:59 +0100

Paul,

Thanks for putting this into words. It seems the scope of possible requirements here is quite broad, and I am not sure we need all this. Basically my comments are as follows:

1. Concerning discarding a recording, we have agreed in the past that SRS is in charge of policy concerning retention of recordings, and hence will have the final say in whether a request to discard is honoured. I am not sure whether there needs to be any obligation for the SRS to make this policy available to the SRS, and hence I am not sure whether we need a requirement to report back to the SRC the outcome of a discard request. As Leon has pointed out, the outcome might not be known immediately. Also, how trustworthy is it?

So if the SRC wants to discard (perhaps because a user has asked for discard), I had imagined the SRC could send the request to the SRS, and that would be that - no response to indicate whether discarding has been successful or not. If people are uncomfortable with this, I would tend to go in the direction of removing REQ-015/REQ-016 (address them in a later phase if necessary).

Note that cancellation is a different matter, and I think it is covered by pause (REQ-011) or recording selected parts of a CS (REQ-004). So rather than get involved in some of these tricky questions in order to make REQ-015/REQ-016 acceptable, it might be better just to delete REQ-015/REQ-016.

2. Concerning REQ-018, I think we need to avoid specifying any mechanisms within media, but I think an indication at signalling level would be appropriate. This would be targeted at siprec-compliant UAs on the CS and should cover whether the CS is being recorded or not being recorded. Although it might be tempting to get more sophisticated and indicate whether particular media are being recorded (e.g., audio is being recorded, video is not being recorded), I am a little wary of getting too complicated. In my opinion it might be sufficient to have a requirement something like:
"REQ-018 The mechanism MUST provide a means of indicating to UAs involved in a CS that the session is being recorded."

3. Concerning REQ-017, I think we can remove the words "prior to the start of recording". We can also perhaps change "an authorized participant" to "a participant" - any participant can request, although it will only be acted upon if authorized. Perhaps we should go further, and talk about "a User Agent" rather than "a participant" - a user's ability to do this will depend on support from its UA. We don't want to get into mechanisms such as DTMF for covering PSTN participants, for example. So we would end up with:
"REQ-017 The mechanism MUST support a means for a UA involved in a CS to request that the CS not be recorded."

John (as individual)

> Sent: 04 February 2011 16:40
> To: Elwell, John
> Cc: Dave Smith; Ken Rehor (krehor); [email-masked]; Alissa Cooper
> > Some of this will certainly need to be looked at again as 
> part of the solution work, but in order to try to complete 
> the requirements document, can you possibly propose some 
> revised words that you think will be adequate for guiding us 
> in our future endeavours?
> 
> I'll try.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Feb 2011 08:36:10 -0500

Leon,

I don't have an opinion about this. My only concern is that if it *is* a 
requirement then it be expressed in a clear manner. I'll let those of 
you who have an opinion sort it out and decide what you want to be a 
requirement and what should not be.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Feb 2011 09:24:06 -0500

> Thanks for putting this into words. It seems the scope of possible requirements here is quite broad, and I am not sure we need all this. Basically my comments are as follows:

John,

As I already replied to Leon, I don't have much of an opinion of whether 
these things should be requirements or not - just that if they are 
requirements then they need to be clear and logical.

> 1. Concerning discarding a recording, we have agreed in the past that SRS is in charge of policy concerning retention of recordings, and hence will have the final say in whether a request to discar…

Well, whether the SRS needs to allow the SRC an *input* to the policy 
decision is what this is all about.

While I agree that providing an ack/nack to such an input is an 
independent decision, its my feeling that there is little point in 
allowing the input without some feedback.

(From a practical perspective, eliminating the feedback makes life 
simpler for the design of the mechanism.)

> So if the SRC wants to discard (perhaps because a user has asked for discard), I had imagined the SRC could send the request to the SRS, and that would be that - no response to indicate whether dis…

Sure, eliminating the request is one way to eliminate the need for a 
response. If that meets everyone's needs then I'm fine with that.

> "REQ-018 The mechanism MUST provide a means of indicating to UAs involved in a CS that the session is being recorded."

I am ok with that wording. It is philosophically the same thing I was 
going for.

> 3. Concerning REQ-017, I think we can remove the words "prior to the start of recording".

I didn't know if that text was there for a reason or not. Clearly it is 
problematic is some situations. I'd be happy to see it removed.

> We can also perhaps change "an authorized participant" to "a participant" - any participant can request, although it will only be acted upon if authorized.

Sure. I was just preserving the existing wording, and am not attached to 
it. I agree with your logic.

> Perhaps we should go further, and talk about "a User Agent" rather than "a participant" - a user's ability to do this will depend on support from its UA. We don't want to get into mechanisms such as DTMF for covering PSTN participants, for example.

Yes, I agree with all that too.

> So we would end up with:

While I agree with all your logic, these words beg the question of what 
such a request means if the CS is already being recorded. Perhaps:

"REQ-017 The mechanism MUST support a means for a UA involved in a CS to 
request that the CS henceforth not be recorded."

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 7 Feb 2011 15:35:56 +0100

Paul,

Yes, I would agree with your proposed addition of "henceforth" to my proposal for REQ-017.

John (as individual)

> Sent: 07 February 2011 14:24
> To: Elwell, John
> > Thanks for putting this into words. It seems the scope of 
> possible requirements here is quite broad, and I am not sure 
> we need all this. Basically my comments are as follows:
> 
> John,
> 
> > 1. Concerning discarding a recording, we have agreed in the 
> past that SRS is in charge of policy concerning retention of 
> recordings, and hence will have the final say in whether a 
> request to discard is honoured. I am not sure whether there 
> needs to be any obligation for the SRS to make this policy 
> available to the SRS, and hence I am not sure whether we need 
> a requirement to report back to the SRC the outcome of a 
> discard request. As Leon has pointed out, the outcome might 
> not be known immediately. Also, how trustworthy is it?
> 
> > So if the SRC wants to discard (perhaps because a user has 
> asked for discard), I had imagined the SRC could send the 
> request to the SRS, and that would be that - no response to 
> indicate whether discarding has been successful or not. If 
> people are uncomfortable with this, I would tend to go in the 
> direction of removing REQ-015/REQ-016 (address them in a 
> later phase if necessary).
> 
> > Note that cancellation is a different matter, and I think 
> it is covered by pause (REQ-011) or recording selected parts 
> of a CS (REQ-004). So rather than get involved in some of 
> these tricky questions in order to make REQ-015/REQ-016 
> acceptable, it might be better just to delete REQ-015/REQ-016.
> >
> > 2. Concerning REQ-018, I think we need to avoid specifying 
> any mechanisms within media, but I think an indication at 
> signalling level would be appropriate. This would be targeted 
> at siprec-compliant UAs on the CS and should cover whether 
> the CS is being recorded or not being recorded. Although it 
> might be tempting to get more sophisticated and indicate 
> whether particular media are being recorded (e.g., audio is 
> being recorded, video is not being recorded), I am a little 
> wary of getting too complicated. In my opinion it might be 
> sufficient to have a requirement something like:
> > "REQ-018 The mechanism MUST provide a means of indicating 
> to UAs involved in a CS that the session is being recorded."
> 
> > We can also perhaps change "an authorized participant" to 
> "a participant" - any participant can request, although it 
> will only be acted upon if authorized.
> 
> > Perhaps we should go further, and talk about "a User Agent" 
> rather than "a participant" - a user's ability to do this 
> will depend on support from its UA. We don't want to get into 
> mechanisms such as DTMF for covering PSTN participants, for example.
> 
> > "REQ-017 The mechanism MUST support a means for a UA 
> involved in a CS to request that the CS not be recorded."
>

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 7 Feb 2011 16:37:47 -0800

I agree with the proposed changes/recommendations to REQ-015, 16, and
18.  

Regarding REQ-017:  

"Henceforth" means " from this time forth; from now on ".  But I don't
know what that means for our case/use - does it apply in the middle of a
CS?  If this is really about being able to request prior to the start of
recording that a call not be recorded - then I like the earlier wording
better.  But, I want to ask if we are just trying to eliminate the part
about "being able to cancel a recording of a CS in the middle of the
CS"?  And why....that is, I still don't understand why that is a
problem/concern (but maybe I'm missing something)?  We could possibly
also add a Req't to "support a means for a UA involved in a CS to
request that a CS be recorded," whether prior to or even during (e.g.,
in the middle of) a CS, if that is practical.  

Regards,
Dave

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, February 07, 2011 6:36 AM
To: Paul Kyzivat
Cc: Dave Smith; Ken Rehor (krehor); [email-masked]; Alissa Cooper
Subject: RE: [siprec] Proposed change to REQ-017 concerning cancellation

Paul,

Yes, I would agree with your proposed addition of "henceforth" to my
proposal for REQ-017.

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 8 Feb 2011 08:30:39 +0100

I think being able to request prior to the start of a recording is insufficient - once you have missed that window of opportunity (i.e. prior to establishing or answering the call), there is no other opportunity. I think all 4 of the following are needed - if we agree, we can try to find the right words:
- on establishing a CS, request it be recorded;
- on establishing a CS, request that it not be recorded;
- during a CS, request that recording be discontinued;
- during a CS, request that recording be started.

Concerning discontinuation, we could discuss whether this means stop or pause. With pause, you could later resume that same recording. With stop, you would effectively terminate the recording, such that you would need to start a new recording if you need to record later during the CS. The handling of metadata would differ - in the first case the metadata might tell you when the CS ends (as well as when recording is paused) - with the second case it might tell you when recording is stopped and nothing beyond that. I don't know which of these we want (perhaps both).

John (as individual)

> Sent: 08 February 2011 00:38
> To: Elwell, John; Paul Kyzivat
> Cc: Ken Rehor (krehor); [email-masked]; Alissa Cooper

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Feb 2011 08:40:33 -0500

> - during a CS, request that recording be started.

In the first and last cases, there is a presumption that there is 
something in a position to understand and honor the request. In for that 
the first and last differ. In the first, we could potentially use 
callerprefs, and they might cause an SRC to be incorporated into the CS 
as it is established. In the last, if there is not an SRC already in the 
CS, then it may not be possible to honor the request.

I'll observe that almost all of our work has been focused on the SRC-SRS 
interactions. These things that go on in the CS are of a very different 
character. I wonder if perhaps we ought to split that part off as a 
separate activity, which can go on in parallel. There might be a 
somewhat different interest group for that.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 9 Feb 2011 10:07:43 +0100

> Sent: 08 February 2011 13:41
> To: Elwell, John
> > I think being able to request prior to the start of a
> recording is insufficient - once you have missed that window
> of opportunity (i.e. prior to establishing or answering the
> call), there is no other opportunity. I think all 4 of the
> following are needed - if we agree, we can try to find the
> right words:
[JRE] Perhaps this suggests that, as part of the solution, we would want something to signal the presence of an SRC on the path. I don't think this prevents us stating a requirement.

> somewhat different interest group for that.
[JRE] From a solution point of view, we could consider a separate I-D for signalling on the CS path, although I don't necessarily like an explosion in the number of deliverables without good reason. However, I believe all the requirements should be in one place (with the proviso that we can omit requirements if we agree they are not for "phase 1").

John (as individual)

>
>       Thanks,
>       Paul
>
> > Concerning discontinuation, we could discuss whether this
> means stop or pause. With pause, you could later resume that
> same recording. With stop, you would effectively terminate
> the recording, such that you would need to start a new
> recording if you need to record later during the CS. The
> handling of metadata would differ - in the first case the
> metadata might tell you when the CS ends (as well as when
> recording is paused) - with the second case it might tell you
> when recording is stopped and nothing beyond that. I don't
> know which of these we want (perhaps both).
> >
> > John (as individual)
> >
> >

---

From: Leon Portman <[email-masked]>
Date: Mon, 14 Feb 2011 00:39:50 +0200

I agree about separate I-D for indicating in CS something that we can call a recording control mechanism: start, stop, pause, resume, discard of the recording.
We need to keep in mind that such control is not always done by one of the participant, sometimes it is done externally: like agent supervisor and some contact center application (CRM)

I think we have 3 separate use cases where such control can be initiated:
1.  By one of the participants  of CS (UA->SRC)
2.  By external interface exposed by SRS (APP->SRS)
3.  By external interfaces exposed by SRC (APP->SRC)

We had previous discussion that such APP will be a Policy server and this external interface is outside of scope of the SIPREC. Of course on the protocol level RS we should support any relevant implications of such control

>From my point of view, adding such control on CS level it is a specific use case.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Wednesday, February 09, 2011 11:08 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

> recording is insufficient - once you have missed that window of
> opportunity (i.e. prior to establishing or answering the call), there
> is no other opportunity. I think all 4 of the following are needed -
> if we agree, we can try to find the right words:
> callerprefs, and they might cause an SRC to be incorporated into the
> CS as it is established. In the last, if there is not an SRC already
> in the CS, then it may not be possible to honor the request.

>
> I'll observe that almost all of our work has been focused on the
> SRC-SRS interactions. These things that go on in the CS are of a very
> different character. I wonder if perhaps we ought to split that part
> off as a separate activity, which can go on in parallel. There might
> be a somewhat different interest group for that.

John (as individual)

> means stop or pause. With pause, you could later resume that same
> recording. With stop, you would effectively terminate the recording,
> such that you would need to start a new recording if you need to
> record later during the CS. The handling of metadata would differ - in
> the first case the metadata might tell you when the CS ends (as well
> as when recording is paused) - with the second case it might tell you
> when recording is stopped and nothing beyond that. I don't know which
> of these we want (perhaps both).
> >
> > John (as individual)
> >
> >
> >> "REQ-017 The mechanism MUST support a means for a UA involved in a
> >> CS to request that the CS henceforth not be recorded."
> >>
> >> know what that means for our case/use - does it apply in the middle
> >> of a CS?  If this is really about being able to request prior to
> >> the start of recording that a call not be recorded - then I like
> >> the earlier wording better.  But, I want to ask if we are just
> >> trying to eliminate the part about "being able to cancel a
> >> recording of a CS in the
> middle of the
> >>> possible requirements here is quite broad, and I am not sure we
> >>> need all this. Basically my comments are as follows:
> >>>
> >>> John,
> >>>
> >>> As I already replied to Leon, I don't have much of an opinion of
> >>> whether these things should be requirements or not - just that if
> >>> they are requirements then they need to be clear and logical.
> >>>
> >>> recordings, and hence will have the final say in whether a request
> >>> to discard is honoured. I am not sure whether there needs to be
> >>> any obligation for the SRS to make this policy available to the
> >>> SRS, and hence I am not sure whether we need a requirement to
> >>> report back to the SRC the outcome of a discard request. As Leon
> >>> has pointed out, the outcome might not be known immediately. Also,
> >>> how trustworthy is it?
> >>>
> >>> asked for discard), I had imagined the SRC could send the request
> >>> to the SRS, and that would be that - no response to indicate
> >>> whether discarding has been successful or not. If people are
> >>> uncomfortable with this, I would tend to go in the direction of
> >>> removing REQ-015/REQ-016 (address them in a later phase if
> >>> necessary).
> >>>
> >>> it is covered by pause (REQ-011) or recording selected parts of a
> >>> CS (REQ-004). So rather than get involved in some of these tricky
> >>> questions in order to make REQ-015/REQ-016 acceptable, it might be
> >>> better just to delete REQ-015/REQ-016.
> >>>>
> >>> signalling level would be appropriate. This would be targeted at
> >>> siprec-compliant UAs on the CS and should cover whether the CS is
> >>> being recorded or not being recorded. Although it might be
> >>> tempting to get more sophisticated and indicate whether particular
> >>> media are being recorded (e.g., audio is being recorded, video is
> >>> not being recorded), I am a little wary of getting too
> >>> complicated. In my opinion it might be sufficient to have a
> >>> requirement something like:
> >>> "a participant" - any participant can request, although it will
> >>> only be acted upon if authorized.
> >>>
> >>> Sure. I was just preserving the existing wording, and am not
> >>> attached to it. I agree with your logic.
> >>>
> >>> rather than "a participant" - a user's ability to do this will
> >>> depend on support from its UA. We don't want to get into
> >>> While I agree with all your logic, these words beg the question of
> >>> what such a request means if the CS is already being recorded.
> >>> Perhaps:
> >>>
> >>> "REQ-017 The mechanism MUST support a means for a UA involved in a
> >>> CS to request that the CS henceforth not be recorded."
> >>>
> >>>      Thanks,
> >>>      Paul
> >>>
> >>>> John (as individual)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> part of the solution work, but in order to try to complete the
> >>>>> requirements document, can you possibly propose some revised
> >>>>> words that you think will be adequate for guiding us in our
> >>>>> future endeavours?
> >>>>>
> >>>>> I'll try.
> >>>>> happened in response to requests to delete already recorded
> >>>>> media and/or metadata.
> >>>>>
> >>>>> from the SRC to the "authorized particpant" the outcome of a
> >>>>> request it made.
> >>>>>
> >>>>> The other is the indicating recording, indicating of
> >>>>> non-recording, or not indicating of recording, to all
> >>>>> participants. I
> >>> despair coming up
> >>>>> with a reasonable requirement on this. To be complete it would
> >>>>> need to include media-only participants, and work for all media.
> >> (What if a
> >>>>> participant has only video but you only send the indication in
> >>>>> audio?) Also, exactly what is required here is based on laws
> >>>>> that vary by locale.
> >>>>>
> >>>>> participant in each CS, that can receive the indications and
> >>>>> render them in the media.
> >>>>>
> >>>>>   Thanks,
> >>>>>   Paul
> >>>>>
> >>>
> >>
> >>
> >> 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: "Elwell, John" <[email-masked]>
Date: Mon, 14 Feb 2011 08:34:46 +0100

Leon,

I think case 1 is different, in that it is signalling on the CS SIP path and might stand a better chance of being considered in-scope for SIPREC. Also there are other things that would fall into the category of signalling on the CS SIP path, including notifications that the session is/is not being recorded and notifications whether an SRC is on the path. So the question for now is whether the group is interesting in formulating appropriate requirements in this area. I don't think we should address 2 and 3.

John (as individual)

> From: Leon Portman [mailto:[email-masked]]
> Sent: 13 February 2011 22:40
> I agree about separate I-D for indicating in CS something
> that we can call a recording control mechanism: start, stop,
> pause, resume, discard of the recording.
> We need to keep in mind that such control is not always done
> by one of the participant, sometimes it is done externally:
> like agent supervisor and some contact center application (CRM)
>
> We had previous discussion that such APP will be a Policy
> server and this external interface is outside of scope of the
> SIPREC. Of course on the protocol level RS we should support
> any relevant implications of such control
>
> [JRE] Perhaps this suggests that, as part of the solution, we
> would want something to signal the presence of an SRC on the
> path. I don't think this prevents us stating a requirement.
>
> >
> [JRE] From a solution point of view, we could consider a
> separate I-D for signalling on the CS path, although I don't
> necessarily like an explosion in the number of deliverables
> without good reason. However, I believe all the requirements
> should be in one place (with the proviso that we can omit
> requirements if we agree they are not for "phase 1").
>
> John (as individual)
>
> >
> >       Thanks,
> >       Paul
> >
> involved in a
> involved in a
> > >>>>> None of that provides any confirmation. The following
> is what we
> > >>>>> have on
> > >>>>> that:
> > >>>>>
> > >>>>>       participants involved in a CS that their
> session is being
> > >>>>> recorded.
> > >>>>>
> information in

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 14 Feb 2011 23:13:59 +0530

It is good to have case 1 requirement using CS SIP path to indicate start,stop, pause, resume  recording operations. For the time being, it is better to be tracked as separete ID. All these operations has to be supported by SIPREC protocol delivery and metadata mechanism.
 
I have the trouble in understanding discarding data from metadata perspective. Paul splits REQ-17 into four sub-requirements with the assumption that discarding applies to CS only. My question is whether the discard request from participant has to be considered for CS group. For example in call centre scenario with single CSG, 
 
1) Customer establish dialog with Agent1  (CS1)
2) Customer dialog is transferred to Agent2 by Agent1 (CS2)
3) Customer sends discard indication through CS2
 
Whether CS2 alone has to be discarded or CS1 & CS2 has to be discarded as the customer is in the single session with different agents. From the customer perspective, it *may* be preferred to discard the whole CSG rather than discarding the last agent conversation (CS2) alone. IMO, It is preferred to discard CSG or CS depend upon the application. Please let me know your opinion on the same.
 
Thanks
Partha
________________________________

From: [email-masked] on behalf of Elwell, John
Sent: Mon 2/14/2011 1:04 PM
To: Leon Portman; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation

Leon,

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Feb 2011 09:40:55 +0100

Partha,

See ticket#63 on discarding. If we decide to delete any requirements concerning discarding, presumably this would solve your issue below. Please feel free to respond on the #63 thread on any matter concerning discarding.

Thanks,

John

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: 14 February 2011 17:44
> To: Elwell, John; Leon Portman; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> It is good to have case 1 requirement using CS SIP path to
> indicate start,stop, pause, resume  recording operations. For
> the time being, it is better to be tracked as separete ID.
> All these operations has to be supported by SIPREC protocol
> delivery and metadata mechanism.
>
> I have the trouble in understanding discarding data from
> metadata perspective. Paul splits REQ-17 into four
> sub-requirements with the assumption that discarding applies
> to CS only. My question is whether the discard request from
> participant has to be considered for CS group. For example in
> call centre scenario with single CSG,
>
> Whether CS2 alone has to be discarded or CS1 & CS2 has to be
> discarded as the customer is in the single session with
> different agents. From the customer perspective, it *may* be
> preferred to discard the whole CSG rather than discarding the
> last agent conversation (CS2) alone. IMO, It is preferred to
> discard CSG or CS depend upon the application. Please let me
> know your opinion on the same.
>
> Thanks
> Partha
> I think case 1 is different, in that it is signalling on the
> CS SIP path and might stand a better chance of being
> considered in-scope for SIPREC. Also there are other things
> that would fall into the category of signalling on the CS SIP
> path, including notifications that the session is/is not
> being recorded and notifications whether an SRC is on the
> path. So the question for now is whether the group is
> interesting in formulating appropriate requirements in this
> area. I don't think we should address 2 and 3.
>
> John (as individual)
>
>
> > > >>>>>       o REQ-015: The mechanism MUST support a means
> to cancel
> > > >>>>> and discard
> > > >>>>>       o REQ-016: The mechanism MUST support a means
> to cancel
> > > >>>>> and discard
> > > >>>>> understand this) about communication between a CS
> participant
> > > >>>>> and the SRC:
> > > >>>>>