Minutes of the SIPREC WG Session at IETF 78, Maastricht, NL, 2010-07-30, 13.00-15.15 GMT+2 =============================================== Meeting chaired by Brian Rosen and John Elwell. Minutes produced by John Elwell based on notes from Henry Lum and Matt Lepinski. Jabber log: http://www.ietf.org/jabber/logs/siprec/2010-07-30.txt Meeting started at 13.00. Topic - Administrivia (chairs) ============================== http://www.ietf.org/proceedings/78/slides/siprec-1.ppt No changes to published agenda. A correction to the chairs' slides was noted - the latest requirements document is req-00, not req-01. Topic - Requirements (Ken Rehor) draft-ietf-siprec-req-00 ================================ http://www.ietf.org/proceedings/78/slides/siprec-4.pptx Ken noted that a working version of 01 had been circulated to the list, but the version officially posted is 00. Ken will continue to work on 01. Concerning REQ-017, Andy Hutton questioned whether it should be a single recording session rather than multiple. Leon Portman indicated it would depend on whether metadata is inside or outside a recording session. John Elwell (chair) suggested that whether it is inside or outside a recording session is probably beyond the scope of the requirements document. Paul Kyzivat was happy with the present vagueness of the requirement. Deepanshu saw no use cases for metadata describing multiple CSs being recorded. Partha would like to see CS defined. Simon Romano stated that we should have the ability to reproduce the CS in the recording for playback, but he was OK with the wordking of REQ-017/-018. This last point has apparently been raised on the list and should be captured in the tracker (action Ken). The chairs asked for consensus whether there were strong objections to the current text, and no objections were raised. While discussing the newly proposed REQ-023 on the slides (request that a session not be recorded), Alissa Cooper said there should be a requirement for stopping the recording mid-call and deleting the recording. It was agreed that Alissa should post this to the list and Ken should capture it in the tracker. Hadriel Kaplan was concerned that requirements of this nature (pause/resume/stop) are at the "solution" level rather than at the "protocol" level, and perhaps are not needed, but the chairs explained that a solution whereby the client can control recording is still required at some layer or other. It was concluded that the text of the requirement should be worded in terms of SRC rather than UA. Concerning REQ-023, Hadriel Kaplan was concerned about the endpoint needing to support SIPREC extensions in order to control recording or be aware recording is taking place, and believed instead that this is the job of the SRC, as a middlebox. After some discussion, it was agreed this should be taken to the list, in particular whether this indication is at the user level or the SIP UA level. Concerning REQ-025/026, it was noted that the slide is in error - the new wording is for REQ-025/026, and not for REQ-026/027. In reply to a question from Hadriel Kaplan, it was clarified that REQ-030 is a requirement for a header for the RS, not the CS. Concerning ticket #40, on "what is real-time?", Paul Kyzivat asked whether it really matters, or whether other factors such as the reliability of recorded media are more important. Brian Rosen concurred that the control of recorded media is what really matters. The ticket needs to be enhanced to discuss the tradeoff between real-time and reliability - action on Ken. Concerning use case 10 (high availability), Partha believes that we should not be required to come up with a mechanism for high availability. Leon suggested we may need rapid detection of failure, buffering during switchover, etc., to support such a requirement. After some discussion, John Elwell (as individual) proposed rewording the requirement along the lines of "the mechanism MUST NOT prevent high availability deployments", and this seemed to find favour. On deferred items in general, it was questioned how to handle them. The chair asked how to cover in the requirements document those items for which we don't intend providing a solution in "version 1" (bearing in mind we are looking to have something within one year). There appeared to be concensus to omit from the requirements document those items not needed for "version 1". On security, it was stated by the Brian Rosen (as individual) that security is a sensitive area and that we need to be explicit. Ken wants to have requirements to ensure the mechanism supports different regulatory requirements. Several pointed out complexities here. In particular, James Polk pointed out differences between states in the US, with some having requirements for one party to agree to recording and some having requirements for two parties to agree to recording. James was asked to post something to the list on this. Discussion on security requirements should continue on the list, but the chairs pointed out that requirements should be kept at requirements level, without diving down to architecture and mechanism. In summary, Ken will produce an -01, reflecting consensus from this meeting (having sought consensus on the list too). We need energy on the list DURING AUGUST to close the remaining issues and get this document ready for WGLC in September. Topic - Architecture (Andy Hutton) draft-ietf-siprec-architecture-00 ==================================================================== http://www.ietf.org/proceedings/78/slides/siprec-3.ppt No comments on proposal for ticket #17. On ticket #38 (conferencing), Brian Rosen pointed out that the IETF provides a number of useful things for metadata, such as list of conference members, XCON- related things. Deepanshu wanted to know whether this conference situation fitted into either of the present architectural models in the draft, if so how, and if not, do we need another model. Andy believes it fits into an existing model - the SRC is an endpoint in the conference - and will add some clarifying text. Simon Romano would like to see more clarification on how the architecture fits with MediaCtrl, and why MediaCtrl cannot be used. Simon had submitted information on the list earlier, and did not find sufficient information in the draft as to why MediaCtrl is considered out of scope. Brian Rosen asked that Simon identify what part of the architecture document should be changed in order to use MediaCtrl. Simon said no part should be changed. Brian interpreted this is meaning that when we get to mechanisms we should consider MediaCtrl. Simon clarified that the requirements (in the requirements document) could all be solved by MediaCtrl, but the architecture document does not give a good reason for not using MediaCtrl. Mary Barnes stated that the solution is not going to be complete without describing more of the functionality, and it should not be difficult to go ahead and do the mapping as to how you might use MediaCtrl. The chair indicated contributions would be welcome if more text is needed in the architecture document. Brian Rosen stated that the information already sent by Simon was not specific about text changes required. Hadriel preferred to see a separte draft on how MediaCtrl could be used to solve the problem. Simon pointed out that draft-romano-dcon-recording-01 is already available. Andy stated that he and others had read it several times, but don't see how it fits and need an explanation. Eric Burger pointed out that along with the draft comes running code. No comments on proposal for ticket #39. Concerning how to satisfy REQ-013 from the requirements draft (multiple recording sessions for a single communication session), Henry Lum had a concern that this requirement is really needed for the customer-agent-supervisor case where the agent and supervisor are on different sites and can use separate media relays to provided recorded media to the SRS. Since the contact centre as SRC understands the context of a CS, it should be able to provide metadata to tie them together. Andy responded that the agent and supervisor can be considered as belonging to separate CSs, and let the SRS figure out, using heuristics, that the two CSs are related. Responding to a question from Deepanshu, Andy clarified that all media for a single CS should be associated with a single RS. Deepanshu was concerned this would not meet all requirements, e.g., for dynamic recording. John Elwell asked if Deepanshu was concerned about the case where an RS is stopped, because recording is stopped, and later in the same CS recording is started again, resulting in a new RS for the same CS. It seems wording needs to take account of this. Andy clarified that the intention is not to split the streams at any one time between different RSs. Henry Lum still had a concern that by removing REQ-013 it would prevent a decomposed SRC from using multiple RSs for a single CS. Brian asked whether Henry wanted a server controlling a number of different media servers. Henry still doubted whether it had to be a single RS. Brian said the multiple media servers would be invisible to what we are describing, and Andy agreed with this. It comes back to the question of whether this is modelled as one or more CSs. John Elwell (chair) stated that we need wording that does not preclude the arrangement that Henry has in mind. To continue on list. Concerning the need to show a Policy Server, Andy suggested it would be outside the scope of SIPREC, i.e., the decision whether or not to record a CS is outside the scope of SIPREC. Paul Kzyivat thought that the original proposal for a Policy Server was that it be associated with the SRS. In view of time, need to take this to the list. No commnt on "What is a CS" slide. Deepanshu pointed out that there is a section in the draft about media transcoding, which should be taken out since there is now no longer a requirement. The next steps will be to update the architecture draft, and further review will be needed. At the end of the meeting there were a few minutes left to address a question for which there was no time during the architecture presentation. Hadriel Kaplan asked whether we really care about both sides of a B2BUA. B2BUAs tend to change things like dialog identifiers and phone numbers, perform transcoding, etc., so do we really need two lots of metadata, or should we just consider one side of the B2BUA? Paul Kyzivat stated that it is not pre-ordained that a CS has to be a dialog - we can make it be what we want it to be. Brian Rosen (as individual) thinks it is hard for us to imagine why anything that B2BUAs do matters to us - we can just treat it as one CS. For each metadata item, we should ask whether this is impacted by a B2BUA in the path. Paul suggested that we need to study various use cases - this should be taken to the list. Topic - Metadata model(Paul Kyzivat) ================================ http://www.ietf.org/proceedings/78/slides/siprec-0.pptx Paul stressed this is just a strawhorse proposal to get the discussion going. Hadriel agreed we need something to define the concept and that it should not be XML at this stage. He wondered whether it should not even go as far as using a relation model, but just focus on data. It should go in a separate document (which would not necessarily become an RFC), not the architecture document. Ken Rehor supported this work and agreed it should not go in the architecture document. James Polk also supported the work and wanted to scope/define metadata as closely as possible. Deepanshu wanted to know if all the metadata shown on the slide would be transferred from SRC to SRS. Paul answered that this models what the metadata is, and a later step would be to determine how the SRS gets it. Deepanshu says some of this is about the recording session, and this might not need to be sent. Paul says some of it can be inferred. John (as chair) said it is good to have the model, but when we pick a solution some parts might be intrinsically provided and others might require extension of the basic solution. Also some might not need to be retained at the SRS once the RS is complete. There was a question from the Jabber room concerning metadata containing simultaneous XMPP. Paul Kyzivat thought this was out of scope. Brian (as chair) thought this wasn't entirely clear, but the present scope of SIPREC appears to be only RTP media, but in longer term we will need to capture non-RTP media. Real-time text (RFC 4103) is clearly in scope. A hum was taken as to whether this work is useful and should somehow be incorporated into our work. Unanimously in favour. A second hum was taken as to whether this should be a in a separate document, as opposed to part of the architecture document. Strongly in favour - one person humming insistently against. Topic - Call control extensions (Alan Johnston) draft-johnston-siprec-cc-rec-00 ================================ http://www.ietf.org/proceedings/78/slides/siprec-2.pptx Brian Rosen asked whether this approach eliminated the need for a discovery mechanism. Alan answered yes, feature tags are themselves a form of discovery mechanism. John Elwell pointed out that they are not a replacement for an authentication mechanism. Andrew Allen asked if the sip.src and sip.srs tags were mutually exclusive. Was wondering why we don't have an enumerated list (i.e., single tag with values, rather than separate tags). That might work. Paul Kyzivat pointed out that the caller preferences mechanism is optional. Concerning the whole proposal, Paul Kyzivat stated that this proposal is putting the cart before the horse, in that we are not far enough advanced with requirements and architecture. It's good to have the proposals on the table, so that at some point in the future we can decide. The chairs encouraged Alan to pursue the topic as requirements and architecture get refined. Wrap-up ================================ Before closing the meeting, the chairs suggested that we might hold an interim virtual meeting, perhaps in late September. The importance of thrashing out the requirements issues during August in preparation for WGLC in September was re- iterated. The meeting was closed at 15.15.