From pkyzivat@cisco.com Tue Feb 1 05:34:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363BA3A705B for ; Tue, 1 Feb 2011 05:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJJQ+nyrR381 for ; Tue, 1 Feb 2011 05:34:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 838E53A7773 for ; Tue, 1 Feb 2011 05:33:00 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtACAA+bR01AZnwN/2dsb2JhbACWI45ic4gsmFubK4J8glcEhROHEINC Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Feb 2011 13:36:16 +0000 Received: from [10.86.251.161] (bxb-vpn3-929.cisco.com [10.86.251.161]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p11DaGrZ017196; Tue, 1 Feb 2011 13:36:16 GMT Message-ID: <4D480C4F.9030704@cisco.com> Date: Tue, 01 Feb 2011 08:36:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Smith References: <4D417365.60205@cisco.com> <4D476F05.8060506@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 13:34:09 -0000 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:pkyzivat@cisco.com] > Sent: Monday, January 31, 2011 6:25 PM > To: Dave Smith > Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Paul Kyzivat >> Sent: Thursday, January 27, 2011 5:30 AM >> To: siprec@ietf.org >> 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:Dave.d.Smith@alcatel-lucent.com] >>>>> Sent: 26 January 2011 21:22 >>>>> To: Elwell, John; siprec@ietf.org >>>>> 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: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>> Of Elwell, John >>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>> To: siprec@ietf.org >>>>> 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 >>>>> siprec@ietf.org >>>>> 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 >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> 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 Henry.Lum@alcatel-lucent.com Tue Feb 1 07:44:47 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1699D3A6C28 for ; Tue, 1 Feb 2011 07:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mDcEcytsEyw for ; Tue, 1 Feb 2011 07:44:45 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 62F113A6C1D for ; Tue, 1 Feb 2011 07:44:45 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p11Flvtm027165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Feb 2011 09:47:58 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p11Fluuc005615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 09:47:57 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p11Flt0d019669; Tue, 1 Feb 2011 07:47:55 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 07:47:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 07:47:53 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] mechansim for requesting no-record for recording aware UA Thread-Index: AcvBtrvY+4K6dol3SeWfmBSZbyPs/QAKEftwAA9OsqA= References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com> From: "Henry Lum" To: "Elwell, John" , "Paul Kyzivat" , X-OriginalArrivalTime: 01 Feb 2011 15:47:55.0570 (UTC) FILETIME=[647E4120:01CBC227] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:44:47 -0000 Inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Tuesday, February 01, 2011 2:29 AM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] mechansim for requesting no-record for recording > aware UA >=20 > 1. One thing we need to clarify is which entity has the final say on > whether recording will take place - the SRC or the SRS. In the SRC > case, if no-record is requested, the SRC would not offer the session or > medium to the SRS. In the SRS case, the SRC would pass the no-record > request to the SRS, which would respond according to its policy. [[hlum]] I think the request to honor no-record in CS and recording policy should be decoupled; if the SRC needs to defer the decision for handling no-record to the SRS, then we need to come up with a mechanism to tie the establishment of a CS with an RS. This looks to me more of an implementation decision to tie them together. > Although superficially this does not impact the choice of mechanism on > the CS, the time taken to consult the SRS might possibly have some > influence. For example, it might not be possible to signal the outcome > in the response to the CS request that asked for no-record (c.f., > discussions taking place in SIPCORE on whether, for a no-INVITE > transaction, you can expect to dereference the location URL before > sending the SIP response). This might be an issue for some of the > proposed mechanisms for no-record. [[hlum]] I am hoping that this mechanism don't need to deal with timing issues between CS/RS because it needs to defer a recording decision to the SRS. I see this as an implementation issue. >=20 > 2. Either UA in the call might request no-record, and at any stage in > the call, so we cannot assume the request will be in in the initial > INVITE request. If the callee UA wants to request no-record, it could > do it in response to the initial INVITE request, or in a separate > request. If it is in a response, we would need to use another request, > in the reverse direction, to signal the outcome. Mechanisms such as > caller preferences and the Require header field would not work for a > response. Asking for no-record in a mid-dialog request might also have > issues - I am not sure how caller preferences would apply, and use of > the Require header field would perhaps not have the desired outcome. > Finally, whatever mechanism we choose must be usable in 3PCC > situations. >=20 [[hlum]] Yes, caller preferences and Require header needs to be in the initial INVITE so you are right they won't work.=20 > 3. Do we need a mechanism whereby the CS is automatically cleared if > no-record cannot be granted, or is it sufficient just to indicate this > to the user concerned and leave the user to take action?=20 [[hlum]] It should be desirable to allow both mechanisms. In any case, if an endpoint does not understand the no-record preference and tries to record, the caller would need to clear the CS manually anyways when the caller receive indication (probably audio indication) that the call is being recorded.=20 > Certainly if > we decide that no-record can be on a per-medium basis, automatically > clearing the call seems unreasonable. [[hlum]] The endpoint can reject the media stream if the endpoint does not wish the clear the call. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 01 February 2011 02:21 > > To: siprec@ietf.org > > Subject: Re: [siprec] mechansim for requesting no-record for > > recording aware UA > > > > Just to be clear, this is discussing how this request is indicated in > > the *CS*, right? > > > > I *think* I prefer option 3 (in SDP) for the flexibility it gives and > > because fundamentally this is about media. However that > > probably won't > > say anything about whether *metadata* about the call is > > recorded. Do we > > care about that? > > > > Thanks, > > Paul > > > > On 1/31/2011 5:16 PM, Henry Lum wrote: > > > This is one of the issues from the interim call. > > > > > > In order for a recording-aware UA to request that a call not to be > > > recorded, there are 3 proposed mechanisms. I want to get feedback > on > > > which mechanism is most appropriate to meet REQ-017 and REQ-018: > > > > > > 1)Use caller preference to request that a call not to be recorded > > > > > > For example, > > > > > > Reject-Contact: *;sip.recorded > > > > > > For a UA to request that a call not to be recorded. When the call > is > > > being recorded, use the feature tag sip.recorded to > > indicate that the > > > call is being recorded. The mechanism is optional so this > > preference may > > > not be honored all the time. Also, the mechanism in > > Reject-Contact would > > > prevent the call from connecting there are no contacts that > > would not > > > record the call. > > > > > > 2)Specify a new SIP header to indicate recording preference > > > > > > Define a new option tag called no-record and use a new SIP header > to > > > indicate recording preference in a new SIP header. > > > > > > For example, > > > > > > Record-Preference: record / no-record-reject / no-record-accept > > > > > > record means that the caller is requesting the call to be recorded > > > > > > no-record-reject means that the caller does not wish to > > connect the call > > > if the call must be recorded. > > > > > > no-record-accept means that the caller does not wish to be > > recorded but > > > may establish the call is recording is enabled. > > > > > > When the call is recorded, use the feature tag sip.recorded > > to indicate > > > that the call is being recorded. > > > > > > 3)Define a new SDP attribute to request for either a > > session or media > > > stream not to be recorded. > > > > > > This one is suggested during the interim call and allows > > the caller to > > > indicate recording preference using a session-level or media-level > > > attribute. We can define two attributes: > > > > > > a=3Drecordpref:[preference] > > > > > > preference =3D "record" / "no-record-reject" / "no-record-accept" > > > > > > The meaning of the preferences are the same as 2) above. > > > > > > a=3Drecord:[state] > > > > > > state =3D "active" / "inactive" > > > > > > The first attribute is used by the user agent who wishes to > > indicate the > > > preference for recording the session. The second attribute > > is used to > > > indicate whether recording is actually active or inactive. This > > > mechanism also allows a user agent is allowed to send a > > reINVITE in the > > > middle of the call to change the recording preference. > > > > > > Regards, > > > > > > Henry > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > may contain > > > confidential and proprietary information of Alcatel-Lucent > > and/or its > > > affiliated entities. Access by the intended recipient only is > > > authorized. Any liability arising from any party acting, or > > refraining > > > from acting, on any information contained in this e-mail is hereby > > > excluded. If you are not the intended recipient, please notify the > > > sender immediately, destroy the original transmission and its > > > attachments and do not disclose the contents to any other > > person, use it > > > for any purpose, or store or copy the information in any medium. > > > Copyright in this e-mail and any attachments belongs to > > Alcatel-Lucent > > > and/or its affiliated entities. > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From Dave.d.Smith@alcatel-lucent.com Tue Feb 1 21:12:07 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8073A6CF1 for ; Tue, 1 Feb 2011 21:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5R-z6UqH88a for ; Tue, 1 Feb 2011 21:12:04 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 359443A67D3 for ; Tue, 1 Feb 2011 21:12:03 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p125F3H9006772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Feb 2011 23:15:04 -0600 (CST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p125F1Fa000556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 23:15:03 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p125F0ZR007889; Tue, 1 Feb 2011 21:15:00 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 21:15:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 21:14:55 -0800 Message-ID: In-Reply-To: <4D480C4F.9030704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvCFQPKd+aaNxLwT9mt6h4ocaSbDwAgae7g References: <4D480C4F.9030704@cisco.com> From: "Dave Smith" To: "Paul Kyzivat" X-OriginalArrivalTime: 02 Feb 2011 05:15:00.0133 (UTC) FILETIME=[23C82D50:01CBC298] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 05:12:07 -0000 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. =20 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. =20 Regards, Dave -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, February 01, 2011 5:36 AM To: Dave Smith Cc: siprec@ietf.org; Alissa Cooper; Elwell, John Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation 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=20 telling me first, and I trust that if I ask you to stop recording and=20 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=20= 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=20= informed before a call can be recorded. In other states only a single=20 party need be aware. I don't know if/how that would translate into=20 honoring requests to cease recording, or into rules for partial recording. That means that just honoring these requests will require policy=20 decisions. Is that policy to be enforced by the SRC, or by the SRS? I=20 suspect the SRC may not be an ideal place. But if its the SRS that will=20= enforce the policy, then everything needs to be sent to the SRS so that=20= 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:pkyzivat@cisco.com] > Sent: Monday, January 31, 2011 6:25 PM > To: Dave Smith > Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Paul Kyzivat >> Sent: Thursday, January 27, 2011 5:30 AM >> To: siprec@ietf.org >> 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:Dave.d.Smith@alcatel-lucent.com] >>>>> Sent: 26 January 2011 21:22 >>>>> To: Elwell, John; siprec@ietf.org >>>>> 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: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>> Of Elwell, John >>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>> To: siprec@ietf.org >>>>> 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 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> 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=3Dpb&SP=3DMC&rID=3D= >>>>> 8263017&rK >>>>> ey=3D19329980a044b45b >>>>> >>>>> Meeting started at 15.02. >>>>> >>>>> Topic - Administrivia (chairs) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>>>> >>>>> No changes to published agenda. >>>>> >>>>> >>>>> Topic - Requirements (Ken Rehor) >>>>> draft-ietf-siprec-req-06 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> 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 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>>> 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 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>>> 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 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> 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 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>> 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 >>>>> siprec@ietf.org >>>>> 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 >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> >> =09 >> > ------------------------------------------------------------------------ > ------------------------------------------- >> 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. >> =09 >> > > =09 > ------------------------------------------------------------------------ ------------------------------------------- > 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. > =09 > =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Wed Feb 2 00:16:48 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACCA3A6E3D for ; Wed, 2 Feb 2011 00:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKwJaK5TBQxY for ; Wed, 2 Feb 2011 00:16:45 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1A4C03A7120 for ; Wed, 2 Feb 2011 00:16:44 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3237179; Wed, 2 Feb 2011 09:20:03 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4F9D423F0278; Wed, 2 Feb 2011 09:20:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Feb 2011 09:20:03 +0100 From: "Elwell, John" To: Dave Smith , Paul Kyzivat Date: Wed, 2 Feb 2011 09:20:01 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvCFQPKd+aaNxLwT9mt6h4ocaSbDwAgae7gAAbKmCA= Message-ID: References: <4D480C4F.9030704@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:16:48 -0000 I agree we need to try to keep it simple, and the words proposed by Dave be= low seem good enough to me. John (as individual). > -----Original Message----- > From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > Sent: 02 February 2011 05:15 > To: Paul Kyzivat > Cc: siprec@ietf.org; Alissa Cooper; Elwell, John > Subject: RE: [siprec] Proposed change to REQ-017 concerning > cancellation > > 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:pkyzivat@cisco.com] > Sent: Tuesday, February 01, 2011 5:36 AM > To: Dave Smith > Cc: siprec@ietf.org; Alissa Cooper; Elwell, John > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > > > 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:pkyzivat@cisco.com] > > Sent: Monday, January 31, 2011 6:25 PM > > To: Dave Smith > > Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > >> Of Paul Kyzivat > >> Sent: Thursday, January 27, 2011 5:30 AM > >> To: siprec@ietf.org > >> 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:Dave.d.Smith@alcatel-lucent.com] > >>>>> Sent: 26 January 2011 21:22 > >>>>> To: Elwell, John; siprec@ietf.org > >>>>> 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: siprec-bounces@ietf.org > >>>>> [mailto:siprec-bounces@ietf.org] On Behalf > >>>>> Of Elwell, John > >>>>> Sent: Tuesday, January 25, 2011 2:24 PM > >>>>> To: siprec@ietf.org > >>>>> 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 > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> 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=3Dpb&SP=3DMC&rID= =3D > >>>>> 8263017&rK > >>>>> ey=3D19329980a044b45b > >>>>> > >>>>> Meeting started at 15.02. > >>>>> > >>>>> Topic - Administrivia (chairs) > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > >>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf > >>>>> > >>>>> No changes to published agenda. > >>>>> > >>>>> > >>>>> Topic - Requirements (Ken Rehor) > >>>>> draft-ietf-siprec-req-06 > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> 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 > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >>>>> 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 > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >>>>> 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 > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> 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 > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> 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 > >>>>> siprec@ietf.org > >>>>> 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 > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >>> > >>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> 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. > > > > > > > -------------------------------------------------------------- > ----------------------------------------------------- > 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 john.elwell@siemens-enterprise.com Wed Feb 2 00:36:30 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265743A6B9F for ; Wed, 2 Feb 2011 00:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1CiFE3LZcql for ; Wed, 2 Feb 2011 00:36:28 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 70F903A6965 for ; Wed, 2 Feb 2011 00:36:28 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3237614; Wed, 2 Feb 2011 09:39:46 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id C138B23F0278; Wed, 2 Feb 2011 09:39:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Feb 2011 09:39:46 +0100 From: "Elwell, John" To: Henry Lum , Paul Kyzivat , "siprec@ietf.org" Date: Wed, 2 Feb 2011 09:39:45 +0100 Thread-Topic: [siprec] mechansim for requesting no-record for recording aware UA Thread-Index: AcvBtrvY+4K6dol3SeWfmBSZbyPs/QAKEftwAA9OsqAAJY1QUA== Message-ID: References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com> <059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:36:30 -0000 =20 > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 > Sent: 01 February 2011 15:48 > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > Subject: RE: [siprec] mechansim for requesting no-record for=20 > recording aware UA >=20 > Inline. >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Tuesday, February 01, 2011 2:29 AM > > To: Paul Kyzivat; siprec@ietf.org > > Subject: Re: [siprec] mechansim for requesting no-record=20 > for recording > > aware UA > >=20 > > 1. One thing we need to clarify is which entity has the final say on > > whether recording will take place - the SRC or the SRS. In the SRC > > case, if no-record is requested, the SRC would not offer the session > or > > medium to the SRS. In the SRS case, the SRC would pass the no-record > > request to the SRS, which would respond according to its policy. >=20 > [[hlum]] I think the request to honor no-record in CS and recording > policy should be decoupled; if the SRC needs to defer the decision for > handling no-record to the SRS, then we need to come up with a=20 > mechanism > to tie the establishment of a CS with an RS. This looks to me=20 > more of an > implementation decision to tie them together. >=20 > > Although superficially this does not impact the choice of=20 > mechanism on > > the CS, the time taken to consult the SRS might possibly have some > > influence. For example, it might not be possible to signal=20 > the outcome > > in the response to the CS request that asked for no-record (c.f., > > discussions taking place in SIPCORE on whether, for a no-INVITE > > transaction, you can expect to dereference the location URL before > > sending the SIP response). This might be an issue for some of the > > proposed mechanisms for no-record. >=20 > [[hlum]] I am hoping that this mechanism don't need to deal=20 > with timing > issues between CS/RS because it needs to defer a recording decision to > the SRS. I see this as an implementation issue. [JRE] So let us imagine the SRC sends a no-record indication to the SRS. At= some stage there will need to be an indication on the CS as to whether the= call is being recorded or not. The issue is whether that indication needs = to be in response to the request conveying the no-record request, or whethe= r it can be deferred for a later request. John (as individual) > >=20 > > 2. Either UA in the call might request no-record, and at=20 > any stage in > > the call, so we cannot assume the request will be in in the initial > > INVITE request. If the callee UA wants to request=20 > no-record, it could > > do it in response to the initial INVITE request, or in a separate > > request. If it is in a response, we would need to use=20 > another request, > > in the reverse direction, to signal the outcome. Mechanisms such as > > caller preferences and the Require header field would not work for a > > response. Asking for no-record in a mid-dialog request=20 > might also have > > issues - I am not sure how caller preferences would apply,=20 > and use of > > the Require header field would perhaps not have the desired outcome. > > Finally, whatever mechanism we choose must be usable in 3PCC > > situations. > >=20 > [[hlum]] Yes, caller preferences and Require header needs to be in the > initial INVITE so you are right they won't work.=20 >=20 > > 3. Do we need a mechanism whereby the CS is automatically cleared if > > no-record cannot be granted, or is it sufficient just to=20 > indicate this > > to the user concerned and leave the user to take action?=20 >=20 > [[hlum]] It should be desirable to allow both mechanisms. In any case, > if an endpoint does not understand the no-record preference=20 > and tries to > record, the caller would need to clear the CS manually=20 > anyways when the > caller receive indication (probably audio indication) that the call is > being recorded.=20 >=20 > > Certainly if > > we decide that no-record can be on a per-medium basis, automatically > > clearing the call seems unreasonable. >=20 > [[hlum]] The endpoint can reject the media stream if the endpoint does > not wish the clear the call. > >=20 > > John (as individual) > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > Sent: 01 February 2011 02:21 > > > To: siprec@ietf.org > > > Subject: Re: [siprec] mechansim for requesting no-record for > > > recording aware UA > > > > > > Just to be clear, this is discussing how this request is indicated > in > > > the *CS*, right? > > > > > > I *think* I prefer option 3 (in SDP) for the flexibility it gives > and > > > because fundamentally this is about media. However that > > > probably won't > > > say anything about whether *metadata* about the call is > > > recorded. Do we > > > care about that? > > > > > > Thanks, > > > Paul > > > > > > On 1/31/2011 5:16 PM, Henry Lum wrote: > > > > This is one of the issues from the interim call. > > > > > > > > In order for a recording-aware UA to request that a=20 > call not to be > > > > recorded, there are 3 proposed mechanisms. I want to=20 > get feedback > > on > > > > which mechanism is most appropriate to meet REQ-017 and REQ-018: > > > > > > > > 1)Use caller preference to request that a call not to=20 > be recorded > > > > > > > > For example, > > > > > > > > Reject-Contact: *;sip.recorded > > > > > > > > For a UA to request that a call not to be recorded.=20 > When the call > > is > > > > being recorded, use the feature tag sip.recorded to > > > indicate that the > > > > call is being recorded. The mechanism is optional so this > > > preference may > > > > not be honored all the time. Also, the mechanism in > > > Reject-Contact would > > > > prevent the call from connecting there are no contacts that > > > would not > > > > record the call. > > > > > > > > 2)Specify a new SIP header to indicate recording preference > > > > > > > > Define a new option tag called no-record and use a new=20 > SIP header > > to > > > > indicate recording preference in a new SIP header. > > > > > > > > For example, > > > > > > > > Record-Preference: record / no-record-reject / no-record-accept > > > > > > > > record means that the caller is requesting the call to=20 > be recorded > > > > > > > > no-record-reject means that the caller does not wish to > > > connect the call > > > > if the call must be recorded. > > > > > > > > no-record-accept means that the caller does not wish to be > > > recorded but > > > > may establish the call is recording is enabled. > > > > > > > > When the call is recorded, use the feature tag sip.recorded > > > to indicate > > > > that the call is being recorded. > > > > > > > > 3)Define a new SDP attribute to request for either a > > > session or media > > > > stream not to be recorded. > > > > > > > > This one is suggested during the interim call and allows > > > the caller to > > > > indicate recording preference using a session-level or=20 > media-level > > > > attribute. We can define two attributes: > > > > > > > > a=3Drecordpref:[preference] > > > > > > > > preference =3D "record" / "no-record-reject" / "no-record-accept" > > > > > > > > The meaning of the preferences are the same as 2) above. > > > > > > > > a=3Drecord:[state] > > > > > > > > state =3D "active" / "inactive" > > > > > > > > The first attribute is used by the user agent who wishes to > > > indicate the > > > > preference for recording the session. The second attribute > > > is used to > > > > indicate whether recording is actually active or inactive. This > > > > mechanism also allows a user agent is allowed to send a > > > reINVITE in the > > > > middle of the call to change the recording preference. > > > > > > > > Regards, > > > > > > > > Henry > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > > may contain > > > > confidential and proprietary information of Alcatel-Lucent > > > and/or its > > > > affiliated entities. Access by the intended recipient only is > > > > authorized. Any liability arising from any party acting, or > > > refraining > > > > from acting, on any information contained in this=20 > e-mail is hereby > > > > excluded. If you are not the intended recipient, please=20 > 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 > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 > =09 > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > = From acooper@cdt.org Wed Feb 2 02:12:38 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34353A6E66 for ; Wed, 2 Feb 2011 02:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoE1UGMG44of for ; Wed, 2 Feb 2011 02:12:35 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 602503A6CB6 for ; Wed, 2 Feb 2011 02:12:35 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 2 Feb 2011 05:15:45 -0500 Message-Id: <69F3B865-1668-4557-BB47-836CCA7D7FDA@cdt.org> From: Alissa Cooper To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Feb 2011 10:15:43 +0000 References: <4D480C4F.9030704@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 10:12:39 -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 On Feb 2, 2011, at 8:20 AM, Elwell, John wrote: > 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). > >> -----Original Message----- >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >> Sent: 02 February 2011 05:15 >> To: Paul Kyzivat >> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >> Subject: RE: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> 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:pkyzivat@cisco.com] >> Sent: Tuesday, February 01, 2011 5:36 AM >> To: Dave Smith >> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >> Subject: Re: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> >> >> 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:pkyzivat@cisco.com] >>> Sent: Monday, January 31, 2011 6:25 PM >>> To: Dave Smith >>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>>> Of Paul Kyzivat >>>> Sent: Thursday, January 27, 2011 5:30 AM >>>> To: siprec@ietf.org >>>> 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:Dave.d.Smith@alcatel-lucent.com] >>>>>>> Sent: 26 January 2011 21:22 >>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>> 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: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>> Of Elwell, John >>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>>>> To: siprec@ietf.org >>>>>>> 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 >>>>>>> siprec@ietf.org >>>>>>> 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 >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> 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. >>> >>> >> >> >> -------------------------------------------------------------- >> ----------------------------------------------------- >> 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 pkyzivat@cisco.com Wed Feb 2 05:44:45 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C0D3A6CE9 for ; Wed, 2 Feb 2011 05:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cAEN+LG4xpt for ; Wed, 2 Feb 2011 05:44:42 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 370203A68EF for ; Wed, 2 Feb 2011 05:44:42 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBACzvSE1AZnwN/2dsb2JhbACWN45ic4gsmDmbGIJ8glcEhHiGaYMq Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2011 13:48:01 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p12Dm03n012434; Wed, 2 Feb 2011 13:48:00 GMT Message-ID: <4D49608F.3050506@cisco.com> Date: Wed, 02 Feb 2011 08:47:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <4D480C4F.9030704@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 13:44:46 -0000 On 2/2/2011 3:20 AM, Elwell, John wrote: > 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 > John (as individual). > >> -----Original Message----- >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >> Sent: 02 February 2011 05:15 >> To: Paul Kyzivat >> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >> Subject: RE: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> 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:pkyzivat@cisco.com] >> Sent: Tuesday, February 01, 2011 5:36 AM >> To: Dave Smith >> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >> Subject: Re: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> >> >> 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:pkyzivat@cisco.com] >>> Sent: Monday, January 31, 2011 6:25 PM >>> To: Dave Smith >>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>>> Of Paul Kyzivat >>>> Sent: Thursday, January 27, 2011 5:30 AM >>>> To: siprec@ietf.org >>>> 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:Dave.d.Smith@alcatel-lucent.com] >>>>>>> Sent: 26 January 2011 21:22 >>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>> 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: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>> Of Elwell, John >>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>>>> To: siprec@ietf.org >>>>>>> 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 >>>>>>> siprec@ietf.org >>>>>>> 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 >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> 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. >>> >>> >> >> >> -------------------------------------------------------------- >> ----------------------------------------------------- >> 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 pkyzivat@cisco.com Wed Feb 2 06:04:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D46F3A6CD2 for ; Wed, 2 Feb 2011 06:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USLI29ZsTZ28 for ; Wed, 2 Feb 2011 06:04:48 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 13E9B3A6BB1 for ; Wed, 2 Feb 2011 06:04:48 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANLzSE2tJV2Y/2dsb2JhbAClGXOgWZsYhVMEhHiGaYMq Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 14:08:07 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p12E86ub003593; Wed, 2 Feb 2011 14:08:06 GMT Message-ID: <4D496545.5010702@cisco.com> Date: Wed, 02 Feb 2011 09:08:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com> <059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , Henry Lum Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 14:04:49 -0000 On 2/2/2011 3:39 AM, Elwell, John wrote: > [JRE] So let us imagine the SRC sends a no-record indication to the SRS. At some stage there will need to be an indication on the CS as to whether the call is being recorded or not. The issue is whether that indication needs to be in response to the request conveying the no-record request, or whether it can be deferred for a later request. ISTM that the caller will initially be informed (or already know) that the call is being recorded. He will then post a request that it *not* be recorded, but should continue to assume it is being recorded until receiving some positive confirmation that it is not. That confirmation may come immediately, later, or never. Thanks, Paul From Henry.Lum@alcatel-lucent.com Wed Feb 2 06:31:46 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0F23A6D02 for ; Wed, 2 Feb 2011 06:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJQVXTHbjO3F for ; Wed, 2 Feb 2011 06:31:45 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 4857D3A6D25 for ; Wed, 2 Feb 2011 06:31:42 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p12EYF9h029138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Feb 2011 08:34:15 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p12EYDa0010307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 08:34:15 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p12EYDSQ025998; Wed, 2 Feb 2011 06:34:13 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 06:34:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 06:34:12 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406A1F135@NAHALD.us.int.genesyslab.com> In-Reply-To: <4D496545.5010702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] mechansim for requesting no-record for recording aware UA Thread-Index: AcvC4qCjPLE/fXFjRzOfsz/YIRIG3gAAsChg References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com> <059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> <4D496545.5010702@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 02 Feb 2011 14:34:13.0256 (UTC) FILETIME=[43007080:01CBC2E6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: siprec@ietf.org Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 14:31:46 -0000 Yes, I think the confirmation or indication of recording is independent of the no-record preference. Of course, unless the caller specifically requests that the call to be rejected if no-record cannot be honoured but then this type of request needs to be made when the call is placed. Henry > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: February-02-11 9:08 AM > To: Elwell, John > Cc: Henry Lum; siprec@ietf.org > Subject: Re: [siprec] mechansim for requesting no-record for recording > aware UA >=20 >=20 >=20 > On 2/2/2011 3:39 AM, Elwell, John wrote: >=20 > > [JRE] So let us imagine the SRC sends a no-record indication to the SRS. At > some stage there will need to be an indication on the CS as to whether the > call is being recorded or not. The issue is whether that indication needs to be > in response to the request conveying the no-record request, or whether it > can be deferred for a later request. >=20 > ISTM that the caller will initially be informed (or already know) that the call is > being recorded. He will then post a request that it *not* be recorded, but > should continue to assume it is being recorded until receiving some positive > confirmation that it is not. That confirmation may come immediately, later, or > never. >=20 > Thanks, > Paul =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pkyzivat@cisco.com Wed Feb 2 08:44:20 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7403A6D2B for ; Wed, 2 Feb 2011 08:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+I09nGZTVDi for ; Wed, 2 Feb 2011 08:44:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8CED83A6CDC for ; Wed, 2 Feb 2011 08:44:19 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFIZSU1AZnwM/2dsb2JhbAClGnOgb5sbhVMEhHiGaYMq Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 16:47:39 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p12GlctF026053; Wed, 2 Feb 2011 16:47:38 GMT Message-ID: <4D498AA9.8090202@cisco.com> Date: Wed, 02 Feb 2011 11:47:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Henry Lum References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com> <059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> <4D496545.5010702@cisco.com> <059AF07365DC474393A19A3AF187DF7406A1F135@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406A1F135@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 16:44:20 -0000 On 2/2/2011 9:34 AM, Henry Lum wrote: > Yes, I think the confirmation or indication of recording is independent > of the no-record preference. Of course, unless the caller specifically > requests that the call to be rejected if no-record cannot be honoured > but then this type of request needs to be made when the call is placed. I think the best we could do for *that* is to reject the call if there will be an RS. But even then, who is responsible for honoring that request? Thanks, Paul > Henry > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: February-02-11 9:08 AM >> To: Elwell, John >> Cc: Henry Lum; siprec@ietf.org >> Subject: Re: [siprec] mechansim for requesting no-record for recording >> aware UA >> >> >> >> On 2/2/2011 3:39 AM, Elwell, John wrote: >> >>> [JRE] So let us imagine the SRC sends a no-record indication to the > SRS. At >> some stage there will need to be an indication on the CS as to whether > the >> call is being recorded or not. The issue is whether that indication > needs to be >> in response to the request conveying the no-record request, or whether > it >> can be deferred for a later request. >> >> ISTM that the caller will initially be informed (or already know) that > the call is >> being recorded. He will then post a request that it *not* be recorded, > but >> should continue to assume it is being recorded until receiving some > positive >> confirmation that it is not. That confirmation may come immediately, > later, or >> never. >> >> 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 john.elwell@siemens-enterprise.com Wed Feb 2 09:15:34 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE52F3A6CEC for ; Wed, 2 Feb 2011 09:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFwsPs9GsjGG for ; Wed, 2 Feb 2011 09:15:34 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DC1B53A6BC0 for ; Wed, 2 Feb 2011 09:15:33 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3240669; Wed, 2 Feb 2011 18:18:45 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A32931EB82AE; Wed, 2 Feb 2011 18:18:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Feb 2011 18:18:45 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Wed, 2 Feb 2011 18:18:44 +0100 Thread-Topic: [siprec] mechansim for requesting no-record for recording aware UA Thread-Index: AcvC4p62rWSlA42URciB1rfil53TbwAGoikA Message-ID: References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com> <059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> <4D496545.5010702@cisco.com> In-Reply-To: <4D496545.5010702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" , Henry Lum Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:15:35 -0000 Paul, That would be fine with me - I just wanted to make sure we understood the i= mplications. John (as individual) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 02 February 2011 14:08 > To: Elwell, John > Cc: Henry Lum; siprec@ietf.org > Subject: Re: [siprec] mechansim for requesting no-record for=20 > recording aware UA >=20 >=20 >=20 > On 2/2/2011 3:39 AM, Elwell, John wrote: >=20 > > [JRE] So let us imagine the SRC sends a no-record=20 > indication to the SRS. At some stage there will need to be an=20 > indication on the CS as to whether the call is being recorded=20 > or not. The issue is whether that indication needs to be in=20 > response to the request conveying the no-record request, or=20 > whether it can be deferred for a later request. >=20 > ISTM that the caller will initially be informed (or already=20 > know) that=20 > the call is being recorded. He will then post a request that=20 > it *not* be=20 > recorded, but should continue to assume it is being recorded until=20 > receiving some positive confirmation that it is not. That=20 > confirmation=20 > may come immediately, later, or never. >=20 > Thanks, > Paul > = From Dave.d.Smith@alcatel-lucent.com Wed Feb 2 11:17:17 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E145D3A6BFB for ; Wed, 2 Feb 2011 11:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfUY2xPLjIsz for ; Wed, 2 Feb 2011 11:17:14 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5282C3A67B7 for ; Wed, 2 Feb 2011 11:17:14 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p12JKWsq019017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Feb 2011 13:20:33 -0600 (CST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p12JKVRO015506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 13:20:32 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p12JKUDg009442; Wed, 2 Feb 2011 11:20:30 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 11:20:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 11:20:30 -0800 Message-ID: In-Reply-To: <4D496545.5010702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] mechansim for requesting no-record for recording aware UA Thread-Index: AcvC4qGEbYN9HY/5T/iUYppWxkFc7wAJlAEQ References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com><059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> <4D496545.5010702@cisco.com> From: "Dave Smith" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 02 Feb 2011 19:20:30.0318 (UTC) FILETIME=[415418E0:01CBC30E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Henry Lum , siprec@ietf.org Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:17:18 -0000 Can we rely on the implementation associated with REQ-018 to address that confirmation? o REQ-018 The mechanism MUST provide a means of indicating to the participants involved in a CS that their session is being recorded. Regards, Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, February 02, 2011 6:08 AM To: Elwell, John Cc: siprec@ietf.org; Henry Lum Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA On 2/2/2011 3:39 AM, Elwell, John wrote: > [JRE] So let us imagine the SRC sends a no-record indication to the SRS. At some stage there will need to be an indication on the CS as to whether the call is being recorded or not. The issue is whether that indication needs to be in response to the request conveying the no-record request, or whether it can be deferred for a later request. ISTM that the caller will initially be informed (or already know) that=20= the call is being recorded. He will then post a request that it *not* be recorded, but should continue to assume it is being recorded until=20 receiving some positive confirmation that it is not. That confirmation=20= may come immediately, later, or never. Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From Dave.d.Smith@alcatel-lucent.com Wed Feb 2 11:17:35 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DF13A67B7 for ; Wed, 2 Feb 2011 11:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u4nqpcSOFIi for ; Wed, 2 Feb 2011 11:17:32 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 94DDE3A6D4D for ; Wed, 2 Feb 2011 11:17:32 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p12JKYe4019037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Feb 2011 13:20:34 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p12JKV9h015514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 13:20:33 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p12JKU6j021079; Wed, 2 Feb 2011 11:20:31 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 11:20:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 11:20:30 -0800 Message-ID: In-Reply-To: <4D49608F.3050506@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvC39NOw+to13AzS9ygR1JGqAWa+wAKw3Uw References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> From: "Dave Smith" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 02 Feb 2011 19:20:30.0756 (UTC) FILETIME=[4196EE40:01CBC30E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:17:35 -0000 I don't think our req't changes for a conference. =20 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. =20 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). =20 Regards, Dave -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, February 02, 2011 5:48 AM To: Elwell, John Cc: Dave Smith; siprec@ietf.org; Alissa Cooper Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation On 2/2/2011 3:20 AM, Elwell, John wrote: > 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=20= it is that you are requesting not be recorded. So far we have not been=20= 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=20 know he is in a conference) requests that the CS not be recorded, then=20= 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 > John (as individual). > >> -----Original Message----- >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >> Sent: 02 February 2011 05:15 >> To: Paul Kyzivat >> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >> Subject: RE: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> 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:pkyzivat@cisco.com] >> Sent: Tuesday, February 01, 2011 5:36 AM >> To: Dave Smith >> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >> Subject: Re: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> >> >> 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:pkyzivat@cisco.com] >>> Sent: Monday, January 31, 2011 6:25 PM >>> To: Dave Smith >>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>>> Of Paul Kyzivat >>>> Sent: Thursday, January 27, 2011 5:30 AM >>>> To: siprec@ietf.org >>>> 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:Dave.d.Smith@alcatel-lucent.com] >>>>>>> Sent: 26 January 2011 21:22 >>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>> 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: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>> Of Elwell, John >>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>>>> To: siprec@ietf.org >>>>>>> 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 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>>>>> 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=3Dpb&SP=3DMC&rID= =3D >>>>>>> 8263017&rK >>>>>>> ey=3D19329980a044b45b >>>>>>> >>>>>>> Meeting started at 15.02. >>>>>>> >>>>>>> Topic - Administrivia (chairs) >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>>>>>> >>>>>>> No changes to published agenda. >>>>>>> >>>>>>> >>>>>>> Topic - Requirements (Ken Rehor) >>>>>>> draft-ietf-siprec-req-06 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> 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 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>>>>> 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 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>>>>> 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 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> 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 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> 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 >>>>>>> siprec@ietf.org >>>>>>> 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 >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> 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. >>> >>> >> >> >> -------------------------------------------------------------- >> ----------------------------------------------------- >> 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. >> >> > =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pkyzivat@cisco.com Wed Feb 2 13:13:08 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C7F3A6DB7 for ; Wed, 2 Feb 2011 13:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.525 X-Spam-Level: X-Spam-Status: No, score=-110.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5gf2g9kVQ94 for ; Wed, 2 Feb 2011 13:13:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 993803A6DAC for ; Wed, 2 Feb 2011 13:13:07 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvABAKJYSU1AZnwN/2dsb2JhbACWPY5ic6EImyOFUwSEeIZpgyo Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2011 21:16:27 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p12LGMft023444; Wed, 2 Feb 2011 21:16:27 GMT Message-ID: <4D49C9A6.5030402@cisco.com> Date: Wed, 02 Feb 2011 16:16:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Smith References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com><4D476E23.5060104@cisco.com><059AF07365DC474393A19A3AF187DF7406A1EF38@NAHALD.us.int.genesyslab.com> <4D496545.5010702@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Henry Lum , siprec@ietf.org Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 21:13:09 -0000 On 2/2/2011 2:20 PM, Dave Smith wrote: > Can we rely on the implementation associated with REQ-018 to address > that confirmation? > > o REQ-018 The mechanism MUST provide a means of indicating to the > participants involved in a CS that their session is being recorded. That doesn't currently require a mechanism to indicate that you are *not* being recorded. The indication that you are being recorded might be a one-time thing rather than a continuous thing. In that case its absence doesn't mean you are not being recorded. Thanks, Paul > Regards, > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, February 02, 2011 6:08 AM > To: Elwell, John > Cc: siprec@ietf.org; Henry Lum > Subject: Re: [siprec] mechansim for requesting no-record for recording > aware UA > > > > On 2/2/2011 3:39 AM, Elwell, John wrote: > >> [JRE] So let us imagine the SRC sends a no-record indication to the > SRS. At some stage there will need to be an indication on the CS as to > whether the call is being recorded or not. The issue is whether that > indication needs to be in response to the request conveying the > no-record request, or whether it can be deferred for a later request. > > ISTM that the caller will initially be informed (or already know) that > the call is being recorded. He will then post a request that it *not* be > > recorded, but should continue to assume it is being recorded until > receiving some positive confirmation that it is not. That confirmation > may come immediately, later, or never. > > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > 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 pkyzivat@cisco.com Wed Feb 2 14:03:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEA73A6DD4 for ; Wed, 2 Feb 2011 14:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.526 X-Spam-Level: X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6IGe9D-X9Kp for ; Wed, 2 Feb 2011 14:03:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6AFF33A687A for ; Wed, 2 Feb 2011 14:03:46 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvABAFJkSU1AZnwN/2dsb2JhbACWPY5ic4gsmEibJYJ8glcEhHiGaYMq Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 22:07:06 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p12M75ki005044; Wed, 2 Feb 2011 22:07:05 GMT Message-ID: <4D49D588.1050405@cisco.com> Date: Wed, 02 Feb 2011 17:07:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Smith References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:03:50 -0000 On 2/2/2011 2:20 PM, Dave Smith wrote: > 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). 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 > Regards, > Dave > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, February 02, 2011 5:48 AM > To: Elwell, John > Cc: Dave Smith; siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation > > > > On 2/2/2011 3:20 AM, Elwell, John wrote: >> 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 > >> John (as individual). >> >>> -----Original Message----- >>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>> Sent: 02 February 2011 05:15 >>> To: Paul Kyzivat >>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>> Subject: RE: [siprec] Proposed change to REQ-017 concerning >>> cancellation >>> >>> 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:pkyzivat@cisco.com] >>> Sent: Tuesday, February 01, 2011 5:36 AM >>> To: Dave Smith >>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning >>> cancellation >>> >>> >>> >>> 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:pkyzivat@cisco.com] >>>> Sent: Monday, January 31, 2011 6:25 PM >>>> To: Dave Smith >>>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf >>>>> Of Paul Kyzivat >>>>> Sent: Thursday, January 27, 2011 5:30 AM >>>>> To: siprec@ietf.org >>>>> 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:Dave.d.Smith@alcatel-lucent.com] >>>>>>>> Sent: 26 January 2011 21:22 >>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>> 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: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>> Of Elwell, John >>>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>>>>> To: siprec@ietf.org >>>>>>>> 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 >>>>>>>> siprec@ietf.org >>>>>>>> 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 >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> 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. >>>> >>>> >>> >>> >>> -------------------------------------------------------------- >>> ----------------------------------------------------- >>> 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.d.Smith@alcatel-lucent.com Wed Feb 2 18:20:57 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6763A6778 for ; Wed, 2 Feb 2011 18:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6GjS5dtyXYq for ; Wed, 2 Feb 2011 18:20:53 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E686C3A67CF for ; Wed, 2 Feb 2011 18:20:52 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p132NseS013031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Feb 2011 20:23:54 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p132Nq6b010043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 20:23:53 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p132NpFt012985; Wed, 2 Feb 2011 18:23:51 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 18:23:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 18:23:20 -0800 Message-ID: In-Reply-To: <4D49D588.1050405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvDJYsrhyopKAakQAy+OS7GnZjfzwAGFJPA References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> From: "Dave Smith" To: "Paul Kyzivat" , "Ken Rehor (krehor)" X-OriginalArrivalTime: 03 Feb 2011 02:23:51.0414 (UTC) FILETIME=[658FC160:01CBC349] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 02:20:57 -0000 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. =20 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:pkyzivat@cisco.com]=20 Sent: Wednesday, February 02, 2011 2:07 PM To: Dave Smith Cc: Elwell, John; siprec@ietf.org; Alissa Cooper Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation On 2/2/2011 2:20 PM, Dave Smith wrote: > 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). If the intent is to ack this request with a "the call is not being=20 recorded", then its important that there be agreement about *what* is=20 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] =20 For instance, is it ok that only the media *from* the requester is not=20= recorded, while all the media *to* his still is? Or is it ok if all the=20= media containing bits to/from him are not recorded, but other media=20 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=20= 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]=20 Thanks, Paul > Regards, > Dave > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, February 02, 2011 5:48 AM > To: Elwell, John > Cc: Dave Smith; siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation > > > > On 2/2/2011 3:20 AM, Elwell, John wrote: >> 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 > >> John (as individual). >> >>> -----Original Message----- >>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>> Sent: 02 February 2011 05:15 >>> To: Paul Kyzivat >>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>> Subject: RE: [siprec] Proposed change to REQ-017 concerning >>> cancellation >>> >>> 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:pkyzivat@cisco.com] >>> Sent: Tuesday, February 01, 2011 5:36 AM >>> To: Dave Smith >>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning >>> cancellation >>> >>> >>> >>> 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:pkyzivat@cisco.com] >>>> Sent: Monday, January 31, 2011 6:25 PM >>>> To: Dave Smith >>>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf >>>>> Of Paul Kyzivat >>>>> Sent: Thursday, January 27, 2011 5:30 AM >>>>> To: siprec@ietf.org >>>>> 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:Dave.d.Smith@alcatel-lucent.com] >>>>>>>> Sent: 26 January 2011 21:22 >>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>> 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: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>> Of Elwell, John >>>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>>>>> To: siprec@ietf.org >>>>>>>> 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 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>>>>>> 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=3Dpb&SP=3DMC&rI= D=3D >>>>>>>> 8263017&rK >>>>>>>> ey=3D19329980a044b45b >>>>>>>> >>>>>>>> Meeting started at 15.02. >>>>>>>> >>>>>>>> Topic - Administrivia (chairs) >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>>>>>>> >>>>>>>> No changes to published agenda. >>>>>>>> >>>>>>>> >>>>>>>> Topic - Requirements (Ken Rehor) >>>>>>>> draft-ietf-siprec-req-06 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>> 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 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>>>>>> 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 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>>>>>> 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 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>> >>>>>>>> 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 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>> 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 >>>>>>>> siprec@ietf.org >>>>>>>> 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 >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> 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. >>>> >>>> >>> >>> >>> -------------------------------------------------------------- >>> ----------------------------------------------------- >>> 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. >>> >>> >> > > =09 > ------------------------------------------------------------------------ ------------------------------------------- > 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. > =09 > =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From partr@cisco.com Wed Feb 2 21:20:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901513A685A for ; Wed, 2 Feb 2011 21:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfXGiJybhUh1 for ; Wed, 2 Feb 2011 21:20:41 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 46B793A6859 for ; Wed, 2 Feb 2011 21:20:41 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAIPKSU1AaMHG/2dsb2JhbACWSo5kc6BZmyKCe4JcBIR3iiA Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 03 Feb 2011 05:24:02 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p135LsRQ023232 for ; Thu, 3 Feb 2011 05:24:00 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 10:53:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 10:53:55 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP based Media overload control draft Thread-Index: Acu7+lyOL6q/0agWRuinGl+8LnohWAAACHagABtidVAAA6oooAAFAN1AAYvtnVAAJfL8YA== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 03 Feb 2011 05:23:55.0331 (UTC) FILETIME=[8D32A930:01CBC362] Subject: [siprec] FW: [dispatch] SIP based Media overload control draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 05:20:42 -0000 Hi all, draft-partha-dispatch-sip-media-overload-control-00 (http://tools.ietf.org/search/draft-partha-dispatch-sip-media-overload-c ontrol-00) is created to define the problem statement for SIP based Media overload control. SRS in SIPREC is a media server with disk storage. I have included the usecase in the draft. I'm interested in hearing from you in case you have more specific requirement to be solved in this area.=20 IMO, there is a need for generic SIP based media overload control. Please provide your valuable comments. Thanks Partha -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Wednesday, February 02, 2011 3:01 PM To: DRAGE, Keith (Keith); Elwell, John; dispatch@ietf.org; dworley@avaya.com Subject: Re: [dispatch] SIP based Media overload control draft Keith/John/Dale, Mediactrl (MRB) discusses about Resource monitoring at media server and currently, there is no mechanism exists for overload control. I attached SoC WG stance on SIP based Media overload control as a note of this mail. As a follow up query, Please let me know your take on whether SIP based media overload has to be solved as part of=20 1) Mediactrl WG 2) Any other WG exists. If so, Please name it. 3) New WG has to be created. 4) solve as individual draft. 5) or any other IETF way Thanks in advance Partha Note: Sec 1 of draft-ietf-soc-overload-design-04 There are cases in which a SIP server runs other services that do not involve the processing of SIP messages (e.g., processing of RTP packets, database queries, software updates and event handling). These services may, or may not, be correlated with the SIP message volume. These services can use up a substantial share of resources available on the server (e.g., CPU cycles) and leave the server in a condition where it is unable to process all incoming SIP requests. -----Original Message----- From: Parthasarathi R (partr) Sent: Tuesday, January 25, 2011 6:23 PM To: 'DRAGE, Keith (Keith)'; Elwell, John; dispatch@ietf.org Cc: 'dworley@avaya.com' Subject: RE: SIP based Media overload control draft =20 Keith, AFAIK, the mentioned issue is not solved in MRB. Including Dale Worley (Mediactrl WG Chair) in this mail thread to double confirm my understanding. Apart from the Mediactrl Mediaservers, I'm trying to find the solution for devices which acts as both Application server(AS) and Media Server (MS) at the same time. In the deployment, these devices shall be realized as PSTN GW, SBC, IP PBX with media handling.=20 Thanks Partha -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Tuesday, January 25, 2011 3:31 PM To: Elwell, John; Parthasarathi R (partr); dispatch@ietf.org Subject: RE: SIP based Media overload control draft If they are mediaservers, then does not the media resource broker in mediactrl already address this issue. Regards Keith -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John Sent: 25 January 2011 08:28 To: Parthasarathi R (partr); dispatch@ietf.org Subject: Re: [dispatch] SIP based Media overload control draft Partha, A fundamental difference between the problem addressed by SOC and the problem stated in your draft is as follows. SOC addresses the problem where a SIP server is so overloaded that receipt of further SIP requests will compound the problem, and therefore it is essential to take steps to reduce the number of SIP requests arriving at the overloaded server. The problem described in your draft is where the server is not overloaded in the sense of being unable to handle further SIP requests, but is overloaded in terms of media it can handle. Therefore it can still receive SIP requests, but it would have to reject some of them if the necessary media resources are not available. There may still be some benefit in preventing SIP requests arriving if media resources are not available. The main benefit would be that those SIP requests can more quickly be rerouted elsewhere, thereby reducing call set-up time. One scenario that might benefit would be where there are several, perhaps 10 or more, candidate media servers for a particular request, and trying each of these in turn would definitely impact call establishment times (or call rejection times on occasions when all candidates are overloaded). Is this the essence of the problem you are trying to address? It seems the document could certainly do with more on use cases and potential benefits that a solution might bring. John > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R > (partr) > Sent: 24 January 2011 19:38 > To: dispatch@ietf.org > Subject: [dispatch] SIP based Media overload control draft >=20 > Hi all, >=20 > IETF SoC WG is created for overload control solution of dedicated SIP=20 > signaling server only. There is an another kind of SIP servers exists=20 > in SIP deployment which handle SIP signaling and its related media=20 > (RTP, > T.38) in the same physical device. Those servers needs separate SIP=20 > based overload control solution. SIP based Media overload control=20 > draft summarizes problem specific to SIP media servers overload,=20 > requirements for SIP based media overload control solution and the=20 > draft is available at >=20 > http://datatracker.ietf.org/doc/draft-partha-dispatch-sip-medi > a-overload > -control/ >=20 > draft-partha-dispatch-resource-availability-00 and=20 > draft-jones-sip-overload-sce-00 are submitted in IETF-78 SoC WG for=20 > addressing the same problem. But, SIP based media overload control is=20 > considered as outside the scope of SoC WG. I'm interested in hearing=20 > from you whether this is a worth solving problem in IETF. >=20 > This draft is in straw-horse proposal state. I post this draft in=20 > dispatch to identify which WG is right place to solve this issue in=20 > IETF in case it is considered as worth solving problem. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, January 25, 2011 12:37 AM > To: Parthasarathi R (partr) > Subject: New Version Notification for > draft-partha-dispatch-sip-media-overload-control-00 >=20 >=20 > A new version of I-D, > draft-partha-dispatch-sip-media-overload-control-00.txt has been=20 > successfully submitted by Parthasarathi R and posted to the IETF=20 > repository. >=20 > Filename: draft-partha-dispatch-sip-media-overload-control > Revision: 00 > Title: Session Initiation Protocol (SIP)=20 > based Media overload > control Requirement > Creation_date: 2011-01-24 > WG ID: Independent Submission > Number_of_pages: 6 >=20 > Abstract: > Overload occurs in Session Initiation Protocol (SIP) networks when SIP > servers have insufficient resources to handle all SIP messages they=20 > receive. SIP based overload mechanism exists for dedicated SIP=20 > signaling servers. But there is a need for overload control solution=20 > of SIP based media servers like PSTN GW, Session border controllers=20 > (SBC), Session Recording Server(SRS). This document summarizes=20 > problem specific to SIP media servers, requirements for the solution=20 > of SIP based media overload control. > =20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Thu Feb 3 18:56:51 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FAB63A69BA for ; Thu, 3 Feb 2011 18:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-ednxPeEpaP for ; Thu, 3 Feb 2011 18:56:47 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DF3823A68CF for ; Thu, 3 Feb 2011 18:56:46 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2011 03:00:10 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1430AAh021817; Fri, 4 Feb 2011 03:00:10 GMT Message-ID: <4D4B6BBA.1020103@cisco.com> Date: Thu, 03 Feb 2011 22:00:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Smith References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 02:56:51 -0000 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 On 2/2/2011 9:23 PM, Dave Smith wrote: > 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:pkyzivat@cisco.com] > Sent: Wednesday, February 02, 2011 2:07 PM > To: Dave Smith > Cc: Elwell, John; siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation > > > > On 2/2/2011 2:20 PM, Dave Smith wrote: >> 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). > > 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 > >> Regards, >> Dave >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, February 02, 2011 5:48 AM >> To: Elwell, John >> Cc: Dave Smith; siprec@ietf.org; Alissa Cooper >> Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation >> >> >> >> On 2/2/2011 3:20 AM, Elwell, John wrote: >>> 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 >> >>> John (as individual). >>> >>>> -----Original Message----- >>>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>>> Sent: 02 February 2011 05:15 >>>> To: Paul Kyzivat >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>>> Subject: RE: [siprec] Proposed change to REQ-017 concerning >>>> cancellation >>>> >>>> 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:pkyzivat@cisco.com] >>>> Sent: Tuesday, February 01, 2011 5:36 AM >>>> To: Dave Smith >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning >>>> cancellation >>>> >>>> >>>> >>>> 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:pkyzivat@cisco.com] >>>>> Sent: Monday, January 31, 2011 6:25 PM >>>>> To: Dave Smith >>>>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Paul Kyzivat >>>>>> Sent: Thursday, January 27, 2011 5:30 AM >>>>>> To: siprec@ietf.org >>>>>> 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:Dave.d.Smith@alcatel-lucent.com] >>>>>>>>> Sent: 26 January 2011 21:22 >>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>> 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: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>>> Of Elwell, John >>>>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> 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 >>>>>>>>> siprec@ietf.org >>>>>>>>> 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 >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> 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. >>>>> >>>>> >>>> >>>> >>>> -------------------------------------------------------------- >>>> ----------------------------------------------------- >>>> 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. >> >> > > > ------------------------------------------------------------------------------------------------------------------- > 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 srao@ctigroup.com Thu Feb 3 19:03:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3113A679F for ; Thu, 3 Feb 2011 19:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrGjBcDdPRoh for ; Thu, 3 Feb 2011 19:03:20 -0800 (PST) Received: from EXCHANGE2K3.ctigroup.com (etomernpv.ctigroup.com [64.132.87.194]) by core3.amsl.com (Postfix) with ESMTP id DDF0F3A6A16 for ; Thu, 3 Feb 2011 19:03:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 22:06:38 -0500 Message-ID: In-Reply-To: <4D4B6BBA.1020103@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvEF6eUfIcYt/ZJQI6NF/0u2y6/qgAAIppQ References: <4D480C4F.9030704@cisco.com><4D49608F.3050506@cisco.com><4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> From: "Sid Rao" To: "Paul Kyzivat" , "Dave Smith" Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 03:03:24 -0000 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, February 03, 2011 10:00 PM To: Dave Smith Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation 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 On 2/2/2011 9:23 PM, Dave Smith wrote: > Paul - See In line below ( [DS] ). Hopefully that philosophy will work. > > > > Ken - By the way, REQ-018 never did get updated as I=20 > 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=20 > being recorded. > > > Regards, > Dave > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, February 02, 2011 2:07 PM > To: Dave Smith > Cc: Elwell, John; siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning=20 > cancellation > > > > On 2/2/2011 2:20 PM, Dave Smith wrote: >> 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). > > If the intent is to ack this request with a "the call is not being=20 > recorded", then its important that there be agreement about *what* is=20 > not being recorded.[DS] The idea is that any=20 > conversation/conference/call that includes this participant would not=20 > be recorded. Regardless of whether it is 2 participants or more,=20 > there is a request to "do NOT record." The SRC then can make a=20 > 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=20 > the media containing bits to/from him are not recorded, but other=20 > media involving other participants is?[DS] No, we're not considering=20 > bits and pieces of a call or a conference....keep it simple, all or=20 > nothing...we're talking about all of the conversation between the=20 > participants of a call where one of them does not want the=20 > 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=20 > 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=20 > 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=20 > recording is occurring currently" and the agent/UA would notice a change in the > Indication subsequent to their Request. [DS] > > Thanks, > Paul > >> Regards, >> Dave >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, February 02, 2011 5:48 AM >> To: Elwell, John >> Cc: Dave Smith; siprec@ietf.org; Alissa Cooper >> Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation >> >> >> >> On 2/2/2011 3:20 AM, Elwell, John wrote: >>> 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=20 >> been very explicit about the definition of a CS - leaving it up to=20 >> 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=20 >> know he is in a conference) requests that the CS not be recorded,=20 >> 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=20 >> as > a >> >> CS Group with a separate CS between the focus and each participant. >> >> Thanks, >> Paul >> >>> John (as individual). >>> >>>> -----Original Message----- >>>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>>> Sent: 02 February 2011 05:15 >>>> To: Paul Kyzivat >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>>> Subject: RE: [siprec] Proposed change to REQ-017 concerning=20 >>>> cancellation >>>> >>>> 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=20 >>>> participant involved in a CS to request, during or prior to the=20 >>>> start of recording, that the CS not be recorded. >>>> >>>> If we can't agree to that, or something just as simple, then maybe=20 >>>> 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:pkyzivat@cisco.com] >>>> Sent: Tuesday, February 01, 2011 5:36 AM >>>> To: Dave Smith >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John >>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning=20 >>>> cancellation >>>> >>>> >>>> >>>> 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=20 >>>> 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=20 >>>> can't >>>> >>>> record me without informing me. You could of course violate the=20 >>>> law, but >>>> >>>> then I can hold that against you. >>>> >>>> Maybe there are also laws that obligate you to stop recording if I=20 >>>> ask you to do so. (I suspect that is less likely, but I have no=20 >>>> 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=20 >>>> honoring requests to cease recording, or into rules for partial=20 >>>> recording. >>>> >>>> That means that just honoring these requests will require policy=20 >>>> 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=20 >>>> will enforce the policy, then everything needs to be sent to the=20 >>>> SRS so that it *can* record if it decides to. Or perhaps we must=20 >>>> allow the policy to >>>> >>>> be enforced by either the SRC or the SRS. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, >>>>> Dave >>>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Monday, January 31, 2011 6:25 PM >>>>> To: Dave Smith >>>>> Cc: siprec@ietf.org; 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=20 >>>>>> to >>>>> stop >>>>>> the recording and the Agent could then send a signal to the SRC=20 >>>>>> to >>>>> Stop >>>>>> recording. And probably similar functionality could be done by=20 >>>>>> 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=20 >>>>>> 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"=20 >>>>>> as >>>>> well >>>>>> as "prior to the start of recording." >>>>>> >>>>>> Regards, >>>>>> Dave >>>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Paul Kyzivat >>>>>> Sent: Thursday, January 27, 2011 5:30 AM >>>>>> To: siprec@ietf.org >>>>>> 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=20 >>>>>>> stopped >>>> and >>>>>>> discarded. Recording stops. Recording is discarded. >>>>>>> (3) Recording starts. Customer requests that recording be=20 >>>>>>> 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=20 >>>>>>> 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=20 >>>>>>> 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=20 >>>>>>> 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=20 >>>>>> 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:Dave.d.Smith@alcatel-lucent.com] >>>>>>>>> Sent: 26 January 2011 21:22 >>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>> 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=20 >>>>>>>>> participants might be able to request regarding "canceling"=20 >>>>>>>>> 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=20 >>>>>>>>> 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=20 >>>>>>>>> 3. Customer starts discussing their issue with the Agent 4.=20 >>>>>>>>> Customer realizes that the call is being recorded (e.g., they=20 >>>>>>>>> hear a "beep" tone indicating that the call is currently >>>> being >>>>>>>>> recorded) >>>>>>>>> 5. Customer decides that they do not want the call to be=20 >>>>>>>>> recorded 6. Customer requests that the call not be recorded=20 >>>>>>>>> (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=20 >>>>>>>>> recording Also note the following that could further be done,=20 >>>>>>>>> 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=20 >>>>>>>>> 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: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John >>>>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] Minutes day 1 >>>>>>>>> >>>>>>>>> Minutes of the SIPREC WG Interim Virtual Meeting 2011-01-25,=20 >>>>>>>>> 15.00-17.00 GMT/UTC and 2011-01-25, 14.00-16.00 GMT/UTC=20 >>>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> 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=20 >>>>>>>>> Kyzivat, Dave Smith, Parthasarathi, Dan Romascanu, Alissa=20 >>>>>>>>> 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=3Dpb&SP=3DMC&rID=3D >>>>>>>>> 8263017&rK >>>>>>>>> ey=3D19329980a044b45b >>>>>>>>> >>>>>>>>> Meeting started at 15.02. >>>>>>>>> >>>>>>>>> Topic - Administrivia (chairs) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>>>>>>>> >>>>>>>>> No changes to published agenda. >>>>>>>>> >>>>>>>>> >>>>>>>>> Topic - Requirements (Ken Rehor) >>>>>>>>> draft-ietf-siprec-req-06 >>>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>>>>>>> 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=20 >>>>>>>>> covered by other requirements (e.g., you can pause and not=20 >>>>>>>>> resume, effectively cancelling). So the main issue concerned=20 >>>>>>>>> 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=20 >>>>>>>>> the SRS, and outside the scope of SIPREC. There was no=20 >>>>>>>>> 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=20 >>>>>>>>> SRC, >>>> can >>>>>>>>> request the pausing / stopping of a recording, or even request >>>>>>>>> deletion of the recording. This would be a requirement=20 >>>>>>>>> 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=20 >>>>>>>>> forward into the present protocol draft). Dave was invited to=20 >>>>>>>>> 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=20 >>>>>>>>> the >>>>>> IESG. >>>>>>>>> >>>>>>>>> >>>>>>>>> Topic - Metadata model (Ram Mohan) >>>>>>>>> draft-ram-siprec-metadata-03 >>>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> 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=20 >>>>>>>>> would contribute to the media stream, but those participants=20 >>>>>>>>> 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=20 >>>>>>>>> participants rathe r than the mixer. So there can be=20 >>>>>>>>> participants in the media > that >>>>> are >>>>>>>>> not participants in the CS. Charles was worried that some=20 >>>>>>>>> media streams might not have any identified participants who=20 >>>>>>>>> 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=20 >>>>>>>>> particular use >>>>>> cases, >>>>>>>>> make them known and we check how they would be represented.=20 >>>>>>>>> Ram >>>>> will >>>>>>>>> solicit use cases. Partha also had concerns similar to those=20 >>>>>>>>> of Charles, but Charles was beginning to see how the present=20 >>>>>>>>> model might work if you can get information about non-CS=20 >>>>>>>>> participants who are generating a media stream. Paul pointed=20 >>>>>>>>> out that the model does cater for a >>>>> participant >>>>>>>>> that is not part of a CS. Charles was invited to post his=20 >>>>>>>>> continued conc erns / scenarios to the list, but Paul thinks=20 >>>>>>>>> the use cases >>>>>> concerned >>>>>>>>> are already covered by the model. >>>>>>>>> >>>>>>>>> Slide 6 (CS Group): Nobody on list had come up with a reason=20 >>>>>>>>> for having more than one CSG associated with a single CS, and=20 >>>>>>>>> the >>>> conclusion >>>>>>>>> reached on the list seems to stand. >>>>>>>>> >>>>>>>>> Slide 7 (CS): No comments on CS slide, except that forced=20 >>>>>>>>> deletion is to be removed in line with the requirements=20 >>>>>>>>> discussion. >>>>>>>>> >>>>>>>>> Slide 8 (Participant): Clarified that the multiple AORs are=20 >>>>>>>>> aliases, in the sense of P-Asserted-Identity being able to=20 >>>>>>>>> carry aliases. >>>>>>>>> >>>>>>>>> Concerning the issue of whether participant role is needed as > an >>>>>>>>> attribute, Leon suggested it could be done in application=20 >>>>>>>>> data, >>>> but >>>>>>>>> asked whether we would then publish some application data >>>>>> dictionary. >>>>>>>>> Paul suggested that application data is just some additional=20 >>>>>>>>> XML in some other namespace, so some other group could get=20 >>>>>>>>> together >>>> and define >>>>>> it. >>>>>>>>> Leon was concerned that without some sort of standardization,=20 >>>>>>>>> different vendors would implement it differently. John=20 >>>>>>>>> suggested we need to decide what things are needed by 80% of=20 >>>>>>>>> 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,=20 >>>>>>>>> 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,=20 >>>>>>>>> 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=20 >>>>>>>>> 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=20 >>>>>>>>> there was media that was available for recording but couldn't=20 >>>>>>>>> be > recorded, >>>>> but >>>>>>>>> there are two cases: where you don't want to record, or where=20 >>>>>>>>> because of a temporary limitation you are unable to record but >>>>>>>>> might want to record later. Paul agreed, but was concerned=20 >>>>>>>>> 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=20 >>>>>>>>> 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=20 >>>>>>>>> attributes of other objects. Paul said it was just an artefact >>>>>>>>> of how the model is drawn, but in the solution it would just=20 >>>>>>>>> be extensibility data. >>>> The >>>>>>>>> authors will rework this with these comments in mind. >>>>>>>>> >>>>>>>>> On next steps, people are asked to review and submit further=20 >>>>>>>>> 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 >>>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> 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 >>>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>>>>>>> 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 >>>>>>>>> siprec@ietf.org >>>>>>>>> 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 >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> 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. >>>>> >>>>> >>>> >>>> >>>> -------------------------------------------------------------- >>>> ----------------------------------------------------- >>>> 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. >>>> >>>> >>> >> >> =09 >> > ------------------------------------------------------------------------ > ------------------------------------------- >> 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. >> =09 >> > > =09 > ------------------------------------------------------------------------ ------------------------------------------- > 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. > =09 > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ From john.elwell@siemens-enterprise.com Thu Feb 3 23:19:17 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F893A677C for ; Thu, 3 Feb 2011 23:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yewt9SQ3Lju0 for ; Thu, 3 Feb 2011 23:19:14 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 076EF3A6866 for ; Thu, 3 Feb 2011 23:19:12 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3269686; Fri, 4 Feb 2011 08:22:35 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8DD5C1EB82BB; Fri, 4 Feb 2011 08:22:35 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 4 Feb 2011 08:22:35 +0100 From: "Elwell, John" To: Paul Kyzivat , Dave Smith Date: Fri, 4 Feb 2011 08:22:33 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvEF6UY6nay8mllTYGbAIkmO7OjzAAJGfCA Message-ID: References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> In-Reply-To: <4D4B6BBA.1020103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 07:19:17 -0000 Paul, Some of this will certainly need to be looked at again as part of the solut= ion work, but in order to try to complete the requirements document, can yo= u possibly propose some revised words that you think will be adequate for g= uiding us in our future endeavours? Thanks, John (as chair) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 04 February 2011 03:00 > To: Dave Smith > Cc: Ken Rehor (krehor); Elwell, John; siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > 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 > > On 2/2/2011 9:23 PM, Dave Smith wrote: > > 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:pkyzivat@cisco.com] > > Sent: Wednesday, February 02, 2011 2:07 PM > > To: Dave Smith > > Cc: Elwell, John; siprec@ietf.org; Alissa Cooper > > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > > > > > > > On 2/2/2011 2:20 PM, Dave Smith wrote: > >> 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). > > > > 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 > > > >> Regards, > >> Dave > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, February 02, 2011 5:48 AM > >> To: Elwell, John > >> Cc: Dave Smith; siprec@ietf.org; Alissa Cooper > >> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > cancellation > >> > >> > >> > >> On 2/2/2011 3:20 AM, Elwell, John wrote: > >>> 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 > >> > >>> John (as individual). > >>> > >>>> -----Original Message----- > >>>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > >>>> Sent: 02 February 2011 05:15 > >>>> To: Paul Kyzivat > >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John > >>>> Subject: RE: [siprec] Proposed change to REQ-017 concerning > >>>> cancellation > >>>> > >>>> 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:pkyzivat@cisco.com] > >>>> Sent: Tuesday, February 01, 2011 5:36 AM > >>>> To: Dave Smith > >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John > >>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >>>> cancellation > >>>> > >>>> > >>>> > >>>> 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:pkyzivat@cisco.com] > >>>>> Sent: Monday, January 31, 2011 6:25 PM > >>>>> To: Dave Smith > >>>>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf > >>>>>> Of Paul Kyzivat > >>>>>> Sent: Thursday, January 27, 2011 5:30 AM > >>>>>> To: siprec@ietf.org > >>>>>> 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:Dave.d.Smith@alcatel-lucent.com] > >>>>>>>>> Sent: 26 January 2011 21:22 > >>>>>>>>> To: Elwell, John; siprec@ietf.org > >>>>>>>>> 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: siprec-bounces@ietf.org > >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf > >>>>>>>>> Of Elwell, John > >>>>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM > >>>>>>>>> To: siprec@ietf.org > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >>>>>>>>> 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=3Dpb&SP=3DMC&rID=3D > >>>>>>>>> 8263017&rK > >>>>>>>>> ey=3D19329980a044b45b > >>>>>>>>> > >>>>>>>>> Meeting started at 15.02. > >>>>>>>>> > >>>>>>>>> Topic - Administrivia (chairs) > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf > >>>>>>>>> > >>>>>>>>> No changes to published agenda. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Topic - Requirements (Ken Rehor) > >>>>>>>>> draft-ietf-siprec-req-06 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>>>> > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>>>> 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 > >>>>>>>>> siprec@ietf.org > >>>>>>>>> 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 > >>>>>>>> siprec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> siprec mailing list > >>>>>> siprec@ietf.org > >>>>>> 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. > >>>>> > >>>>> > >>>> > >>>> > >>>> -------------------------------------------------------------- > >>>> ----------------------------------------------------- > >>>> 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. > >> > >> > > > > > > > -------------------------------------------------------------- > ----------------------------------------------------- > > 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 john.elwell@siemens-enterprise.com Fri Feb 4 00:29:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998EB3A6AE0 for ; Fri, 4 Feb 2011 00:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8TXRQiyQlLN for ; Fri, 4 Feb 2011 00:29:30 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 86BD53A689A for ; Fri, 4 Feb 2011 00:29:30 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3272244; Fri, 4 Feb 2011 09:32:53 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 916FB23F0278; Fri, 4 Feb 2011 09:32:53 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 4 Feb 2011 09:32:53 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 4 Feb 2011 09:32:51 +0100 Thread-Topic: Apps advisor for SIPREC Thread-Index: AcvERhxuBwyHPtRWRWyf1h91g4G34w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stpeter@stpeter.im" Subject: [siprec] Apps advisor for SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 08:29:31 -0000 I am very pleased to announce that Peter Saint-Andre has agreed to be the A= pps advisor to SIPREC, with special focus on XML. The authors of the metada= ta format draft have already identified questions in this area, so please i= nvolve Peter. John= From john.elwell@siemens-enterprise.com Fri Feb 4 01:36:18 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735A23A689B for ; Fri, 4 Feb 2011 01:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkuMAshwp7kt for ; Fri, 4 Feb 2011 01:36:11 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1AC2C3A68AC for ; Fri, 4 Feb 2011 01:36:09 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3271373; Fri, 4 Feb 2011 10:39:33 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id CDD1E23F028E; Fri, 4 Feb 2011 10:39:33 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 4 Feb 2011 10:39:33 +0100 From: "Elwell, John" To: Sid Rao , Paul Kyzivat , Dave Smith Date: Fri, 4 Feb 2011 10:39:32 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvEF6eUfIcYt/ZJQI6NF/0u2y6/qgAAIppQAA20SfA= Message-ID: References: <4D480C4F.9030704@cisco.com><4D49608F.3050506@cisco.com><4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 09:36:19 -0000 I don't think it is the intention to prevent notification by media, and I a= gree 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/S= DP to allow injection of tones / announcements, and the nature of the tone/= announcement cannot be subject to standardization. John > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Sid Rao > Sent: 04 February 2011 03:07 > To: Paul Kyzivat; Dave Smith > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > 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: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, February 03, 2011 10:00 PM > To: Dave Smith > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > 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 > > On 2/2/2011 9:23 PM, Dave Smith wrote: > > 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:pkyzivat@cisco.com] > > Sent: Wednesday, February 02, 2011 2:07 PM > > To: Dave Smith > > Cc: Elwell, John; siprec@ietf.org; Alissa Cooper > > Subject: Re: [siprec] Proposed change to REQ-017 concerning > > cancellation > > > > > > > > On 2/2/2011 2:20 PM, Dave Smith wrote: > >> 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). > > > > 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 > > > >> Regards, > >> Dave > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, February 02, 2011 5:48 AM > >> To: Elwell, John > >> Cc: Dave Smith; siprec@ietf.org; Alissa Cooper > >> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > cancellation > >> > >> > >> > >> On 2/2/2011 3:20 AM, Elwell, John wrote: > >>> 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 > >> > >>> John (as individual). > >>> > >>>> -----Original Message----- > >>>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > >>>> Sent: 02 February 2011 05:15 > >>>> To: Paul Kyzivat > >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John > >>>> Subject: RE: [siprec] Proposed change to REQ-017 concerning > >>>> cancellation > >>>> > >>>> 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:pkyzivat@cisco.com] > >>>> Sent: Tuesday, February 01, 2011 5:36 AM > >>>> To: Dave Smith > >>>> Cc: siprec@ietf.org; Alissa Cooper; Elwell, John > >>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >>>> cancellation > >>>> > >>>> > >>>> > >>>> 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:pkyzivat@cisco.com] > >>>>> Sent: Monday, January 31, 2011 6:25 PM > >>>>> To: Dave Smith > >>>>> Cc: siprec@ietf.org; 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: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf > >>>>>> Of Paul Kyzivat > >>>>>> Sent: Thursday, January 27, 2011 5:30 AM > >>>>>> To: siprec@ietf.org > >>>>>> 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:Dave.d.Smith@alcatel-lucent.com] > >>>>>>>>> Sent: 26 January 2011 21:22 > >>>>>>>>> To: Elwell, John; siprec@ietf.org > >>>>>>>>> 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: siprec-bounces@ietf.org > >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > >>>>>>>>> Sent: Tuesday, January 25, 2011 2:24 PM > >>>>>>>>> To: siprec@ietf.org > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >>>>>>>>> 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=3Dpb&SP=3DMC&rID=3D > >>>>>>>>> 8263017&rK > >>>>>>>>> ey=3D19329980a044b45b > >>>>>>>>> > >>>>>>>>> Meeting started at 15.02. > >>>>>>>>> > >>>>>>>>> Topic - Administrivia (chairs) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >>>>>>>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf > >>>>>>>>> > >>>>>>>>> No changes to published agenda. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Topic - Requirements (Ken Rehor) > >>>>>>>>> draft-ietf-siprec-req-06 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>>>> > >>>>>>>>> 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 > >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>>>> 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 > >>>>>>>>> siprec@ietf.org > >>>>>>>>> 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 > >>>>>>>> siprec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> siprec mailing list > >>>>>> siprec@ietf.org > >>>>>> 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. > >>>>> > >>>>> > >>>> > >>>> > >>>> -------------------------------------------------------------- > >>>> ----------------------------------------------------- > >>>> 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. > >> > >> > > > > > > > -------------------------------------------------------------- > ---------- > ------------------------------------------- > > 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 > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partr@cisco.com Fri Feb 4 02:03:30 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801513A68CB for ; Fri, 4 Feb 2011 02:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6W2kebF+lJ6 for ; Fri, 4 Feb 2011 02:03:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6B7733A68B0 for ; Fri, 4 Feb 2011 02:03:29 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUBAFdeS02Q/khMgWdsb2JhbACWT45eFQEBFiIknnqadoJ9gl0EhHiKIg Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2011 10:06:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p14A6pnv010039; Fri, 4 Feb 2011 10:06:53 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 15:36:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Feb 2011 15:36:49 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Apps advisor for SIPREC Thread-Index: AcvERhxuBwyHPtRWRWyf1h91g4G34wACndSQ References: From: "Parthasarathi R (partr)" To: "Elwell, John" , , X-OriginalArrivalTime: 04 Feb 2011 10:06:52.0904 (UTC) FILETIME=[3F087680:01CBC453] Subject: Re: [siprec] Apps advisor for SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 10:03:30 -0000 John, Thanks for identifying Peter as the app advisor for metadata format. Peter, Thanks to agree for app advisor for SIPREC. The strawhorse proposal of Metadata XML format is available at http://www.ietf.org/internet-drafts/draft-ram-siprec-metadata-format-00. txt. Please provide your valuable comments. Open items 1: The current approach is to pass the complete metadata for each transaction from SRC to SRS. The limitation is that SRS has to keep track of the last metadata and identify the difference. There is need to pass only the update of metadata through XML. IOW, partial data has to be passed across in XML document. Some of the approaches which we comes across are: 1) Create individual namespace for each XML element and pass it whenever it is updated using its unique id. 2) RFC5261 which uses XPath to locate and make changes to the snapshot. XCON event package uses this mechanism and the draft is expired. 3) REST Architecture for SIPREC XML 4) or any other ? Please provide your valuable opinion which best fit for SIPREC metadata document. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, February 04, 2011 2:03 PM To: siprec@ietf.org Cc: stpeter@stpeter.im Subject: [siprec] Apps advisor for SIPREC I am very pleased to announce that Peter Saint-Andre has agreed to be the Apps advisor to SIPREC, with special focus on XML. The authors of the metadata format draft have already identified questions in this area, so please involve Peter. John _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Fri Feb 4 06:26:45 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414743A6935 for ; Fri, 4 Feb 2011 06:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bKyRbNQ-6bt for ; Fri, 4 Feb 2011 06:26:43 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 139FE3A691A for ; Fri, 4 Feb 2011 06:26:42 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3278940; Fri, 4 Feb 2011 15:30:06 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E1DB41EB82AB; Fri, 4 Feb 2011 15:30:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 4 Feb 2011 15:30:06 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , "siprec@ietf.org" , "stpeter@stpeter.im" Date: Fri, 4 Feb 2011 15:30:05 +0100 Thread-Topic: [siprec] Apps advisor for SIPREC Thread-Index: AcvERhxuBwyHPtRWRWyf1h91g4G34wACndSQAAnIsFA= Message-ID: References: Keywords: SIPREC In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Apps advisor for SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:26:45 -0000 Well, I should have mentioned it was Gonzalo who did the negotiation, so th= anks to Gonzalo, not me, and also of course to Peter for taking on this tas= k. John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 04 February 2011 10:07 > To: Elwell, John; siprec@ietf.org; stpeter@stpeter.im > Subject: RE: [siprec] Apps advisor for SIPREC >=20 > John, >=20 > Thanks for identifying Peter as the app advisor for metadata format. >=20 > Peter, >=20 > Thanks to agree for app advisor for SIPREC. The strawhorse proposal of > Metadata XML format is available at > http://www.ietf.org/internet-drafts/draft-ram-siprec-metadata- > format-00. > txt. Please provide your valuable comments. >=20 > Open items 1: > The current approach is to pass the complete metadata for each > transaction from SRC to SRS. The limitation is that SRS has to keep > track of the last metadata and identify the difference. There=20 > is need to > pass only the update of metadata through XML. IOW, partial data has to > be passed across in XML document. Some of the approaches=20 > which we comes > across are: >=20 > 1) Create individual namespace for each XML element and pass=20 > it whenever > it is updated using its unique id. > 2) RFC5261 which uses XPath to locate and make changes to the=20 > snapshot. > XCON event package uses this mechanism and the draft is expired. > 3) REST Architecture for SIPREC XML > 4) or any other ? >=20 > Please provide your valuable opinion which best fit for=20 > SIPREC metadata > document. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Friday, February 04, 2011 2:03 PM > To: siprec@ietf.org > Cc: stpeter@stpeter.im > Subject: [siprec] Apps advisor for SIPREC >=20 > I am very pleased to announce that Peter Saint-Andre has agreed to be > the Apps advisor to SIPREC, with special focus on XML. The authors of > the metadata format draft have already identified questions in this > area, so please involve Peter. >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@cisco.com Fri Feb 4 08:37:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058EC3A6907 for ; Fri, 4 Feb 2011 08:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU2Qbh3OmVwC for ; Fri, 4 Feb 2011 08:37:00 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A80CE3A67F7 for ; Fri, 4 Feb 2011 08:37:00 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2011 16:40:25 +0000 Received: from [161.44.182.140] (dhcp-161-44-182-140.cisco.com [161.44.182.140]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p14GePs1019676; Fri, 4 Feb 2011 16:40:25 GMT Message-ID: <4D4C2BF9.5060004@cisco.com> Date: Fri, 04 Feb 2011 11:40:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:37:02 -0000 On 2/4/2011 2:22 AM, Elwell, John wrote: > 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? 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: 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 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@nice.com Sun Feb 6 07:59:41 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E473A693B for ; Sun, 6 Feb 2011 07:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPksBcvQWhRM for ; Sun, 6 Feb 2011 07:59:40 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id BDADF3A6900 for ; Sun, 6 Feb 2011 07:59:39 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 6 Feb 2011 17:59:40 +0200 From: Leon Portman To: Paul Kyzivat , "Elwell, John" Date: Sun, 6 Feb 2011 17:59:38 +0200 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvEij5rCPN3nLxwRYmvzjKaDD/gwwBi0fWw Message-ID: <07465C1D981ABC41A344374066AE1A2C38A354D9C7@TLVMBX01.nice.com> References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> In-Reply-To: <4D4C2BF9.5060004@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 15:59:41 -0000 Paul, Hi Please see below my comments Regards Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Friday, February 04, 2011 6:40 PM To: Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation On 2/4/2011 2:22 AM, Elwell, John wrote: > Paul, > > Some of this will certainly need to be looked at again as part of the sol= ution 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. Here is the existing related bunch of requirements, and my attempt to re-sp= in 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. [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 application= s. And also confirmation of the removal of the recording can be asynchronou= s (department of defence deletion takes time for example) and better to be = implemented outside RS session (web services for example) 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 understan= d this) about communication between a CS participant and the SRC: [Leon] I agree that it is belongs to outband signaling channel 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 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 wit= h: * 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 capabili= ties of participants to recognize an indication in signaling, and conversel= y an inability to nail down how this might be dealt with generically withou= t that. This also doesn't address what might have happened in response to r= equests to delete already recorded media and/or metadata. I think we need to split this into two parts. One concerns signaling from t= he 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 re= asonable 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 re= quired 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 implemen= tations. Where required by business or legal reasons, an implementation can= ensure that there is a sufficiently capable participant in each CS, that c= an receive the indications and render them in the media. [Leon] I agree Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Sun Feb 6 18:50:11 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5330F3A6BDA for ; Sun, 6 Feb 2011 18:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7wFQsnBjxrs for ; Sun, 6 Feb 2011 18:50:08 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BEC533A69EF for ; Sun, 6 Feb 2011 18:50:08 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC/sTk2rRDoI/2dsb2JhbAClMXOfdpoqhVoEhHqGbYMu Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Feb 2011 02:50:11 +0000 Received: from [10.86.250.246] (bxb-vpn3-758.cisco.com [10.86.250.246]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p172oAGh003914; Mon, 7 Feb 2011 02:50:11 GMT Message-ID: <4D4F5DE2.8030206@cisco.com> Date: Sun, 06 Feb 2011 21:50:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Leon Portman References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <07465C1D981ABC41A344374066AE1A2C38A354D9C7@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A354D9C7@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 02:50:11 -0000 Just one comment back to you > 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. > > [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) 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@nice.com Sun Feb 6 23:19:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C259C3A6C9F for ; Sun, 6 Feb 2011 23:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3PGF4kiDr77 for ; Sun, 6 Feb 2011 23:19:02 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id AA89E3A6BDB for ; Sun, 6 Feb 2011 23:19:01 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 7 Feb 2011 09:19:04 +0200 From: Leon Portman To: Paul Kyzivat Date: Mon, 7 Feb 2011 09:19:03 +0200 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvGccNgKlik4edPS7W8IdF2iq1CHAAJP46g Message-ID: <07465C1D981ABC41A344374066AE1A2C38A354DB0E@TLVMBX01.nice.com> References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <07465C1D981ABC41A344374066AE1A2C38A354D9C7@TLVMBX01.nice.com> <4D4F5DE2.8030206@cisco.com> In-Reply-To: <4D4F5DE2.8030206@cisco.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 07:19:02 -0000 Paul, Hi The reason why I am think that is out of scope because all use cases of ret= ention, canceling and discarding of the media and metadata is more about po= licy 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:pkyzivat@cisco.com]=20 Sent: Monday, February 07, 2011 4:50 AM To: Leon Portman Cc: Elwell, John; siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation Just one comment back to you > 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. > > [Leon] I have no problem with wording however still think that these flow= s are outside of SIPREC protocol. Because for some configurations SRS expos= es such functionality directly (and not via SRS) to agent desktop applicati= ons. And also confirmation of the removal of the recording can be asynchron= ous (department of defence deletion takes time for example) and better to b= e implemented outside RS session (web services for example) 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 john.elwell@siemens-enterprise.com Mon Feb 7 04:18:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22593A6DEE for ; Mon, 7 Feb 2011 04:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGS-yn1xHZdf for ; Mon, 7 Feb 2011 04:18:02 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id EFAB13A6DED for ; Mon, 7 Feb 2011 04:18:01 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3295471; Mon, 7 Feb 2011 13:18:03 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 0A70D23F0290; Mon, 7 Feb 2011 13:18:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 7 Feb 2011 13:18:02 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Mon, 7 Feb 2011 13:17:59 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvEijpOth1qxE8CQmaz8qxY0cC5DgCMgJCg Message-ID: References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> In-Reply-To: <4D4C2BF9.5060004@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 12:18:03 -0000 Paul, Thanks for putting this into words. It seems the scope of possible requirem= ents 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 i= s in charge of policy concerning retention of recordings, and hence will ha= ve 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 a= vailable 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 poi= nted 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 discar= d), I had imagined the SRC could send the request to the SRS, and that woul= d 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 di= rection of removing REQ-015/REQ-016 (address them in a later phase if neces= sary). 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 th= an 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 w= ithin media, but I think an indication at signalling level would be appropr= iate. This would be targeted at siprec-compliant UAs on the CS and should c= over whether the CS is being recorded or not being recorded. Although it mi= ght be tempting to get more sophisticated and indicate whether particular m= edia 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 i= n 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 A= gent" 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 re= quest that the CS not be recorded." John (as individual) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 04 February 2011 16:40 > To: Elwell, John > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning=20 > cancellation >=20 >=20 >=20 > On 2/4/2011 2:22 AM, Elwell, John wrote: > > Paul, > > > > Some of this will certainly need to be looked at again as=20 > part of the solution work, but in order to try to complete=20 > the requirements document, can you possibly propose some=20 > revised words that you think will be adequate for guiding us=20 > in our future endeavours? >=20 > I'll try. > Here is the existing related bunch of requirements, and my attempt to=20 > re-spin them: >=20 > o REQ-015: The mechanism MUST support a means to cancel=20 > and discard > the recording and associated metadata for a CS. >=20 > Perhaps we replace those with: >=20 > * 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. >=20 > * 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. >=20 > Similarly, replace >=20 > o REQ-016: The mechanism MUST support a means to cancel=20 > and discard > the recording but not the associated metadata for a CS. >=20 > with: >=20 > * 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. >=20 > * 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. >=20 > Note that the above are only about SRC to SRS communication.=20 > Presumably=20 > it can all be done in the signaling channel. The remainder are (as I=20 > understand this) about communication between a CS participant=20 > and the SRC: >=20 > 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 >=20 > This clearly has problems if there is a pre-established RS. It also=20 > doesn't address the distinction between media and metadata.=20 > So perhaps=20 > replace with: >=20 > * 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. >=20 > (This is only applicable to CSs where an RS has not yet been > established. Not clear if its worth the trouble.) >=20 > * 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. >=20 > * 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. >=20 > * 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. >=20 > None of that provides any confirmation. The following is what=20 > we have on=20 > that: >=20 > o REQ-018 The mechanism MUST provide a means of indicating to the > participants involved in a CS that their session is being=20 > recorded. >=20 > 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. >=20 > We have been dancing around this one because of concerns about the=20 > capabilities of participants to recognize an indication in signaling,=20 > and conversely an inability to nail down how this might be dealt with=20 > generically without that. This also doesn't address what might have=20 > happened in response to requests to delete already recorded=20 > media and/or=20 > metadata. >=20 > I think we need to split this into two parts. One concerns signaling=20 > from the SRC to the "authorized particpant" the outcome of a=20 > request it=20 > made. >=20 > The other is the indicating recording, indicating of=20 > non-recording, or=20 > not indicating of recording, to all participants. I despair coming up=20 > with a reasonable requirement on this. To be complete it=20 > would need to=20 > include media-only participants, and work for all media. (What if a=20 > participant has only video but you only send the indication=20 > in audio?)=20 > Also, exactly what is required here is based on laws that=20 > vary by locale. >=20 > * 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. >=20 > (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.) >=20 > Given that, I think we have to leave the media-based indication to=20 > implementations. Where required by business or legal reasons, an=20 > implementation can ensure that there is a sufficiently capable=20 > participant in each CS, that can receive the indications and=20 > render them=20 > in the media. >=20 > Thanks, > Paul > = From pkyzivat@cisco.com Mon Feb 7 05:36:07 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8A33A6E0A for ; Mon, 7 Feb 2011 05:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2UBcyTPNjLT for ; Mon, 7 Feb 2011 05:36:06 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B9E6D3A6E09 for ; Mon, 7 Feb 2011 05:36:06 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAJGET01AZnwN/2dsb2JhbACWVI5ec59ImleFWgSEeoZtgy4 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2011 13:36:10 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p17DaABL019047; Mon, 7 Feb 2011 13:36:10 GMT Message-ID: <4D4FF54A.3090509@cisco.com> Date: Mon, 07 Feb 2011 08:36:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Leon Portman References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <07465C1D981ABC41A344374066AE1A2C38A354D9C7@TLVMBX01.nice.com> <4D4F5DE2.8030206@cisco.com> <07465C1D981ABC41A344374066AE1A2C38A354DB0E@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A354DB0E@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 13:36:07 -0000 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 On 2/7/2011 2:19 AM, Leon Portman wrote: > 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:pkyzivat@cisco.com] > Sent: Monday, February 07, 2011 4:50 AM > To: Leon Portman > Cc: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation > > Just one comment back to you > >> 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. >> >> [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) > > 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 pkyzivat@cisco.com Mon Feb 7 06:24:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EC53A68EC for ; Mon, 7 Feb 2011 06:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1mcScYDVK9p for ; Mon, 7 Feb 2011 06:24:03 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CF8E03A68C6 for ; Mon, 7 Feb 2011 06:24:02 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2011 14:24:06 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p17EO60J008924; Mon, 7 Feb 2011 14:24:06 GMT Message-ID: <4D500086.3010506@cisco.com> Date: Mon, 07 Feb 2011 09:24:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:24:04 -0000 On 2/7/2011 7:17 AM, Elwell, John wrote: > 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: 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 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? 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 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). 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. > 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." 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: > "REQ-017 The mechanism MUST support a means for a UA involved in a CS to request that the CS not be recorded." 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) > > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 04 February 2011 16:40 >> To: Elwell, John >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper >> Subject: Re: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> >> >> On 2/4/2011 2:22 AM, Elwell, John wrote: >>> 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? >> >> 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: >> >> 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 >> >> 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 john.elwell@siemens-enterprise.com Mon Feb 7 06:36:08 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08DB3A68C6 for ; Mon, 7 Feb 2011 06:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGBpiyhNqUO6 for ; Mon, 7 Feb 2011 06:36:07 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8EE723A691C for ; Mon, 7 Feb 2011 06:36:06 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3289858; Mon, 7 Feb 2011 15:35:57 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E06E61EB82B5; Mon, 7 Feb 2011 15:35:57 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 7 Feb 2011 15:35:57 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Mon, 7 Feb 2011 15:35:56 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvG0q8pP2EaoF4PRTycz4xIXosErAAAYQQQ Message-ID: References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <4D500086.3010506@cisco.com> In-Reply-To: <4D500086.3010506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:36:08 -0000 Paul, Yes, I would agree with your proposed addition of "henceforth" to my propos= al for REQ-017. John (as individual) =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 07 February 2011 14:24 > To: Elwell, John > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning=20 > cancellation >=20 >=20 >=20 > On 2/7/2011 7:17 AM, Elwell, John wrote: > > Paul, > > > > Thanks for putting this into words. It seems the scope of=20 > possible requirements here is quite broad, and I am not sure=20 > we need all this. Basically my comments are as follows: >=20 > John, >=20 > As I already replied to Leon, I don't have much of an opinion=20 > of whether=20 > these things should be requirements or not - just that if they are=20 > requirements then they need to be clear and logical. >=20 > > 1. Concerning discarding a recording, we have agreed in the=20 > past that SRS is in charge of policy concerning retention of=20 > recordings, and hence will have the final say in whether a=20 > request to discard is honoured. I am not sure whether there=20 > needs to be any obligation for the SRS to make this policy=20 > available to the SRS, and hence I am not sure whether we need=20 > a requirement to report back to the SRC the outcome of a=20 > discard request. As Leon has pointed out, the outcome might=20 > not be known immediately. Also, how trustworthy is it? >=20 > Well, whether the SRS needs to allow the SRC an *input* to the policy=20 > decision is what this is all about. >=20 > While I agree that providing an ack/nack to such an input is an=20 > independent decision, its my feeling that there is little point in=20 > allowing the input without some feedback. >=20 > (From a practical perspective, eliminating the feedback makes life=20 > simpler for the design of the mechanism.) >=20 > > So if the SRC wants to discard (perhaps because a user has=20 > asked for discard), I had imagined the SRC could send the=20 > request to the SRS, and that would be that - no response to=20 > indicate whether discarding has been successful or not. If=20 > people are uncomfortable with this, I would tend to go in the=20 > direction of removing REQ-015/REQ-016 (address them in a=20 > later phase if necessary). >=20 > Sure, eliminating the request is one way to eliminate the need for a=20 > response. If that meets everyone's needs then I'm fine with that. >=20 > > Note that cancellation is a different matter, and I think=20 > it is covered by pause (REQ-011) or recording selected parts=20 > of a CS (REQ-004). So rather than get involved in some of=20 > these tricky questions in order to make REQ-015/REQ-016=20 > acceptable, it might be better just to delete REQ-015/REQ-016. > > > > 2. Concerning REQ-018, I think we need to avoid specifying=20 > any mechanisms within media, but I think an indication at=20 > signalling level would be appropriate. This would be targeted=20 > at siprec-compliant UAs on the CS and should cover whether=20 > the CS is being recorded or not being recorded. Although it=20 > might be tempting to get more sophisticated and indicate=20 > whether particular media are being recorded (e.g., audio is=20 > being recorded, video is not being recorded), I am a little=20 > wary of getting too complicated. In my opinion it might be=20 > sufficient to have a requirement something like: > > "REQ-018 The mechanism MUST provide a means of indicating=20 > to UAs involved in a CS that the session is being recorded." >=20 > I am ok with that wording. It is philosophically the same thing I was=20 > going for. >=20 > > 3. Concerning REQ-017, I think we can remove the words=20 > "prior to the start of recording". >=20 > I didn't know if that text was there for a reason or not.=20 > Clearly it is=20 > problematic is some situations. I'd be happy to see it removed. >=20 > > We can also perhaps change "an authorized participant" to=20 > "a participant" - any participant can request, although it=20 > will only be acted upon if authorized. >=20 > Sure. I was just preserving the existing wording, and am not=20 > attached to=20 > it. I agree with your logic. >=20 > > Perhaps we should go further, and talk about "a User Agent"=20 > rather than "a participant" - a user's ability to do this=20 > will depend on support from its UA. We don't want to get into=20 > mechanisms such as DTMF for covering PSTN participants, for example. >=20 > Yes, I agree with all that too. >=20 > > So we would end up with: > > "REQ-017 The mechanism MUST support a means for a UA=20 > involved in a CS to request that the CS not be recorded." >=20 > While I agree with all your logic, these words beg the=20 > question of what=20 > such a request means if the CS is already being recorded. Perhaps: >=20 > "REQ-017 The mechanism MUST support a means for a UA involved=20 > in a CS to=20 > request that the CS henceforth not be recorded." >=20 > Thanks, > Paul >=20 > > John (as individual) > > > > > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 04 February 2011 16:40 > >> To: Elwell, John > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > >> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >> cancellation > >> > >> > >> > >> On 2/4/2011 2:22 AM, Elwell, John wrote: > >>> 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? > >> > >> I'll try. > >> Here is the existing related bunch of requirements, and my=20 > 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=20 > 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=20 > 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=20 > 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=20 > are (as I > >> understand this) about communication between a CS participant > >> and the SRC: > >> > >> 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 > >> > >> 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=20 > 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=20 > authorized > >> participant involved in a CS to request that any=20 > existing RS for > >> this CS be terminated, and that all recorded media=20 > and associated > >> metadata for the CS be discarded. > >> > >> * REQ-017c: The mechanism MUST support a means for an=20 > authorized > >> participant involved in a CS to request that further=20 > recording of > >> media and associated metadata for this CS be terminated. > >> > >> * REQ-017d: The mechanism MUST support a means for an=20 > authorized > >> participant involved in a CS to request that further=20 > 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=20 > indicating to the > >> participants involved in a CS that their session is being > >> recorded. > >> > >> Examples include: inject tones into the CS from the=20 > 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=20 > signaling, > >> and conversely an inability to nail down how this might be=20 > 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=20 > 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=20 > 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=20 > indicating to a > >> participant in a CS if recording of media is=20 > currently enabled, > >> if recording of metadata is currently enabled, if any=20 > media has > >> been recorded for this CS, if any metadata has been=20 > recorded for > >> this CS. > >> > >> (Its expected that this be a signaling mechanism, not a media > >> mechanism. Hence it will only reach to signaling=20 > 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 eckelcu@cisco.com Mon Feb 7 15:49:48 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A2E3A6FDB for ; Mon, 7 Feb 2011 15:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNwFaxdIecaC for ; Mon, 7 Feb 2011 15:49:47 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5C5B03A6FD9 for ; Mon, 7 Feb 2011 15:49:47 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0BALsTUE2rR7H+/2dsb2JhbACWS45bc54+mxWCfYJdBIR6iiE Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Feb 2011 23:49:52 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p17NnqiY028438 for ; Mon, 7 Feb 2011 23:49:52 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 15:49:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2011 15:49:51 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: [dispatch] SIP based Media overload control draft Thread-Index: Acu7+lyOL6q/0agWRuinGl+8LnohWAAACHagABtidVAAA6oooAAFAN1AAYvtnVAAJfL8YADzhJqQ References: From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , X-OriginalArrivalTime: 07 Feb 2011 23:49:52.0525 (UTC) FILETIME=[B6D1EBD0:01CBC721] Subject: Re: [siprec] FW: [dispatch] SIP based Media overload control draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:49:48 -0000 Hi Partha, Thanks for putting this draft together. I gave it a read and I can appreciate the point you are making regarding servers that handle SIP signaling and media (media servers) potentially having unique overload requirements to those that handle signaling only. You mention two initial concerns, 488 and 503. For 488, it seems worthwhile in general to try another media server. Is the point you are making that for 488 for a session requesting 10 Mbps of bandwidth may need to be treated differently than a 488 for a session requesting 100 kbps of bandwidth? I think signaling servers might well make similar decisions based on analysis of the SDP signaling. For 503, it seems to be handled by RFC 5390. Is there something specific about media servers that you think needs to be addressed? Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: Wednesday, February 02, 2011 9:24 PM > To: siprec@ietf.org > Subject: [siprec] FW: [dispatch] SIP based Media overload control draft >=20 > Hi all, >=20 > draft-partha-dispatch-sip-media-overload-control-00 > (http://tools.ietf.org/search/draft-partha-dispatch-sip-media-overload-c > ontrol-00) is created to define the problem statement for SIP based > Media overload control. SRS in SIPREC is a media server with disk > storage. I have included the usecase in the draft. I'm interested in > hearing from you in case you have more specific requirement to be solved > in this area. >=20 > IMO, there is a need for generic SIP based media overload control. > Please provide your valuable comments. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Parthasarathi R (partr) > Sent: Wednesday, February 02, 2011 3:01 PM > To: DRAGE, Keith (Keith); Elwell, John; dispatch@ietf.org; > dworley@avaya.com > Subject: Re: [dispatch] SIP based Media overload control draft >=20 > Keith/John/Dale, >=20 > Mediactrl (MRB) discusses about Resource monitoring at media server and > currently, there is no mechanism exists for overload control. I attached > SoC WG stance on SIP based Media overload control as a note of this > mail. >=20 > As a follow up query, Please let me know your take on whether SIP based > media overload has to be solved as part of >=20 > 1) Mediactrl WG > 2) Any other WG exists. If so, Please name it. > 3) New WG has to be created. > 4) solve as individual draft. > 5) or any other IETF way >=20 > Thanks in advance > Partha >=20 > Note: Sec 1 of draft-ietf-soc-overload-design-04 >=20 > There are cases in which a SIP server runs other services that do not > involve the processing of SIP messages (e.g., processing of RTP > packets, database queries, software updates and event handling). > These services may, or may not, be correlated with the SIP message > volume. These services can use up a substantial share of resources > available on the server (e.g., CPU cycles) and leave the server in a > condition where it is unable to process all incoming SIP requests. >=20 > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Tuesday, January 25, 2011 6:23 PM > To: 'DRAGE, Keith (Keith)'; Elwell, John; dispatch@ietf.org > Cc: 'dworley@avaya.com' > Subject: RE: SIP based Media overload control draft >=20 >=20 > Keith, >=20 > AFAIK, the mentioned issue is not solved in MRB. Including Dale Worley > (Mediactrl WG Chair) in this mail thread to double confirm my > understanding. >=20 > Apart from the Mediactrl Mediaservers, I'm trying to find the solution > for devices which acts as both Application server(AS) and Media Server > (MS) at the same time. In the deployment, these devices shall be > realized as PSTN GW, SBC, IP PBX with media handling. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Tuesday, January 25, 2011 3:31 PM > To: Elwell, John; Parthasarathi R (partr); dispatch@ietf.org > Subject: RE: SIP based Media overload control draft >=20 > If they are mediaservers, then does not the media resource broker in > mediactrl already address this issue. >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: 25 January 2011 08:28 > To: Parthasarathi R (partr); dispatch@ietf.org > Subject: Re: [dispatch] SIP based Media overload control draft >=20 > Partha, >=20 > A fundamental difference between the problem addressed by SOC and the > problem stated in your draft is as follows. SOC addresses the problem > where a SIP server is so overloaded that receipt of further SIP requests > will compound the problem, and therefore it is essential to take steps > to reduce the number of SIP requests arriving at the overloaded server. > The problem described in your draft is where the server is not > overloaded in the sense of being unable to handle further SIP requests, > but is overloaded in terms of media it can handle. Therefore it can > still receive SIP requests, but it would have to reject some of them if > the necessary media resources are not available. >=20 > There may still be some benefit in preventing SIP requests arriving if > media resources are not available. The main benefit would be that those > SIP requests can more quickly be rerouted elsewhere, thereby reducing > call set-up time. One scenario that might benefit would be where there > are several, perhaps 10 or more, candidate media servers for a > particular request, and trying each of these in turn would definitely > impact call establishment times (or call rejection times on occasions > when all candidates are overloaded). Is this the essence of the problem > you are trying to address? It seems the document could certainly do with > more on use cases and potential benefits that a solution might bring. >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R > > (partr) > > Sent: 24 January 2011 19:38 > > To: dispatch@ietf.org > > Subject: [dispatch] SIP based Media overload control draft > > > > Hi all, > > > > IETF SoC WG is created for overload control solution of dedicated SIP > > signaling server only. There is an another kind of SIP servers exists > > in SIP deployment which handle SIP signaling and its related media > > (RTP, > > T.38) in the same physical device. Those servers needs separate SIP > > based overload control solution. SIP based Media overload control > > draft summarizes problem specific to SIP media servers overload, > > requirements for SIP based media overload control solution and the > > draft is available at > > > > http://datatracker.ietf.org/doc/draft-partha-dispatch-sip-medi > > a-overload > > -control/ > > > > draft-partha-dispatch-resource-availability-00 and > > draft-jones-sip-overload-sce-00 are submitted in IETF-78 SoC WG for > > addressing the same problem. But, SIP based media overload control is > > considered as outside the scope of SoC WG. I'm interested in hearing > > from you whether this is a worth solving problem in IETF. > > > > This draft is in straw-horse proposal state. I post this draft in > > dispatch to identify which WG is right place to solve this issue in > > IETF in case it is considered as worth solving problem. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Tuesday, January 25, 2011 12:37 AM > > To: Parthasarathi R (partr) > > Subject: New Version Notification for > > draft-partha-dispatch-sip-media-overload-control-00 > > > > > > A new version of I-D, > > draft-partha-dispatch-sip-media-overload-control-00.txt has been > > successfully submitted by Parthasarathi R and posted to the IETF > > repository. > > > > Filename: draft-partha-dispatch-sip-media-overload-control > > Revision: 00 > > Title: Session Initiation Protocol (SIP) > > based Media overload > > control Requirement > > Creation_date: 2011-01-24 > > WG ID: Independent Submission > > Number_of_pages: 6 > > > > Abstract: > > Overload occurs in Session Initiation Protocol (SIP) networks when SIP >=20 > > servers have insufficient resources to handle all SIP messages they > > receive. SIP based overload mechanism exists for dedicated SIP > > signaling servers. But there is a need for overload control solution > > of SIP based media servers like PSTN GW, Session border controllers > > (SBC), Session Recording Server(SRS). This document summarizes > > problem specific to SIP media servers, requirements for the solution > > of SIP based media overload control. > > > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Dave.d.Smith@alcatel-lucent.com Mon Feb 7 16:39:06 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885703A6F06 for ; Mon, 7 Feb 2011 16:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUz9V3LB4iKH for ; Mon, 7 Feb 2011 16:39:05 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id DCE273A6EAC for ; Mon, 7 Feb 2011 16:39:04 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p180ck6a019301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 18:38:46 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p180cjBJ012827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Feb 2011 18:38:46 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p180bkiN007531; Mon, 7 Feb 2011 16:38:42 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 16:37:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2011 16:37:47 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvG0q8pP2EaoF4PRTycz4xIXosErAAAYQQQAAugQkA= References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <4D500086.3010506@cisco.com> From: "Dave Smith" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 08 Feb 2011 00:37:49.0844 (UTC) FILETIME=[69D5F540:01CBC728] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:39:06 -0000 I agree with the proposed changes/recommendations to REQ-015, 16, and 18. =20 Regarding REQ-017: =20 "REQ-017 The mechanism MUST support a means for a UA involved in a CS to request that the CS henceforth not be recorded." "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. =20 Regards, Dave -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, February 07, 2011 6:36 AM To: Paul Kyzivat Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; 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) =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 07 February 2011 14:24 > To: Elwell, John > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning=20 > cancellation >=20 >=20 >=20 > On 2/7/2011 7:17 AM, Elwell, John wrote: > > Paul, > > > > Thanks for putting this into words. It seems the scope of=20 > possible requirements here is quite broad, and I am not sure=20 > we need all this. Basically my comments are as follows: >=20 > John, >=20 > As I already replied to Leon, I don't have much of an opinion=20 > of whether=20 > these things should be requirements or not - just that if they are=20 > requirements then they need to be clear and logical. >=20 > > 1. Concerning discarding a recording, we have agreed in the=20 > past that SRS is in charge of policy concerning retention of=20 > recordings, and hence will have the final say in whether a=20 > request to discard is honoured. I am not sure whether there=20 > needs to be any obligation for the SRS to make this policy=20 > available to the SRS, and hence I am not sure whether we need=20 > a requirement to report back to the SRC the outcome of a=20 > discard request. As Leon has pointed out, the outcome might=20 > not be known immediately. Also, how trustworthy is it? >=20 > Well, whether the SRS needs to allow the SRC an *input* to the policy=20= > decision is what this is all about. >=20 > While I agree that providing an ack/nack to such an input is an=20 > independent decision, its my feeling that there is little point in=20 > allowing the input without some feedback. >=20 > (From a practical perspective, eliminating the feedback makes life=20 > simpler for the design of the mechanism.) >=20 > > So if the SRC wants to discard (perhaps because a user has=20 > asked for discard), I had imagined the SRC could send the=20 > request to the SRS, and that would be that - no response to=20 > indicate whether discarding has been successful or not. If=20 > people are uncomfortable with this, I would tend to go in the=20 > direction of removing REQ-015/REQ-016 (address them in a=20 > later phase if necessary). >=20 > Sure, eliminating the request is one way to eliminate the need for a=20= > response. If that meets everyone's needs then I'm fine with that. >=20 > > Note that cancellation is a different matter, and I think=20 > it is covered by pause (REQ-011) or recording selected parts=20 > of a CS (REQ-004). So rather than get involved in some of=20 > these tricky questions in order to make REQ-015/REQ-016=20 > acceptable, it might be better just to delete REQ-015/REQ-016. > > > > 2. Concerning REQ-018, I think we need to avoid specifying=20 > any mechanisms within media, but I think an indication at=20 > signalling level would be appropriate. This would be targeted=20 > at siprec-compliant UAs on the CS and should cover whether=20 > the CS is being recorded or not being recorded. Although it=20 > might be tempting to get more sophisticated and indicate=20 > whether particular media are being recorded (e.g., audio is=20 > being recorded, video is not being recorded), I am a little=20 > wary of getting too complicated. In my opinion it might be=20 > sufficient to have a requirement something like: > > "REQ-018 The mechanism MUST provide a means of indicating=20 > to UAs involved in a CS that the session is being recorded." >=20 > I am ok with that wording. It is philosophically the same thing I was=20= > going for. >=20 > > 3. Concerning REQ-017, I think we can remove the words=20 > "prior to the start of recording". >=20 > I didn't know if that text was there for a reason or not.=20 > Clearly it is=20 > problematic is some situations. I'd be happy to see it removed. >=20 > > We can also perhaps change "an authorized participant" to=20 > "a participant" - any participant can request, although it=20 > will only be acted upon if authorized. >=20 > Sure. I was just preserving the existing wording, and am not=20 > attached to=20 > it. I agree with your logic. >=20 > > Perhaps we should go further, and talk about "a User Agent"=20 > rather than "a participant" - a user's ability to do this=20 > will depend on support from its UA. We don't want to get into=20 > mechanisms such as DTMF for covering PSTN participants, for example. >=20 > Yes, I agree with all that too. >=20 > > So we would end up with: > > "REQ-017 The mechanism MUST support a means for a UA=20 > involved in a CS to request that the CS not be recorded." >=20 > While I agree with all your logic, these words beg the=20 > question of what=20 > such a request means if the CS is already being recorded. Perhaps: >=20 > "REQ-017 The mechanism MUST support a means for a UA involved=20 > in a CS to=20 > request that the CS henceforth not be recorded." >=20 > Thanks, > Paul >=20 > > John (as individual) > > > > > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 04 February 2011 16:40 > >> To: Elwell, John > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > >> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >> cancellation > >> > >> > >> > >> On 2/4/2011 2:22 AM, Elwell, John wrote: > >>> 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? > >> > >> I'll try. > >> Here is the existing related bunch of requirements, and my=20 > 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=20 > 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=20 > 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=20 > 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=20 > are (as I > >> understand this) about communication between a CS participant > >> and the SRC: > >> > >> 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 > >> > >> 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=20 > 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=20 > authorized > >> participant involved in a CS to request that any=20 > existing RS for > >> this CS be terminated, and that all recorded media=20 > and associated > >> metadata for the CS be discarded. > >> > >> * REQ-017c: The mechanism MUST support a means for an=20 > authorized > >> participant involved in a CS to request that further=20 > recording of > >> media and associated metadata for this CS be terminated. > >> > >> * REQ-017d: The mechanism MUST support a means for an=20 > authorized > >> participant involved in a CS to request that further=20 > 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=20 > indicating to the > >> participants involved in a CS that their session is being > >> recorded. > >> > >> Examples include: inject tones into the CS from the=20 > 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=20 > signaling, > >> and conversely an inability to nail down how this might be=20 > 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=20 > 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=20 > 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=20 > indicating to a > >> participant in a CS if recording of media is=20 > currently enabled, > >> if recording of metadata is currently enabled, if any=20 > media has > >> been recorded for this CS, if any metadata has been=20 > recorded for > >> this CS. > >> > >> (Its expected that this be a signaling mechanism, not a media > >> mechanism. Hence it will only reach to signaling=20 > 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 > >> >=20 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Mon Feb 7 23:30:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35813A67B6 for ; Mon, 7 Feb 2011 23:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhvsTPfxQZIO for ; Mon, 7 Feb 2011 23:30:40 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 59A903A6AE3 for ; Mon, 7 Feb 2011 23:30:40 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3306543; Tue, 8 Feb 2011 08:30:41 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 82B3723F0278; Tue, 8 Feb 2011 08:30:41 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 8 Feb 2011 08:30:41 +0100 From: "Elwell, John" To: Dave Smith , Paul Kyzivat Date: Tue, 8 Feb 2011 08:30:39 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvG0q8pP2EaoF4PRTycz4xIXosErAAAYQQQAAugQkAAFyyQ0A== Message-ID: References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <4D500086.3010506@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:30:42 -0000 I think being able to request prior to the start of a recording is insuffic= ient - once you have missed that window of opportunity (i.e. prior to estab= lishing 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 w= ords: - 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 pau= se. With pause, you could later resume that same recording. With stop, you = would effectively terminate the recording, such that you would need to star= t a new recording if you need to record later during the CS. The handling o= f metadata would differ - in the first case the metadata might tell you whe= n 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) > -----Original Message----- > From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > Sent: 08 February 2011 00:38 > To: Elwell, John; Paul Kyzivat > Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > Subject: RE: [siprec] Proposed change to REQ-017 concerning > cancellation > > I agree with the proposed changes/recommendations to REQ-015, 16, and > 18. > > Regarding REQ-017: > "REQ-017 The mechanism MUST support a means for a UA involved > in a CS to > request that the CS henceforth not be recorded." > > "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:john.elwell@siemens-enterprise.com] > Sent: Monday, February 07, 2011 6:36 AM > To: Paul Kyzivat > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; 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) > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 07 February 2011 14:24 > > To: Elwell, John > > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > > Subject: Re: [siprec] Proposed change to REQ-017 concerning > > cancellation > > > > > > > > On 2/7/2011 7:17 AM, Elwell, John wrote: > > > 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: > > > > 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 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? > > > > 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 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). > > > > 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. > > > > > 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." > > > > 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: > > > "REQ-017 The mechanism MUST support a means for a UA > > involved in a CS to request that the CS not be recorded." > > > > 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) > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: 04 February 2011 16:40 > > >> To: Elwell, John > > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > Alissa Cooper > > >> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > >> cancellation > > >> > > >> > > >> > > >> On 2/4/2011 2:22 AM, Elwell, John wrote: > > >>> 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? > > >> > > >> 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: > > >> > > >> 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 > > >> > > >> 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 > > >> > > > > > -------------------------------------------------------------- > ----------------------------------------------------- > 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 pkyzivat@cisco.com Tue Feb 8 05:40:32 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B163A7140 for ; Tue, 8 Feb 2011 05:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGwut8Tx2nuw for ; Tue, 8 Feb 2011 05:40:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 008D43A714A for ; Tue, 8 Feb 2011 05:40:29 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 13:40:33 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18DeX2I005915; Tue, 8 Feb 2011 13:40:33 GMT Message-ID: <4D5147D1.1010807@cisco.com> Date: Tue, 08 Feb 2011 08:40:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <4D500086.3010506@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:40:32 -0000 On 2/8/2011 2:30 AM, Elwell, John wrote: > 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. 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 > 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) > > >> -----Original Message----- >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >> Sent: 08 February 2011 00:38 >> To: Elwell, John; Paul Kyzivat >> Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper >> Subject: RE: [siprec] Proposed change to REQ-017 concerning >> cancellation >> >> I agree with the proposed changes/recommendations to REQ-015, 16, and >> 18. >> >> Regarding REQ-017: >> "REQ-017 The mechanism MUST support a means for a UA involved >> in a CS to >> request that the CS henceforth not be recorded." >> >> "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:john.elwell@siemens-enterprise.com] >> Sent: Monday, February 07, 2011 6:36 AM >> To: Paul Kyzivat >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; 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) >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 07 February 2011 14:24 >>> To: Elwell, John >>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning >>> cancellation >>> >>> >>> >>> On 2/7/2011 7:17 AM, Elwell, John wrote: >>>> 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: >>> >>> 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 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? >>> >>> 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 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). >>> >>> 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. >>> >>>> 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." >>> >>> 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: >>>> "REQ-017 The mechanism MUST support a means for a UA >>> involved in a CS to request that the CS not be recorded." >>> >>> 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) >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 04 February 2011 16:40 >>>>> To: Elwell, John >>>>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; >> Alissa Cooper >>>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning >>>>> cancellation >>>>> >>>>> >>>>> >>>>> On 2/4/2011 2:22 AM, Elwell, John wrote: >>>>>> 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? >>>>> >>>>> 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: >>>>> >>>>> 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 >>>>> >>>>> 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 >>>>> >>> >> >> >> -------------------------------------------------------------- >> ----------------------------------------------------- >> 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 partr@cisco.com Tue Feb 8 21:17:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D843A68F5 for ; Tue, 8 Feb 2011 21:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAe1-KjObTkT for ; Tue, 8 Feb 2011 21:17:36 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 33DA13A68ED for ; Tue, 8 Feb 2011 21:17:35 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwBACeyUU2Q/khNgWdsb2JhbACWaI5cFQEBFiIkoiKbKYJ9gl0EhHmKJg Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2011 05:17:43 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p195GnXN018514 for ; Wed, 9 Feb 2011 05:17:42 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 10:47:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 10:46:43 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: [dispatch] SIP based Media overload control draft Thread-Index: Acu7+lyOL6q/0agWRuinGl+8LnohWAAACHagABtidVAAA6oooAAFAN1AAYvtnVAAJfL8YADzhJqQADxgMCA= References: From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 09 Feb 2011 05:17:35.0683 (UTC) FILETIME=[A9637930:01CBC818] Subject: Re: [siprec] FW: [dispatch] SIP based Media overload control draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 05:17:37 -0000 Hi Charles, Thanks for looking into the draft.=20 As you mentioned, 488 response shall be used for redirection to alternate server but the open questions are 1) Whether forthcoming new request has to be sent to the first server or to the alternate server. A) In case of first server is selected for all the forthcoming request, downstream will reply with 488 response till overload is over. Forthcoming request will put load in the first server for creating negative response. In case of load balance scenario with 1:75(upstream:downstream) topology, 488 is not appropriate as it leads to multiple redirection (488) from upstream. The feedback from the downstream is more appropriate compare to 488 with warning-code 307. I'm making the point that 488 has to be considered as last resort and there is a need for feedback mechanism from downstream. B) In case alternate server is selected for all the forthcoming request, there is a need of feedback from first server to indicate that the overload is over and the server is ready for processing more request. Based your comments, I'll add more text in the draft for better clarity between 488 vs feedback. Please let me know in case you have other opinion here. 2) Limitation of 503 response in RFC 5390 are taken care by draft-ietf-soc-overload-design but SoC design is based on number of SIP message only. This is not well suited for all types of media servers. For example: Media servers share CPU/Memory for Media and SIP signaling, 503 response *MAY* be due to excess of media handling rather than signaling. 3) As you mentioned, Upstream server *SHALL* be signaling server or application server which takes informed decision based on the received SDP feedback (10 Mbps or 100 Kbps). Thanks Partha -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Tuesday, February 08, 2011 5:20 AM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] FW: [dispatch] SIP based Media overload control draft Hi Partha, Thanks for putting this draft together. I gave it a read and I can appreciate the point you are making regarding servers that handle SIP signaling and media (media servers) potentially having unique overload requirements to those that handle signaling only. You mention two initial concerns, 488 and 503. For 488, it seems worthwhile in general to try another media server. Is the point you are making that for 488 for a session requesting 10 Mbps of bandwidth may need to be treated differently than a 488 for a session requesting 100 kbps of bandwidth? I think signaling servers might well make similar decisions based on analysis of the SDP signaling. For 503, it seems to be handled by RFC 5390. Is there something specific about media servers that you think needs to be addressed? Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Parthasarathi R (partr) > Sent: Wednesday, February 02, 2011 9:24 PM > To: siprec@ietf.org > Subject: [siprec] FW: [dispatch] SIP based Media overload control=20 > draft >=20 > Hi all, >=20 > draft-partha-dispatch-sip-media-overload-control-00 > (http://tools.ietf.org/search/draft-partha-dispatch-sip-media-overload > -c > ontrol-00) is created to define the problem statement for SIP based=20 > Media overload control. SRS in SIPREC is a media server with disk=20 > storage. I have included the usecase in the draft. I'm interested in=20 > hearing from you in case you have more specific requirement to be=20 > solved in this area. >=20 > IMO, there is a need for generic SIP based media overload control. > Please provide your valuable comments. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Parthasarathi R (partr) > Sent: Wednesday, February 02, 2011 3:01 PM > To: DRAGE, Keith (Keith); Elwell, John; dispatch@ietf.org;=20 > dworley@avaya.com > Subject: Re: [dispatch] SIP based Media overload control draft >=20 > Keith/John/Dale, >=20 > Mediactrl (MRB) discusses about Resource monitoring at media server=20 > and currently, there is no mechanism exists for overload control. I=20 > attached SoC WG stance on SIP based Media overload control as a note=20 > of this mail. >=20 > As a follow up query, Please let me know your take on whether SIP=20 > based media overload has to be solved as part of >=20 > 1) Mediactrl WG > 2) Any other WG exists. If so, Please name it. > 3) New WG has to be created. > 4) solve as individual draft. > 5) or any other IETF way >=20 > Thanks in advance > Partha >=20 > Note: Sec 1 of draft-ietf-soc-overload-design-04 >=20 > There are cases in which a SIP server runs other services that do not > involve the processing of SIP messages (e.g., processing of RTP > packets, database queries, software updates and event handling). > These services may, or may not, be correlated with the SIP message > volume. These services can use up a substantial share of resources > available on the server (e.g., CPU cycles) and leave the server in a > condition where it is unable to process all incoming SIP requests. >=20 > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Tuesday, January 25, 2011 6:23 PM > To: 'DRAGE, Keith (Keith)'; Elwell, John; dispatch@ietf.org > Cc: 'dworley@avaya.com' > Subject: RE: SIP based Media overload control draft >=20 >=20 > Keith, >=20 > AFAIK, the mentioned issue is not solved in MRB. Including Dale Worley > (Mediactrl WG Chair) in this mail thread to double confirm my=20 > understanding. >=20 > Apart from the Mediactrl Mediaservers, I'm trying to find the solution > for devices which acts as both Application server(AS) and Media Server > (MS) at the same time. In the deployment, these devices shall be=20 > realized as PSTN GW, SBC, IP PBX with media handling. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Tuesday, January 25, 2011 3:31 PM > To: Elwell, John; Parthasarathi R (partr); dispatch@ietf.org > Subject: RE: SIP based Media overload control draft >=20 > If they are mediaservers, then does not the media resource broker in=20 > mediactrl already address this issue. >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: 25 January 2011 08:28 > To: Parthasarathi R (partr); dispatch@ietf.org > Subject: Re: [dispatch] SIP based Media overload control draft >=20 > Partha, >=20 > A fundamental difference between the problem addressed by SOC and the=20 > problem stated in your draft is as follows. SOC addresses the problem=20 > where a SIP server is so overloaded that receipt of further SIP=20 > requests will compound the problem, and therefore it is essential to=20 > take steps to reduce the number of SIP requests arriving at the overloaded server. > The problem described in your draft is where the server is not=20 > overloaded in the sense of being unable to handle further SIP=20 > requests, but is overloaded in terms of media it can handle. Therefore > it can still receive SIP requests, but it would have to reject some of > them if the necessary media resources are not available. >=20 > There may still be some benefit in preventing SIP requests arriving if > media resources are not available. The main benefit would be that=20 > those SIP requests can more quickly be rerouted elsewhere, thereby=20 > reducing call set-up time. One scenario that might benefit would be=20 > where there are several, perhaps 10 or more, candidate media servers=20 > for a particular request, and trying each of these in turn would=20 > definitely impact call establishment times (or call rejection times on > occasions when all candidates are overloaded). Is this the essence of=20 > the problem you are trying to address? It seems the document could=20 > certainly do with more on use cases and potential benefits that a solution might bring. >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R > > (partr) > > Sent: 24 January 2011 19:38 > > To: dispatch@ietf.org > > Subject: [dispatch] SIP based Media overload control draft > > > > Hi all, > > > > IETF SoC WG is created for overload control solution of dedicated=20 > > SIP signaling server only. There is an another kind of SIP servers=20 > > exists in SIP deployment which handle SIP signaling and its related=20 > > media (RTP, > > T.38) in the same physical device. Those servers needs separate SIP=20 > > based overload control solution. SIP based Media overload control=20 > > draft summarizes problem specific to SIP media servers overload,=20 > > requirements for SIP based media overload control solution and the=20 > > draft is available at > > > > http://datatracker.ietf.org/doc/draft-partha-dispatch-sip-medi > > a-overload > > -control/ > > > > draft-partha-dispatch-resource-availability-00 and=20 > > draft-jones-sip-overload-sce-00 are submitted in IETF-78 SoC WG for=20 > > addressing the same problem. But, SIP based media overload control=20 > > is considered as outside the scope of SoC WG. I'm interested in=20 > > hearing from you whether this is a worth solving problem in IETF. > > > > This draft is in straw-horse proposal state. I post this draft in=20 > > dispatch to identify which WG is right place to solve this issue in=20 > > IETF in case it is considered as worth solving problem. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Tuesday, January 25, 2011 12:37 AM > > To: Parthasarathi R (partr) > > Subject: New Version Notification for=20 > > draft-partha-dispatch-sip-media-overload-control-00 > > > > > > A new version of I-D, > > draft-partha-dispatch-sip-media-overload-control-00.txt has been=20 > > successfully submitted by Parthasarathi R and posted to the IETF=20 > > repository. > > > > Filename: draft-partha-dispatch-sip-media-overload-control > > Revision: 00 > > Title: Session Initiation Protocol (SIP) > > based Media overload > > control Requirement > > Creation_date: 2011-01-24 > > WG ID: Independent Submission > > Number_of_pages: 6 > > > > Abstract: > > Overload occurs in Session Initiation Protocol (SIP) networks when=20 > > SIP >=20 > > servers have insufficient resources to handle all SIP messages they=20 > > receive. SIP based overload mechanism exists for dedicated SIP=20 > > signaling servers. But there is a need for overload control=20 > > solution of SIP based media servers like PSTN GW, Session border=20 > > controllers (SBC), Session Recording Server(SRS). This document=20 > > summarizes problem specific to SIP media servers, requirements for=20 > > the solution of SIP based media overload control. > > > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Feb 9 01:07:41 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A793A6959 for ; Wed, 9 Feb 2011 01:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpkKcJIGS-XG for ; Wed, 9 Feb 2011 01:07:39 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DC4A53A6942 for ; Wed, 9 Feb 2011 01:07:38 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3329599; Wed, 9 Feb 2011 10:07:45 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 35F251EB82AE; Wed, 9 Feb 2011 10:07:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 9 Feb 2011 10:07:45 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Wed, 9 Feb 2011 10:07:43 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvHlcXlMWPhfccVR76FrXcITnkOYgAoi4MA Message-ID: References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <4D500086.3010506@cisco.com> <4D5147D1.1010807@cisco.com> In-Reply-To: <4D5147D1.1010807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:07:41 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 08 February 2011 13:41 > To: Elwell, John > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > > > On 2/8/2011 2:30 AM, Elwell, John wrote: > > 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. > > 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. [JRE] Perhaps this suggests that, as part of the solution, we would want so= mething to signal the presence of an SRC on the path. I don't think this pr= events us stating a requirement. > > 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. [JRE] From a solution point of view, we could consider a separate I-D for s= ignalling 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 req= uirements 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) > > > > > >> -----Original Message----- > >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > >> Sent: 08 February 2011 00:38 > >> To: Elwell, John; Paul Kyzivat > >> Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > >> Subject: RE: [siprec] Proposed change to REQ-017 concerning > >> cancellation > >> > >> I agree with the proposed changes/recommendations to > REQ-015, 16, and > >> 18. > >> > >> Regarding REQ-017: > >> "REQ-017 The mechanism MUST support a means for a UA involved > >> in a CS to > >> request that the CS henceforth not be recorded." > >> > >> "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:john.elwell@siemens-enterprise.com] > >> Sent: Monday, February 07, 2011 6:36 AM > >> To: Paul Kyzivat > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; 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) > >> > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 07 February 2011 14:24 > >>> To: Elwell, John > >>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >>> cancellation > >>> > >>> > >>> > >>> On 2/7/2011 7:17 AM, Elwell, John wrote: > >>>> 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: > >>> > >>> 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 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? > >>> > >>> 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 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). > >>> > >>> 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. > >>> > >>>> 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." > >>> > >>> 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: > >>>> "REQ-017 The mechanism MUST support a means for a UA > >>> involved in a CS to request that the CS not be recorded." > >>> > >>> 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) > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> Sent: 04 February 2011 16:40 > >>>>> To: Elwell, John > >>>>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > >> Alissa Cooper > >>>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >>>>> cancellation > >>>>> > >>>>> > >>>>> > >>>>> On 2/4/2011 2:22 AM, Elwell, John wrote: > >>>>>> 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? > >>>>> > >>>>> 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: > >>>>> > >>>>> 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 > >>>>> > >>>>> 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 > >>>>> > >>> > >> > >> > >> -------------------------------------------------------------- > >> ----------------------------------------------------- > >> 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 john.elwell@siemens-enterprise.com Fri Feb 11 06:28:30 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F3A3A685A for ; Fri, 11 Feb 2011 06:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu1Aa9fUBQJa for ; Fri, 11 Feb 2011 06:28:29 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D54823A6999 for ; Fri, 11 Feb 2011 06:28:28 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3367872; Fri, 11 Feb 2011 15:28:41 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 591681EB82B0; Fri, 11 Feb 2011 15:28:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 11 Feb 2011 15:28:40 +0100 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Fri, 11 Feb 2011 15:28:39 +0100 Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu+VBWN/0UhnZhoTuyG1XfePuGXDwLo0uGQ Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> <4D41C01C.4050205@cisco.com> Keywords: SIPREC In-Reply-To: <4D41C01C.4050205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 14:28:30 -0000 I realise I was directly addressed earlier in this thread and I didn't repl= y (it was left sitting in my inbox). I don't have anything further to add - I see both sides of the argument. Pa= ul/Ram are looking for sufficient expressiveness to cover a wide range of s= ituations, even though in many cases information available will be limited.= Charles is concerned, I think, with it being misleading in some cases wher= e limited information is available. So perhaps we need other opinions in or= der to close on this one. John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 27 January 2011 18:58 > To: siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is=20 > not part of CS >=20 > Charles, >=20 > I don't think we will be able (or should try) to design this so that=20 > everything the SRC specifies is guaranteed to be as complete=20 > as you wish=20 > it to be. At the end of the day, the SRC will have to do what it can,=20 > and some will be better at it than others. If the SRC you have chosen=20 > isn't supplying the information it could have and wish it=20 > had, then you=20 > can complain and request upgrades, or you can choose a=20 > different product. >=20 > As long as we have sufficient expressiveness to describe=20 > things as you=20 > wish for any given case then I think we are good. Lets ensure=20 > we can at=20 > least do that. >=20 > BTW, this is exactly the sort of discussion I have been=20 > hoping we would=20 > have over the model. I expected it would happen quite some=20 > time ago. But=20 > better now than never. >=20 > Thanks, > Paul >=20 > On 1/27/2011 1:07 PM, Charles Eckel (eckelcu) wrote: > > Hi Ram, > > > > If all CS participants are required to support the conference event > > package and provide sufficient info about each non-CS participant in > > order to be allowed to bring them in, then I am ok with it.=20 > My concern > > is that the SRS will not be able to get sufficient info about non-CS > > participant in all cases. In such cases, it seems to me the media > > streams should be associated with the CS participant=20 > responsible for the > > non-CS participant, rather than allowing media from incompletely > > described non-CS participants to exist on its own. > > You mention the case of the conference focus, in which=20 > everything may be > > fine, but there are other cases, as mentioned by Jon, for=20 > which this may > > not be the case. > > > > Cheers, > > Charles > > > > > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) > >> Sent: Thursday, January 27, 2011 4:35 AM > >> To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org > >> Subject: RE: [siprec] metadata model for participant that=20 > is not part > > of CS > >> > >> Hi Charles/John, > >> > >> In the current model, a media stream is always associated with at > > least one participant. Here is the > >> snippet of the associations between CS and Participant and=20 > Participant > > and Media Streams taken from > >> the draft > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > >> > >> Section 4.3.2 has the associations between CS and Participant > >> Section 4.4.2 has the associations between media stream and > > participant > >> > >> The current model allows participants who are not part of CS to be > > part of the model. > >> A example of such a case is: > >> - participants in a premixed media stream. The SRC may=20 > have knowledge > > of such Participants, yet not > >> have any signaling relationship with them. This might arise if one > > participant in CS is a conf focus. > >> > >> In those case, if the metadata for non-CS participants is=20 > incomplete, > > the SRC can use other mechanisms > >> like subscribing to conference event package to retrieve the > > information about non-CS participants. > >> > >> To summarize the model allows representing of non-CS=20 > participants who > > contribute media to CS. > >> > >> Charles, > >> The use case section is at the end of this document > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > >> > >> Please note the case where Focus is acting as SRC is simpler as all > > participants of conference which > >> are connected to focus will in turn become participants of CS too. > >> > >> Thanks, > >> Ram > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Elwell, John > >>> Sent: Thursday, January 27, 2011 1:09 PM > >>> To: Charles Eckel (eckelcu); siprec@ietf.org > >>> Subject: Re: [siprec] metadata model for participant that is not > > part > >>> of CS > >>> > >>> I am starting to see Charles's point. For a participant behind a > >>> bridge, you don't really know what media he is=20 > contributing or what > >>> media he is receiving. All you know for certain is that the bridge > > is a > >>> participant. Perhaps we could assign multiple user identities to a > >>> bridge participant, thereby reflecting users behind the=20 > bridge that > > may > >>> or may not be contributing to the media the bridge sends=20 > and may or > > may > >>> not be recipients of media the bridge receives. > >>> > >>> Note that the model when the SRC is at the bridge, rather than > > outside > >>> the bridge, is quite different. Also the model where the bridge is > >>> switching, rather than mixing, might be different. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > (eckelcu) > >>>> Sent: 26 January 2011 18:56 > >>>> To: siprec@ietf.org > >>>> Subject: [siprec] metadata model for participant that is not > >>>> part of CS > >>>> > >>>> This is to follow up on some questions I raised regarding the > >>> metadata > >>>> model during the interim meeting Tuesday. > >>>> My initial concern was that I thought we were allowing media > >>>> streams to > >>>> be defined without any participant. I now understand that is not > > the > >>>> case; rather, a media stream is always associated with at least > > one > >>>> participant, but that participant need not necessary be > >>>> associated with > >>>> the CS. > >>>> Now I have some concern about participants that are not part > >>>> of the CS. > >>>> My concern is that the level of metadata we have for such > >>> participants > >>>> will be inconsistent at best. If the metadata for a non-CS > >>> participant > >>>> is incomplete, what do we plan to do? > >>>> Also, I believe there was reference to a document that contains > > the > >>>> model and some use cases. Which document is that? > >>>> > >>>> Thanks, > >>>> Charles > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From Leon.Portman@nice.com Sun Feb 13 14:39:25 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BA33A6C35 for ; Sun, 13 Feb 2011 14:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-AuM0wPaeCa for ; Sun, 13 Feb 2011 14:39:24 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id CA5603A6A53 for ; Sun, 13 Feb 2011 14:39:23 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 14 Feb 2011 00:39:43 +0200 From: Leon Portman To: "Elwell, John" , Paul Kyzivat , "siprec@ietf.org" Date: Mon, 14 Feb 2011 00:39:43 +0200 Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu+VBWN/0UhnZhoTuyG1XfePuGXDwLo0uGQAG7QqQA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38A68075BE@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> <4D41C01C.4050205@cisco.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 22:39:25 -0000 Hello, I agree with Paul statement that SRC should provide best effort to report c= omplete metadata as possible. And we should model it as complete as possibl= e as well.=20 In cases where information is not complete or cannot be guaranteed to be co= rrect, we should allow SRC to indicate it: maybe we should add a parameter= called: "Metadata Certainty"? Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Friday, February 11, 2011 4:29 PM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] metadata model for participant that is not part of CS I realise I was directly addressed earlier in this thread and I didn't repl= y (it was left sitting in my inbox). I don't have anything further to add - I see both sides of the argument. Pa= ul/Ram are looking for sufficient expressiveness to cover a wide range of s= ituations, even though in many cases information available will be limited.= Charles is concerned, I think, with it being misleading in some cases wher= e limited information is available. So perhaps we need other opinions in or= der to close on this one. John > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 27 January 2011 18:58 > To: siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is not part=20 > of CS >=20 > Charles, >=20 > I don't think we will be able (or should try) to design this so that=20 > everything the SRC specifies is guaranteed to be as complete as you=20 > wish it to be. At the end of the day, the SRC will have to do what it=20 > can, and some will be better at it than others. If the SRC you have=20 > chosen isn't supplying the information it could have and wish it had,=20 > then you can complain and request upgrades, or you can choose a=20 > different product. >=20 > As long as we have sufficient expressiveness to describe things as you=20 > wish for any given case then I think we are good. Lets ensure we can=20 > at least do that. >=20 > BTW, this is exactly the sort of discussion I have been hoping we=20 > would have over the model. I expected it would happen quite some time=20 > ago. But better now than never. >=20 > Thanks, > Paul >=20 > On 1/27/2011 1:07 PM, Charles Eckel (eckelcu) wrote: > > Hi Ram, > > > > If all CS participants are required to support the conference event=20 > > package and provide sufficient info about each non-CS participant in=20 > > order to be allowed to bring them in, then I am ok with it. > My concern > > is that the SRS will not be able to get sufficient info about non-CS=20 > > participant in all cases. In such cases, it seems to me the media=20 > > streams should be associated with the CS participant > responsible for the > > non-CS participant, rather than allowing media from incompletely=20 > > described non-CS participants to exist on its own. > > You mention the case of the conference focus, in which > everything may be > > fine, but there are other cases, as mentioned by Jon, for > which this may > > not be the case. > > > > Cheers, > > Charles > > > > > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) > >> Sent: Thursday, January 27, 2011 4:35 AM > >> To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org > >> Subject: RE: [siprec] metadata model for participant that > is not part > > of CS > >> > >> Hi Charles/John, > >> > >> In the current model, a media stream is always associated with at > > least one participant. Here is the > >> snippet of the associations between CS and Participant and > Participant > > and Media Streams taken from > >> the draft > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > >> > >> Section 4.3.2 has the associations between CS and Participant=20 > >> Section 4.4.2 has the associations between media stream and > > participant > >> > >> The current model allows participants who are not part of CS to be > > part of the model. > >> A example of such a case is: > >> - participants in a premixed media stream. The SRC may > have knowledge > > of such Participants, yet not > >> have any signaling relationship with them. This might arise if one > > participant in CS is a conf focus. > >> > >> In those case, if the metadata for non-CS participants is > incomplete, > > the SRC can use other mechanisms > >> like subscribing to conference event package to retrieve the > > information about non-CS participants. > >> > >> To summarize the model allows representing of non-CS > participants who > > contribute media to CS. > >> > >> Charles, > >> The use case section is at the end of this document=20 > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > >> > >> Please note the case where Focus is acting as SRC is simpler as all > > participants of conference which > >> are connected to focus will in turn become participants of CS too. > >> > >> Thanks, > >> Ram > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > >>> Behalf Of Elwell, John > >>> Sent: Thursday, January 27, 2011 1:09 PM > >>> To: Charles Eckel (eckelcu); siprec@ietf.org > >>> Subject: Re: [siprec] metadata model for participant that is not > > part > >>> of CS > >>> > >>> I am starting to see Charles's point. For a participant behind a=20 > >>> bridge, you don't really know what media he is > contributing or what > >>> media he is receiving. All you know for certain is that the bridge > > is a > >>> participant. Perhaps we could assign multiple user identities to a=20 > >>> bridge participant, thereby reflecting users behind the > bridge that > > may > >>> or may not be contributing to the media the bridge sends > and may or > > may > >>> not be recipients of media the bridge receives. > >>> > >>> Note that the model when the SRC is at the bridge, rather than > > outside > >>> the bridge, is quite different. Also the model where the bridge is=20 > >>> switching, rather than mixing, might be different. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > (eckelcu) > >>>> Sent: 26 January 2011 18:56 > >>>> To: siprec@ietf.org > >>>> Subject: [siprec] metadata model for participant that is not part=20 > >>>> of CS > >>>> > >>>> This is to follow up on some questions I raised regarding the > >>> metadata > >>>> model during the interim meeting Tuesday. > >>>> My initial concern was that I thought we were allowing media=20 > >>>> streams to be defined without any participant. I now understand=20 > >>>> that is not > > the > >>>> case; rather, a media stream is always associated with at least > > one > >>>> participant, but that participant need not necessary be=20 > >>>> associated with the CS. > >>>> Now I have some concern about participants that are not part of=20 > >>>> the CS. > >>>> My concern is that the level of metadata we have for such > >>> participants > >>>> will be inconsistent at best. If the metadata for a non-CS > >>> participant > >>>> is incomplete, what do we plan to do? > >>>> Also, I believe there was reference to a document that contains > > the > >>>> model and some use cases. Which document is that? > >>>> > >>>> Thanks, > >>>> Charles > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Sun Feb 13 14:39:33 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9963C3A6C39 for ; Sun, 13 Feb 2011 14:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uGWMHy7TTtF for ; Sun, 13 Feb 2011 14:39:31 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id C50033A6C38 for ; Sun, 13 Feb 2011 14:39:30 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 14 Feb 2011 00:39:51 +0200 From: Leon Portman To: "Elwell, John" , Paul Kyzivat Date: Mon, 14 Feb 2011 00:39:50 +0200 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvHlcXlMWPhfccVR76FrXcITnkOYgAoi4MAAN7qYpA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38A68075BF@TLVMBX01.nice.com> References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <4D500086.3010506@cisco.com> <4D5147D1.1010807@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 22:39:33 -0000 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 r= ecording. 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 som= e 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 e= xternal interface is outside of scope of the SIPREC. Of course on the proto= col 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Wednesday, February 09, 2011 11:08 AM To: Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 08 February 2011 13:41 > To: Elwell, John > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > > > On 2/8/2011 2:30 AM, Elwell, John wrote: > > 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. > > 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. [JRE] Perhaps this suggests that, as part of the solution, we would want so= mething to signal the presence of an SRC on the path. I don't think this pr= events us stating a requirement. > > 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. [JRE] From a solution point of view, we could consider a separate I-D for s= ignalling 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 req= uirements 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) > > > > > >> -----Original Message----- > >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > >> Sent: 08 February 2011 00:38 > >> To: Elwell, John; Paul Kyzivat > >> Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > >> Subject: RE: [siprec] Proposed change to REQ-017 concerning > >> cancellation > >> > >> I agree with the proposed changes/recommendations to > REQ-015, 16, and > >> 18. > >> > >> Regarding REQ-017: > >> "REQ-017 The mechanism MUST support a means for a UA involved in a > >> CS to request that the CS henceforth not be recorded." > >> > >> "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:john.elwell@siemens-enterprise.com] > >> Sent: Monday, February 07, 2011 6:36 AM > >> To: Paul Kyzivat > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; 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) > >> > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 07 February 2011 14:24 > >>> To: Elwell, John > >>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >>> cancellation > >>> > >>> > >>> > >>> On 2/7/2011 7:17 AM, Elwell, John wrote: > >>>> 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: > >>> > >>> 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 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? > >>> > >>> 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 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). > >>> > >>> 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. > >>> > >>>> 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." > >>> > >>> 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: > >>>> "REQ-017 The mechanism MUST support a means for a UA > >>> involved in a CS to request that the CS not be recorded." > >>> > >>> 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) > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> Sent: 04 February 2011 16:40 > >>>>> To: Elwell, John > >>>>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > >> Alissa Cooper > >>>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > >>>>> cancellation > >>>>> > >>>>> > >>>>> > >>>>> On 2/4/2011 2:22 AM, Elwell, John wrote: > >>>>>> 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? > >>>>> > >>>>> 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: > >>>>> > >>>>> 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 > >>>>> > >>>>> 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 > >>>>> > >>> > >> > >> > >> -------------------------------------------------------------- > >> ----------------------------------------------------- > >> 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 siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Sun Feb 13 23:35:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BA33A6ABF for ; Sun, 13 Feb 2011 23:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDlvacM9Nw8z for ; Sun, 13 Feb 2011 23:35:00 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 23EAD3A6A91 for ; Sun, 13 Feb 2011 23:34:57 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3374196; Mon, 14 Feb 2011 08:35:14 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6DC081EB82AE; Mon, 14 Feb 2011 08:34:48 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 14 Feb 2011 08:34:48 +0100 From: "Elwell, John" To: Leon Portman , Paul Kyzivat Date: Mon, 14 Feb 2011 08:34:46 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvHlcXlMWPhfccVR76FrXcITnkOYgAoi4MAAN7qYpAAGVfBcA== Message-ID: References: <4D480C4F.9030704@cisco.com> <4D49608F.3050506@cisco.com> <4D49D588.1050405@cisco.com> <4D4B6BBA.1020103@cisco.com> <4D4C2BF9.5060004@cisco.com> <4D500086.3010506@cisco.com> <4D5147D1.1010807@cisco.com> <07465C1D981ABC41A344374066AE1A2C38A68075BF@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A68075BF@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 07:35:03 -0000 Leon, I think case 1 is different, in that it is signalling on the CS SIP path an= d 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 r= ecorded and notifications whether an SRC is on the path. So the question fo= r now is whether the group is interesting in formulating appropriate requir= ements in this area. I don't think we should address 2 and 3. John (as individual) > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 13 February 2011 22:40 > To: Elwell, John; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] Proposed change to REQ-017 concerning > cancellation > > 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: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, February 09, 2011 11:08 AM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 08 February 2011 13:41 > > To: Elwell, John > > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > > Subject: Re: [siprec] Proposed change to REQ-017 concerning > > cancellation > > > > > > > > On 2/8/2011 2:30 AM, Elwell, John wrote: > > > 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. > > > > 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. > [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. > > > > > 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. > [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) > > > > > > > > >> -----Original Message----- > > >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > > >> Sent: 08 February 2011 00:38 > > >> To: Elwell, John; Paul Kyzivat > > >> Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > > >> Subject: RE: [siprec] Proposed change to REQ-017 concerning > > >> cancellation > > >> > > >> I agree with the proposed changes/recommendations to > > REQ-015, 16, and > > >> 18. > > >> > > >> Regarding REQ-017: > > >> "REQ-017 The mechanism MUST support a means for a UA > involved in a > > >> CS to request that the CS henceforth not be recorded." > > >> > > >> "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:john.elwell@siemens-enterprise.com] > > >> Sent: Monday, February 07, 2011 6:36 AM > > >> To: Paul Kyzivat > > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > 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) > > >> > > >> > > >>> -----Original Message----- > > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>> Sent: 07 February 2011 14:24 > > >>> To: Elwell, John > > >>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > Alissa Cooper > > >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > >>> cancellation > > >>> > > >>> > > >>> > > >>> On 2/7/2011 7:17 AM, Elwell, John wrote: > > >>>> 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: > > >>> > > >>> 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 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? > > >>> > > >>> 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 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). > > >>> > > >>> 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. > > >>> > > >>>> 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." > > >>> > > >>> 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: > > >>>> "REQ-017 The mechanism MUST support a means for a UA > > >>> involved in a CS to request that the CS not be recorded." > > >>> > > >>> 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) > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>>> Sent: 04 February 2011 16:40 > > >>>>> To: Elwell, John > > >>>>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > > >> Alissa Cooper > > >>>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > >>>>> cancellation > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 2/4/2011 2:22 AM, Elwell, John wrote: > > >>>>>> 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? > > >>>>> > > >>>>> 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: > > >>>>> > > >>>>> 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 > > >>>>> > > >>>>> 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 > > >>>>> > > >>> > > >> > > >> > > >> -------------------------------------------------------------- > > >> ----------------------------------------------------- > > >> 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 > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Sun Feb 13 23:37:00 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCE73A6A91 for ; Sun, 13 Feb 2011 23:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic33aAchiLDF for ; Sun, 13 Feb 2011 23:36:58 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8CDC83A6B5D for ; Sun, 13 Feb 2011 23:36:32 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3387346; Mon, 14 Feb 2011 08:36:02 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 76A001EB82AB; Mon, 14 Feb 2011 08:36:02 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 14 Feb 2011 08:36:02 +0100 From: "Elwell, John" To: Leon Portman , Paul Kyzivat , "siprec@ietf.org" Date: Mon, 14 Feb 2011 08:36:01 +0100 Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu+VBWN/0UhnZhoTuyG1XfePuGXDwLo0uGQAG7QqQAAGceTsA== Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> <4D41C01C.4050205@cisco.com> <07465C1D981ABC41A344374066AE1A2C38A68075BE@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A68075BE@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 07:37:00 -0000 Or we could have values "unknown" for certain things.=20 John (as individual) > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 13 February 2011 22:40 > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > Subject: RE: [siprec] metadata model for participant that is=20 > not part of CS >=20 > Hello, >=20 > I agree with Paul statement that SRC should provide best=20 > effort to report complete metadata as possible. And we should=20 > model it as complete as possible as well.=20 > In cases where information is not complete or cannot be=20 > guaranteed to be correct, we should allow SRC to indicate it:=20 > maybe we should add a parameter called: "Metadata Certainty"? >=20 > Leon >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, February 11, 2011 4:29 PM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is=20 > not part of CS >=20 > I realise I was directly addressed earlier in this thread and=20 > I didn't reply (it was left sitting in my inbox). >=20 > I don't have anything further to add - I see both sides of=20 > the argument. Paul/Ram are looking for sufficient=20 > expressiveness to cover a wide range of situations, even=20 > though in many cases information available will be limited.=20 > Charles is concerned, I think, with it being misleading in=20 > some cases where limited information is available. So perhaps=20 > we need other opinions in order to close on this one. >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 27 January 2011 18:58 > > To: siprec@ietf.org > > Subject: Re: [siprec] metadata model for participant that=20 > is not part=20 > > of CS > >=20 > > Charles, > >=20 > > I don't think we will be able (or should try) to design=20 > this so that=20 > > everything the SRC specifies is guaranteed to be as complete as you=20 > > wish it to be. At the end of the day, the SRC will have to=20 > do what it=20 > > can, and some will be better at it than others. If the SRC you have=20 > > chosen isn't supplying the information it could have and=20 > wish it had,=20 > > then you can complain and request upgrades, or you can choose a=20 > > different product. > >=20 > > As long as we have sufficient expressiveness to describe=20 > things as you=20 > > wish for any given case then I think we are good. Lets=20 > ensure we can=20 > > at least do that. > >=20 > > BTW, this is exactly the sort of discussion I have been hoping we=20 > > would have over the model. I expected it would happen quite=20 > some time=20 > > ago. But better now than never. > >=20 > > Thanks, > > Paul > >=20 > > On 1/27/2011 1:07 PM, Charles Eckel (eckelcu) wrote: > > > Hi Ram, > > > > > > If all CS participants are required to support the=20 > conference event=20 > > > package and provide sufficient info about each non-CS=20 > participant in=20 > > > order to be allowed to bring them in, then I am ok with it. > > My concern > > > is that the SRS will not be able to get sufficient info=20 > about non-CS=20 > > > participant in all cases. In such cases, it seems to me the media=20 > > > streams should be associated with the CS participant > > responsible for the > > > non-CS participant, rather than allowing media from incompletely=20 > > > described non-CS participants to exist on its own. > > > You mention the case of the conference focus, in which > > everything may be > > > fine, but there are other cases, as mentioned by Jon, for > > which this may > > > not be the case. > > > > > > Cheers, > > > Charles > > > > > > > > > > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) > > >> Sent: Thursday, January 27, 2011 4:35 AM > > >> To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org > > >> Subject: RE: [siprec] metadata model for participant that > > is not part > > > of CS > > >> > > >> Hi Charles/John, > > >> > > >> In the current model, a media stream is always associated with at > > > least one participant. Here is the > > >> snippet of the associations between CS and Participant and > > Participant > > > and Media Streams taken from > > >> the draft > > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > > >> > > >> Section 4.3.2 has the associations between CS and Participant=20 > > >> Section 4.4.2 has the associations between media stream and > > > participant > > >> > > >> The current model allows participants who are not part=20 > of CS to be > > > part of the model. > > >> A example of such a case is: > > >> - participants in a premixed media stream. The SRC may > > have knowledge > > > of such Participants, yet not > > >> have any signaling relationship with them. This might=20 > arise if one > > > participant in CS is a conf focus. > > >> > > >> In those case, if the metadata for non-CS participants is > > incomplete, > > > the SRC can use other mechanisms > > >> like subscribing to conference event package to retrieve the > > > information about non-CS participants. > > >> > > >> To summarize the model allows representing of non-CS > > participants who > > > contribute media to CS. > > >> > > >> Charles, > > >> The use case section is at the end of this document=20 > > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > > >> > > >> Please note the case where Focus is acting as SRC is=20 > simpler as all > > > participants of conference which > > >> are connected to focus will in turn become participants=20 > of CS too. > > >> > > >> Thanks, > > >> Ram > > >> > > >>> -----Original Message----- > > >>> From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On=20 > > >>> Behalf Of Elwell, John > > >>> Sent: Thursday, January 27, 2011 1:09 PM > > >>> To: Charles Eckel (eckelcu); siprec@ietf.org > > >>> Subject: Re: [siprec] metadata model for participant that is not > > > part > > >>> of CS > > >>> > > >>> I am starting to see Charles's point. For a participant=20 > behind a=20 > > >>> bridge, you don't really know what media he is > > contributing or what > > >>> media he is receiving. All you know for certain is that=20 > the bridge > > > is a > > >>> participant. Perhaps we could assign multiple user=20 > identities to a=20 > > >>> bridge participant, thereby reflecting users behind the > > bridge that > > > may > > >>> or may not be contributing to the media the bridge sends > > and may or > > > may > > >>> not be recipients of media the bridge receives. > > >>> > > >>> Note that the model when the SRC is at the bridge, rather than > > > outside > > >>> the bridge, is quite different. Also the model where=20 > the bridge is=20 > > >>> switching, rather than mixing, might be different. > > >>> > > >>> John (as individual) > > >>> > > >>>> -----Original Message----- > > >>>> From: siprec-bounces@ietf.org > > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > (eckelcu) > > >>>> Sent: 26 January 2011 18:56 > > >>>> To: siprec@ietf.org > > >>>> Subject: [siprec] metadata model for participant that=20 > is not part=20 > > >>>> of CS > > >>>> > > >>>> This is to follow up on some questions I raised regarding the > > >>> metadata > > >>>> model during the interim meeting Tuesday. > > >>>> My initial concern was that I thought we were allowing media=20 > > >>>> streams to be defined without any participant. I now=20 > understand=20 > > >>>> that is not > > > the > > >>>> case; rather, a media stream is always associated with at least > > > one > > >>>> participant, but that participant need not necessary be=20 > > >>>> associated with the CS. > > >>>> Now I have some concern about participants that are=20 > not part of=20 > > >>>> the CS. > > >>>> My concern is that the level of metadata we have for such > > >>> participants > > >>>> will be inconsistent at best. If the metadata for a non-CS > > >>> participant > > >>>> is incomplete, what do we plan to do? > > >>>> Also, I believe there was reference to a document that contains > > > the > > >>>> model and some use cases. Which document is that? > > >>>> > > >>>> Thanks, > > >>>> Charles > > >>>> _______________________________________________ > > >>>> siprec mailing list > > >>>> siprec@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>> > > >>> _______________________________________________ > > >>> siprec mailing list > > >>> siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From partr@cisco.com Mon Feb 14 09:43:53 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2103A69EB for ; Mon, 14 Feb 2011 09:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkga3ysZ8umq for ; Mon, 14 Feb 2011 09:43:49 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6E65D3A6A16 for ; Mon, 14 Feb 2011 09:43:49 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BACb5WE1AaMHG/2dsb2JhbACXLo12Z3OgHZskhV4EhQKKNQ X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208,217";a="259794604" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2011 17:44:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1EHhl9M006621; Mon, 14 Feb 2011 17:44:05 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 23:14:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBCC6E.C2B3A8B4" Date: Mon, 14 Feb 2011 23:13:59 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvHlcXlMWPhfccVR76FrXcITnkOYgAoi4MAAN7qYpAAGVfBcAAUr7ye References: <4D480C4F.9030704@cisco.com><4D49608F.3050506@cisco.com><4D49D588.1050405@cisco.com><4D4B6BBA.1020103@cisco.com><4D4C2BF9.5060004@cisco.com><4D500086.3010506@cisco.com><4D5147D1.1010807@cisco.com><07465C1D981ABC41A34 4374066A E1A2C38A68075BF@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Leon Portman" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 14 Feb 2011 17:44:00.0041 (UTC) FILETIME=[C302F190:01CBCC6E] Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:43:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCC6E.C2B3A8B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. =20 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,=20 =20 1) Customer establish dialog with Agent1 (CS1) 2) Customer dialog is transferred to Agent2 by Agent1 (CS2) 3) Customer sends discard indication through CS2 =20 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. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Elwell, John Sent: Mon 2/14/2011 1:04 PM To: Leon Portman; Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation 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) > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 13 February 2011 22:40 > To: Elwell, John; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] Proposed change to REQ-017 concerning > cancellation > > 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: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, February 09, 2011 11:08 AM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 08 February 2011 13:41 > > To: Elwell, John > > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > > Subject: Re: [siprec] Proposed change to REQ-017 concerning > > cancellation > > > > > > > > On 2/8/2011 2:30 AM, Elwell, John wrote: > > > 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. > > > > 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. > [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. > > > > > 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. > [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) > > > > > > > > >> -----Original Message----- > > >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > > >> Sent: 08 February 2011 00:38 > > >> To: Elwell, John; Paul Kyzivat > > >> Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > > >> Subject: RE: [siprec] Proposed change to REQ-017 concerning > > >> cancellation > > >> > > >> I agree with the proposed changes/recommendations to > > REQ-015, 16, and > > >> 18. > > >> > > >> Regarding REQ-017: > > >> "REQ-017 The mechanism MUST support a means for a UA > involved in a > > >> CS to request that the CS henceforth not be recorded." > > >> > > >> "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:john.elwell@siemens-enterprise.com] > > >> Sent: Monday, February 07, 2011 6:36 AM > > >> To: Paul Kyzivat > > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > 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) > > >> > > >> > > >>> -----Original Message----- > > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>> Sent: 07 February 2011 14:24 > > >>> To: Elwell, John > > >>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > Alissa Cooper > > >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > >>> cancellation > > >>> > > >>> > > >>> > > >>> On 2/7/2011 7:17 AM, Elwell, John wrote: > > >>>> 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: > > >>> > > >>> 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 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? > > >>> > > >>> 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 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). > > >>> > > >>> 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. > > >>> > > >>>> 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." > > >>> > > >>> 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: > > >>>> "REQ-017 The mechanism MUST support a means for a UA > > >>> involved in a CS to request that the CS not be recorded." > > >>> > > >>> 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) > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>>> Sent: 04 February 2011 16:40 > > >>>>> To: Elwell, John > > >>>>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > > >> Alissa Cooper > > >>>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > >>>>> cancellation > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 2/4/2011 2:22 AM, Elwell, John wrote: > > >>>>>> 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? > > >>>>> > > >>>>> 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: > > >>>>> > > >>>>> 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 > > >>>>> > > >>>>> 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 > > >>>>> > > >>> > > >> > > >> > > >> -------------------------------------------------------------- > > >> ----------------------------------------------------- > > >> 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 > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBCC6E.C2B3A8B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [siprec] Proposed change to REQ-017 = concerning cancellation=0A= =0A= =0A= =0A=
=0A=
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.
=0A=
 
=0A=
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,
=0A=
 
=0A=
1) Customer establish dialog with Agent1  = (CS1)
=0A=
2) Customer dialog is = transferred to Agent2 by Agent1 (CS2)
=0A=
3) Customer sends discard = indication through CS2
=0A=
 
=0A=
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.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=
=0A=
=0A=
=0A=
From: = siprec-bounces@ietf.org on behalf of Elwell, John
Sent: Mon = 2/14/2011 1:04 PM
To: Leon Portman; Paul Kyzivat = (pkyzivat)
Cc: siprec@ietf.org
Subject: Re: [siprec] = Proposed change to REQ-017 concerning = cancellation

=0A=
=0A=

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)


> -----Original Message-----
> From: = Leon Portman [mailto:Leon.Portman@nice.com]> Sent: 13 February 2011 22:40
> To: Elwell, John; Paul = Kyzivat
> Cc: siprec@ietf.org
> Subject: RE: [siprec] = Proposed change to REQ-017 concerning
> = cancellation
>
> 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: = siprec-bounces@ietf.org
> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John
> Sent: Wednesday, February 09, 2011 = 11:08 AM
> To: Paul Kyzivat
> Cc: siprec@ietf.org
> = Subject: Re: [siprec] Proposed change to REQ-017 concerning
> = cancellation
>
>
>
> > -----Original = Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>= > Sent: 08 February 2011 13:41
> > To: Elwell, John
> = > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa = Cooper
> > Subject: Re: [siprec] Proposed change to REQ-017 = concerning
> > cancellation
> >
> >
> = >
> > On 2/8/2011 2:30 AM, Elwell, John wrote:
> > = > 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.
> >
> > 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.
> [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.
>
> >
> > 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.
> [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)
> = > >
> > >
> > >> -----Original = Message-----
> > >> From: Dave Smith [mailto:Dave.d.Smith@alcat= el-lucent.com]
> > >> Sent: 08 February 2011 = 00:38
> > >> To: Elwell, John; Paul Kyzivat
> > = >> Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper
> = > >> Subject: RE: [siprec] Proposed change to REQ-017 = concerning
> > >> cancellation
> > = >>
> > >> I agree with the proposed = changes/recommendations to
> > REQ-015, 16, and
> > = >> 18.
> > >>
> > >> Regarding = REQ-017:
> > >> "REQ-017 The mechanism MUST support a = means for a UA
> involved in a
> > >> CS to request = that the CS henceforth not be recorded."
> > >>
> = > >> "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:john.elwell@sie= mens-enterprise.com]
> > >> Sent: Monday, February = 07, 2011 6:36 AM
> > >> To: Paul Kyzivat
> > = >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org;
> = 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)
> > >>
> > >>
> > = >>> -----Original Message-----
> > >>> From: = Paul Kyzivat [mailto:pkyzivat@cisco.com]
>= > >>> Sent: 07 February 2011 14:24
> > = >>> To: Elwell, John
> > >>> Cc: Dave Smith; = Ken Rehor (krehor); siprec@ietf.org;
> Alissa Cooper
> > = >>> Subject: Re: [siprec] Proposed change to REQ-017 = concerning
> > >>> cancellation
> > = >>>
> > >>>
> > >>>
> = > >>> On 2/7/2011 7:17 AM, Elwell, John wrote:
> > = >>>> 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:
> > >>>
> > = >>> 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 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?
> > >>>
> > = >>> 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 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).
> = > >>>
> > >>> 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.
> > >>>
> > = >>>> 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."
> > >>>
> = > >>> 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:
> > >>>> "REQ-017 The mechanism MUST = support a means for a UA
> > >>> involved in a CS to = request that the CS not be recorded."
> > >>>
> = > >>> 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)
> = > >>>>
> > >>>>
> > = >>>>
> > >>>>
> > = >>>>> -----Original Message-----
> > = >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>= > >>>>> Sent: 04 February 2011 16:40
> > = >>>>> To: Elwell, John
> > >>>>> = Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org;
> > = >> Alissa Cooper
> > >>>>> Subject: Re: = [siprec] Proposed change to REQ-017 concerning
> > = >>>>> cancellation
> > = >>>>>
> > >>>>>
> > = >>>>>
> > >>>>> On 2/4/2011 2:22 = AM, Elwell, John wrote:
> > >>>>>> = 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?
> > >>>>>
> > = >>>>> 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:
> > = >>>>>
> > = >>>>>       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
> > = >>>>>
> > >>>>> 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
> > = >>>>>
> > >>>
> > = >>
> > >>
> > >> = --------------------------------------------------------------
> = > >> = -----------------------------------------------------
> > = >> 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
> siprec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/siprec
>
________________________________= _______________
siprec mailing list
siprec@ietf.org
https://www.ietf.or= g/mailman/listinfo/siprec

------_=_NextPart_001_01CBCC6E.C2B3A8B4-- From eckelcu@cisco.com Mon Feb 14 11:25:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525793A6DA2 for ; Mon, 14 Feb 2011 11:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjUxckNPu79n for ; Mon, 14 Feb 2011 11:25:29 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E45AE3A6DA5 for ; Mon, 14 Feb 2011 11:25:29 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAJcQWU2rR7Ht/2dsb2JhbACXMo5dc6AhmyWFXgSFBIoz X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="263365933" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2011 19:25:52 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1EJPqIp020512; Mon, 14 Feb 2011 19:25:52 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 11:25:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: Ho1i I8zT KMzZ Oj2P Oljt PjEe PugR R1PX TM3G WuKc YxIZ cyMC dbL1 d6ws j0DV kIme; 3; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AGwAZQBvAG4ALgBwAG8AcgB0AG0AYQBuAEAAbgBpAGMAZQAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {338393C4-862C-4610-9CBF-209A3E5B746B}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Mon, 14 Feb 2011 19:25:44 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABtAGUAdABhAGQAYQB0AGEAIABtAG8AZABlAGwAIABmAG8AcgAgAHAAYQByAHQAaQBjAGkAcABhAG4AdAAgAHQAaABhAHQAIABpAHMAIABuAG8AdAAgAHAAYQByAHQAIABvAGYAIABDAFMA x-cr-puzzleid: {338393C4-862C-4610-9CBF-209A3E5B746B} Content-class: urn:content-classes:message Date: Mon, 14 Feb 2011 11:25:44 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu+VBWN/0UhnZhoTuyG1XfePuGXDwLo0uGQAG7QqQAAGceTsAAYVW7A References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com><4D41C01C.4050205@cisco.com><07465C1D981ABC41A344374066AE1A2C38A68075BE@TLVMBX01.nice.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Leon Portman" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 14 Feb 2011 19:25:52.0478 (UTC) FILETIME=[FE4ECFE0:01CBCC7C] Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 19:25:31 -0000 I am ok with this best effort handling as in reality that is always the case anyway. If we show two use cases, one with highly functionality and cooperative participants and another with lower functioning participants, and illustrate the resulting meta data population, I think that will address my concerns. For example: 1) Participant A within a CS conferences in another party that is not a part of the CS via internal 3rd party conference feature. Participant A does not provide any SIP signaling regarding this toward the SRS. What is the resulting metadata? 2) MCU is used to host a multiparty conference that is part of a CS. What is the resulting metadata at the SRS if the MCU supports the conferencing package? How do things look if it does not. Perhaps (1) is just a special case of (2), but I think going through the metadata example will help determine that.=20 Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Sunday, February 13, 2011 11:36 PM > To: Leon Portman; Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is not part of CS >=20 > Or we could have values "unknown" for certain things. >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 13 February 2011 22:40 > > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > > Subject: RE: [siprec] metadata model for participant that is > > not part of CS > > > > Hello, > > > > I agree with Paul statement that SRC should provide best > > effort to report complete metadata as possible. And we should > > model it as complete as possible as well. > > In cases where information is not complete or cannot be > > guaranteed to be correct, we should allow SRC to indicate it: > > maybe we should add a parameter called: "Metadata Certainty"? > > > > Leon > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Friday, February 11, 2011 4:29 PM > > To: Paul Kyzivat; siprec@ietf.org > > Subject: Re: [siprec] metadata model for participant that is > > not part of CS > > > > I realise I was directly addressed earlier in this thread and > > I didn't reply (it was left sitting in my inbox). > > > > I don't have anything further to add - I see both sides of > > the argument. Paul/Ram are looking for sufficient > > expressiveness to cover a wide range of situations, even > > though in many cases information available will be limited. > > Charles is concerned, I think, with it being misleading in > > some cases where limited information is available. So perhaps > > we need other opinions in order to close on this one. > > > > John > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > Sent: 27 January 2011 18:58 > > > To: siprec@ietf.org > > > Subject: Re: [siprec] metadata model for participant that > > is not part > > > of CS > > > > > > Charles, > > > > > > I don't think we will be able (or should try) to design > > this so that > > > everything the SRC specifies is guaranteed to be as complete as you > > > wish it to be. At the end of the day, the SRC will have to > > do what it > > > can, and some will be better at it than others. If the SRC you have > > > chosen isn't supplying the information it could have and > > wish it had, > > > then you can complain and request upgrades, or you can choose a > > > different product. > > > > > > As long as we have sufficient expressiveness to describe > > things as you > > > wish for any given case then I think we are good. Lets > > ensure we can > > > at least do that. > > > > > > BTW, this is exactly the sort of discussion I have been hoping we > > > would have over the model. I expected it would happen quite > > some time > > > ago. But better now than never. > > > > > > Thanks, > > > Paul > > > > > > On 1/27/2011 1:07 PM, Charles Eckel (eckelcu) wrote: > > > > Hi Ram, > > > > > > > > If all CS participants are required to support the > > conference event > > > > package and provide sufficient info about each non-CS > > participant in > > > > order to be allowed to bring them in, then I am ok with it. > > > My concern > > > > is that the SRS will not be able to get sufficient info > > about non-CS > > > > participant in all cases. In such cases, it seems to me the media > > > > streams should be associated with the CS participant > > > responsible for the > > > > non-CS participant, rather than allowing media from incompletely > > > > described non-CS participants to exist on its own. > > > > You mention the case of the conference focus, in which > > > everything may be > > > > fine, but there are other cases, as mentioned by Jon, for > > > which this may > > > > not be the case. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Ram Mohan R (rmohanr) > > > >> Sent: Thursday, January 27, 2011 4:35 AM > > > >> To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org > > > >> Subject: RE: [siprec] metadata model for participant that > > > is not part > > > > of CS > > > >> > > > >> Hi Charles/John, > > > >> > > > >> In the current model, a media stream is always associated with at > > > > least one participant. Here is the > > > >> snippet of the associations between CS and Participant and > > > Participant > > > > and Media Streams taken from > > > >> the draft > > > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > > > >> > > > >> Section 4.3.2 has the associations between CS and Participant > > > >> Section 4.4.2 has the associations between media stream and > > > > participant > > > >> > > > >> The current model allows participants who are not part > > of CS to be > > > > part of the model. > > > >> A example of such a case is: > > > >> - participants in a premixed media stream. The SRC may > > > have knowledge > > > > of such Participants, yet not > > > >> have any signaling relationship with them. This might > > arise if one > > > > participant in CS is a conf focus. > > > >> > > > >> In those case, if the metadata for non-CS participants is > > > incomplete, > > > > the SRC can use other mechanisms > > > >> like subscribing to conference event package to retrieve the > > > > information about non-CS participants. > > > >> > > > >> To summarize the model allows representing of non-CS > > > participants who > > > > contribute media to CS. > > > >> > > > >> Charles, > > > >> The use case section is at the end of this document > > > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > > > >> > > > >> Please note the case where Focus is acting as SRC is > > simpler as all > > > > participants of conference which > > > >> are connected to focus will in turn become participants > > of CS too. > > > >> > > > >> Thanks, > > > >> Ram > > > >> > > > >>> -----Original Message----- > > > >>> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > >>> Behalf Of Elwell, John > > > >>> Sent: Thursday, January 27, 2011 1:09 PM > > > >>> To: Charles Eckel (eckelcu); siprec@ietf.org > > > >>> Subject: Re: [siprec] metadata model for participant that is not > > > > part > > > >>> of CS > > > >>> > > > >>> I am starting to see Charles's point. For a participant > > behind a > > > >>> bridge, you don't really know what media he is > > > contributing or what > > > >>> media he is receiving. All you know for certain is that > > the bridge > > > > is a > > > >>> participant. Perhaps we could assign multiple user > > identities to a > > > >>> bridge participant, thereby reflecting users behind the > > > bridge that > > > > may > > > >>> or may not be contributing to the media the bridge sends > > > and may or > > > > may > > > >>> not be recipients of media the bridge receives. > > > >>> > > > >>> Note that the model when the SRC is at the bridge, rather than > > > > outside > > > >>> the bridge, is quite different. Also the model where > > the bridge is > > > >>> switching, rather than mixing, might be different. > > > >>> > > > >>> John (as individual) > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: siprec-bounces@ietf.org > > > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > (eckelcu) > > > >>>> Sent: 26 January 2011 18:56 > > > >>>> To: siprec@ietf.org > > > >>>> Subject: [siprec] metadata model for participant that > > is not part > > > >>>> of CS > > > >>>> > > > >>>> This is to follow up on some questions I raised regarding the > > > >>> metadata > > > >>>> model during the interim meeting Tuesday. > > > >>>> My initial concern was that I thought we were allowing media > > > >>>> streams to be defined without any participant. I now > > understand > > > >>>> that is not > > > > the > > > >>>> case; rather, a media stream is always associated with at least > > > > one > > > >>>> participant, but that participant need not necessary be > > > >>>> associated with the CS. > > > >>>> Now I have some concern about participants that are > > not part of > > > >>>> the CS. > > > >>>> My concern is that the level of metadata we have for such > > > >>> participants > > > >>>> will be inconsistent at best. If the metadata for a non-CS > > > >>> participant > > > >>>> is incomplete, what do we plan to do? > > > >>>> Also, I believe there was reference to a document that contains > > > > the > > > >>>> model and some use cases. Which document is that? > > > >>>> > > > >>>> Thanks, > > > >>>> Charles > > > >>>> _______________________________________________ > > > >>>> siprec mailing list > > > >>>> siprec@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/siprec > > > >>>> > > > >>> _______________________________________________ > > > >>> siprec mailing list > > > >>> siprec@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From trac@tools.ietf.org Tue Feb 15 00:02:17 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5873A6A5A for ; Tue, 15 Feb 2011 00:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvWU4oP2NJvO for ; Tue, 15 Feb 2011 00:02:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D0F3F3A6B7C for ; Tue, 15 Feb 2011 00:02:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PpFrq-0005bQ-7K; Tue, 15 Feb 2011 00:02:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: leon.portman@nice.com, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Tue, 15 Feb 2011 08:02:38 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/63 Message-ID: <075.13fa3cf5cb60742d46f34fcd19b8f580@tools.ietf.org> X-Trac-Ticket-ID: 63 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leon.portman@nice.com, john.elwell@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:02:17 -0000 #63: REQ-015/REQ-016 and discarding recordings Do we need any requirement concerning a participant's ability to request the discarding of a cancelled recording? If not, can we remove that part of REQ-015/016 to do with discarding a recording? John -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: leon.portman@… Type: defect | Status: new Priority: major | Milestone: Component: Requirements | Version: Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From trac@tools.ietf.org Tue Feb 15 00:05:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D4F3A6C78 for ; Tue, 15 Feb 2011 00:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UITLEpTpDlHo for ; Tue, 15 Feb 2011 00:05:31 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F3B3D3A6A5A for ; Tue, 15 Feb 2011 00:05:30 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PpFv1-0005oJ-6Q; Tue, 15 Feb 2011 00:05:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: leon.portman@nice.com, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Tue, 15 Feb 2011 08:05:55 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/siprec/trac/ticket/64 Message-ID: <075.d0db8f34c277334b137156e493ae53f5@tools.ietf.org> X-Trac-Ticket-ID: 64 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leon.portman@nice.com, john.elwell@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancelling a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:05:31 -0000 #64: REQ-015/REQ-016 and cancelling a recording Do we need any requirement concerning cancelling a recording? We already have REQ-011 on pausing and resuming, and pausing without subsequently resuming can probably be considered to be cancelling the recording. If the resolution of ticket #63 results in no requirement for discarding a recording, and if REQ-011 is considered to cover cancelling a recording, can REQ-015 and REQ-016 be removed entirely? John -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: leon.portman@… Type: defect | Status: new Priority: major | Milestone: Component: Requirements | Version: Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From trac@tools.ietf.org Tue Feb 15 00:20:51 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A040A3A6E61 for ; Tue, 15 Feb 2011 00:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuFl6F2gMCGq for ; Tue, 15 Feb 2011 00:20:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 686D33A6E66 for ; Tue, 15 Feb 2011 00:20:50 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PpG9q-0002zY-W9; Tue, 15 Feb 2011 00:21:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: krehor@cisco.com, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Tue, 15 Feb 2011 08:21:14 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/siprec/trac/ticket/65 Message-ID: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> X-Trac-Ticket-ID: 65 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: krehor@cisco.com, john.elwell@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] Requirements #65 (new): Extension of REQ-017 concerning preference to record/not record X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:20:52 -0000 #65: Extension of REQ-017 concerning preference to record/not record We have "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". Should this be extended to cover a request during a CS, and also the ability during a CS to request that recording be allowed? In other words, the ability for a participant to indicate a preference for recording or not recording, at the start of a CS or during a CS. Note that such a requirement would be realisable only from a siprec-aware UA. This is related to REQ-011 (pause/resume), but with the difference that it is the participant who expresses the preference (REQ-011 seems to imply the SRC decides). So in considering any possible rewording of REQ-017, we should perhaps consider its relationship to REQ-011. John -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: krehor@… Type: defect | Status: new Priority: major | Milestone: Component: Requirements | Version: Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From trac@tools.ietf.org Tue Feb 15 00:23:45 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73C13A6E61 for ; Tue, 15 Feb 2011 00:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukJQoQNRJvk4 for ; Tue, 15 Feb 2011 00:23:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0173B3A6A5A for ; Tue, 15 Feb 2011 00:23:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PpGCf-0002YE-9m; Tue, 15 Feb 2011 00:24:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: leon.portman@nice.com, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Tue, 15 Feb 2011 08:24:09 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/siprec/trac/ticket/66 Message-ID: <075.d9e0afcd7cf3ee35c38905ea3efdd6c9@tools.ietf.org> X-Trac-Ticket-ID: 66 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leon.portman@nice.com, john.elwell@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:23:45 -0000 #66: Clarification of REQ-018 on indications to participants REQ-018 can be satisfied in general by playing media to participants, but do we need a more specific requirement, e.g., for siprec-aware UAs to know whether the CS is being recorded or not? John -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: leon.portman@… Type: defect | Status: new Priority: major | Milestone: Component: Requirements | Version: Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From john.elwell@siemens-enterprise.com Tue Feb 15 00:24:22 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070D33A6A5A for ; Tue, 15 Feb 2011 00:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR-jlvdzJzRd for ; Tue, 15 Feb 2011 00:24:21 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E58093A6E6B for ; Tue, 15 Feb 2011 00:24:20 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3404030 for siprec@ietf.org; Tue, 15 Feb 2011 09:24:41 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4569923F028E for ; Tue, 15 Feb 2011 09:24:41 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 15 Feb 2011 09:24:41 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 15 Feb 2011 09:24:39 +0100 Thread-Topic: Outstanding issues from req-06 last call Thread-Index: AcvM6cnN7xs5U0YZTi2Rpv0+B2ma3A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Outstanding issues from req-06 last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:24:22 -0000 We need to try to close the outstanding issues from last call on req-06 and= subsequent discussions. As I see it, the following requirements have been = the subject of discussion: - REQ-015 and REQ-016 on cancelling and discarding (with/without discarding= metadata); - REQ-017 on requesting no recording at the start of a recording; - REQ-018 on providing indications to participants as to whether the CS is = being recorded. I think the issues that have arisen can be classified as: 1. Do we need any requirement concerning a participant's ability to request= the discarding of a cancelled recording? (ticket #63) 2. Do we need any requirement concerning cancelling a recording? We already= have REQ-011 on pausing and resuming, and pausing without subsequently res= uming can probably be considered to be cancelling the recording. (ticket #6= 4) 3. Should REQ-017 be extended to cover a request during a CS, and also the = ability during a CS to request that recording be allowed? In other words, t= he ability for a participant to indicate a preference for recording or not = recording, at the start of a CS or during a CS. (ticket #65) 4. REQ-018 can be satisfied in general by playing media to participants, bu= t do we need a more specific requirement, e.g., for siprec-aware UAs to kno= w whether the CS is being recorded or not? (ticket #66) I have generated tracker issues for each of these. Please continue discussi= on of these issues on the respective threads started by the tracker. John (as chair)= From john.elwell@siemens-enterprise.com Tue Feb 15 00:28:01 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301763A6E68 for ; Tue, 15 Feb 2011 00:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JQKfJB5XKy8 for ; Tue, 15 Feb 2011 00:28:00 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0A3FE3A6B6A for ; Tue, 15 Feb 2011 00:27:59 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3401795; Tue, 15 Feb 2011 09:28:21 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 431FC23F0278; Tue, 15 Feb 2011 09:28:21 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 15 Feb 2011 09:28:21 +0100 From: "Elwell, John" To: siprec issue tracker , "leon.portman@nice.com" Date: Tue, 15 Feb 2011 09:28:19 +0100 Thread-Topic: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings Thread-Index: AcvM5r1fW0L05sYVThKsdYo/eRJE+AAAyfOQ Message-ID: References: <075.13fa3cf5cb60742d46f34fcd19b8f580@tools.ietf.org> In-Reply-To: <075.13fa3cf5cb60742d46f34fcd19b8f580@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:28:01 -0000 Concerning past discussions on retention of recordings being a policy matte= r for the SRS, I believe we do not need any requirement concerning the abil= ity to request that recordings be discarded. Depending also on the resoluti= on of #64, I believe REQ-015 and REQ-016 can be deleted. John (as individual) > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org]=20 > Sent: 15 February 2011 08:03 > To: leon.portman@nice.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and=20 > discarding recordings >=20 > #63: REQ-015/REQ-016 and discarding recordings >=20 > Do we need any requirement concerning a participant's=20 > ability to request > the discarding of a cancelled recording? If not, can we=20 > remove that part > of REQ-015/016 to do with discarding a recording? >=20 > John >=20 > --=20 > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: leon.portman@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > -------------- >=20 > Ticket URL: > siprec >=20 > = From john.elwell@siemens-enterprise.com Tue Feb 15 00:30:13 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E363A6E61 for ; Tue, 15 Feb 2011 00:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKVfbA2wBUnQ for ; Tue, 15 Feb 2011 00:30:13 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C23113A6E68 for ; Tue, 15 Feb 2011 00:30:12 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3401829; Tue, 15 Feb 2011 09:30:36 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4339F23F028E; Tue, 15 Feb 2011 09:30:36 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 15 Feb 2011 09:30:36 +0100 From: "Elwell, John" To: siprec issue tracker , "leon.portman@nice.com" Date: Tue, 15 Feb 2011 09:30:34 +0100 Thread-Topic: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancelling a recording Thread-Index: AcvM5yx8db2rSuMRR8i7RWhgEqXmLQAAyekg Message-ID: References: <075.d0db8f34c277334b137156e493ae53f5@tools.ietf.org> In-Reply-To: <075.d0db8f34c277334b137156e493ae53f5@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancelling a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:30:14 -0000 I think we don't need a special requirement on cancelling, given the existe= nce of REQ-011 on pause/resume and REQ-017 on requesting no recording. Depe= nding on the resolution of ticket #63, I believe REQ-015 and REQ-016 can be= deleted. John (as individual)=20 > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org]=20 > Sent: 15 February 2011 08:06 > To: leon.portman@nice.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #64 (new): REQ-015/REQ-016 and=20 > cancelling a recording >=20 > #64: REQ-015/REQ-016 and cancelling a recording >=20 > Do we need any requirement concerning cancelling a=20 > recording? We already > have REQ-011 on pausing and resuming, and pausing without=20 > subsequently > resuming can probably be considered to be cancelling the=20 > recording. If the > resolution of ticket #63 results in no requirement for discarding a > recording, and if REQ-011 is considered to cover cancelling=20 > a recording, > can REQ-015 and REQ-016 be removed entirely? >=20 > John >=20 > --=20 > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: leon.portman@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > -------------- >=20 > Ticket URL: > siprec >=20 > = From john.elwell@siemens-enterprise.com Tue Feb 15 00:33:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CDA3A6B5B for ; Tue, 15 Feb 2011 00:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkY2tzO0zC-8 for ; Tue, 15 Feb 2011 00:33:49 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3902F3A6ABB for ; Tue, 15 Feb 2011 00:33:49 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3404158; Tue, 15 Feb 2011 09:34:13 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 40A3F23F0278; Tue, 15 Feb 2011 09:34:13 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 15 Feb 2011 09:34:13 +0100 From: "Elwell, John" To: siprec issue tracker , "krehor@cisco.com" Date: Tue, 15 Feb 2011 09:34:11 +0100 Thread-Topic: [siprec] Requirements #65 (new): Extension of REQ-017 concerning preference to record/not record Thread-Index: AcvM6VDujz3CNrefSaezA1AOWk/G1gAAaplA Message-ID: References: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> In-Reply-To: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #65 (new): Extension of REQ-017 concerning preference to record/not record X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:33:51 -0000 I think we need to cover the following cases: - 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 pau= se. With pause, you could later resume that same recording. With stop, you = would effectively terminate the recording, such that you would need to star= t a new recording if you need to record later during the CS. The handling o= f metadata would differ - in the first case the metadata might tell you whe= n 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) =20 > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org]=20 > Sent: 15 February 2011 08:21 > To: krehor@cisco.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #65 (new): Extension of=20 > REQ-017 concerning preference to record/not record >=20 > #65: Extension of REQ-017 concerning preference to record/not record >=20 > We have "REQ-017 The mechanism MUST support a means for an authorized > participant involved in a CS to request, prior to the start=20 > of recording, > that the CS not be recorded". >=20 > Should this be extended to cover a request during a CS, and also the > ability during a CS to request that recording be allowed? In=20 > other words, > the ability for a participant to indicate a preference for=20 > recording or > not recording, at the start of a CS or during a CS. Note that such a > requirement would be realisable only from a siprec-aware UA. >=20 > This is related to REQ-011 (pause/resume), but with the=20 > difference that it > is the participant who expresses the preference (REQ-011=20 > seems to imply > the SRC decides). So in considering any possible rewording=20 > of REQ-017, we > should perhaps consider its relationship to REQ-011. >=20 > John >=20 > --=20 > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: krehor@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > -------------- >=20 > Ticket URL: > siprec >=20 > = From john.elwell@siemens-enterprise.com Tue Feb 15 00:40:36 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EB73A6E62 for ; Tue, 15 Feb 2011 00:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHUzl9Bb6Lkn for ; Tue, 15 Feb 2011 00:40:33 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 34BAE3A6DE4 for ; Tue, 15 Feb 2011 00:40:32 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3396179; Tue, 15 Feb 2011 09:40:57 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 46DD923F0278; Tue, 15 Feb 2011 09:40:57 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 15 Feb 2011 09:40:57 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , Leon Portman , "Paul Kyzivat (pkyzivat)" Date: Tue, 15 Feb 2011 09:40:55 +0100 Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvHlcXlMWPhfccVR76FrXcITnkOYgAoi4MAAN7qYpAAGVfBcAAUr7yeACAECXA= Message-ID: References: <4D480C4F.9030704@cisco.com><4D49608F.3050506@cisco.com><4D49D588.1050405@cisco.com><4D4B6BBA.1020103@cisco.com><4D4C2BF9.5060004@cisco.com><4D500086.3010506@cisco.com><4D5147D1.1010807@cisco.com><07465C1D981ABC41A34 4374066A E1A2C38A68075BF@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:40:36 -0000 Partha, See ticket#63 on discarding. If we decide to delete any requirements concer= ning discarding, presumably this would solve your issue below. Please feel = free to respond on the #63 thread on any matter concerning discarding. Thanks, John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 14 February 2011 17:44 > To: Elwell, John; Leon Portman; Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Proposed change to REQ-017 concerning > cancellation > > 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: siprec-bounces@ietf.org on behalf of Elwell, John > Sent: Mon 2/14/2011 1:04 PM > To: Leon Portman; Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning > cancellation > > > > 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) > > > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 13 February 2011 22:40 > > To: Elwell, John; Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Proposed change to REQ-017 concerning > > cancellation > > > > 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: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Wednesday, February 09, 2011 11:08 AM > > To: Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Proposed change to REQ-017 concerning > > cancellation > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 08 February 2011 13:41 > > > To: Elwell, John > > > Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > > > Subject: Re: [siprec] Proposed change to REQ-017 concerning > > > cancellation > > > > > > > > > > > > On 2/8/2011 2:30 AM, Elwell, John wrote: > > > > 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. > > > > > > 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. > > [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. > > > > > > > > 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. > > [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) > > > > > > > > > > > >> -----Original Message----- > > > >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > > > >> Sent: 08 February 2011 00:38 > > > >> To: Elwell, John; Paul Kyzivat > > > >> Cc: Ken Rehor (krehor); siprec@ietf.org; Alissa Cooper > > > >> Subject: RE: [siprec] Proposed change to REQ-017 concerning > > > >> cancellation > > > >> > > > >> I agree with the proposed changes/recommendations to > > > REQ-015, 16, and > > > >> 18. > > > >> > > > >> Regarding REQ-017: > > > >> "REQ-017 The mechanism MUST support a means for a UA > > involved in a > > > >> CS to request that the CS henceforth not be recorded." > > > >> > > > >> "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:john.elwell@siemens-enterprise.com] > > > >> Sent: Monday, February 07, 2011 6:36 AM > > > >> To: Paul Kyzivat > > > >> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > > 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) > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >>> Sent: 07 February 2011 14:24 > > > >>> To: Elwell, John > > > >>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > > Alissa Cooper > > > >>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > > >>> cancellation > > > >>> > > > >>> > > > >>> > > > >>> On 2/7/2011 7:17 AM, Elwell, John wrote: > > > >>>> 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: > > > >>> > > > >>> 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 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? > > > >>> > > > >>> 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 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). > > > >>> > > > >>> 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. > > > >>> > > > >>>> 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." > > > >>> > > > >>> 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: > > > >>>> "REQ-017 The mechanism MUST support a means for a UA > > > >>> involved in a CS to request that the CS not be recorded." > > > >>> > > > >>> 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) > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >>>>> Sent: 04 February 2011 16:40 > > > >>>>> To: Elwell, John > > > >>>>> Cc: Dave Smith; Ken Rehor (krehor); siprec@ietf.org; > > > >> Alissa Cooper > > > >>>>> Subject: Re: [siprec] Proposed change to REQ-017 concerning > > > >>>>> cancellation > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On 2/4/2011 2:22 AM, Elwell, John wrote: > > > >>>>>> 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? > > > >>>>> > > > >>>>> 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: > > > >>>>> > > > >>>>> 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 > > > >>>>> > > > >>>>> 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 > > > >>>>> > > > >>> > > > >> > > > >> > > > >> -------------------------------------------------------------- > > > >> ----------------------------------------------------- > > > >> 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 > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > From partr@cisco.com Tue Feb 15 18:53:17 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4E23A6C47 for ; Tue, 15 Feb 2011 18:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.401 X-Spam-Level: X-Spam-Status: No, score=-9.401 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTGQGx-Lb+kD for ; Tue, 15 Feb 2011 18:53:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 12C473A6B77 for ; Tue, 15 Feb 2011 18:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=7371; q=dns/txt; s=amsiport01001; t=1297824823; x=1299034423; h=mime-version:subject:date:message-id:references:from:to: cc; bh=N3zfFCrnjxPf9gEFLKQ5bF6iwt9kkbjhvaNLAnjBNqw=; b=J/9xI0ovJz1CHNIfQs8YpCLUhxqaKWsxxTp6yH3FhvMQnccJzzqOQLnQ uX/06uT6SiCU9+ahIKy/mJqpo+QHjJ9D3DaBM9DbFHa/X3aZLPjU4dXJF 9xicUSTM0dZg6k+r/wbSZOGax0zZ6JtK+h6EboFpR+wpWgYLC7zPxBF9r Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8DAI/LWk2Q/khMgWdsb2JhbACdSwGHMWUVAQEWIiShcptmhV4EhQSKPg X-IronPort-AV: E=Sophos;i="4.60,478,1291593600"; d="scan'208,217";a="76397697" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2011 02:53:32 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1G2rVYZ015458; Wed, 16 Feb 2011 02:53:31 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 08:23:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBCD84.B17670D8" Date: Wed, 16 Feb 2011 08:20:39 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Requirements #63 (new): REQ-015/REQ-016 anddiscarding recordings Thread-Index: AcvM5r1fW0L05sYVThKsdYo/eRJE+AAAyfOQACaZnKE= References: <075.13fa3cf5cb60742d46f34fcd19b8f580@tools.ietf.org> From: "Parthasarathi R (partr)" To: "Elwell, John" , "siprec issue tracker" , X-OriginalArrivalTime: 16 Feb 2011 02:53:31.0173 (UTC) FILETIME=[B1C02D50:01CBCD84] Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 02:53:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCD84.B17670D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm also fine with deleting REQ-015 and REQ-016 based on ticket #63 and = #64.=20 =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Elwell, John Sent: Tue 2/15/2011 1:58 PM To: siprec issue tracker; leon.portman@nice.com Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and = discarding recordings Concerning past discussions on retention of recordings being a policy = matter for the SRS, I believe we do not need any requirement concerning = the ability to request that recordings be discarded. Depending also on = the resolution of #64, I believe REQ-015 and REQ-016 can be deleted. John (as individual) > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org] > Sent: 15 February 2011 08:03 > To: leon.portman@nice.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and > discarding recordings > > #63: REQ-015/REQ-016 and discarding recordings > > Do we need any requirement concerning a participant's > ability to request > the discarding of a cancelled recording? If not, can we > remove that part > of REQ-015/016 to do with discarding a recording? > > John > > -- > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: leon.portman@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > -------------- > > Ticket URL: > siprec > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBCD84.B17670D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [siprec] Requirements #63 (new): = REQ-015/REQ-016 and discarding recordings=0A= =0A= =0A= =0A=
=0A=
I'm also fine = with deleting REQ-015 and REQ-016 based on ticket #63 and #64. =
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=
=0A=
=0A=
=0A=
From: = siprec-bounces@ietf.org on behalf of Elwell, John
Sent: Tue = 2/15/2011 1:58 PM
To: siprec issue tracker; = leon.portman@nice.com
Cc: siprec@ietf.org
Subject: = Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding = recordings

=0A=
=0A=

Concerning past discussions on retention of recordings = being a policy matter for the SRS, I believe we do not need any = requirement concerning the ability to request that recordings be = discarded. Depending also on the resolution of #64, I believe REQ-015 = and REQ-016 can be deleted.

John (as individual)


> = -----Original Message-----
> From: siprec issue tracker [mailto:trac@tools.ietf.org]
&g= t; Sent: 15 February 2011 08:03
> To: leon.portman@nice.com; = Elwell, John
> Cc: siprec@ietf.org
> Subject: [siprec] = Requirements #63 (new): REQ-015/REQ-016 and
> discarding = recordings
>
> #63: REQ-015/REQ-016 and discarding = recordings
>
>  Do we need any requirement concerning a = participant's
> ability to request
>  the discarding of = a cancelled recording? If not, can we
> remove that = part
>  of REQ-015/016 to do with discarding a = recording?
>
>  John
>
> --
> = ------------------------------------------------+-------------
> = --------------
>  Reporter:  = john.elwell@...         &nbs= p;            = ; |      
> Owner:  = leon.portman@...      
>  &= nbsp;   Type:  = defect           &= nbsp;           &n= bsp;      = |     
> Status:  = new           &nbs= p;     
>  Priority:  = major           &n= bsp;           &nb= sp;       |  
> = Milestone:          &nb= sp;           
= > Component:  = Requirements          &= nbsp;           &n= bsp; |    
> = Version:           = ;           
&g= t;  Severity:  In WG Last = Call           &nb= sp;         = |   
> = Keywords:          &nbs= p;           
&= gt; = ------------------------------------------------+-------------
> = --------------
>
> Ticket URL: <http://trac.= tools.ietf.org/wg/siprec/trac/ticket/63>
> siprec <http://tools.ietf.org/siprec/&= gt;
>
>
_______________________________________________siprec mailing list
siprec@ietf.org
https://www.ietf.or= g/mailman/listinfo/siprec

------_=_NextPart_001_01CBCD84.B17670D8-- From acooper@cdt.org Fri Feb 18 09:56:05 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145153A6CF3 for ; Fri, 18 Feb 2011 09:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+DoX5HhLOhv for ; Fri, 18 Feb 2011 09:56:04 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 06E143A6D71 for ; Fri, 18 Feb 2011 09:56:03 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 18 Feb 2011 12:56:02 -0500 Message-Id: From: Alissa Cooper To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 18 Feb 2011 17:56:01 +0000 References: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: "siprec@ietf.org" , siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension of REQ-017 concerning preference to record/not record X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:56:05 -0000 On Feb 15, 2011, at 8:34 AM, Elwell, John wrote: > I think we need to cover the following cases: > - 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. +1 > > 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). Seems like both might be useful, but I have no strong opinion here. Alissa > > John (as individual) > > >> -----Original Message----- >> From: siprec issue tracker [mailto:trac@tools.ietf.org] >> Sent: 15 February 2011 08:21 >> To: krehor@cisco.com; Elwell, John >> Cc: siprec@ietf.org >> Subject: [siprec] Requirements #65 (new): Extension of >> REQ-017 concerning preference to record/not record >> >> #65: Extension of REQ-017 concerning preference to record/not record >> >> We have "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". >> >> Should this be extended to cover a request during a CS, and also the >> ability during a CS to request that recording be allowed? In >> other words, >> the ability for a participant to indicate a preference for >> recording or >> not recording, at the start of a CS or during a CS. Note that such a >> requirement would be realisable only from a siprec-aware UA. >> >> This is related to REQ-011 (pause/resume), but with the >> difference that it >> is the participant who expresses the preference (REQ-011 >> seems to imply >> the SRC decides). So in considering any possible rewording >> of REQ-017, we >> should perhaps consider its relationship to REQ-011. >> >> John >> >> -- >> ------------------------------------------------+------------- >> -------------- >> Reporter: john.elwell@... | >> Owner: krehor@... >> Type: defect | >> Status: new >> Priority: major | >> Milestone: >> Component: Requirements | >> Version: >> Severity: In WG Last Call | >> Keywords: >> ------------------------------------------------+------------- >> -------------- >> >> Ticket URL: >> siprec >> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Leon.Portman@nice.com Sun Feb 20 05:09:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74133A6FC9 for ; Sun, 20 Feb 2011 05:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcsAS6v2Jhog for ; Sun, 20 Feb 2011 05:09:08 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 362C03A6FAB for ; Sun, 20 Feb 2011 05:09:07 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 20 Feb 2011 15:09:45 +0200 From: Leon Portman To: "Parthasarathi R (partr)" , "Elwell, John" , siprec issue tracker Date: Sun, 20 Feb 2011 15:09:44 +0200 Thread-Topic: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings Thread-Index: AcvM5r1fW0L05sYVThKsdYo/eRJE+AAAyfOQACaZnKEA3sjJYA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38A697AEC0@TLVMBX01.nice.com> References: <075.13fa3cf5cb60742d46f34fcd19b8f580@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38A697AEC0TLVMBX01nicec_" MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 13:09:09 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38A697AEC0TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Leon From: Parthasarathi R (partr) [mailto:partr@cisco.com] Sent: Wednesday, February 16, 2011 4:51 AM To: Elwell, John; siprec issue tracker; Leon Portman Cc: siprec@ietf.org Subject: RE: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardin= g recordings I'm also fine with deleting REQ-015 and REQ-016 based on ticket #63 and #64= . Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Elwell, John Sent: Tue 2/15/2011 1:58 PM To: siprec issue tracker; leon.portman@nice.com Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardin= g recordings Concerning past discussions on retention of recordings being a policy matte= r for the SRS, I believe we do not need any requirement concerning the abil= ity to request that recordings be discarded. Depending also on the resoluti= on of #64, I believe REQ-015 and REQ-016 can be deleted. John (as individual) > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org] > Sent: 15 February 2011 08:03 > To: leon.portman@nice.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and > discarding recordings > > #63: REQ-015/REQ-016 and discarding recordings > > Do we need any requirement concerning a participant's > ability to request > the discarding of a cancelled recording? If not, can we > remove that part > of REQ-015/016 to do with discarding a recording? > > John > > -- > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | > Owner: leon.portman@... > Type: defect | > Status: new > Priority: major | > Milestone: > Component: Requirements | > Version: > Severity: In WG Last Call | > Keywords: > ------------------------------------------------+------------- > -------------- > > Ticket URL: > siprec > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec --_000_07465C1D981ABC41A344374066AE1A2C38A697AEC0TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [siprec] Requirements #63 (new): REQ-015/REQ= -016 and discarding recordings

+1

 

Leon

 

From: Parth= asarathi R (partr) [mailto:partr@cisco.com]
Sent: Wednesday, Feb= ruary 16, 2011 4:51 AM
To: Elwell, John; siprec issue tracker; Le= on Portman
Cc: siprec@ietf.org
Subject: RE: [siprec] Re= quirements #63 (new): REQ-015/REQ-016 and discarding recordings<= /span>

 

I'm also fine with deleting= REQ-015 and REQ-016 based on ticket #63 and #64.

 

Th= anks

Partha

From: siprec-bounces@ietf.org on beh= alf of Elwell, John
Sent: Tue 2/15/2011 1:58 PM
To: sip= rec issue tracker; leon.portman@nice.com
Cc: siprec@ietf.org
<= b>Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and dis= carding recordings

Concerning past discussions on retention of recordings be= ing a policy matter for the SRS, I believe we do not need any requirement c= oncerning the ability to request that recordings be discarded. Depending al= so on the resolution of #64, I believe REQ-015 and REQ-016 can be deleted.<= br>
John (as individual)


> -----Original Message-----
&= gt; From: siprec issue tracker [mail= to:trac@tools.ietf.org]
> Sent: 15 February 2011 08:03
> To= : leon.portman@nice.com; Elwel= l, John
> Cc: siprec@ietf.org<= br>> Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and
&g= t; discarding recordings
>
> #63: REQ-015/REQ-016 and discardin= g recordings
>
>  Do we need any requirement concerning a = participant's
> ability to request
>  the discarding of a = cancelled recording? If not, can we
> remove that part
>  = of REQ-015/016 to do with discarding a recording?
>
>  Joh= n
>
> --
> ----------------------------------------------= --+-------------
> --------------
>  Reporter:  john.elwell@...     = ;            &n= bsp;     |      
> = Owner:  leon.portman@... &nb= sp;    
>      Type:&nbs= p; defect           =             &nb= sp;      |     
> S= tatus:  new          = ;       
>  Priority:  m= ajor            = ;            &n= bsp;      |  
> Milestone: &n= bsp;            = ;        
> Component:  = Requirements          &nb= sp;            = |    
> Version:     &n= bsp;            = ;    
>  Severity:  In WG Last Call&nbs= p;            &= nbsp;       |   
> Keywo= rds:            = ;          
> -----= -------------------------------------------+-------------
> ---------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket= /63>
> siprec <ht= tp://tools.ietf.org/siprec/>
>
>
____________________= ___________________________
siprec mailing list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec<= o:p>

= --_000_07465C1D981ABC41A344374066AE1A2C38A697AEC0TLVMBX01nicec_-- From Leon.Portman@nice.com Sun Feb 20 05:10:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A99A3A6FC9 for ; Sun, 20 Feb 2011 05:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-EfvzcpSqJP for ; Sun, 20 Feb 2011 05:10:30 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id E6AE13A6FAC for ; Sun, 20 Feb 2011 05:10:27 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 20 Feb 2011 15:11:06 +0200 From: Leon Portman To: Alissa Cooper , "Elwell, John" Date: Sun, 20 Feb 2011 15:11:05 +0200 Thread-Topic: [siprec] Requirements #65 (new): Extension of REQ-017 concerning preference to record/not record Thread-Index: AcvPlTtzsLrany/MSpm4wxMDal8zSwBakLPg Message-ID: <07465C1D981ABC41A344374066AE1A2C38A697AEC1@TLVMBX01.nice.com> References: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" , siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension of REQ-017 concerning preference to record/not record X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 13:10:31 -0000 +1 We need both pause and stop. In both cases SRS need to know when CS is ende= d. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Alissa Cooper Sent: Friday, February 18, 2011 7:56 PM To: Elwell, John Cc: siprec@ietf.org; siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension of REQ-017 concerni= ng preference to record/not record On Feb 15, 2011, at 8:34 AM, Elwell, John wrote: > I think we need to cover the following cases: > - 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. +1 > > Concerning discontinuation, we could discuss whether this means stop=20 > or pause. With pause, you could later resume that same recording. > With stop, you would effectively terminate the recording, such that=20 > you would need to start a new recording if you need to record later=20 > during the CS. The handling of metadata would differ - in the first=20 > case the metadata might tell you when the CS ends (as well as when=20 > recording is paused) - with the second case it might tell you when=20 > recording is stopped and nothing beyond that. I don't know which of=20 > these we want (perhaps both). Seems like both might be useful, but I have no strong opinion here. Alissa > > John (as individual) > > >> -----Original Message----- >> From: siprec issue tracker [mailto:trac@tools.ietf.org] >> Sent: 15 February 2011 08:21 >> To: krehor@cisco.com; Elwell, John >> Cc: siprec@ietf.org >> Subject: [siprec] Requirements #65 (new): Extension of >> REQ-017 concerning preference to record/not record >> >> #65: Extension of REQ-017 concerning preference to record/not record >> >> We have "REQ-017 The mechanism MUST support a means for an authorized=20 >> participant involved in a CS to request, prior to the start of=20 >> recording, that the CS not be recorded". >> >> Should this be extended to cover a request during a CS, and also the=20 >> ability during a CS to request that recording be allowed? In other=20 >> words, the ability for a participant to indicate a preference for=20 >> recording or not recording, at the start of a CS or during a CS. Note=20 >> that such a requirement would be realisable only from a siprec-aware=20 >> UA. >> >> This is related to REQ-011 (pause/resume), but with the difference=20 >> that it is the participant who expresses the preference (REQ-011=20 >> seems to imply the SRC decides). So in considering any possible=20 >> rewording of REQ-017, we should perhaps consider its relationship to=20 >> REQ-011. >> >> John >> >> -- >> ------------------------------------------------+------------- >> -------------- >> Reporter: john.elwell@... | >> Owner: krehor@... >> Type: defect | >> Status: new >> Priority: major | >> Milestone: >> Component: Requirements | >> Version: >> Severity: In WG Last Call | >> Keywords: >> ------------------------------------------------+------------- >> -------------- >> >> Ticket URL: >> siprec >> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Dave.d.Smith@alcatel-lucent.com Sun Feb 20 09:08:25 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D98C3A6CCA for ; Sun, 20 Feb 2011 09:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb+FWQKVbbOp for ; Sun, 20 Feb 2011 09:08:24 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 3638D3A6AA7 for ; Sun, 20 Feb 2011 09:08:24 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p1KH90hu009016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Feb 2011 11:09:00 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1KH8vYb022408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Feb 2011 11:08:59 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p1KH8uHP017823; Sun, 20 Feb 2011 09:08:56 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Feb 2011 09:08:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD120.DB9BBF2B" Date: Sun, 20 Feb 2011 09:08:57 -0800 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A697AEC0@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings Thread-Index: AcvM5r1fW0L05sYVThKsdYo/eRJE+AAAyfOQACaZnKEA3sjJYAAIVnHQ References: <075.13fa3cf5cb60742d46f34fcd19b8f580@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A697AEC0@TLVMBX01.nice.com> From: "Dave Smith" To: "Leon Portman" , "Parthasarathi R (partr)" , "Elwell, John" , "siprec issue tracker" X-OriginalArrivalTime: 20 Feb 2011 17:08:56.0593 (UTC) FILETIME=[DBBCC010:01CBD120] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 17:08:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD120.DB9BBF2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 Dave =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Sunday, February 20, 2011 5:10 AM To: Parthasarathi R (partr); Elwell, John; siprec issue tracker Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings =20 +1 =20 Leon =20 From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 Sent: Wednesday, February 16, 2011 4:51 AM To: Elwell, John; siprec issue tracker; Leon Portman Cc: siprec@ietf.org Subject: RE: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings =20 I'm also fine with deleting REQ-015 and REQ-016 based on ticket #63 and #64.=20 =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Elwell, John Sent: Tue 2/15/2011 1:58 PM To: siprec issue tracker; leon.portman@nice.com Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings Concerning past discussions on retention of recordings being a policy matter for the SRS, I believe we do not need any requirement concerning the ability to request that recordings be discarded. Depending also on the resolution of #64, I believe REQ-015 and REQ-016 can be deleted. John (as individual) > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org] > Sent: 15 February 2011 08:03 > To: leon.portman@nice.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and > discarding recordings > > #63: REQ-015/REQ-016 and discarding recordings > > Do we need any requirement concerning a participant's > ability to request > the discarding of a cancelled recording? If not, can we > remove that part > of REQ-015/016 to do with discarding a recording? > > John > > -- > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: leon.portman@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > -------------- > > Ticket URL: > siprec > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CBD120.DB9BBF2B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardin= g recordings

+1

 

Dave

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Leon Portman
Sent: Sunday, February 20, 2011 5:10 AM
To: Parthasarathi R (partr); Elwell, John; siprec issue tracker Cc: siprec@ietf.org
Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings

 

+1

 

Leon

 

From: Parthasarat= hi R (partr) [mailto:partr@cisco.com]
Sent: Wednesday, February 16, 2011 4:51 AM
To: Elwell, John; siprec issue tracker; Leon Portman
Cc: siprec@ietf.org
Subject: RE: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings

 

I'm also fine with deleting REQ-015 and REQ-016 based on tic= ket #63 and #64.

 

Thanks

Partha

From: siprec-bounces@ietf.org on behalf of Elwell, John
Sent: Tue 2/15/2011 1:58 PM
To: siprec issue tracker; leon.portman@nice.com
Cc: siprec@ietf.org
Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings

Concerning past discussions on retent= ion of recordings being a policy matter for the SRS, I believe we do not need an= y requirement concerning the ability to request that recordings be discarde= d. Depending also on the resolution of #64, I believe REQ-015 and REQ-016 ca= n be deleted.

John (as individual)


> -----Original Message-----
> From: siprec issue tracker [m= ailto:trac@tools.ietf.org]
> Sent: 15 February 2011 08:03
> To: leon.portman@nice.com; Elwell, John
> Cc: siprec@ietf.org
> Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and
> discarding recordings
>
> #63: REQ-015/REQ-016 and discarding recordings
>
>  Do we need any requirement concerning a participant's
> ability to request
>  the discarding of a cancelled recording? If not, can we
> remove that part
>  of REQ-015/016 to do with discarding a recording?
>
>  John
>
> --
> ------------------------------------------------+-------------
> --------------
>  Reporter:  john.elwell@...           &n= bsp;           |      
> Owner:  leon.portman@...&n= bsp;     
>      Type:  defect           &= nbsp;           &n= bsp;      |     
> Status:  new           &nbs= p;     
>  Priority:  major           &n= bsp;           &nb= sp;       |  
> Milestone:          &nb= sp;           
= > Component:  Requirements          &= nbsp;           &n= bsp; |    
> Version:           = ;           
>  Severity:  In WG Last Call           &nb= sp;         |   
> Keywords:          &nbs= p;           
> ------------------------------------------------+-------------
> --------------
>
> Ticket URL: <http://trac.= tools.ietf.org/wg/siprec/trac/ticket/63>
> siprec <http://tools.ie= tf.org/siprec/>
>
>
_______________________________________________
siprec mailing list
siprec@ietf.org
https://www.ietf= =2Eorg/mailman/listinfo/siprec

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CBD120.DB9BBF2B-- From Dave.d.Smith@alcatel-lucent.com Sun Feb 20 09:22:53 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC383A6CCA for ; Sun, 20 Feb 2011 09:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oefF8q1DP+OE for ; Sun, 20 Feb 2011 09:22:52 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id EDA373A6C68 for ; Sun, 20 Feb 2011 09:22:51 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p1KHNDgT014001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Feb 2011 11:23:13 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1KHNACK015242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Feb 2011 11:23:12 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p1KHN8uV018670; Sun, 20 Feb 2011 09:23:08 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Feb 2011 09:23:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Feb 2011 09:23:09 -0800 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A697AEC1@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Requirements #65 (new): Extension ofREQ-017 concerning preference to record/not record Thread-Index: AcvPlTtzsLrany/MSpm4wxMDal8zSwBakLPgAAhh7VA= References: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A697AEC1@TLVMBX01.nice.com> From: "Dave Smith" To: "Leon Portman" , "Alissa Cooper" , "Elwell, John" X-OriginalArrivalTime: 20 Feb 2011 17:23:08.0045 (UTC) FILETIME=[D73E03D0:01CBD122] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: siprec@ietf.org, siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension ofREQ-017 concerning preference to record/not record X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 17:22:53 -0000 +1, except I'd hope we could simplify this to one or the other (pause or stop), not both, but I'm not sure which one is best. =20 Regards, Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Sunday, February 20, 2011 5:11 AM To: Alissa Cooper; Elwell, John Cc: siprec@ietf.org; siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension ofREQ-017 concerning preference to record/not record +1 We need both pause and stop. In both cases SRS need to know when CS is ended. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Friday, February 18, 2011 7:56 PM To: Elwell, John Cc: siprec@ietf.org; siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension of REQ-017 concerning preference to record/not record On Feb 15, 2011, at 8:34 AM, Elwell, John wrote: > I think we need to cover the following cases: > - 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. +1 > > Concerning discontinuation, we could discuss whether this means stop=20= > or pause. With pause, you could later resume that same recording. > With stop, you would effectively terminate the recording, such that=20 > you would need to start a new recording if you need to record later=20 > during the CS. The handling of metadata would differ - in the first=20 > case the metadata might tell you when the CS ends (as well as when=20 > recording is paused) - with the second case it might tell you when=20 > recording is stopped and nothing beyond that. I don't know which of=20 > these we want (perhaps both). Seems like both might be useful, but I have no strong opinion here. Alissa > > John (as individual) > > >> -----Original Message----- >> From: siprec issue tracker [mailto:trac@tools.ietf.org] >> Sent: 15 February 2011 08:21 >> To: krehor@cisco.com; Elwell, John >> Cc: siprec@ietf.org >> Subject: [siprec] Requirements #65 (new): Extension of >> REQ-017 concerning preference to record/not record >> >> #65: Extension of REQ-017 concerning preference to record/not record >> >> We have "REQ-017 The mechanism MUST support a means for an authorized >> participant involved in a CS to request, prior to the start of=20 >> recording, that the CS not be recorded". >> >> Should this be extended to cover a request during a CS, and also the=20= >> ability during a CS to request that recording be allowed? In other=20 >> words, the ability for a participant to indicate a preference for=20 >> recording or not recording, at the start of a CS or during a CS. Note >> that such a requirement would be realisable only from a siprec-aware=20= >> UA. >> >> This is related to REQ-011 (pause/resume), but with the difference=20 >> that it is the participant who expresses the preference (REQ-011=20 >> seems to imply the SRC decides). So in considering any possible=20 >> rewording of REQ-017, we should perhaps consider its relationship to=20= >> REQ-011. >> >> John >> >> -- >> ------------------------------------------------+------------- >> -------------- >> Reporter: john.elwell@... | >> Owner: krehor@... >> Type: defect | >> Status: new >> Priority: major | >> Milestone: >> Component: Requirements | >> Version: >> Severity: In WG Last Call | >> Keywords: >> ------------------------------------------------+------------- >> -------------- >> >> Ticket URL: >> siprec >> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From Henry.Lum@alcatel-lucent.com Tue Feb 22 07:08:27 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0507F3A68E7 for ; Tue, 22 Feb 2011 07:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1X4-aqwtp1V for ; Tue, 22 Feb 2011 07:08:26 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id DC8F83A689C for ; Tue, 22 Feb 2011 07:08:25 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p1MF8m9s013573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Feb 2011 09:08:49 -0600 (CST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1MF8jFe019296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2011 09:08:46 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p1MF8hMe018309; Tue, 22 Feb 2011 07:08:44 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 07:08:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 07:08:41 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406B18708@NAHALD.us.int.genesyslab.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A697AEC1@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Requirements #65 (new): Extension ofREQ-017 concerning preference to record/not record Thread-Index: AcvPlTtzsLrany/MSpm4wxMDal8zSwBakLPgAGi5IJA= References: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A697AEC1@TLVMBX01.nice.com> From: "Henry Lum" To: "Leon Portman" , "Alissa Cooper" , "Elwell, John" X-OriginalArrivalTime: 22 Feb 2011 15:08:43.0830 (UTC) FILETIME=[656BF560:01CBD2A2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: siprec@ietf.org, siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension ofREQ-017 concerning preference to record/not record X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 15:08:27 -0000 +1 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Sunday, February 20, 2011 8:11 AM > To: Alissa Cooper; Elwell, John > Cc: siprec@ietf.org; siprec issue tracker > Subject: Re: [siprec] Requirements #65 (new): Extension ofREQ-017 > concerning preference to record/not record >=20 > +1 >=20 > We need both pause and stop. In both cases SRS need to know when CS is > ended. >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Alissa Cooper > Sent: Friday, February 18, 2011 7:56 PM > To: Elwell, John > Cc: siprec@ietf.org; siprec issue tracker > Subject: Re: [siprec] Requirements #65 (new): Extension of REQ-017 > concerning preference to record/not record >=20 > On Feb 15, 2011, at 8:34 AM, Elwell, John wrote: >=20 > > I think we need to cover the following cases: > > - 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. >=20 > +1 >=20 > > > > 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). >=20 > Seems like both might be useful, but I have no strong opinion here. >=20 > Alissa >=20 > > > > John (as individual) > > > > > >> -----Original Message----- > >> From: siprec issue tracker [mailto:trac@tools.ietf.org] > >> Sent: 15 February 2011 08:21 > >> To: krehor@cisco.com; Elwell, John > >> Cc: siprec@ietf.org > >> Subject: [siprec] Requirements #65 (new): Extension of > >> REQ-017 concerning preference to record/not record > >> > >> #65: Extension of REQ-017 concerning preference to record/not record > >> > >> We have "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". > >> > >> Should this be extended to cover a request during a CS, and also the > >> ability during a CS to request that recording be allowed? In other > >> words, the ability for a participant to indicate a preference for > >> recording or not recording, at the start of a CS or during a CS. > Note > >> that such a requirement would be realisable only from a siprec-aware > >> UA. > >> > >> This is related to REQ-011 (pause/resume), but with the difference > >> that it is the participant who expresses the preference (REQ-011 > >> seems to imply the SRC decides). So in considering any possible > >> rewording of REQ-017, we should perhaps consider its relationship to > >> REQ-011. > >> > >> John > >> > >> -- > >> ------------------------------------------------+------------- > >> -------------- > >> Reporter: john.elwell@... | > >> Owner: krehor@... > >> Type: defect | > >> Status: new > >> Priority: major | > >> Milestone: > >> Component: Requirements | > >> Version: > >> Severity: In WG Last Call | > >> Keywords: > >> ------------------------------------------------+------------- > >> -------------- > >> > >> Ticket URL: > >> siprec > >> > >> > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From Henry.Lum@alcatel-lucent.com Tue Feb 22 07:08:47 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874473A68E7 for ; Tue, 22 Feb 2011 07:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adhu8SMumuaV for ; Tue, 22 Feb 2011 07:08:46 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6D8053A68A2 for ; Tue, 22 Feb 2011 07:08:46 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p1MF9ThN009339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Feb 2011 09:09:29 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1MF9SkU031704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2011 09:09:29 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p1MF9SKU016045; Tue, 22 Feb 2011 07:09:28 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 07:09:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD2A2.7EB3C634" Date: Tue, 22 Feb 2011 07:09:25 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406B18709@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardingrecordings Thread-Index: AcvM5r1fW0L05sYVThKsdYo/eRJE+AAAyfOQACaZnKEBR4vsYA== References: <075.13fa3cf5cb60742d46f34fcd19b8f580@tools.ietf.org> From: "Henry Lum" To: "Parthasarathi R (partr)" , "Elwell, John" , "siprec issue tracker" , X-OriginalArrivalTime: 22 Feb 2011 15:09:26.0924 (UTC) FILETIME=[7F1B94C0:01CBD2A2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardingrecordings X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 15:08:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD2A2.7EB3C634 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, February 15, 2011 9:51 PM To: Elwell, John; siprec issue tracker; leon.portman@nice.com Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardingrecordings =20 I'm also fine with deleting REQ-015 and REQ-016 based on ticket #63 and #64.=20 =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Elwell, John Sent: Tue 2/15/2011 1:58 PM To: siprec issue tracker; leon.portman@nice.com Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discarding recordings Concerning past discussions on retention of recordings being a policy matter for the SRS, I believe we do not need any requirement concerning the ability to request that recordings be discarded. Depending also on the resolution of #64, I believe REQ-015 and REQ-016 can be deleted. John (as individual) > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org] > Sent: 15 February 2011 08:03 > To: leon.portman@nice.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and > discarding recordings > > #63: REQ-015/REQ-016 and discarding recordings > > Do we need any requirement concerning a participant's > ability to request > the discarding of a cancelled recording? If not, can we > remove that part > of REQ-015/016 to do with discarding a recording? > > John > > -- > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: leon.portman@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > -------------- > > Ticket URL: > siprec > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CBD2A2.7EB3C634 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardin= g recordings

+1

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Tuesday, February 15, 2011 9:51 PM
To: Elwell, John; siprec issue tracker; leon.portman@nice.com
Cc: siprec@ietf.org
Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and discardingrecordings

 

I'm also fine with deleting REQ-015 and REQ-016 based on tic= ket #63 and #64.

 

Thanks

Partha

From: siprec-bounces@ietf.org on behalf of Elwell, John
Sent: Tue 2/15/2011 1:58 PM
To: siprec issue tracker; leon.portman@nice.com
Cc: siprec@ietf.org
Subject: Re: [siprec] Requirements #63 (new): REQ-015/REQ-016 and = discarding recordings

Concerning past discussions on retent= ion of recordings being a policy matter for the SRS, I believe we do not need an= y requirement concerning the ability to request that recordings be discarde= d. Depending also on the resolution of #64, I believe REQ-015 and REQ-016 ca= n be deleted.

John (as individual)


> -----Original Message-----
> From: siprec issue tracker [m= ailto:trac@tools.ietf.org]
> Sent: 15 February 2011 08:03
> To: leon.portman@nice.com; Elwell, John
> Cc: siprec@ietf.org
> Subject: [siprec] Requirements #63 (new): REQ-015/REQ-016 and
> discarding recordings
>
> #63: REQ-015/REQ-016 and discarding recordings
>
>  Do we need any requirement concerning a participant's
> ability to request
>  the discarding of a cancelled recording? If not, can we
> remove that part
>  of REQ-015/016 to do with discarding a recording?
>
>  John
>
> --
> ------------------------------------------------+-------------
> --------------
>  Reporter:  john.elwell@...     &= nbsp;           &n= bsp;     |      
> Owner:  leon.portman@...       >      Type:  defect           &= nbsp;           &n= bsp;      |     
> Status:  new           &nbs= p;     
>  Priority:  major           &n= bsp;           &nb= sp;       |  
> Milestone:          &nb= sp;           
= > Component:  Requirements          &= nbsp;           &n= bsp; |    
> Version:           = ;           
>  Severity:  In WG Last Call           &nb= sp;         |   
> Keywords:          &nbs= p;           
> ------------------------------------------------+-------------
> --------------
>
> Ticket URL: <http://trac.= tools.ietf.org/wg/siprec/trac/ticket/63>
> siprec <http://tools.ie= tf.org/siprec/>
>
>
_______________________________________________
siprec mailing list
siprec@ietf.org
https://www.ietf= =2Eorg/mailman/listinfo/siprec

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CBD2A2.7EB3C634-- From Leon.Portman@nice.com Wed Feb 23 09:19:35 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34083A690A for ; Wed, 23 Feb 2011 09:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVHFKpXhNNjo for ; Wed, 23 Feb 2011 09:19:35 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id A10B33A67A1 for ; Wed, 23 Feb 2011 09:19:34 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 23 Feb 2011 19:20:20 +0200 From: Leon Portman To: "Elwell, John" , siprec issue tracker Date: Wed, 23 Feb 2011 19:20:18 +0200 Thread-Topic: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancelling a recording Thread-Index: AcvM5yx8db2rSuMRR8i7RWhgEqXmLQAAyekgAaSy6AA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38A78FCD5E@TLVMBX01.nice.com> References: <075.d0db8f34c277334b137156e493ae53f5@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancelling a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 17:19:36 -0000 I am not very comfortable of treating pausing of the recording as a canceli= ng of the recording. Pausing of the recording usually will keep recording c= hannel allocated and not available for other recordings until end of the ca= ll. Canceling/stopping recording will release the channel. So I may be we need a requirement for just stopping recording, like this: "The mechanism MUST support a means to stop the recording". I remember tha= t we have multiple discussion about it The actual request of discarding of the recording media and metadata is out= of scope and should be handled by policy server (Ticket #63) Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Tuesday, February 15, 2011 10:31 AM To: siprec issue tracker; Leon Portman Cc: siprec@ietf.org Subject: RE: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancellin= g a recording I think we don't need a special requirement on cancelling, given the existe= nce of REQ-011 on pause/resume and REQ-017 on requesting no recording. Depe= nding on the resolution of ticket #63, I believe REQ-015 and REQ-016 can be= deleted. John (as individual)=20 > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org] > Sent: 15 February 2011 08:06 > To: leon.portman@nice.com; Elwell, John > Cc: siprec@ietf.org > Subject: [siprec] Requirements #64 (new): REQ-015/REQ-016 and=20 > cancelling a recording >=20 > #64: REQ-015/REQ-016 and cancelling a recording >=20 > Do we need any requirement concerning cancelling a recording? We=20 > already have REQ-011 on pausing and resuming, and pausing without=20 > subsequently resuming can probably be considered to be cancelling the=20 > recording. If the resolution of ticket #63 results in no requirement=20 > for discarding a recording, and if REQ-011 is considered to cover=20 > cancelling a recording, can REQ-015 and REQ-016 be removed entirely? >=20 > John >=20 > -- > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: leon.portman@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > -------------- >=20 > Ticket URL: > siprec >=20 >=20 From Leon.Portman@nice.com Wed Feb 23 09:24:21 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193543A68C5 for ; Wed, 23 Feb 2011 09:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJa+vYUevVLB for ; Wed, 23 Feb 2011 09:24:20 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id D18703A67A1 for ; Wed, 23 Feb 2011 09:24:19 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 23 Feb 2011 19:25:06 +0200 From: Leon Portman To: siprec issue tracker , "john.elwell@siemens-enterprise.com" Date: Wed, 23 Feb 2011 19:25:05 +0200 Thread-Topic: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants Thread-Index: AcvM6cpYQ57UUrunTBCS241IKWnf7AGlK6Vw Message-ID: <07465C1D981ABC41A344374066AE1A2C38A78FCD61@TLVMBX01.nice.com> References: <075.d9e0afcd7cf3ee35c38905ea3efdd6c9@tools.ietf.org> In-Reply-To: <075.d9e0afcd7cf3ee35c38905ea3efdd6c9@tools.ietf.org> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 17:24:21 -0000 QmVjYXVzZSBzdXBwb3J0aW5nIG9mIHNpcHJlYy1hd2FyZSBVQSBpbmRpY2F0aW9uIHdpbGwgcmVx dWlyZSBzb21lIGFkZGl0aW9uYWwgcHJvdG9jb2wgY2hhbmdlcyBmb3IgQ1MsIHdlIHByb2JhYmx5 IHNob3VsZCBoYXZlIGEgc2VwYXJhdGUgcmVxdWlyZW1lbnQgZm9yIHRoYXQNCg0KTGVvbg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2lwcmVjIGlzc3VlIHRyYWNrZXIgW21h aWx0bzp0cmFjQHRvb2xzLmlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE1LCAy MDExIDEwOjI0IEFNDQpUbzogTGVvbiBQb3J0bWFuOyBqb2huLmVsd2VsbEBzaWVtZW5zLWVudGVy cHJpc2UuY29tDQpDYzogc2lwcmVjQGlldGYub3JnDQpTdWJqZWN0OiBbc2lwcmVjXSBSZXF1aXJl bWVudHMgIzY2IChuZXcpOiBDbGFyaWZpY2F0aW9uIG9mIFJFUS0wMTggb24gaW5kaWNhdGlvbnMg dG8gcGFydGljaXBhbnRzDQoNCiM2NjogQ2xhcmlmaWNhdGlvbiBvZiBSRVEtMDE4IG9uIGluZGlj YXRpb25zIHRvIHBhcnRpY2lwYW50cw0KDQogUkVRLTAxOCBjYW4gYmUgc2F0aXNmaWVkIGluIGdl bmVyYWwgYnkgcGxheWluZyBtZWRpYSB0byBwYXJ0aWNpcGFudHMsIGJ1dCAgZG8gd2UgbmVlZCBh IG1vcmUgc3BlY2lmaWMgcmVxdWlyZW1lbnQsIGUuZy4sIGZvciBzaXByZWMtYXdhcmUgVUFzIHRv IGtub3cgIHdoZXRoZXIgdGhlIENTIGlzIGJlaW5nIHJlY29yZGVkIG9yIG5vdD8NCg0KIEpvaG4N Cg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tDQogUmVwb3J0ZXI6ICBqb2huLmVsd2VsbEDigKYgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgT3duZXI6ICBsZW9uLnBvcnRtYW5A4oCmICAgICAgIA0K ICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldyAgICAgICAgICAgICAgICAgIA0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgICAgICAgICAgICAgICAgICAg IA0KQ29tcG9uZW50OiAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg VmVyc2lvbjogICAgICAgICAgICAgICAgICAgICAgIA0KIFNldmVyaXR5OiAgSW4gV0cgTGFzdCBD YWxsICAgICAgICAgICAgICAgICAgICAgfCAgICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAg ICAgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cHM6Ly90cmFjLnRvb2xzLmll dGYub3JnL3dnL3NpcHJlYy90cmFjL3RpY2tldC82Nj4NCnNpcHJlYyA8aHR0cDovL3Rvb2xzLmll dGYub3JnL3NpcHJlYy8+DQoNCg== From john.elwell@siemens-enterprise.com Wed Feb 23 12:35:47 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C623A6A5F for ; Wed, 23 Feb 2011 12:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXrOJEKluGyY for ; Wed, 23 Feb 2011 12:35:46 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3A4E83A6A5E for ; Wed, 23 Feb 2011 12:35:44 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3518658; Wed, 23 Feb 2011 21:36:25 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 906E423F028E; Wed, 23 Feb 2011 21:36:25 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 23 Feb 2011 21:36:25 +0100 From: "Elwell, John" To: Leon Portman , siprec issue tracker Date: Wed, 23 Feb 2011 21:36:24 +0100 Thread-Topic: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants Thread-Index: AcvM6cpYQ57UUrunTBCS241IKWnf7AGlK6VwAAa0NbA= Message-ID: References: <075.d9e0afcd7cf3ee35c38905ea3efdd6c9@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A78FCD61@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A78FCD61@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 20:35:47 -0000 My feeling too. John (as individual)=20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 23 February 2011 17:25 > To: siprec issue tracker; Elwell, John > Cc: siprec@ietf.org > Subject: RE: [siprec] Requirements #66 (new): Clarification=20 > of REQ-018 on indications to participants >=20 > Because supporting of siprec-aware UA indication will require=20 > some additional protocol changes for CS, we probably should=20 > have a separate requirement for that >=20 > Leon >=20 > -----Original Message----- > From: siprec issue tracker [mailto:trac@tools.ietf.org]=20 > Sent: Tuesday, February 15, 2011 10:24 AM > To: Leon Portman; john.elwell@siemens-enterprise.com > Cc: siprec@ietf.org > Subject: [siprec] Requirements #66 (new): Clarification of=20 > REQ-018 on indications to participants >=20 > #66: Clarification of REQ-018 on indications to participants >=20 > REQ-018 can be satisfied in general by playing media to=20 > participants, but do we need a more specific requirement,=20 > e.g., for siprec-aware UAs to know whether the CS is being=20 > recorded or not? >=20 > John >=20 > --=20 > ------------------------------------------------+------------- > ---------- > ------------------------------------------------+---- > Reporter: john.elwell@... | =20 > Owner: leon.portman@... =20 > Type: defect | =20 > Status: new =20 > Priority: major | =20 > Milestone: =20 > Component: Requirements | =20 > Version: =20 > Severity: In WG Last Call | =20 > Keywords: =20 > ------------------------------------------------+------------- > ---------- > ------------------------------------------------+---- >=20 > Ticket URL: > siprec >=20 > = From john.elwell@siemens-enterprise.com Thu Feb 24 23:28:10 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298B23A6940 for ; Thu, 24 Feb 2011 23:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXicu7pLG2lb for ; Thu, 24 Feb 2011 23:28:09 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C2E213A681C for ; Thu, 24 Feb 2011 23:28:08 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3545290 for siprec@ietf.org; Fri, 25 Feb 2011 08:28:59 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EBC7C1EB82AB for ; Fri, 25 Feb 2011 08:28:58 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 25 Feb 2011 08:28:58 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 25 Feb 2011 08:28:56 +0100 Thread-Topic: SIPREC - Requested session has been scheduled for IETF 80 Thread-Index: AcvUeZGpS4+GWVXwTrSOL/0odSIF/gAQvChg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] FW: SIPREC - Requested session has been scheduled for IETF 80 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 07:28:10 -0000 Note that we provisionally have a 2.5 hour session Thursday morning in Prag= ue, BUT THIS COULD CHANGE. Please send your agenda requests to me and Brian - I realise time requireme= nts will change nearer the time, but I would at least like to compile a pro= visional agenda. Please be aware of the forthcoming deadlines for I-D submission, registrati= on, etc.: http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 John=20 > -----Original Message----- > From: wwwrun@core3.amsl.com [mailto:wwwrun@core3.amsl.com] On=20 > Behalf Of IETF Secretariat > Sent: 24 February 2011 23:21 > To: Elwell, John > Cc: br@brianrosen.net; gonzalo.camarillo@ericsson.com;=20 > rjsparks@nostrum.com; session-request@ietf.org > Subject: SIPREC - Requested session has been scheduled for IETF 80=20 >=20 > Dear John Elwell, >=20 > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by=20 > the information of sessions that you have requested. >=20 > SIPREC Session 1 (2 hours) > Thursday, Morning Session I 0900-1130 > Room Name: Barcelona > ---------------------------------------------- >=20 >=20 >=20 > Requested Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: siprec > Area Name: Real-time Applications and Infrastructure Area > Session Requester: John Elwell >=20 > Number of Sessions: 1 > Length of Session(s): 2 hours > =20 > =20 > Number of Attendees: 50 > Conflicts to Avoid: > First Priority: p2psip mmusic avtcore avtext ecrit geopriv=20 > sipcore dispatch mediactrl xcon clue hip > Second Priority: simple alto bliss codec xmpp sipclf enum=20 > speechsc drinks speermint cuss salud splices soc > BOF or IRTF Session: RTC-Web >=20 > Special Requests: > =20 > --------------------------------------------------------- >=20 >=20 > = From partr@cisco.com Fri Feb 25 08:47:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925953A6774 for ; Fri, 25 Feb 2011 08:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.335 X-Spam-Level: X-Spam-Status: No, score=-9.335 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrtRzTXneI4n for ; Fri, 25 Feb 2011 08:47:49 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 69FD03A63EB for ; Fri, 25 Feb 2011 08:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6488; q=dns/txt; s=iport; t=1298652519; x=1299862119; h=mime-version:subject:date:message-id:from:to:cc; bh=2oiglv37Ei/frHGpFjMlRNq39YV0DbnwZaTyQT3vEbQ=; b=BqvigvIcbDvOUhWNgsiRajYt1JoFvsRXw/wP0Y2HHLTdrEe+5zNeSPND Bne256yNx6iW76OFFv6t1CmIBnNlW8J7fj+y715zcAWCzmDs+w5i2CPRJ YjEqTX9uao19QJtNr0MbIHeZ8QiDlD5WwrSbTU2bIj9aM8fnz8E1GkIGH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA5sZ01AaMHG/2dsb2JhbAClZFl0oU2baoJ+gmIEhQ6KUw X-IronPort-AV: E=Sophos;i="4.62,226,1297036800"; d="scan'208,217";a="315221225" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2011 16:48:38 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PGmbn4019746; Fri, 25 Feb 2011 16:48:37 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 22:18:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD50B.D8AA7A4E" Date: Fri, 25 Feb 2011 22:14:45 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Metadata XML document error representation for whole doc or for portion of doc Thread-Index: AcvVC08K83RqhmptSQO1l+XZnxU3hA== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 25 Feb 2011 16:48:37.0063 (UTC) FILETIME=[D8E7FD70:01CBD50B] Subject: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:47:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD50B.D8AA7A4E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I'm interested in hearing whether it makes more appropriate to create = the (syntax or semantic) error for the whole Metadata XML document or = for section/portion of XML document. Each approach has its own pros and = cons.=20 =20 Whole Metadata XML document error handling:: Any syntax of semantic error is seen in the XML document, the = whole document will be rejected by SIP response code (like 415/488). =20 Pros:=20 1) Here SRC has no need to decode XML document while receiving = the error response 2) Simple Implementation as the operation is success or = failure only Cons: 1) Even most of the XML document is acceptable, the document = is rejected in SRS=20 2) It is not possible to identify the exact error=20 =20 Error handling for Portion of XML document::=20 Any syntax or semantic error has to be represented with the specific XML = element has the error. The portion of the xml element will be identified = by the id corresponding to the element. The error has to be passed from = SRS to SRC in the XML format with special XML syntax. say participant = AOR is not accepted then XML error sends back to indicate that partipant = element is not accepted. =20 Open item: 1) What SIP response code to be sent when the portion of the XML is = accepted =20 =20 Pros: 1) The portion of the element will only be rejected and rest of = the XML is accepted in SRS. 2) Provide more granular control Cons: 1) SRC *MUST* be XML decoding functionality with response = handling to identify the error 2) Complex design in nature for metadata itself =20 Please provide your valuable input about which approach will be most = suitable from SIPREC perspective. =20 Thanks Partha ------_=_NextPart_001_01CBD50B.D8AA7A4E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=
Hi all,
=0A=
=0A=
=0A=
 
=0A=
I'm interested in hearing whether it = makes more appropriate to create the (syntax or semantic) = error for the whole Metadata XML document or for section/portion of = XML document. Each approach has its own pros and cons.
=0A=
 
=0A=
Whole Metadata XML document error = handling::
=0A=
          = Any syntax of semantic error is seen in the XML document, the whole = document will be rejected by SIP response code (like 415/488).  =
=0A=
Pros:
=0A=
          1) = Here SRC has no need to decode XML document while receiving the error = response
=0A=
          2) = Simple Implementation as the operation is success or failure = only
=0A=
Cons:
=0A=
          1) = Even most of the XML document is acceptable, the document is rejected in = SRS
=0A=
          = 2) It is not possible to identify the exact error
=0A=
 
=0A=
Error handling for Portion of XML = document::
=0A=
Any syntax or semantic error has to be = represented with the specific XML element has the error. The portion of = the xml element will be identified by the id corresponding to the = element. The error has to be passed from SRS to SRC in the XML format = with special XML syntax. say participant AOR is not accepted then XML = error sends back to indicate that partipant element is not = accepted.
=0A=
 
=0A=
Open item:
=0A=
1) What SIP response code to be = sent when the portion of the XML is accepted  
=0A=
 
=0A=
Pros:
=0A=
         1) The = portion of the element will only be rejected and rest of the XML is = accepted in SRS.
=0A=
          2) = Provide more granular control
=0A=
Cons:
=0A=
         1) SRC = *MUST* be XML decoding functionality with response handling to identify = the error
=0A=
         2) = Complex design in nature for metadata itself
=0A=
 
=0A=
Please provide your valuable = input about which approach will be most suitable from SIPREC = perspective.
=0A=
 
=0A=
Thanks
=0A=
Partha
------_=_NextPart_001_01CBD50B.D8AA7A4E-- From pkyzivat@cisco.com Fri Feb 25 09:51:53 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3103A67EB for ; Fri, 25 Feb 2011 09:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyqz72V+9KQI for ; Fri, 25 Feb 2011 09:51:52 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DEA373A65A5 for ; Fri, 25 Feb 2011 09:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4981; q=dns/txt; s=iport; t=1298656365; x=1299865965; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4TjsFacbMlRMu+Q8Z5IcrBzeSbsIZnJPfCBgbtE0jU0=; b=k8PjuI5azztmxjfqDTCgpCSFpOpLp00yd3YSF2+gJMuMgAyWEEzfxRxv /Ftk01pv3+gTPVOxF84j9QeEC6E2wemt8pl0wJjH0OWwOE0p/mddjQKoh 9Qv8vB1eCtz4JiXUUvGUQmHwxxeuWq88D3DC7zxZG61/zHOgMyE72RK9F 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIZ7Z01AZnwM/2dsb2JhbACmO3ShN5tign6CYgSFEIcNgz4 X-IronPort-AV: E=Sophos;i="4.62,226,1297036800"; d="scan'208";a="220029112" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2011 17:52:42 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PHqglA012143 for ; Fri, 25 Feb 2011 17:52:42 GMT Message-ID: <4D67EC69.7080507@cisco.com> Date: Fri, 25 Feb 2011 12:52:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:51:53 -0000 On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > Hi all, > I'm interested in hearing whether it makes more appropriate to create > the (syntax or semantic) error for the whole Metadata XML document or > for section/portion of XML document. Each approach has its own pros and > cons. General comments on this subject: I don't think we should expect that the transmitted metadata information will be processed prior to responding to the message that conveys it. For one thing it is a layer violation. For another, the processing of this data could be *harder* than processing the sip message, and so need to be offloaded and queued for processing. So I don't think any error report about the metadata should be *expected* in the response to the message carrying it. (We may still *permit* an error report to be conveyed in that response, but it should also be possible to send it later.) IMO its not important to give fine-grained error information. It almost certainly won't result in the sender "fixing" what it is doing. Its mostly just information that can be used for reporting/fixing errors. So a more general "couldn't handle this", plus perhaps some free form field for conveying info potentially useful to someone fixing things, should be sufficient. Two possible variations on that: If we plan for options and extensions in the mechanism, and define some rules for how those are handed, we may want a way to say "I didn't understand x and skipped it". Right now I only see that for "extension data", and I'm not certain we want to be chatty about that. Current thinking (not yet presented to the group) is that the messages conveying metadata will consist of a sequence of individual packets of metadata to be added to the collected metadata for the RS. There could be a bunch of these in the message, and they will need to be processed in sequence. If there is trouble along the way, it probably compromises the ability to process subsequent pieces. We might want to treat the entire message as atomic, with all the stuff in it being processed, or none of them. OR, we might want to say these are processed one by one until there is a problem, and then no more are processed. (Until when?) This has implications on the protocol for conveying these things, especially since the "responses" will probably be delayed and the SRC will not want for a response before sending more. My *inclination* right now is to perhaps sequence number the individual metadata update packets, and have a response ack/nack up to a particular sequence number. If there is an error, then no more would be processed until some handshake occurred. That would allow the updates to be pipelined without regard to message boundaries. We also need a philosophy here. In general I think we must assume that the SRC and SRS are implemented correctly. Once that has been proven wrong, by detection of an error, there is a real question of whether to attempt to continue the RS, or simply give it up. Just giving up and dropping it has the merit of simplicity. OTOH, I know that often recordings are essential, and so it may be better to keep going in crippled form with as much as you can figure out. I don't have an answer here yet. Thanks, Paul > Whole Metadata XML document error handling:: > Any syntax of semantic error is seen in the XML document, the whole > document will be rejected by SIP response code (like 415/488). > Pros: > 1) Here SRC has no need to decode XML document while receiving the error > response > 2) Simple Implementation as the operation is success or failure only > Cons: > 1) Even most of the XML document is acceptable, the document is rejected > in SRS > 2) It is not possible to identify the exact error > Error handling for Portion of XML document:: > Any syntax or semantic error has to be represented with the specific XML > element has the error. The portion of the xml element will be identified > by the id corresponding to the element. The error has to be passed from > SRS to SRC in the XML format with special XML syntax. say participant > AOR is not accepted then XML error sends back to indicate that partipant > element is not accepted. > Open item: > 1) What SIP response code to be sent when the portion of the XML is > accepted > Pros: > 1) The portion of the element will only be rejected and rest of the XML > is accepted in SRS. > 2) Provide more granular control > Cons: > 1) SRC *MUST* be XML decoding functionality with response handling to > identify the error > 2) Complex design in nature for metadata itself > Please provide your valuable input about which approach will be most > suitable from SIPREC perspective. > Thanks > Partha > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Fri Feb 25 11:34:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370723A6A16 for ; Fri, 25 Feb 2011 11:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.302 X-Spam-Level: X-Spam-Status: No, score=-9.302 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwIfhXusHwXh for ; Fri, 25 Feb 2011 11:34:22 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 93F383A6831 for ; Fri, 25 Feb 2011 11:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=14330; q=dns/txt; s=iport; t=1298662515; x=1299872115; h=mime-version:subject:date:message-id:references:from:to; bh=mtNQa6mf9vURZWAtVAJnekx6CN87cmGRPoFN8fNOPgE=; b=cYctiLr9+jLwB2nVvIilrurKk0FaB1Sgu4Qj2e4JsahwxeQUP1n5uN++ U4mF5l1+v+qurzaCrbT25SrQ3vMH8PJ+eHVUEH/4UI4LC0FqtsKBMyh7C FOQ2hJGYhhgCZzhWZqQZeIoWM2kRH/bnG+t7cRPBbl4WpGARTC3dSubpu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAPeSZ02Q/khMgWdsb2JhbAClYlkVAQEWIiWhJ5tXgn6CYgSFDopT X-IronPort-AV: E=Sophos;i="4.62,227,1297036800"; d="scan'208,217";a="20164489" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 25 Feb 2011 19:35:13 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1PJZCXn012427 for ; Fri, 25 Feb 2011 19:35:13 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Feb 2011 01:05:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD523.1EAAB28B" Date: Sat, 26 Feb 2011 01:05:12 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata XML document error representation for whole doc or for portion of doc Thread-Index: AcvVFNYcogmFkhRETpCOe6YWGa+8iQAB4ZJv References: <4D67EC69.7080507@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 25 Feb 2011 19:35:12.0761 (UTC) FILETIME=[1ECE7690:01CBD523] Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:34:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD523.1EAAB28B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, =20 Thanks for your detailed mail. IIRC, you propose to represent the error = for the whole XML document instead of individual specific element in XML = error. I agree with you that extension data error has to be part of the = metadata XML error handling. Let us see others opinion in this approach. =20 You have brought back discussion during last interim meeting whether = error handling in SIPREC solution draft has to done immediately in the = response of SIP transaction or later. I'll span the separate thread for = discussing as I'm not fully convinced with sending error message later = after sending 200 OK for the request.=20 =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) Sent: Fri 2/25/2011 11:22 PM To: siprec@ietf.org Subject: Re: [siprec] Metadata XML document error representation for = whole doc or for portion of doc On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > Hi all, > I'm interested in hearing whether it makes more appropriate to create > the (syntax or semantic) error for the whole Metadata XML document or > for section/portion of XML document. Each approach has its own pros = and > cons. General comments on this subject: I don't think we should expect that the transmitted metadata information will be processed prior to responding to the message that conveys it. For one thing it is a layer violation. For another, the processing of this data could be *harder* than processing the sip message, and so need to be offloaded and queued for processing. So I don't think any error report about the metadata should be *expected* in the response to the message carrying it. (We may still *permit* an error report to be conveyed in that response, but it should also be possible to send it later.) IMO its not important to give fine-grained error information. It almost certainly won't result in the sender "fixing" what it is doing. Its mostly just information that can be used for reporting/fixing errors. So a more general "couldn't handle this", plus perhaps some free form field for conveying info potentially useful to someone fixing things, should be sufficient. Two possible variations on that: If we plan for options and extensions in the mechanism, and define some rules for how those are handed, we may want a way to say "I didn't understand x and skipped it". Right now I only see that for "extension data", and I'm not certain we want to be chatty about that. Current thinking (not yet presented to the group) is that the messages conveying metadata will consist of a sequence of individual packets of metadata to be added to the collected metadata for the RS. There could be a bunch of these in the message, and they will need to be processed in sequence. If there is trouble along the way, it probably compromises the ability to process subsequent pieces. We might want to treat the entire message as atomic, with all the stuff in it being processed, or none of them. OR, we might want to say these are processed one by one until there is a problem, and then no more are processed. (Until when?) This has implications on the protocol for conveying these things, especially since the "responses" will probably be delayed and the SRC will not want for a response before sending more. My *inclination* right now is to perhaps sequence number the individual metadata update packets, and have a response ack/nack up to a particular sequence number. If there is an error, then no more would be processed until some handshake occurred. That would allow the updates to be pipelined without regard to message boundaries. We also need a philosophy here. In general I think we must assume that the SRC and SRS are implemented correctly. Once that has been proven wrong, by detection of an error, there is a real question of whether to attempt to continue the RS, or simply give it up. Just giving up and dropping it has the merit of simplicity. OTOH, I know that often recordings are essential, and so it may be better to keep going in crippled form with as much as you can figure out. I don't have an answer here yet. Thanks, Paul > Whole Metadata XML document error handling:: > Any syntax of semantic error is seen in the XML document, the whole > document will be rejected by SIP response code (like 415/488). > Pros: > 1) Here SRC has no need to decode XML document while receiving the = error > response > 2) Simple Implementation as the operation is success or failure only > Cons: > 1) Even most of the XML document is acceptable, the document is = rejected > in SRS > 2) It is not possible to identify the exact error > Error handling for Portion of XML document:: > Any syntax or semantic error has to be represented with the specific = XML > element has the error. The portion of the xml element will be = identified > by the id corresponding to the element. The error has to be passed = from > SRS to SRC in the XML format with special XML syntax. say participant > AOR is not accepted then XML error sends back to indicate that = partipant > element is not accepted. > Open item: > 1) What SIP response code to be sent when the portion of the XML is > accepted > Pros: > 1) The portion of the element will only be rejected and rest of the = XML > is accepted in SRS. > 2) Provide more granular control > Cons: > 1) SRC *MUST* be XML decoding functionality with response handling to > identify the error > 2) Complex design in nature for metadata itself > Please provide your valuable input about which approach will be most > suitable from SIPREC perspective. > Thanks > Partha > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBD523.1EAAB28B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [siprec] Metadata XML document error = representation for whole doc or for portion of doc=0A= =0A= =0A= =0A=
=0A=
Paul,
=0A=
 
=0A=
Thanks for your detailed = mail. IIRC, you propose to represent the error for the whole XML = document instead of individual specific element in XML error. I = agree with you that extension data error has to be part of the metadata = XML error handling. Let us see others opinion in this = approach.
=0A=
 
=0A=
You have brought back = discussion during last interim meeting whether error handling = in SIPREC solution draft has to done immediately in the response of SIP = transaction or later. I'll span the separate thread for = discussing as I'm not fully convinced with sending error message = later after sending 200 OK for the request.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: siprec-bounces@ietf.org on = behalf of Paul Kyzivat (pkyzivat)
Sent: Fri 2/25/2011 11:22 = PM
To: siprec@ietf.org
Subject: Re: [siprec] = Metadata XML document error representation for whole doc or for portion = of doc

=0A=

=0A=

On 2/25/2011 11:44 AM, Parthasarathi R (partr) = wrote:
> Hi all,
> I'm interested in hearing whether it = makes more appropriate to create
> the (syntax or semantic) error = for the whole Metadata XML document or
> for section/portion of = XML document. Each approach has its own pros and
> = cons.

General comments on this subject:

I don't think we = should expect that the transmitted metadata information
will be = processed prior to responding to the message that conveys it.
For one = thing it is a layer violation. For another, the processing of
this = data could be *harder* than processing the sip message, and so = need
to be offloaded and queued for processing.

So I don't = think any error report about the metadata should be
*expected* in the = response to the message carrying it. (We may still
*permit* an error = report to be conveyed in that response, but it should
also be = possible to send it later.)

IMO its not important to give = fine-grained error information. It almost
certainly won't result in = the sender "fixing" what it is doing. Its
mostly just information = that can be used for reporting/fixing errors. So
a more general = "couldn't handle this", plus perhaps some free form field
for = conveying info potentially useful to someone fixing things, should
be = sufficient.

Two possible variations on that:

If we plan = for options and extensions in the mechanism, and define some
rules = for how those are handed, we may want a way to say "I = didn't
understand x and skipped it". Right now I only see that for = "extension
data", and I'm not certain we want to be chatty about = that.

Current thinking (not yet presented to the group) is that = the messages
conveying metadata will consist of a sequence of = individual packets of
metadata to be added to the collected metadata = for the RS. There could
be a bunch of these in the message, and they = will need to be processed
in sequence. If there is trouble along the = way, it probably compromises
the ability to process subsequent = pieces.

We might want to treat the entire message as atomic, with = all the stuff
in it being processed, or none of them.

OR, we = might want to say these are processed one by one until there is = a
problem, and then no more are processed. (Until when?)

This = has implications on the protocol for conveying these = things,
especially since the "responses" will probably be delayed and = the SRC
will not want for a response before sending more.

My = *inclination* right now is to perhaps sequence number the = individual
metadata update packets, and have a response ack/nack up = to a particular
sequence number. If there is an error, then no more = would be processed
until some handshake occurred. That would allow = the updates to be
pipelined without regard to message = boundaries.

We also need a philosophy here. In general I think we = must assume that
the SRC and SRS are implemented correctly. Once that = has been proven
wrong, by detection of an error, there is a real = question of whether to
attempt to continue the RS, or simply give it = up. Just giving up and
dropping it has the merit of simplicity. OTOH, = I know that often
recordings are essential, and so it may be better = to keep going in
crippled form with as much as you can figure out. I = don't have an answer
here = yet.

        = Thanks,
        Paul

> = Whole Metadata XML document error handling::
> Any syntax of = semantic error is seen in the XML document, the whole
> document = will be rejected by SIP response code (like 415/488).
> = Pros:
> 1) Here SRC has no need to decode XML document while = receiving the error
> response
> 2) Simple Implementation as = the operation is success or failure only
> Cons:
> 1) Even = most of the XML document is acceptable, the document is rejected
> = in SRS
> 2) It is not possible to identify the exact error
> = Error handling for Portion of XML document::
> Any syntax or = semantic error has to be represented with the specific XML
> = element has the error. The portion of the xml element will be = identified
> by the id corresponding to the element. The error has = to be passed from
> SRS to SRC in the XML format with special XML = syntax. say participant
> AOR is not accepted then XML error sends = back to indicate that partipant
> element is not accepted.
> = Open item:
> 1) What SIP response code to be sent when the portion = of the XML is
> accepted
> Pros:
> 1) The portion of = the element will only be rejected and rest of the XML
> is = accepted in SRS.
> 2) Provide more granular control
> = Cons:
> 1) SRC *MUST* be XML decoding functionality with response = handling to
> identify the error
> 2) Complex design in = nature for metadata itself
> Please provide your valuable input = about which approach will be most
> suitable from SIPREC = perspective.
> Thanks
> = Partha
>
>
>
> = _______________________________________________
> siprec mailing = list
> siprec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/siprec
________________________________________= _______
siprec mailing list
siprec@ietf.org
https://www.ietf.or= g/mailman/listinfo/siprec

------_=_NextPart_001_01CBD523.1EAAB28B-- From partr@cisco.com Fri Feb 25 11:34:36 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3903A6831 for ; Fri, 25 Feb 2011 11:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.282 X-Spam-Level: X-Spam-Status: No, score=-9.282 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71CYtl1NZoC5 for ; Fri, 25 Feb 2011 11:34:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8A9833A6A19 for ; Fri, 25 Feb 2011 11:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=18005; q=dns/txt; s=iport; t=1298662527; x=1299872127; h=mime-version:subject:date:message-id:references:from:to; bh=NHJI5/tzgNP7/XqfCtSqGhJXlwWHVeNlLzovMqSbXMg=; b=gf+kCQfosCu5f0gr2U0waEqKGL9+m6A7D9ZhmwwEZMbacBkuAqRnQtGl v7uts1PlU79HIkz4M6gzVy/gy0AhD1vOm9uL30xmtcm5wVv0iNJjAbEtw 5IQ5vZHf/FaVzKjiDDr+JXCe5FFMute4pasCxnwDhuF3wKwYF4JYtOmkI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAKqTZ02Q/khLgWdsb2JhbAClYlkVAQEWIiWhJptUgn6CYgSFDopT X-IronPort-AV: E=Sophos;i="4.62,227,1297036800"; d="scan'208,217";a="77397983" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 25 Feb 2011 19:35:25 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1PJZOSK021534 for ; Fri, 25 Feb 2011 19:35:25 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Feb 2011 01:05:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD523.25DB5907" Date: Sat, 26 Feb 2011 01:05:24 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Process Message body completely before sending response or not [was RE: [siprec] Metadata XML document error representation for whole doc or for portion of doc] Thread-Index: AcvVFNYcogmFkhRETpCOe6YWGa+8iQACOkbA References: <4D67EC69.7080507@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 25 Feb 2011 19:35:24.0869 (UTC) FILETIME=[2605FF50:01CBD523] Subject: [siprec] Process Message body completely before sending response or not [was RE: Metadata XML document error representation for whole doc or for portion of doc] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:34:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD523.25DB5907 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 =20 The separate question brought by Paul in this below mail thread and = others during last interim meeting is whether Metadata XML body will be = processed before sending the response to SRC or not. I believe that each = transaction in SIP message will be completed when 200 OK is send for the = request. For example: INVITE carries metadata XML document from SRC to = SRS, 200 OK from SRS indicates that INVITE with message body (metadata = XML) is accepted. In case of any error, it *MUST* be conveyed in the = form of non-2xx response. Still I could not get the point that 200 OK = will be sent but message body processing error will be conveyed through = new SIP mechanism. XML usage as message body (like PIDF) is prevalent in = SIP and SIPREC is not exception to this, Could you please point out any = existing mechanism which sends 200 OK immediately without processing = message body and sending the error later through other SIP mechanism.=20 =20 The general concern is whether it is possible to process complete SIPREC = XML body before sending the response to SRC. INVITE with provisional = response like 100 will provide ample time for SRS to process the message = body and convey the appropriate response code (2xx or non-2xx). The = question may arise how SRC will queue forthcoming transaction till the = first transaction is complete. IMO, the real question is whether SRC or = SRS has to queue the messages as SRS is not processed the first message = itself. It is preferred to queue in SRC rather than sending to SRS = which could not digest the earlier messages itself. As Paul indicated in = the below mail, there will be troublesome situation in queuing the = message in SRS without complete processing in case the first message has = error how to deal with the rest of the queued message in SRS. It will be = better to queue the rest of the message in SRC queue till the processing = completing in SRS.=20 =20 Please read inline =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) Sent: Fri 2/25/2011 11:22 PM To: siprec@ietf.org Subject: Re: [siprec] Metadata XML document error representation for = whole doc or for portion of doc On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > Hi all, > I'm interested in hearing whether it makes more appropriate to create > the (syntax or semantic) error for the whole Metadata XML document or > for section/portion of XML document. Each approach has its own pros = and > cons. General comments on this subject: I don't think we should expect that the transmitted metadata information will be processed prior to responding to the message that conveys it. For one thing it is a layer violation. Could you please explain in detail about for the layer = violation here For another, the processing of this data could be *harder* than processing the sip message, and so need to be offloaded and queued for processing. So I don't think any error report about the metadata should be *expected* in the response to the message carrying it. (We may still *permit* an error report to be conveyed in that response, but it should also be possible to send it later.) IMO its not important to give fine-grained error information. It almost certainly won't result in the sender "fixing" what it is doing. Its mostly just information that can be used for reporting/fixing errors. So a more general "couldn't handle this", plus perhaps some free form field for conveying info potentially useful to someone fixing things, should be sufficient. Two possible variations on that: If we plan for options and extensions in the mechanism, and define some rules for how those are handed, we may want a way to say "I didn't understand x and skipped it". Right now I only see that for "extension data", and I'm not certain we want to be chatty about that. Current thinking (not yet presented to the group) is that the messages conveying metadata will consist of a sequence of individual packets of metadata to be added to the collected metadata for the RS. There could be a bunch of these in the message, and they will need to be processed in sequence. If there is trouble along the way, it probably compromises the ability to process subsequent pieces. We might want to treat the entire message as atomic, with all the stuff in it being processed, or none of them. OR, we might want to say these are processed one by one until there is a problem, and then no more are processed. (Until when?) This has implications on the protocol for conveying these things, especially since the "responses" will probably be delayed and the SRC will not want for a response before sending more. My *inclination* right now is to perhaps sequence number the individual metadata update packets, and have a response ack/nack up to a particular sequence number. If there is an error, then no more would be processed until some handshake occurred. That would allow the updates to be pipelined without regard to message boundaries. We also need a philosophy here. In general I think we must assume that the SRC and SRS are implemented correctly. Once that has been proven wrong, by detection of an error, there is a real question of whether to attempt to continue the RS, or simply give it up. Just giving up and dropping it has the merit of simplicity. OTOH, I know that often recordings are essential, and so it may be better to keep going in crippled form with as much as you can figure out. I don't have an answer here yet. Thanks, Paul > Whole Metadata XML document error handling:: > Any syntax of semantic error is seen in the XML document, the whole > document will be rejected by SIP response code (like 415/488). > Pros: > 1) Here SRC has no need to decode XML document while receiving the = error > response > 2) Simple Implementation as the operation is success or failure only > Cons: > 1) Even most of the XML document is acceptable, the document is = rejected > in SRS > 2) It is not possible to identify the exact error > Error handling for Portion of XML document:: > Any syntax or semantic error has to be represented with the specific = XML > element has the error. The portion of the xml element will be = identified > by the id corresponding to the element. The error has to be passed = from > SRS to SRC in the XML format with special XML syntax. say participant > AOR is not accepted then XML error sends back to indicate that = partipant > element is not accepted. > Open item: > 1) What SIP response code to be sent when the portion of the XML is > accepted > Pros: > 1) The portion of the element will only be rejected and rest of the = XML > is accepted in SRS. > 2) Provide more granular control > Cons: > 1) SRC *MUST* be XML decoding functionality with response handling to > identify the error > 2) Complex design in nature for metadata itself > Please provide your valuable input about which approach will be most > suitable from SIPREC perspective. > Thanks > Partha > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBD523.25DB5907 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [siprec] Metadata XML document error = representation for whole doc or for portion of doc=0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=
Hi all,
=0A=
 
=0A=
The separate question brought by = Paul in this below mail thread and others during last interim = meeting is whether Metadata XML body will be processed before = sending the response to SRC or not. I believe that each transaction in = SIP message will be completed when 200 OK is send for the = request. For example: INVITE carries metadata XML document = from SRC to SRS, 200 OK from SRS indicates that INVITE with message body = (metadata XML) is accepted. In case of any error, it *MUST* be = conveyed in the form of non-2xx response. Still I could not = get the point that  200 OK will be sent but message body = processing error will be conveyed through new SIP mechanism. XML usage = as message body (like PIDF) is prevalent in SIP and SIPREC is not = exception to this, Could you please point out any existing = mechanism which sends 200 OK immediately without processing message = body and sending the error = later through other SIP = mechanism. 
=0A=
 
=0A=
The general concern is = whether it is possible to = process complete SIPREC XML body before sending the = response to SRC. INVITE with = provisional response like 100 will provide ample time for SRS to process = the message body and convey the appropriate response code (2xx or = non-2xx). The question may arise how SRC will queue forthcoming = transaction till the first transaction is complete. IMO, the real = question is whether SRC or SRS has to queue the messages as SRS is not = processed the first message itself.  It is preferred to queue in = SRC rather than sending to SRS which could not digest the earlier = messages itself. As Paul indicated in the below mail, there will be = troublesome situation in queuing the message in SRS without complete = processing in case the first message has error how to deal = with the rest of the queued message in SRS. It will be better to queue the rest of the = message in SRC queue till the processing completing in SRS.
=0A=
 
=0A=
Please read inline
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: siprec-bounces@ietf.org on = behalf of Paul Kyzivat (pkyzivat)
Sent: Fri 2/25/2011 11:22 = PM
To: siprec@ietf.org
Subject: Re: [siprec] = Metadata XML document error representation for whole doc or for portion = of doc

=0A=

=0A=

On 2/25/2011 11:44 AM, Parthasarathi R (partr) = wrote:
> Hi all,
> I'm interested in hearing whether it = makes more appropriate to create
> the (syntax or semantic) error = for the whole Metadata XML document or
> for section/portion of = XML document. Each approach has its own pros and
> = cons.

General comments on this subject:

I don't think we = should expect that the transmitted metadata information
will be = processed prior to responding to the message that conveys it.
For one = thing it is a layer violation.

=0A=

<Partha>  Could you please explain in = detail about for the layer violation here = </Partha>

=0A=

For another, the processing of
this data could be = *harder* than processing the sip message, and so need
to be offloaded = and queued for processing.

So I don't think any error report = about the metadata should be
*expected* in the response to the = message carrying it. (We may still
*permit* an error report to be = conveyed in that response, but it should
also be possible to send it = later.)

IMO its not important to give fine-grained error = information. It almost
certainly won't result in the sender "fixing" = what it is doing. Its
mostly just information that can be used for = reporting/fixing errors. So
a more general "couldn't handle this", = plus perhaps some free form field
for conveying info potentially = useful to someone fixing things, should
be sufficient.

Two = possible variations on that:

If we plan for options and = extensions in the mechanism, and define some
rules for how those are = handed, we may want a way to say "I didn't
understand x and skipped = it". Right now I only see that for "extension
data", and I'm not = certain we want to be chatty about that.

Current thinking (not = yet presented to the group) is that the messages
conveying metadata = will consist of a sequence of individual packets of
metadata to be = added to the collected metadata for the RS. There could
be a bunch of = these in the message, and they will need to be processed
in sequence. = If there is trouble along the way, it probably compromises
the = ability to process subsequent pieces.

We might want to treat the = entire message as atomic, with all the stuff
in it being processed, = or none of them.

OR, we might want to say these are processed one = by one until there is a
problem, and then no more are processed. = (Until when?)

This has implications on the protocol for conveying = these things,
especially since the "responses" will probably be = delayed and the SRC
will not want for a response before sending = more.

My *inclination* right now is to perhaps sequence number = the individual
metadata update packets, and have a response ack/nack = up to a particular
sequence number. If there is an error, then no = more would be processed
until some handshake occurred. That would = allow the updates to be
pipelined without regard to message = boundaries.

We also need a philosophy here. In general I think we = must assume that
the SRC and SRS are implemented correctly. Once that = has been proven
wrong, by detection of an error, there is a real = question of whether to
attempt to continue the RS, or simply give it = up. Just giving up and
dropping it has the merit of simplicity. OTOH, = I know that often
recordings are essential, and so it may be better = to keep going in
crippled form with as much as you can figure out. I = don't have an answer
here = yet.

        = Thanks,
        Paul

> = Whole Metadata XML document error handling::
> Any syntax of = semantic error is seen in the XML document, the whole
> document = will be rejected by SIP response code (like 415/488).
> = Pros:
> 1) Here SRC has no need to decode XML document while = receiving the error
> response
> 2) Simple Implementation as = the operation is success or failure only
> Cons:
> 1) Even = most of the XML document is acceptable, the document is rejected
> = in SRS
> 2) It is not possible to identify the exact error
> = Error handling for Portion of XML document::
> Any syntax or = semantic error has to be represented with the specific XML
> = element has the error. The portion of the xml element will be = identified
> by the id corresponding to the element. The error has = to be passed from
> SRS to SRC in the XML format with special XML = syntax. say participant
> AOR is not accepted then XML error sends = back to indicate that partipant
> element is not accepted.
> = Open item:
> 1) What SIP response code to be sent when the portion = of the XML is
> accepted
> Pros:
> 1) The portion of = the element will only be rejected and rest of the XML
> is = accepted in SRS.
> 2) Provide more granular control
> = Cons:
> 1) SRC *MUST* be XML decoding functionality with response = handling to
> identify the error
> 2) Complex design in = nature for metadata itself
> Please provide your valuable input = about which approach will be most
> suitable from SIPREC = perspective.
> Thanks
> = Partha
>
>
>
> = _______________________________________________
> siprec mailing = list
> siprec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/siprec
________________________________________= _______
siprec mailing list
siprec@ietf.org
https://www.ietf.or= g/mailman/listinfo/siprec

------_=_NextPart_001_01CBD523.25DB5907-- From Henry.Lum@alcatel-lucent.com Fri Feb 25 13:35:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40C23A6A59 for ; Fri, 25 Feb 2011 13:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0dxq3VOfywu for ; Fri, 25 Feb 2011 13:35:22 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B8FF33A6A44 for ; Fri, 25 Feb 2011 13:35:22 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p1PLZsGw014447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Feb 2011 15:35:54 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1PLZqvp028522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Feb 2011 15:35:53 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p1PLZocE002606; Fri, 25 Feb 2011 13:35:50 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 13:35:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 13:35:48 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406BADEA6@NAHALD.us.int.genesyslab.com> In-Reply-To: <4D67EC69.7080507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata XML document error representation for whole doc or for portion of doc Thread-Index: AcvVFNIoUXW28e7ZT86Ws2db3iTSrQAHFdug References: <4D67EC69.7080507@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , X-OriginalArrivalTime: 25 Feb 2011 21:35:51.0422 (UTC) FILETIME=[F96279E0:01CBD533] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 21:35:24 -0000 Hi Paul, Leon and I had a similar discussion about the different philosophies of handling errors. If we opt for a chatty protocol to ack/nack each message before sending the next one, then what should SRC do when the SRS believes there is an error with a message? We are not sure that the SRC can actually do anything constructive at this point to recover from the error other than reporting the presence of an error. It is possible that the SRS can give up on the RS, but I think SRS should just continue to record the media despite perceived errors in metadata; this is similar to a browser getting badly formatted HTML but will still try to render as much as possible. We are also thinking of providing the SRS with a mechanism to request the SRC to ask for the current snapshot so that the SRC/SRS can reset the states in the case where SRS is in a really bad state. By doing so, we may be able to avoid providing nack responses and avoid using a chatty protocol. I agree sequencing of messages make sense since SRC should be sending only updates to metadata rather than sending the entire metadata view for every message. Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, February 25, 2011 12:53 PM > To: siprec@ietf.org > Subject: Re: [siprec] Metadata XML document error representation for > whole doc or for portion of doc >=20 >=20 > On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > > Hi all, > > I'm interested in hearing whether it makes more appropriate to create > > the (syntax or semantic) error for the whole Metadata XML document or > > for section/portion of XML document. Each approach has its own pros > and > > cons. >=20 > General comments on this subject: >=20 > I don't think we should expect that the transmitted metadata > information > will be processed prior to responding to the message that conveys it. > For one thing it is a layer violation. For another, the processing of > this data could be *harder* than processing the sip message, and so > need > to be offloaded and queued for processing. >=20 > So I don't think any error report about the metadata should be > *expected* in the response to the message carrying it. (We may still > *permit* an error report to be conveyed in that response, but it should > also be possible to send it later.) >=20 > IMO its not important to give fine-grained error information. It almost > certainly won't result in the sender "fixing" what it is doing. Its > mostly just information that can be used for reporting/fixing errors. > So > a more general "couldn't handle this", plus perhaps some free form > field > for conveying info potentially useful to someone fixing things, should > be sufficient. >=20 > Two possible variations on that: >=20 > If we plan for options and extensions in the mechanism, and define some > rules for how those are handed, we may want a way to say "I didn't > understand x and skipped it". Right now I only see that for "extension > data", and I'm not certain we want to be chatty about that. >=20 > Current thinking (not yet presented to the group) is that the messages > conveying metadata will consist of a sequence of individual packets of > metadata to be added to the collected metadata for the RS. There could > be a bunch of these in the message, and they will need to be processed > in sequence. If there is trouble along the way, it probably compromises > the ability to process subsequent pieces. >=20 > We might want to treat the entire message as atomic, with all the stuff > in it being processed, or none of them. >=20 > OR, we might want to say these are processed one by one until there is > a > problem, and then no more are processed. (Until when?) >=20 > This has implications on the protocol for conveying these things, > especially since the "responses" will probably be delayed and the SRC > will not want for a response before sending more. >=20 > My *inclination* right now is to perhaps sequence number the individual > metadata update packets, and have a response ack/nack up to a > particular > sequence number. If there is an error, then no more would be processed > until some handshake occurred. That would allow the updates to be > pipelined without regard to message boundaries. >=20 > We also need a philosophy here. In general I think we must assume that > the SRC and SRS are implemented correctly. Once that has been proven > wrong, by detection of an error, there is a real question of whether to > attempt to continue the RS, or simply give it up. Just giving up and > dropping it has the merit of simplicity. OTOH, I know that often > recordings are essential, and so it may be better to keep going in > crippled form with as much as you can figure out. I don't have an > answer > here yet. >=20 > Thanks, > Paul >=20 > > Whole Metadata XML document error handling:: > > Any syntax of semantic error is seen in the XML document, the whole > > document will be rejected by SIP response code (like 415/488). > > Pros: > > 1) Here SRC has no need to decode XML document while receiving the > error > > response > > 2) Simple Implementation as the operation is success or failure only > > Cons: > > 1) Even most of the XML document is acceptable, the document is > rejected > > in SRS > > 2) It is not possible to identify the exact error > > Error handling for Portion of XML document:: > > Any syntax or semantic error has to be represented with the specific > XML > > element has the error. The portion of the xml element will be > identified > > by the id corresponding to the element. The error has to be passed > from > > SRS to SRC in the XML format with special XML syntax. say participant > > AOR is not accepted then XML error sends back to indicate that > partipant > > element is not accepted. > > Open item: > > 1) What SIP response code to be sent when the portion of the XML is > > accepted > > Pros: > > 1) The portion of the element will only be rejected and rest of the > XML > > is accepted in SRS. > > 2) Provide more granular control > > Cons: > > 1) SRC *MUST* be XML decoding functionality with response handling to > > identify the error > > 2) Complex design in nature for metadata itself > > Please provide your valuable input about which approach will be most > > suitable from SIPREC perspective. > > Thanks > > Partha > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pkyzivat@cisco.com Fri Feb 25 14:50:45 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B64D3A6A62 for ; Fri, 25 Feb 2011 14:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.577 X-Spam-Level: X-Spam-Status: No, score=-110.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXaLapMeML1y for ; Fri, 25 Feb 2011 14:50:43 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6B3763A6A4E for ; Fri, 25 Feb 2011 14:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7646; q=dns/txt; s=iport; t=1298674294; x=1299883894; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vEAksHh77u62+qut9rIsZcopaz4OOUyqP6DrY9aI22U=; b=OAF2DrIeW5kQlhvSgpax1Wo2a9W0ATnStJTJCu8fEGrTP7R0ezGE9W7q W933A94ZQXjg8fhm6bXp/W4ArwDsp+pPrm7VDTKZGSCz8XQODIJ30XVzk KqGce7UuKvgmsN5xpIELQyTnFzWb2ekfGNmdl0Thpk8lqMXeh3Hpu12CU 4=; X-IronPort-AV: E=Sophos;i="4.62,228,1297036800"; d="scan'208";a="220524832" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2011 22:51:32 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PMpWr7000351; Fri, 25 Feb 2011 22:51:32 GMT Message-ID: <4D683273.8060204@cisco.com> Date: Fri, 25 Feb 2011 17:51:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <4D67EC69.7080507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:50:45 -0000 On 2/25/2011 2:35 PM, Parthasarathi R (partr) wrote: > Paul, > Thanks for your detailed mail. IIRC, you propose to represent the error > for the whole XML document instead of individual specific element in XML > error. I agree with you that extension data error has to be part of the > metadata XML error handling. Let us see others opinion in this approach. First lets get some terminology straight. We will have some body part in a sip message, containing an xml "document". Over time there will be a series of these within the RS. I think each such xml document will consist of a sequence of "additions" (for lack of a better word) to the metadata being accumulated at the SRS. One option is to report an error for that whole "document", indicating that it is in error and that none of it was processed. However this probably means the SRC must await a confirmation before sending further metadata. That doesn't seem very good. Another option is to sequence number the individual "additions" not only within a single document, but across the entire RS. (Think of these as analogous to CSeq values.) And then to report status based on these numbers. My thought is to report something like "error found with addition #nnn". And then, since these are generally interdependent, to ignore any further additions until such time as the SRC and SRS can resync. Or to just close out the RS entirely after sending the error. This allows pipelining of the data, without awaiting confirmation that the prior data was processed. > You have brought back discussion during last interim meeting whether > error handling in SIPREC solution draft has to done immediately in the > response of SIP transaction or later. I'll span the separate thread for > discussing as I'm not fully convinced with sending error message later > after sending 200 OK for the request. OK. Will wait and reply to that. Thanks, Paul > Thanks > Partha > > ------------------------------------------------------------------------ > *From:* siprec-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) > *Sent:* Fri 2/25/2011 11:22 PM > *To:* siprec@ietf.org > *Subject:* Re: [siprec] Metadata XML document error representation for > whole doc or for portion of doc > > > On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > > Hi all, > > I'm interested in hearing whether it makes more appropriate to create > > the (syntax or semantic) error for the whole Metadata XML document or > > for section/portion of XML document. Each approach has its own pros and > > cons. > > General comments on this subject: > > I don't think we should expect that the transmitted metadata information > will be processed prior to responding to the message that conveys it. > For one thing it is a layer violation. For another, the processing of > this data could be *harder* than processing the sip message, and so need > to be offloaded and queued for processing. > > So I don't think any error report about the metadata should be > *expected* in the response to the message carrying it. (We may still > *permit* an error report to be conveyed in that response, but it should > also be possible to send it later.) > > IMO its not important to give fine-grained error information. It almost > certainly won't result in the sender "fixing" what it is doing. Its > mostly just information that can be used for reporting/fixing errors. So > a more general "couldn't handle this", plus perhaps some free form field > for conveying info potentially useful to someone fixing things, should > be sufficient. > > Two possible variations on that: > > If we plan for options and extensions in the mechanism, and define some > rules for how those are handed, we may want a way to say "I didn't > understand x and skipped it". Right now I only see that for "extension > data", and I'm not certain we want to be chatty about that. > > Current thinking (not yet presented to the group) is that the messages > conveying metadata will consist of a sequence of individual packets of > metadata to be added to the collected metadata for the RS. There could > be a bunch of these in the message, and they will need to be processed > in sequence. If there is trouble along the way, it probably compromises > the ability to process subsequent pieces. > > We might want to treat the entire message as atomic, with all the stuff > in it being processed, or none of them. > > OR, we might want to say these are processed one by one until there is a > problem, and then no more are processed. (Until when?) > > This has implications on the protocol for conveying these things, > especially since the "responses" will probably be delayed and the SRC > will not want for a response before sending more. > > My *inclination* right now is to perhaps sequence number the individual > metadata update packets, and have a response ack/nack up to a particular > sequence number. If there is an error, then no more would be processed > until some handshake occurred. That would allow the updates to be > pipelined without regard to message boundaries. > > We also need a philosophy here. In general I think we must assume that > the SRC and SRS are implemented correctly. Once that has been proven > wrong, by detection of an error, there is a real question of whether to > attempt to continue the RS, or simply give it up. Just giving up and > dropping it has the merit of simplicity. OTOH, I know that often > recordings are essential, and so it may be better to keep going in > crippled form with as much as you can figure out. I don't have an answer > here yet. > > Thanks, > Paul > > > Whole Metadata XML document error handling:: > > Any syntax of semantic error is seen in the XML document, the whole > > document will be rejected by SIP response code (like 415/488). > > Pros: > > 1) Here SRC has no need to decode XML document while receiving the error > > response > > 2) Simple Implementation as the operation is success or failure only > > Cons: > > 1) Even most of the XML document is acceptable, the document is rejected > > in SRS > > 2) It is not possible to identify the exact error > > Error handling for Portion of XML document:: > > Any syntax or semantic error has to be represented with the specific XML > > element has the error. The portion of the xml element will be identified > > by the id corresponding to the element. The error has to be passed from > > SRS to SRC in the XML format with special XML syntax. say participant > > AOR is not accepted then XML error sends back to indicate that partipant > > element is not accepted. > > Open item: > > 1) What SIP response code to be sent when the portion of the XML is > > accepted > > Pros: > > 1) The portion of the element will only be rejected and rest of the XML > > is accepted in SRS. > > 2) Provide more granular control > > Cons: > > 1) SRC *MUST* be XML decoding functionality with response handling to > > identify the error > > 2) Complex design in nature for metadata itself > > Please provide your valuable input about which approach will be most > > suitable from SIPREC perspective. > > Thanks > > Partha > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Fri Feb 25 15:04:06 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41E83A6A6F for ; Fri, 25 Feb 2011 15:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDJ3MA6tajmb for ; Fri, 25 Feb 2011 15:04:04 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D11CE3A6A69 for ; Fri, 25 Feb 2011 15:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=9356; q=dns/txt; s=iport; t=1298675097; x=1299884697; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8DFxDx1aLZI0CYjcUuI2cl+xjJhan9t4bIF2Tjzt9wQ=; b=mbHqeVsGDmrR8UiYlPgMtepcNTbrxhRqyxmiKrOm6sLgWbSBkFzPBg0i Z3KHJmZcznMyxW06jhZsC/kGFxa8EtI7PTA8EP4dpU2yVWbXGxHcu+trW m614/CZnh+gQC3IyJL9tjRC46DFfZHrvTqx71K8Q/2B2mEiexeRWD+IT3 A=; X-IronPort-AV: E=Sophos;i="4.62,228,1297036800"; d="scan'208";a="220157979" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2011 23:04:57 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PN4u1D003334; Fri, 25 Feb 2011 23:04:56 GMT Message-ID: <4D683598.9090608@cisco.com> Date: Fri, 25 Feb 2011 18:04:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <4D67EC69.7080507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Process Message body completely before sending response or not [was RE: Metadata XML document error representation for whole doc or for portion of doc] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:04:06 -0000 Partha, On 2/25/2011 2:35 PM, Parthasarathi R (partr) wrote: > Hi all, > The separate question brought by Paul in this below mail thread and > others during last interim meeting is whether Metadata XML body will be > processed before sending the response to SRC or not. I believe that each > transaction in SIP message will be completed when 200 OK is send for the > request. For example: INVITE carries metadata XML document from SRC to > SRS, 200 OK from SRS indicates that INVITE with message body (metadata > XML) is accepted. In case of any error, it *MUST* be conveyed in the > form of non-2xx response. Still I could not get the point that 200 OK > will be sent but message body processing error will be conveyed through > new SIP mechanism. XML usage as message body (like PIDF) is prevalent in > SIP and SIPREC is not exception to this, Could you please point out any > existing mechanism which sends 200 OK immediately without processing > message body and sending the error laterthrough other SIP mechanism. This has come up in numerous contexts. In discussion of INFO packages, it was spelled out that if an info package requires a "response", then that response needs to be in another INFO in the other direction, not in the response to INFO. In the case of event packages, information is unidirectional. In the case of MESSAGE, there is no guarantee that the message has been displayed to the user or otherwise processed before the response is sent. In the case of location-conveyance there has been some discussion of whether the location must be validated before responding and the answer was "no". In the siprec case, the "recorder" is likely to be an "application" built on top of a sip stack. The ways these things are built vary. There is no guarantee that the application will have the opportunity to process the the body before the stack replies. They may run in differing environments with some loose coupling. And its quite likely that the recorder will need to do some database accesses in the process of validating and processing the metadata. (E.g. to verify that the IDs of references in the metadata have already been defined.) It is entirely unreasonable to expect that such db access will go on while the sip stack is waiting to send its response. *If* a particular implementation can do its processing before the sip response is sent, it may make sense to permit it to send an "ack" about it in the response. But we should not require that. Thanks, Paul > The general concern is whether it is possible toprocess complete SIPREC > XML body before sending the responseto SRC. INVITE with provisional > response like 100 will provide ample time for SRS to process the message > body and convey the appropriate response code (2xx or non-2xx). The > question may arise how SRC will queue forthcoming transaction till the > first transaction is complete. IMO, the real question is whether SRC or > SRS has to queue the messages as SRS is not processed the first message > itself. It is preferred to queue in SRC rather than sending to SRS which > could not digest the earlier messages itself. As Paul indicated in the > below mail, there will be troublesome situation in queuing the message > in SRS without complete processing in case the first message has error > how to deal with the rest of the queued message in SRS. It will be > better to queue the rest of the message in SRC queue till the processing > completing in SRS. > Please read inline > Thanks > Partha > > ------------------------------------------------------------------------ > *From:* siprec-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) > *Sent:* Fri 2/25/2011 11:22 PM > *To:* siprec@ietf.org > *Subject:* Re: [siprec] Metadata XML document error representation for > whole doc or for portion of doc > > > On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > > Hi all, > > I'm interested in hearing whether it makes more appropriate to create > > the (syntax or semantic) error for the whole Metadata XML document or > > for section/portion of XML document. Each approach has its own pros and > > cons. > > General comments on this subject: > > I don't think we should expect that the transmitted metadata information > will be processed prior to responding to the message that conveys it. > For one thing it is a layer violation. > > Could you please explain in detail about for the layer > violation here > > For another, the processing of > this data could be *harder* than processing the sip message, and so need > to be offloaded and queued for processing. > > So I don't think any error report about the metadata should be > *expected* in the response to the message carrying it. (We may still > *permit* an error report to be conveyed in that response, but it should > also be possible to send it later.) > > IMO its not important to give fine-grained error information. It almost > certainly won't result in the sender "fixing" what it is doing. Its > mostly just information that can be used for reporting/fixing errors. So > a more general "couldn't handle this", plus perhaps some free form field > for conveying info potentially useful to someone fixing things, should > be sufficient. > > Two possible variations on that: > > If we plan for options and extensions in the mechanism, and define some > rules for how those are handed, we may want a way to say "I didn't > understand x and skipped it". Right now I only see that for "extension > data", and I'm not certain we want to be chatty about that. > > Current thinking (not yet presented to the group) is that the messages > conveying metadata will consist of a sequence of individual packets of > metadata to be added to the collected metadata for the RS. There could > be a bunch of these in the message, and they will need to be processed > in sequence. If there is trouble along the way, it probably compromises > the ability to process subsequent pieces. > > We might want to treat the entire message as atomic, with all the stuff > in it being processed, or none of them. > > OR, we might want to say these are processed one by one until there is a > problem, and then no more are processed. (Until when?) > > This has implications on the protocol for conveying these things, > especially since the "responses" will probably be delayed and the SRC > will not want for a response before sending more. > > My *inclination* right now is to perhaps sequence number the individual > metadata update packets, and have a response ack/nack up to a particular > sequence number. If there is an error, then no more would be processed > until some handshake occurred. That would allow the updates to be > pipelined without regard to message boundaries. > > We also need a philosophy here. In general I think we must assume that > the SRC and SRS are implemented correctly. Once that has been proven > wrong, by detection of an error, there is a real question of whether to > attempt to continue the RS, or simply give it up. Just giving up and > dropping it has the merit of simplicity. OTOH, I know that often > recordings are essential, and so it may be better to keep going in > crippled form with as much as you can figure out. I don't have an answer > here yet. > > Thanks, > Paul > > > Whole Metadata XML document error handling:: > > Any syntax of semantic error is seen in the XML document, the whole > > document will be rejected by SIP response code (like 415/488). > > Pros: > > 1) Here SRC has no need to decode XML document while receiving the error > > response > > 2) Simple Implementation as the operation is success or failure only > > Cons: > > 1) Even most of the XML document is acceptable, the document is rejected > > in SRS > > 2) It is not possible to identify the exact error > > Error handling for Portion of XML document:: > > Any syntax or semantic error has to be represented with the specific XML > > element has the error. The portion of the xml element will be identified > > by the id corresponding to the element. The error has to be passed from > > SRS to SRC in the XML format with special XML syntax. say participant > > AOR is not accepted then XML error sends back to indicate that partipant > > element is not accepted. > > Open item: > > 1) What SIP response code to be sent when the portion of the XML is > > accepted > > Pros: > > 1) The portion of the element will only be rejected and rest of the XML > > is accepted in SRS. > > 2) Provide more granular control > > Cons: > > 1) SRC *MUST* be XML decoding functionality with response handling to > > identify the error > > 2) Complex design in nature for metadata itself > > Please provide your valuable input about which approach will be most > > suitable from SIPREC perspective. > > Thanks > > Partha > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partr@cisco.com Sat Feb 26 08:35:20 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C383A672F for ; Sat, 26 Feb 2011 08:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.268 X-Spam-Level: X-Spam-Status: No, score=-9.268 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIEhKztHmMe6 for ; Sat, 26 Feb 2011 08:35:18 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 80FF23A67C2 for ; Sat, 26 Feb 2011 08:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=20781; q=dns/txt; s=iport; t=1298738174; x=1299947774; h=mime-version:subject:date:message-id:references:from:to: cc; bh=q48ECcRxqCMUTRkZox+WGAyaweWJ3cioifWPrwPXasw=; b=FfAyfWtAP/a0JZNJy2pgxSp54JWI4dL99PvGEXzpjjUsJk1yhZy9uqWc yMP87cIwKP3ugLhqjBeCq9oZSaLnX67kOSTOrAgK509WZaMztSWks52HM egIZuSjftWjuIVVKaM0JrRx+/WQyWns/qmP76bZBiOG9pZf4TBJj+WVTi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEe6aE1AaMHG/2dsb2JhbAClbVl0oD+bJ4J+gmMEhQ6KUw X-IronPort-AV: E=Sophos;i="4.62,232,1297036800"; d="scan'208,217";a="315522832" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2011 16:36:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1QGaB59017652 for ; Sat, 26 Feb 2011 16:36:12 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Feb 2011 22:06:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD5D3.4685ED06" Date: Sat, 26 Feb 2011 22:06:10 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata XML document error representation for whole doc or for portion of doc Thread-Index: AcvVPo4pKqv5k3KhSiS5jmZGSw70kAAkRGK9 References: <4D67EC69.7080507@cisco.com> <4D683273.8060204@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 26 Feb 2011 16:36:11.0222 (UTC) FILETIME=[46C36F60:01CBD5D3] Cc: siprec@ietf.org Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 16:35:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD5D3.4685ED06 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, =20 Please read inline. =20 Thanks Partha ________________________________ From: Paul Kyzivat (pkyzivat) Sent: Sat 2/26/2011 4:21 AM To: Parthasarathi R (partr) Cc: siprec@ietf.org Subject: Re: [siprec] Metadata XML document error representation for = whole doc or for portion of doc On 2/25/2011 2:35 PM, Parthasarathi R (partr) wrote: > Paul, > Thanks for your detailed mail. IIRC, you propose to represent the = error > for the whole XML document instead of individual specific element in = XML > error. I agree with you that extension data error has to be part of = the > metadata XML error handling. Let us see others opinion in this = approach. First lets get some terminology straight. We will have some body part in a sip message, containing an xml "document". Over time there will be a series of these within the RS. The other part of message body will have SDP. I think each such xml document will consist of a sequence of "additions" (for lack of a better word) to the metadata being accumulated at the = SRS. One option is to report an error for that whole "document", indicating that it is in error and that none of it was processed. However this probably means the SRC must await a confirmation before sending further metadata. That doesn't seem very good. Most of the SIPREC transaction will have stream (SDP) involved = as we are recording the media. SRS is UAS which processes SDP, = negotiate stream parameters in the response. In case SDP and XML body = exist in the same message body(metadata), SDP will be processed before = sending the response but whether XML processing will be deferred as it = will take more time to process? Also, SRC MUST wait for the response in = case SDP message body is sent towards SRS as per offer/answer model. So = awaiting for the response before forwarding further metdata is not so = bad. Still I'm not very clear about pipeline of SDP + XML (metadata) in = SRS. Another option is to sequence number the individual "additions" not only within a single document, but across the entire RS. (Think of these as analogous to CSeq values.) And then to report status based on these numbers. My thought is to report something like "error found with addition #nnn". And then, since these are generally interdependent, to ignore any further additions until such time as the SRC and SRS can resync. Or to just close out the RS entirely after sending the error. This allows pipelining of the data, without awaiting confirmation that the prior data was processed. > You have brought back discussion during last interim meeting whether > error handling in SIPREC solution draft has to done immediately in the > response of SIP transaction or later. I'll span the separate thread = for > discussing as I'm not fully convinced with sending error message later > after sending 200 OK for the request. OK. Will wait and reply to that. Thanks, Paul > Thanks > Partha > > = ------------------------------------------------------------------------ > *From:* siprec-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) > *Sent:* Fri 2/25/2011 11:22 PM > *To:* siprec@ietf.org > *Subject:* Re: [siprec] Metadata XML document error representation for > whole doc or for portion of doc > > > On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > > Hi all, > > I'm interested in hearing whether it makes more appropriate to = create > > the (syntax or semantic) error for the whole Metadata XML document = or > > for section/portion of XML document. Each approach has its own pros = and > > cons. > > General comments on this subject: > > I don't think we should expect that the transmitted metadata = information > will be processed prior to responding to the message that conveys it. > For one thing it is a layer violation. For another, the processing of > this data could be *harder* than processing the sip message, and so = need > to be offloaded and queued for processing. > > So I don't think any error report about the metadata should be > *expected* in the response to the message carrying it. (We may still > *permit* an error report to be conveyed in that response, but it = should > also be possible to send it later.) > > IMO its not important to give fine-grained error information. It = almost > certainly won't result in the sender "fixing" what it is doing. Its > mostly just information that can be used for reporting/fixing errors. = So > a more general "couldn't handle this", plus perhaps some free form = field > for conveying info potentially useful to someone fixing things, should > be sufficient. > > Two possible variations on that: > > If we plan for options and extensions in the mechanism, and define = some > rules for how those are handed, we may want a way to say "I didn't > understand x and skipped it". Right now I only see that for "extension > data", and I'm not certain we want to be chatty about that. > > Current thinking (not yet presented to the group) is that the messages > conveying metadata will consist of a sequence of individual packets of > metadata to be added to the collected metadata for the RS. There could > be a bunch of these in the message, and they will need to be processed > in sequence. If there is trouble along the way, it probably = compromises > the ability to process subsequent pieces. > > We might want to treat the entire message as atomic, with all the = stuff > in it being processed, or none of them. > > OR, we might want to say these are processed one by one until there is = a > problem, and then no more are processed. (Until when?) > > This has implications on the protocol for conveying these things, > especially since the "responses" will probably be delayed and the SRC > will not want for a response before sending more. > > My *inclination* right now is to perhaps sequence number the = individual > metadata update packets, and have a response ack/nack up to a = particular > sequence number. If there is an error, then no more would be processed > until some handshake occurred. That would allow the updates to be > pipelined without regard to message boundaries. > > We also need a philosophy here. In general I think we must assume that > the SRC and SRS are implemented correctly. Once that has been proven > wrong, by detection of an error, there is a real question of whether = to > attempt to continue the RS, or simply give it up. Just giving up and > dropping it has the merit of simplicity. OTOH, I know that often > recordings are essential, and so it may be better to keep going in > crippled form with as much as you can figure out. I don't have an = answer > here yet. > > Thanks, > Paul > > > Whole Metadata XML document error handling:: > > Any syntax of semantic error is seen in the XML document, the whole > > document will be rejected by SIP response code (like 415/488). > > Pros: > > 1) Here SRC has no need to decode XML document while receiving the = error > > response > > 2) Simple Implementation as the operation is success or failure = only > > Cons: > > 1) Even most of the XML document is acceptable, the document is = rejected > > in SRS > > 2) It is not possible to identify the exact error > > Error handling for Portion of XML document:: > > Any syntax or semantic error has to be represented with the = specific XML > > element has the error. The portion of the xml element will be = identified > > by the id corresponding to the element. The error has to be passed = from > > SRS to SRC in the XML format with special XML syntax. say = participant > > AOR is not accepted then XML error sends back to indicate that = partipant > > element is not accepted. > > Open item: > > 1) What SIP response code to be sent when the portion of the XML is > > accepted > > Pros: > > 1) The portion of the element will only be rejected and rest of the = XML > > is accepted in SRS. > > 2) Provide more granular control > > Cons: > > 1) SRC *MUST* be XML decoding functionality with response handling = to > > identify the error > > 2) Complex design in nature for metadata itself > > Please provide your valuable input about which approach will be = most > > suitable from SIPREC perspective. > > Thanks > > Partha > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > ------_=_NextPart_001_01CBD5D3.4685ED06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [siprec] Metadata XML document error = representation for whole doc or for portion of doc=0A= =0A= =0A= =0A=
=0A=
Paul,
=0A=
 
=0A=
Please read = inline.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: Paul Kyzivat = (pkyzivat)
Sent: Sat 2/26/2011 4:21 AM
To: = Parthasarathi R (partr)
Cc: siprec@ietf.org
Subject: = Re: [siprec] Metadata XML document error representation for whole doc or = for portion of doc

=0A=


=0A=

On 2/25/2011 2:35 PM, Parthasarathi R (partr) = wrote:
> Paul,
> Thanks for your detailed mail. IIRC, you = propose to represent the error
> for the whole XML document = instead of individual specific element in XML
> error. I agree = with you that extension data error has to be part of the
> = metadata XML error handling. Let us see others opinion in this = approach.

First lets get some terminology straight.

We = will have some body part in a sip message, containing an = xml
"document". Over time there will be a series of these within the = RS.

=0A=

<Partha> The other part of message body will = have SDP. </Partha>

I think each such xml document will = consist of a sequence of "additions"
(for lack of a better word) to = the metadata being accumulated at the = SRS.

One option is to report an error for that whole "document", = indicating
that it is in error and that none of it was processed. = However this
probably means the SRC must await a confirmation before = sending further
metadata. That doesn't seem very good.

=0A=

<Partha>  Most of the SIPREC transaction = will have stream (SDP) involved as  we are recording the media. SRS = is UAS which processes SDP, negotiate stream parameters in the = response.  In  case SDP and XML body exist in the same message = body(metadata), SDP will be processed before sending the response = but whether XML processing will be deferred as it will take more time to = process? Also, SRC MUST wait for the response in case SDP message = body is sent towards SRS as per offer/answer model. So = awaiting for the response before = forwarding further metdata is not so bad. Still I'm not very = clear about pipeline of SDP + XML (metadata) in = SRS.  </Partha>

=0A=


Another option is to = sequence number the individual "additions" not only
within a single = document, but across the entire RS. (Think of these as
analogous to = CSeq values.) And then to report status based on these
numbers. My = thought is to report something like "error found with
addition #nnn". = And then, since these are generally interdependent, to
ignore any = further additions until such time as the SRC and SRS can
resync. Or = to just close out the RS entirely after sending the error.

This = allows pipelining of the data, without awaiting confirmation that
the = prior data was processed.

> You have brought back discussion = during last interim meeting whether
> error handling in SIPREC = solution draft has to done immediately in the
> response of SIP = transaction or later. I'll span the separate thread for
> = discussing as I'm not fully convinced with sending error message = later
> after sending 200 OK for the request.

OK. Will wait = and reply to that.

        = Thanks,
        Paul

> = Thanks
> Partha
>
> = ------------------------------------------------------------------------<= BR>> *From:* siprec-bounces@ietf.org on behalf of Paul Kyzivat = (pkyzivat)
> *Sent:* Fri 2/25/2011 11:22 PM
> *To:* = siprec@ietf.org
> *Subject:* Re: [siprec] Metadata XML document = error representation for
> whole doc or for portion of = doc
>
>
> On 2/25/2011 11:44 AM, Parthasarathi R = (partr) wrote:
>  > Hi all,
>  > I'm = interested in hearing whether it makes more appropriate to = create
>  > the (syntax or semantic) error for the whole = Metadata XML document or
>  > for section/portion of XML = document. Each approach has its own pros and
>  > = cons.
>
> General comments on this subject:
>
> = I don't think we should expect that the transmitted metadata = information
> will be processed prior to responding to the message = that conveys it.
> For one thing it is a layer violation. For = another, the processing of
> this data could be *harder* than = processing the sip message, and so need
> to be offloaded and = queued for processing.
>
> So I don't think any error report = about the metadata should be
> *expected* in the response to the = message carrying it. (We may still
> *permit* an error report to = be conveyed in that response, but it should
> also be possible to = send it later.)
>
> IMO its not important to give = fine-grained error information. It almost
> certainly won't result = in the sender "fixing" what it is doing. Its
> mostly just = information that can be used for reporting/fixing errors. So
> a = more general "couldn't handle this", plus perhaps some free form = field
> for conveying info potentially useful to someone fixing = things, should
> be sufficient.
>
> Two possible = variations on that:
>
> If we plan for options and = extensions in the mechanism, and define some
> rules for how those = are handed, we may want a way to say "I didn't
> understand x and = skipped it". Right now I only see that for "extension
> data", and = I'm not certain we want to be chatty about that.
>
> Current = thinking (not yet presented to the group) is that the messages
> = conveying metadata will consist of a sequence of individual packets = of
> metadata to be added to the collected metadata for the RS. = There could
> be a bunch of these in the message, and they will = need to be processed
> in sequence. If there is trouble along the = way, it probably compromises
> the ability to process subsequent = pieces.
>
> We might want to treat the entire message as = atomic, with all the stuff
> in it being processed, or none of = them.
>
> OR, we might want to say these are processed one = by one until there is a
> problem, and then no more are processed. = (Until when?)
>
> This has implications on the protocol for = conveying these things,
> especially since the "responses" will = probably be delayed and the SRC
> will not want for a response = before sending more.
>
> My *inclination* right now is to = perhaps sequence number the individual
> metadata update packets, = and have a response ack/nack up to a particular
> sequence number. = If there is an error, then no more would be processed
> until some = handshake occurred. That would allow the updates to be
> pipelined = without regard to message boundaries.
>
> We also need a = philosophy here. In general I think we must assume that
> the SRC = and SRS are implemented correctly. Once that has been proven
> = wrong, by detection of an error, there is a real question of whether = to
> attempt to continue the RS, or simply give it up. Just giving = up and
> dropping it has the merit of simplicity. OTOH, I know = that often
> recordings are essential, and so it may be better to = keep going in
> crippled form with as much as you can figure out. = I don't have an answer
> here yet.
>
> Thanks,
> = Paul
>
>  > Whole Metadata XML document error = handling::
>  > Any syntax of semantic error is seen in = the XML document, the whole
>  > document will be rejected = by SIP response code (like 415/488).
>  > = Pros:
>  > 1) Here SRC has no need to decode XML document = while receiving the error
>  > response
>  > = 2) Simple Implementation as the operation is success or failure = only
>  > Cons:
>  > 1) Even most of the XML = document is acceptable, the document is rejected
>  > in = SRS
>  > 2) It is not possible to identify the exact = error
>  > Error handling for Portion of XML = document::
>  > Any syntax or semantic error has to be = represented with the specific XML
>  > element has the = error. The portion of the xml element will be identified
>  = > by the id corresponding to the element. The error has to be passed = from
>  > SRS to SRC in the XML format with special XML = syntax. say participant
>  > AOR is not accepted then XML = error sends back to indicate that partipant
>  > element = is not accepted.
>  > Open item:
>  > 1) = What SIP response code to be sent when the portion of the XML = is
>  > accepted
>  > Pros:
>  = > 1) The portion of the element will only be rejected and rest of the = XML
>  > is accepted in SRS.
>  > 2) Provide = more granular control
>  > Cons:
>  > 1) SRC = *MUST* be XML decoding functionality with response handling = to
>  > identify the error
>  > 2) Complex = design in nature for metadata itself
>  > Please provide = your valuable input about which approach will be most
>  > = suitable from SIPREC perspective.
>  > = Thanks
>  > Partha
>  >
>  = >
>  >
>  > = _______________________________________________
>  > = siprec mailing list
>  > siprec@ietf.org
>  = > https://www.ietf.or= g/mailman/listinfo/siprec
> = _______________________________________________
> siprec mailing = list
> siprec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/siprec
>

------_=_NextPart_001_01CBD5D3.4685ED06-- From john.elwell@siemens-enterprise.com Mon Feb 28 06:23:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104333A6A06 for ; Mon, 28 Feb 2011 06:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRAxyhSr6Rwd for ; Mon, 28 Feb 2011 06:23:40 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 28E8F3A69CC for ; Mon, 28 Feb 2011 06:23:39 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3560437; Mon, 28 Feb 2011 15:24:39 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 5AB2E1EB82B4; Mon, 28 Feb 2011 15:24:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 28 Feb 2011 15:24:39 +0100 From: "Elwell, John" To: Henry Lum , Paul Kyzivat , "siprec@ietf.org" Date: Mon, 28 Feb 2011 15:24:38 +0100 Thread-Topic: [siprec] Metadata XML document error representation for whole doc or for portion of doc Thread-Index: AcvVFNIoUXW28e7ZT86Ws2db3iTSrQAHFdugAIetdnA= Message-ID: References: <4D67EC69.7080507@cisco.com> <059AF07365DC474393A19A3AF187DF7406BADEA6@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406BADEA6@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 14:23:42 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 25 February 2011 21:36 > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Metadata XML document error=20 > representation for whole doc or for portion of doc >=20 > Hi Paul, >=20 > Leon and I had a similar discussion about the different=20 > philosophies of > handling errors. If we opt for a chatty protocol to ack/nack each > message before sending the next one, then what should SRC do when the > SRS believes there is an error with a message? We are not=20 > sure that the > SRC can actually do anything constructive at this point to=20 > recover from > the error other than reporting the presence of an error. It=20 > is possible > that the SRS can give up on the RS, but I think SRS should=20 > just continue > to record the media despite perceived errors in metadata; this is > similar to a browser getting badly formatted HTML but will=20 > still try to > render as much as possible. [JRE] I can perhaps draw an analogy with RFC 3265 event packages. My unders= tanding is that the 200 OK response to NOTIFY requests doesn't mean much mo= re than "I received this NOTIFY request in the context of a valid subscript= ion and I support the MIME type(s) attached". There is no provision for con= veying error information beyond the basic SIP response codes for rejecting = the request. A specific event package might require more than this, althoug= h I don't think that is common practice and I don't think it was the intent= of RFC 3265. Moreover, RFC 3265 and event packages do not provide any othe= r mechanism, apart from the NOTIFY response, for reporting issues in notifi= ed data. I think metadata transmissions and updates can be treated the same way, tha= t a 200 response does not mean metadata was correct - only that it was rece= ived and passed to the application. If we decide that the SRS application n= eeds to be able to report errors to the SRC, that would need to be a separa= te mechanism. > We are also thinking of providing the SRS > with a mechanism to request the SRC to ask for the current snapshot so > that the SRC/SRS can reset the states in the case where SRS is in a > really bad state. By doing so, we may be able to avoid providing nack > responses and avoid using a chatty protocol. [JRE] Yes, and the request to resend full metadata could optionally include= some sort of error report that gave rise to the request. That error report= could, for example, include the sequence number of the metadata update tha= t was found to be in error. John (as individual) >=20 > I agree sequencing of messages make sense since SRC should be sending > only updates to metadata rather than sending the entire metadata view > for every message. >=20 > Regards, > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Friday, February 25, 2011 12:53 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] Metadata XML document error representation for > > whole doc or for portion of doc > >=20 > >=20 > > On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: > > > Hi all, > > > I'm interested in hearing whether it makes more appropriate to > create > > > the (syntax or semantic) error for the whole Metadata XML document > or > > > for section/portion of XML document. Each approach has=20 > its own pros > > and > > > cons. > >=20 > > General comments on this subject: > >=20 > > I don't think we should expect that the transmitted metadata > > information > > will be processed prior to responding to the message that=20 > conveys it. > > For one thing it is a layer violation. For another, the=20 > processing of > > this data could be *harder* than processing the sip message, and so > > need > > to be offloaded and queued for processing. > >=20 > > So I don't think any error report about the metadata should be > > *expected* in the response to the message carrying it. (We may still > > *permit* an error report to be conveyed in that response, but it > should > > also be possible to send it later.) > >=20 > > IMO its not important to give fine-grained error information. It > almost > > certainly won't result in the sender "fixing" what it is doing. Its > > mostly just information that can be used for=20 > reporting/fixing errors. > > So > > a more general "couldn't handle this", plus perhaps some free form > > field > > for conveying info potentially useful to someone fixing=20 > things, should > > be sufficient. > >=20 > > Two possible variations on that: > >=20 > > If we plan for options and extensions in the mechanism, and define > some > > rules for how those are handed, we may want a way to say "I didn't > > understand x and skipped it". Right now I only see that for=20 > "extension > > data", and I'm not certain we want to be chatty about that. > >=20 > > Current thinking (not yet presented to the group) is that=20 > the messages > > conveying metadata will consist of a sequence of individual=20 > packets of > > metadata to be added to the collected metadata for the RS.=20 > There could > > be a bunch of these in the message, and they will need to=20 > be processed > > in sequence. If there is trouble along the way, it probably > compromises > > the ability to process subsequent pieces. > >=20 > > We might want to treat the entire message as atomic, with all the > stuff > > in it being processed, or none of them. > >=20 > > OR, we might want to say these are processed one by one=20 > until there is > > a > > problem, and then no more are processed. (Until when?) > >=20 > > This has implications on the protocol for conveying these things, > > especially since the "responses" will probably be delayed=20 > and the SRC > > will not want for a response before sending more. > >=20 > > My *inclination* right now is to perhaps sequence number the > individual > > metadata update packets, and have a response ack/nack up to a > > particular > > sequence number. If there is an error, then no more would=20 > be processed > > until some handshake occurred. That would allow the updates to be > > pipelined without regard to message boundaries. > >=20 > > We also need a philosophy here. In general I think we must=20 > assume that > > the SRC and SRS are implemented correctly. Once that has been proven > > wrong, by detection of an error, there is a real question of whether > to > > attempt to continue the RS, or simply give it up. Just giving up and > > dropping it has the merit of simplicity. OTOH, I know that often > > recordings are essential, and so it may be better to keep going in > > crippled form with as much as you can figure out. I don't have an > > answer > > here yet. > >=20 > > Thanks, > > Paul > >=20 > > > Whole Metadata XML document error handling:: > > > Any syntax of semantic error is seen in the XML document,=20 > the whole > > > document will be rejected by SIP response code (like 415/488). > > > Pros: > > > 1) Here SRC has no need to decode XML document while receiving the > > error > > > response > > > 2) Simple Implementation as the operation is success or=20 > failure only > > > Cons: > > > 1) Even most of the XML document is acceptable, the document is > > rejected > > > in SRS > > > 2) It is not possible to identify the exact error > > > Error handling for Portion of XML document:: > > > Any syntax or semantic error has to be represented with=20 > the specific > > XML > > > element has the error. The portion of the xml element will be > > identified > > > by the id corresponding to the element. The error has to be passed > > from > > > SRS to SRC in the XML format with special XML syntax. say > participant > > > AOR is not accepted then XML error sends back to indicate that > > partipant > > > element is not accepted. > > > Open item: > > > 1) What SIP response code to be sent when the portion of=20 > the XML is > > > accepted > > > Pros: > > > 1) The portion of the element will only be rejected and=20 > rest of the > > XML > > > is accepted in SRS. > > > 2) Provide more granular control > > > Cons: > > > 1) SRC *MUST* be XML decoding functionality with response handling > to > > > identify the error > > > 2) Complex design in nature for metadata itself > > > Please provide your valuable input about which approach=20 > will be most > > > suitable from SIPREC perspective. > > > Thanks > > > Partha > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 > =09 > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@cisco.com Mon Feb 28 07:21:26 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891863A6BF4 for ; Mon, 28 Feb 2011 07:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.581 X-Spam-Level: X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYzf-iKysPi8 for ; Mon, 28 Feb 2011 07:21:24 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3B5753A6C33 for ; Mon, 28 Feb 2011 07:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=10371; q=dns/txt; s=iport; t=1298906544; x=1300116144; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6atxyWGvYhgX4NBjwJoEA0Cjn9Q+zbrN5sZnt1CoIwc=; b=kVtuq0MMwiyK+7c8IBbJ+sjR1CGn/vYf79Me2MgFoxLIni+iHaRkuOoY 7vk8z2ZP5wkMdjaSl2JPYjVAvIkRnY1Nr4cNaUdGNi8g325UhpQNhKjan xBnE6qWrDfpeamSdHWbTi8mLOXjxK3dFaqR4Me1BCu7vsqtR8legRItGL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAN9Ma01AZnwN/2dsb2JhbACXc45UdKESmySCfoJjBIUQhw2DPg X-IronPort-AV: E=Sophos;i="4.62,240,1297036800"; d="scan'208";a="220729753" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2011 15:22:22 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SFMMv4005624; Mon, 28 Feb 2011 15:22:22 GMT Message-ID: <4D6BBDAE.3020808@cisco.com> Date: Mon, 28 Feb 2011 10:22:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <4D67EC69.7080507@cisco.com> <059AF07365DC474393A19A3AF187DF7406BADEA6@NAHALD.us.int.genesyslab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , Henry Lum Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:21:26 -0000 On 2/28/2011 9:24 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum >> Sent: 25 February 2011 21:36 >> To: Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Metadata XML document error >> representation for whole doc or for portion of doc >> >> Hi Paul, >> >> Leon and I had a similar discussion about the different >> philosophies of >> handling errors. If we opt for a chatty protocol to ack/nack each >> message before sending the next one, then what should SRC do when the >> SRS believes there is an error with a message? We are not >> sure that the >> SRC can actually do anything constructive at this point to >> recover from >> the error other than reporting the presence of an error. It >> is possible >> that the SRS can give up on the RS, but I think SRS should >> just continue >> to record the media despite perceived errors in metadata; this is >> similar to a browser getting badly formatted HTML but will >> still try to >> render as much as possible. > [JRE] I can perhaps draw an analogy with RFC 3265 event packages. My understanding is that the 200 OK response to NOTIFY requests doesn't mean much more than "I received this NOTIFY request in the context of a valid subscription and I support the MIME type(s) attached". There is no provision for conveying error information beyond the basic SIP response codes for rejecting the request. A specific event package might require more than this, although I don't think that is common practice and I don't think it was the intent of RFC 3265. Moreover, RFC 3265 and event packages do not provide any other mechanism, apart from the NOTIFY response, for reporting issues in notified data. > > I think metadata transmissions and updates can be treated the same way, that a 200 response does not mean metadata was correct - only that it was received and passed to the application. If we decide that the SRS application needs to be able to report errors to the SRC, that would need to be a separate mechanism. Yes, I think so too. >> We are also thinking of providing the SRS >> with a mechanism to request the SRC to ask for the current snapshot so >> that the SRC/SRS can reset the states in the case where SRS is in a >> really bad state. By doing so, we may be able to avoid providing nack >> responses and avoid using a chatty protocol. > [JRE] Yes, and the request to resend full metadata could optionally include some sort of error report that gave rise to the request. That error report could, for example, include the sequence number of the metadata update that was found to be in error. That is sort of what I had in mind about getting the two sides in sync. But we will have to think more about exactly what it means. At best I think it will describe the *current* state of things in this RS, without regard to what has happened in the past. Even that may present some technical challenges. But we should keep this desire in mind. Thanks, Paul > John (as individual) > >> >> I agree sequencing of messages make sense since SRC should be sending >> only updates to metadata rather than sending the entire metadata view >> for every message. >> >> Regards, >> Henry >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Friday, February 25, 2011 12:53 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Metadata XML document error representation for >>> whole doc or for portion of doc >>> >>> >>> On 2/25/2011 11:44 AM, Parthasarathi R (partr) wrote: >>>> Hi all, >>>> I'm interested in hearing whether it makes more appropriate to >> create >>>> the (syntax or semantic) error for the whole Metadata XML document >> or >>>> for section/portion of XML document. Each approach has >> its own pros >>> and >>>> cons. >>> >>> General comments on this subject: >>> >>> I don't think we should expect that the transmitted metadata >>> information >>> will be processed prior to responding to the message that >> conveys it. >>> For one thing it is a layer violation. For another, the >> processing of >>> this data could be *harder* than processing the sip message, and so >>> need >>> to be offloaded and queued for processing. >>> >>> So I don't think any error report about the metadata should be >>> *expected* in the response to the message carrying it. (We may still >>> *permit* an error report to be conveyed in that response, but it >> should >>> also be possible to send it later.) >>> >>> IMO its not important to give fine-grained error information. It >> almost >>> certainly won't result in the sender "fixing" what it is doing. Its >>> mostly just information that can be used for >> reporting/fixing errors. >>> So >>> a more general "couldn't handle this", plus perhaps some free form >>> field >>> for conveying info potentially useful to someone fixing >> things, should >>> be sufficient. >>> >>> Two possible variations on that: >>> >>> If we plan for options and extensions in the mechanism, and define >> some >>> rules for how those are handed, we may want a way to say "I didn't >>> understand x and skipped it". Right now I only see that for >> "extension >>> data", and I'm not certain we want to be chatty about that. >>> >>> Current thinking (not yet presented to the group) is that >> the messages >>> conveying metadata will consist of a sequence of individual >> packets of >>> metadata to be added to the collected metadata for the RS. >> There could >>> be a bunch of these in the message, and they will need to >> be processed >>> in sequence. If there is trouble along the way, it probably >> compromises >>> the ability to process subsequent pieces. >>> >>> We might want to treat the entire message as atomic, with all the >> stuff >>> in it being processed, or none of them. >>> >>> OR, we might want to say these are processed one by one >> until there is >>> a >>> problem, and then no more are processed. (Until when?) >>> >>> This has implications on the protocol for conveying these things, >>> especially since the "responses" will probably be delayed >> and the SRC >>> will not want for a response before sending more. >>> >>> My *inclination* right now is to perhaps sequence number the >> individual >>> metadata update packets, and have a response ack/nack up to a >>> particular >>> sequence number. If there is an error, then no more would >> be processed >>> until some handshake occurred. That would allow the updates to be >>> pipelined without regard to message boundaries. >>> >>> We also need a philosophy here. In general I think we must >> assume that >>> the SRC and SRS are implemented correctly. Once that has been proven >>> wrong, by detection of an error, there is a real question of whether >> to >>> attempt to continue the RS, or simply give it up. Just giving up and >>> dropping it has the merit of simplicity. OTOH, I know that often >>> recordings are essential, and so it may be better to keep going in >>> crippled form with as much as you can figure out. I don't have an >>> answer >>> here yet. >>> >>> Thanks, >>> Paul >>> >>>> Whole Metadata XML document error handling:: >>>> Any syntax of semantic error is seen in the XML document, >> the whole >>>> document will be rejected by SIP response code (like 415/488). >>>> Pros: >>>> 1) Here SRC has no need to decode XML document while receiving the >>> error >>>> response >>>> 2) Simple Implementation as the operation is success or >> failure only >>>> Cons: >>>> 1) Even most of the XML document is acceptable, the document is >>> rejected >>>> in SRS >>>> 2) It is not possible to identify the exact error >>>> Error handling for Portion of XML document:: >>>> Any syntax or semantic error has to be represented with >> the specific >>> XML >>>> element has the error. The portion of the xml element will be >>> identified >>>> by the id corresponding to the element. The error has to be passed >>> from >>>> SRS to SRC in the XML format with special XML syntax. say >> participant >>>> AOR is not accepted then XML error sends back to indicate that >>> partipant >>>> element is not accepted. >>>> Open item: >>>> 1) What SIP response code to be sent when the portion of >> the XML is >>>> accepted >>>> Pros: >>>> 1) The portion of the element will only be rejected and >> rest of the >>> XML >>>> is accepted in SRS. >>>> 2) Provide more granular control >>>> Cons: >>>> 1) SRC *MUST* be XML decoding functionality with response handling >> to >>>> identify the error >>>> 2) Complex design in nature for metadata itself >>>> Please provide your valuable input about which approach >> will be most >>>> suitable from SIPREC perspective. >>>> Thanks >>>> Partha >>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> 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 >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> From john.elwell@siemens-enterprise.com Mon Feb 28 07:34:48 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42673A69FD for ; Mon, 28 Feb 2011 07:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFfIcyky9TCS for ; Mon, 28 Feb 2011 07:34:47 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 77A1C3A6944 for ; Mon, 28 Feb 2011 07:34:47 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3572318; Mon, 28 Feb 2011 16:35:44 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2336023F02AC; Mon, 28 Feb 2011 16:35:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 28 Feb 2011 16:35:26 +0100 From: "Elwell, John" To: Leon Portman , siprec issue tracker Date: Mon, 28 Feb 2011 16:35:24 +0100 Thread-Topic: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants Thread-Index: AcvM6cpYQ57UUrunTBCS241IKWnf7AGlK6VwAAa0NbAA8LDpEA== Message-ID: References: <075.d9e0afcd7cf3ee35c38905ea3efdd6c9@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A78FCD61@TLVMBX01.nice.com> Keywords: SIPREC Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:34:48 -0000 There has been little discussion on this, apart from support from Leon. The= existing text says: "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." I would suggest the following text: "REQ-018 The mechanism MUST provide a means of indicating to the participan= ts involved in a CS that their session is being recorded. Although this can= be accomplished using existing SIP techniques for playing an in-band tone,= announcement or other media to participants, the mechanism is required als= o to provide an indication to recording-aware UAs for appropriate rendering= at the user interface." John (as individual)=20 > -----Original Message----- > From: Elwell, John=20 > Sent: 23 February 2011 20:36 > To: 'Leon Portman'; siprec issue tracker > Cc: siprec@ietf.org > Subject: RE: [siprec] Requirements #66 (new): Clarification=20 > of REQ-018 on indications to participants >=20 > My feeling too. >=20 > John (as individual)=20 >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > > Sent: 23 February 2011 17:25 > > To: siprec issue tracker; Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Requirements #66 (new): Clarification=20 > > of REQ-018 on indications to participants > >=20 > > Because supporting of siprec-aware UA indication will require=20 > > some additional protocol changes for CS, we probably should=20 > > have a separate requirement for that > >=20 > > Leon > >=20 > > -----Original Message----- > > From: siprec issue tracker [mailto:trac@tools.ietf.org]=20 > > Sent: Tuesday, February 15, 2011 10:24 AM > > To: Leon Portman; john.elwell@siemens-enterprise.com > > Cc: siprec@ietf.org > > Subject: [siprec] Requirements #66 (new): Clarification of=20 > > REQ-018 on indications to participants > >=20 > > #66: Clarification of REQ-018 on indications to participants > >=20 > > REQ-018 can be satisfied in general by playing media to=20 > > participants, but do we need a more specific requirement,=20 > > e.g., for siprec-aware UAs to know whether the CS is being=20 > > recorded or not? > >=20 > > John > >=20 > > --=20 > > ------------------------------------------------+------------- > > ---------- > > ------------------------------------------------+---- > > Reporter: john.elwell@... | =20 > > Owner: leon.portman@... =20 > > Type: defect | =20 > > Status: new =20 > > Priority: major | =20 > > Milestone: =20 > > Component: Requirements | =20 > > Version: =20 > > Severity: In WG Last Call | =20 > > Keywords: =20 > > ------------------------------------------------+------------- > > ---------- > > ------------------------------------------------+---- > >=20 > > Ticket URL: > > siprec > >=20 > > = From john.elwell@siemens-enterprise.com Mon Feb 28 07:36:18 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AE63A69F5 for ; Mon, 28 Feb 2011 07:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWbXHyLNWW62 for ; Mon, 28 Feb 2011 07:36:17 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8965E3A6944 for ; Mon, 28 Feb 2011 07:36:16 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3562307; Mon, 28 Feb 2011 16:37:15 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 24C971EB82B6; Mon, 28 Feb 2011 16:37:15 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 28 Feb 2011 16:37:15 +0100 From: "Elwell, John" To: Henry Lum , Leon Portman , Alissa Cooper Date: Mon, 28 Feb 2011 16:37:13 +0100 Thread-Topic: [siprec] Requirements #65 (new): Extension ofREQ-017 concerning preference to record/not record Thread-Index: AcvPlTtzsLrany/MSpm4wxMDal8zSwBakLPgAGi5IJABLbWdkA== Message-ID: References: <075.bbb33f46ac9ce9e91b16799102ac4fb6@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A697AEC1@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF7406B18708@NAHALD.us.int.genesyslab.com> Keywords: SIPREC In-Reply-To: <059AF07365DC474393A19A3AF187DF7406B18708@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" , siprec issue tracker Subject: Re: [siprec] Requirements #65 (new): Extension ofREQ-017 concerning preference to record/not record X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:36:18 -0000 There seems to be consensus to expand on REQ-017 along the lines proposed i= n my earlier message. Although one person preferred to pick either pause or= stop for discontinuation, but others who responded preferred to keep both = options. Therefore I think REQ-017 can be replaced by two new requirements: "REQ-yyy The mechanism MUST support a means for a recording-aware UA involv= ed in a CS to request at session establishment time that the CS should be r= ecorded or should not be recorded, the honoring of such a request being dep= endent on policy." "REQ-zzz The mechanism MUST support a means for a recording-aware UA involv= ed in a CS to request during a session that the recording of the CS should = be started, paused, resumed or stopped, the honoring of such a request bein= g dependent on policy." In the interests of making progress, if I hear no objections to this by tom= orrow (2011-03-01) I will ask the editor to include this in the next draft = (there will still be time for a quick check of that before it goes to the I= ESG). John (as chair). > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 > Sent: 22 February 2011 15:09 > To: Leon Portman; Alissa Cooper; Elwell, John > Cc: siprec@ietf.org; siprec issue tracker > Subject: RE: [siprec] Requirements #65 (new): Extension=20 > ofREQ-017 concerning preference to record/not record >=20 > +1 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Leon Portman > > Sent: Sunday, February 20, 2011 8:11 AM > > To: Alissa Cooper; Elwell, John > > Cc: siprec@ietf.org; siprec issue tracker > > Subject: Re: [siprec] Requirements #65 (new): Extension ofREQ-017 > > concerning preference to record/not record > >=20 > > +1 > >=20 > > We need both pause and stop. In both cases SRS need to know=20 > when CS is > > ended. > >=20 > > Leon > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Alissa Cooper > > Sent: Friday, February 18, 2011 7:56 PM > > To: Elwell, John > > Cc: siprec@ietf.org; siprec issue tracker > > Subject: Re: [siprec] Requirements #65 (new): Extension of REQ-017 > > concerning preference to record/not record > >=20 > > On Feb 15, 2011, at 8:34 AM, Elwell, John wrote: > >=20 > > > I think we need to cover the following cases: > > > - 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. > >=20 > > +1 > >=20 > > > > > > Concerning discontinuation, we could discuss whether this=20 > means stop > > > or pause. With pause, you could later resume that same recording. > > > With stop, you would effectively terminate the recording,=20 > such that > > > you would need to start a new recording if you need to=20 > record later > > > during the CS. The handling of metadata would differ - in=20 > 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=20 > know which of > > > these we want (perhaps both). > >=20 > > Seems like both might be useful, but I have no strong opinion here. > >=20 > > Alissa > >=20 > > > > > > John (as individual) > > > > > > > > >> -----Original Message----- > > >> From: siprec issue tracker [mailto:trac@tools.ietf.org] > > >> Sent: 15 February 2011 08:21 > > >> To: krehor@cisco.com; Elwell, John > > >> Cc: siprec@ietf.org > > >> Subject: [siprec] Requirements #65 (new): Extension of > > >> REQ-017 concerning preference to record/not record > > >> > > >> #65: Extension of REQ-017 concerning preference to record/not > record > > >> > > >> We have "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". > > >> > > >> Should this be extended to cover a request during a CS, and also > the > > >> ability during a CS to request that recording be=20 > allowed? In other > > >> words, the ability for a participant to indicate a preference for > > >> recording or not recording, at the start of a CS or during a CS. > > Note > > >> that such a requirement would be realisable only from a > siprec-aware > > >> UA. > > >> > > >> This is related to REQ-011 (pause/resume), but with the=20 > difference > > >> that it is the participant who expresses the preference (REQ-011 > > >> seems to imply the SRC decides). So in considering any possible > > >> rewording of REQ-017, we should perhaps consider its relationship > to > > >> REQ-011. > > >> > > >> John > > >> > > >> -- > > >> ------------------------------------------------+------------- > > >> -------------- > > >> Reporter: john.elwell@... | > > >> Owner: krehor@... > > >> Type: defect | > > >> Status: new > > >> Priority: major | > > >> Milestone: > > >> Component: Requirements | > > >> Version: > > >> Severity: In WG Last Call | > > >> Keywords: > > >> ------------------------------------------------+------------- > > >> -------------- > > >> > > >> Ticket URL:=20 > > > >> siprec > > >> > > >> > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > >=20 > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 > =09 > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > = From john.elwell@siemens-enterprise.com Mon Feb 28 07:37:26 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72623A6943 for ; Mon, 28 Feb 2011 07:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ0KSJXS5Gdn for ; Mon, 28 Feb 2011 07:37:26 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5EEEF3A69F5 for ; Mon, 28 Feb 2011 07:37:25 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3570965; Mon, 28 Feb 2011 16:37:54 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 22C9123F0278; Mon, 28 Feb 2011 16:37:54 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 28 Feb 2011 16:37:54 +0100 From: "Elwell, John" To: Leon Portman , siprec issue tracker Date: Mon, 28 Feb 2011 16:37:52 +0100 Thread-Topic: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancelling a recording Thread-Index: AcvM5yx8db2rSuMRR8i7RWhgEqXmLQAAyekgAaSy6AAA93L4gA== Message-ID: References: <075.d0db8f34c277334b137156e493ae53f5@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A78FCD5E@TLVMBX01.nice.com> Keywords: SIPREC In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38A78FCD5E@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #64 (new): REQ-015/REQ-016 and cancelling a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:37:27 -0000 I heard no more proposals on this. Everyone who responded on tickets #63 an= d #64 was in favour of deleting REQ-015 and REQ-016, so the question remain= s whether we can add in place of REQ-015/REQ-016: "REQ-xxx The mechanism MUST support a means to stop the recording", as proposed by Leon. In the interests of making progress, if I hear no objections to this by tom= orrow (2011-03-01) I will ask the editor to include this in the next draft = (there will still be time for a quick check of that before it goes to the I= ESG). John (as chair). > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 23 February 2011 17:20 > To: Elwell, John; siprec issue tracker > Cc: siprec@ietf.org > Subject: RE: [siprec] Requirements #64 (new): REQ-015/REQ-016=20 > and cancelling a recording >=20 > I am not very comfortable of treating pausing of the=20 > recording as a canceling of the recording. Pausing of the=20 > recording usually will keep recording channel allocated and=20 > not available for other recordings until end of the call.=20 > Canceling/stopping recording will release the channel. >=20 > So I may be we need a requirement for just stopping=20 > recording, like this: >=20 > "The mechanism MUST support a means to stop the recording".=20 > I remember that we have multiple discussion about it >=20 > The actual request of discarding of the recording media and=20 > metadata is out of scope and should be handled by policy=20 > server (Ticket #63) >=20 > Leon >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, February 15, 2011 10:31 AM > To: siprec issue tracker; Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] Requirements #64 (new): REQ-015/REQ-016=20 > and cancelling a recording >=20 > I think we don't need a special requirement on cancelling,=20 > given the existence of REQ-011 on pause/resume and REQ-017 on=20 > requesting no recording. Depending on the resolution of=20 > ticket #63, I believe REQ-015 and REQ-016 can be deleted. >=20 > John (as individual)=20 >=20 > > -----Original Message----- > > From: siprec issue tracker [mailto:trac@tools.ietf.org] > > Sent: 15 February 2011 08:06 > > To: leon.portman@nice.com; Elwell, John > > Cc: siprec@ietf.org > > Subject: [siprec] Requirements #64 (new): REQ-015/REQ-016 and=20 > > cancelling a recording > >=20 > > #64: REQ-015/REQ-016 and cancelling a recording > >=20 > > Do we need any requirement concerning cancelling a recording? We=20 > > already have REQ-011 on pausing and resuming, and pausing without=20 > > subsequently resuming can probably be considered to be=20 > cancelling the=20 > > recording. If the resolution of ticket #63 results in no=20 > requirement=20 > > for discarding a recording, and if REQ-011 is considered to cover=20 > > cancelling a recording, can REQ-015 and REQ-016 be removed=20 > entirely? > >=20 > > John > >=20 > > -- > > ------------------------------------------------+------------- > > -------------- > > Reporter: john.elwell@... | =20 > > Owner: leon.portman@... =20 > > Type: defect | =20 > > Status: new =20 > > Priority: major | =20 > > Milestone: =20 > > Component: Requirements | =20 > > Version: =20 > > Severity: In WG Last Call | =20 > > Keywords: =20 > > ------------------------------------------------+------------- > > -------------- > >=20 > > Ticket URL: > > siprec > >=20 > >=20 > = From trac+siprec@trac.tools.ietf.org Mon Feb 28 07:40:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE193A69F3 for ; Mon, 28 Feb 2011 07:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c17WfN-XCBzR for ; Mon, 28 Feb 2011 07:40:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 280B63A6944 for ; Mon, 28 Feb 2011 07:40:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pu5Df-0003Pl-6i; Mon, 28 Feb 2011 07:41:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: leon.portman@nice.com, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Mon, 28 Feb 2011 15:41:07 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/63#comment:1 Message-ID: <084.9a150948287f24ef3f39d680bb2d1369@trac.tools.ietf.org> References: <075.13fa3cf5cb60742d46f34fcd19b8f580@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <075.13fa3cf5cb60742d46f34fcd19b8f580@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leon.portman@nice.com, john.elwell@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 28 Feb 2011 07:42:23 -0800 Cc: siprec@ietf.org Subject: Re: [siprec] #63: REQ-015/REQ-016 and discarding recordings X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:40:09 -0000 #63: REQ-015/REQ-016 and discarding recordings Changes (by john.elwell@…): * status: new => closed * resolution: => fixed Comment: I think we can close this. We agree there should be no requirement on discarding, although the fate of REQ-015/REQ-016 depends on ticket #64. -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: leon.portman@… Type: defect | Status: closed Priority: major | Milestone: Component: Requirements | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Ticket URL: siprec From Henry.Lum@alcatel-lucent.com Mon Feb 28 08:12:22 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA793A69FE for ; Mon, 28 Feb 2011 08:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrvdoydVTWac for ; Mon, 28 Feb 2011 08:12:22 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id D81993A69FC for ; Mon, 28 Feb 2011 08:12:21 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p1SGDLXe017798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Feb 2011 10:13:21 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1SGDJRQ031605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Feb 2011 10:13:20 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p1SGDIET015269; Mon, 28 Feb 2011 08:13:19 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 08:13:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 08:13:17 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406BAE02F@NAHALD.us.int.genesyslab.com> In-Reply-To: <4D6BBDAE.3020808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata XML document error representation for whole doc or for portion of doc Thread-Index: AcvXW03ON+nfMVCWQ8GPwSpOJaYBQQABrURQ References: <4D67EC69.7080507@cisco.com> <059AF07365DC474393A19A3AF187DF7406BADEA6@NAHALD.us.int.genesyslab.com> <4D6BBDAE.3020808@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 28 Feb 2011 16:13:18.0884 (UTC) FILETIME=[699CC640:01CBD762] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: siprec@ietf.org Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:12:23 -0000 =20 > >> We are also thinking of providing the SRS > >> with a mechanism to request the SRC to ask for the current snapshot > so > >> that the SRC/SRS can reset the states in the case where SRS is in a > >> really bad state. By doing so, we may be able to avoid providing > nack > >> responses and avoid using a chatty protocol. > > [JRE] Yes, and the request to resend full metadata could optionally > include some sort of error report that gave rise to the request. That > error report could, for example, include the sequence number of the > metadata update that was found to be in error. >=20 > That is sort of what I had in mind about getting the two sides in sync. > But we will have to think more about exactly what it means. > At best I think it will describe the *current* state of things in this > RS, without regard to what has happened in the past. >=20 > Even that may present some technical challenges. But we should keep > this > desire in mind. [[hlum]] I agree it would be reasonable for the SRC to send the current state as a snapshot and forget what happened previously. The subsequent sequence numbers only refers to the current snapshot rather than the original one, so in a way we are resetting the sequence number. =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From Leon.Portman@nice.com Mon Feb 28 08:15:51 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA743A69FC for ; Mon, 28 Feb 2011 08:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exbFa2weuM8N for ; Mon, 28 Feb 2011 08:15:51 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id A5A883A693B for ; Mon, 28 Feb 2011 08:15:50 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 28 Feb 2011 18:16:50 +0200 From: Leon Portman To: "Elwell, John" , siprec issue tracker Date: Mon, 28 Feb 2011 18:16:49 +0200 Thread-Topic: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants Thread-Index: AcvM6cpYQ57UUrunTBCS241IKWnf7AGlK6VwAAa0NbAA8LDpEAABtcZQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38A81E5A0B@TLVMBX01.nice.com> References: <075.d9e0afcd7cf3ee35c38905ea3efdd6c9@tools.ietf.org> <07465C1D981ABC41A344374066AE1A2C38A78FCD61@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:15:52 -0000 +1 Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, February 28, 2011 5:35 PM To: Leon Portman; siprec issue tracker Cc: siprec@ietf.org Subject: RE: [siprec] Requirements #66 (new): Clarification of REQ-018 on i= ndications to participants There has been little discussion on this, apart from support from Leon. The= existing text says: "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." I would suggest the following text: "REQ-018 The mechanism MUST provide a means of indicating to the participan= ts involved in a CS that their session is being recorded. Although this can= be accomplished using existing SIP techniques for playing an in-band tone,= announcement or other media to participants, the mechanism is required als= o to provide an indication to recording-aware UAs for appropriate rendering= at the user interface." John (as individual)=20 > -----Original Message----- > From: Elwell, John > Sent: 23 February 2011 20:36 > To: 'Leon Portman'; siprec issue tracker > Cc: siprec@ietf.org > Subject: RE: [siprec] Requirements #66 (new): Clarification of REQ-018=20 > on indications to participants >=20 > My feeling too. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 23 February 2011 17:25 > > To: siprec issue tracker; Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Requirements #66 (new): Clarification of=20 > > REQ-018 on indications to participants > >=20 > > Because supporting of siprec-aware UA indication will require some=20 > > additional protocol changes for CS, we probably should have a=20 > > separate requirement for that > >=20 > > Leon > >=20 > > -----Original Message----- > > From: siprec issue tracker [mailto:trac@tools.ietf.org] > > Sent: Tuesday, February 15, 2011 10:24 AM > > To: Leon Portman; john.elwell@siemens-enterprise.com > > Cc: siprec@ietf.org > > Subject: [siprec] Requirements #66 (new): Clarification of > > REQ-018 on indications to participants > >=20 > > #66: Clarification of REQ-018 on indications to participants > >=20 > > REQ-018 can be satisfied in general by playing media to=20 > > participants, but do we need a more specific requirement, e.g., for=20 > > siprec-aware UAs to know whether the CS is being recorded or not? > >=20 > > John > >=20 > > -- > > ------------------------------------------------+------------- > > ---------- > > ------------------------------------------------+---- > > Reporter: john.elwell@... | =20 > > Owner: leon.portman@... =20 > > Type: defect | =20 > > Status: new =20 > > Priority: major | =20 > > Milestone: =20 > > Component: Requirements | =20 > > Version: =20 > > Severity: In WG Last Call | =20 > > Keywords: =20 > > ------------------------------------------------+------------- > > ---------- > > ------------------------------------------------+---- > >=20 > > Ticket URL: > > siprec > >=20 > >=20 From Leon.Portman@nice.com Mon Feb 28 08:17:23 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B01C3A69F9 for ; Mon, 28 Feb 2011 08:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFYyLofKDz-L for ; Mon, 28 Feb 2011 08:17:22 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 2E6093A693B for ; Mon, 28 Feb 2011 08:17:22 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 28 Feb 2011 18:18:22 +0200 From: Leon Portman To: Henry Lum , Paul Kyzivat , "Elwell, John" Date: Mon, 28 Feb 2011 18:18:21 +0200 Thread-Topic: [siprec] Metadata XML document error representation for whole doc or for portion of doc Thread-Index: AcvXW03ON+nfMVCWQ8GPwSpOJaYBQQABrURQAABGHZA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38A81E5A0C@TLVMBX01.nice.com> References: <4D67EC69.7080507@cisco.com> <059AF07365DC474393A19A3AF187DF7406BADEA6@NAHALD.us.int.genesyslab.com> <4D6BBDAE.3020808@cisco.com> <059AF07365DC474393A19A3AF187DF7406BAE02F@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406BAE02F@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:17:23 -0000 +1 Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Henry Lum Sent: Monday, February 28, 2011 6:13 PM To: Paul Kyzivat; Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] Metadata XML document error representation for whole = doc or for portion of doc =20 > >> We are also thinking of providing the SRS with a mechanism to=20 > >> request the SRC to ask for the current snapshot > so > >> that the SRC/SRS can reset the states in the case where SRS is in a=20 > >> really bad state. By doing so, we may be able to avoid providing > nack > >> responses and avoid using a chatty protocol. > > [JRE] Yes, and the request to resend full metadata could optionally > include some sort of error report that gave rise to the request. That=20 > error report could, for example, include the sequence number of the=20 > metadata update that was found to be in error. >=20 > That is sort of what I had in mind about getting the two sides in sync. > But we will have to think more about exactly what it means. > At best I think it will describe the *current* state of things in this=20 > RS, without regard to what has happened in the past. >=20 > Even that may present some technical challenges. But we should keep=20 > this desire in mind. [[hlum]] I agree it would be reasonable for the SRC to send the current sta= te as a snapshot and forget what happened previously. The subsequent sequen= ce numbers only refers to the current snapshot rather than the original one= , so in a way we are resetting the sequence number. =09 ---------------------------------------------------------------------------= ---------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. =09 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec