Subject: [siprec] Minutes day 1

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 Jan 2011 23:24:11 +0100

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&rKey=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 rather 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 concerns / 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 will 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.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 27 Jan 2011 08:03:47 +0100

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
>
> Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul
> Kyzivat, Dave
> Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel
>
> Recording day 1:
> https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID=
> 8263017&rK
> ey=19329980a044b45b
>
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
>
> 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.
>
>  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.
>
>  to Everyone: it seems like there are cases where the hints are
> valuable even if they aren't always honoured
>
> _______________________________________________
> 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.
>
>

---

From: "Dave Smith" <[email-masked]>
Date: Wed, 26 Jan 2011 13:21:36 -0800

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:

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

Also note the following that could further be done, if an implementation

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

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

Recording day 1:
https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID=8263017&rK
ey=19329980a044b45b 

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 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?

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.

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

Day 1 chat log
think we decided not to have requirements related to what happens to the

-------------------------------------------------------------------------------------------------------------------
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: Alissa Cooper <[email-masked]>
Date: Thu, 27 Jan 2011 13:02:19 +0000

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).

Alissa

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 08:30:13 -0500

Inline

On 1/27/2011 8:02 AM, Alissa Cooper wrote:
> 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

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 31 Jan 2011 15:25:48 -0800

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

> I think (2) is by and large what we were discussing when we were
talking
> BUT it sort of sounded like case (3) might be of interest -- i.e.,
that

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.

	Thanks,
	Paul

>>> Draft:
https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
>>> Slides:
http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2011 21:25:09 -0500

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

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 31 Jan 2011 21:13:27 -0800

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.  

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

	Thanks,
	Paul

On 1/31/2011 6:25 PM, Dave Smith wrote:
>>>> the media stream, but those participants would not be part of the
CS
> -
------------------------------------------------------------------------
-------------------------------------------
> 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.