Minutes of the SIPREC WG Meeting, IETF#79, Beijing 2010-11-10, 13.00-15.00 GMT/UTC+8 =============================================== Meeting chaired by Eric Burger (standing in for Brian Rosen) and John Elwell. Minutes produced by John Elwell based on notes from Andy Hutton and Peter Musgrave. Jabber log: http://www.ietf.org/jabber/logs/siprec/2010-11-10.txt Meeting started at 13.00. Topic - Administrivia (chairs) ============================== Slides: http://www.ietf.org/proceedings/79/slides/siprec-1.ppt No changes to published agenda. Topic - Requirements (Paul Kyzivat, on behalf of Ken Rehor) draft-ietf-siprec-req-04 ================================ Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ Slides: http://www.ietf.org/proceedings/79/slides/siprec-2.pdf Slide 5 - REQ-04 - New proposed text on pause/resume, has been on the list. No concerns from the room. Slide 6 - REQ-50 - Aauthorization Since RS establishment in direction SRS to SRC has been declared out of scope, we only need to consider RS establishment from SRC to SRS, and hence SRS authorization of SRC. But that should be an internal matter for the SRS (in accordance with its policy). No objection to removing REQ-050. Slide 7 - Privacy This asked the question whether we needed a GEOPRIV-type archictecture for privacy, with a rule-maker entity and the need to convey rules. John (as individual) pointed out that there had been a lot of off-line discussion leading to a list proposal from himself for text for a simpler approach, which reflected the enterprise-type environments where session recording is typically deployed. The proposal had received some expert feedback from Alissa. We should continue that discussion on the list, rather than spending time on this slide. Alissa Cooper stated that she agrees with the proposal not to go down the GEOPRIV route. Slide 8 - Indication of Recording Reason Alissa Cooper stated that, although she had suggested on the list that there perhaps should be a requirement to indicate the reason or purpose of recording to a participant, she did not intend a standardized list of purposes. John pointed out that a recorded announcement could convey the purpose to a customer and the agent would know through employment contract, say. However, the question remains whether a machine-understandable indication of purpose is needed (in signalling) and whether such purposes need to be standardized. After some discussion, the feeling of the room was that the proposed new requirement on recording reason or purpose is not required. Slide 9 : Privacy and request to clarify scope There was a long discussion about whether SIPREC is only to be used when participants are informed they are being recorded, with the general feeling that saying it can be used when participants are not informed amounts to allowing wiretapping. The charter requires a mechanism for informing participants. Many people seemed to be of the opinion that the solution would need to say that participants MUST be informed. However, enforcing deployments to do this is another matter, and there was also mention, for example, of US states that require only one party to be informed. It was not clear exactly what form of statement should appear in the requirements document. Discussion to continue on the list. Slide 10: Confidentiality etc. It was noted by Ken that the very generic security requirement has been expanded into new sections. Slide 11: Recording a conference Charles Eckel pointed out that media comes from many participants, but the server gives each participant different audio based on the loudest speakers. So how does a recorder have a view of the total and what each participant receives? Paul clarified that there are two points of view. We could record the view as a participant in the conference. Or it could be special, i.e. the SRC could be the focus and have a special relationship and record in a different way. Brian also noted an arrangement whereby the SRC could REFER the SRS into the conference, but some thought this was a more complex situation that should perhaps be out of scope at present. We need more concrete proposals if new requirements are needed for conferences (as opposed to just an impact on the metadata model). Slide 12: Media Delays: Paul Kyzivat stated that it is not sufficient for the SRC to buffer data for the whole call and send it to SRS at the end of the call. But on the other hand, the SRC might not be able to deliver the media to the SRS intantaneously. Therefore is there a specific requirement on the maximum delay in getting information to the SRS? Eric Burger wondered whether this is not purely an implementation matter, and in two years time it will be faster anyway. James Polk pointed out that we might not want the transport to be UDP, since you might not want to lose packets. John suggested we could put this into a "desired" section for SHOULDs - we want this in seconds not days, since you may need to play back the recording while it it still in progress. Leon Portman pointed out that with current implementations the SRS thinks it is receiving data in real-time, although there could be delays because of transcoding etc. We may need to report the delay to ensure correct playback. RTP does not carry wall clock time. Paul Kyzivat noted that there is a different requirement about when media was generated. John (as chair): Can someone propose a wall clock time REQ? John (as chair): Some people want to listen to something (with a short time lag) while the call is still being recorded. Is anyone keen to have a requirement, or can it wait for solution? There was no response to this. John: So there is a requirement for a wall clock time. Next Steps: We should continue discussion on the list over the new few days, particulary on privacy, notification and security, before capturing results to date in -05. Topic - Metadata model(Ram Mohan) draft-ram-siprec-metadata-01 ================================================ Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ Slides: http://www.ietf.org/proceedings/79/slides/siprec-0.ppt Slide 5/6: Recording Session John (as individual) noted that RS figures in model only because this is the way the data is delivered, so Recording Reason doesn't seem appropriate as an attribute of this object. After some discussion it was agreed to take this out, unless somebody comes forward with particular values for this attribute. Slide 7/8: Communication Session Group (CSG) John pointed out that this arose from cases where sessions on-hold or involved in call transfer were somehow linked, in particular where they had been delivered by different SRCs. Ram asked whether we need application data. Paul observed that there had been some discussion on list about other ways to model relationships between CSs or make CSG optional - most differences are superficial. This present proposal seems to do the job. John suggested we seek input on the list. Slides 9/10/11: Communication Session Paul pointed out that Participants used to be linked to media - but we changed this to link Participant to CS. Here we relate it to the signalling. There are other ways. John asked for clarification whether, if I get your name from the SIP conference event package, you are a participant by signalling. Paul was not sure but thinks not, and Ram agreed. John (as chair) called for better articulation on the list to understand implications. John asked why a participant can be associated with more than one CS, and Ram pointed out the transfer case. There was dicussion on the direction and initiator attributes, which needs to be taken to the list. Ram asked whether other attributes are needed, and whether Application Data is needed. There was silence, to which John (as chair) deduced the answer was "no", but Paul thought things would come to light in due course. Slides 12/13: Participant Peter Musgrave asked if we want Contact/GRUU as an attribute, so that we know which exact UA was involved. Paul stated that it sounds reasonable, and that we are likely missing lots of stuff. Leon Portman confirmed there is lots of stuff we need to add, including privacy stuff, MAC, IP address, multi-line etc. Paul asked for text to be sent. Paul pointed out that earlier models did not show a receiving relationship. Mixing policies are also not in the data model here, but it could get very complicated. Leon asked whether we want to calculate volume etc. or record that a person turned down their volume. Slides 14/15: Media Stream Peter Musgrave asked how do I know if sent media streams are left and right? Eric asked what are units for start/end. We did agree we needed to record wall time, so maybe this is the place. Paul called for help from people who understand media to indicate what we need here. Charles Eckel stated that in terms of video will need something about what granularity you can search to - you need an I-frame frequency or a list of where I frames are. We need text. Ram asked whether we need to model information which did not get recorded (i.e. that video was declined) Leon Portman replied yes, there may be cases where we want to know video was an option. We can just reflect what the communication session offered. John asked: Suppose you offer audio+video for recording and only audio is accepted - does the SRS need to know if video is subsequently paused? Leon replied yes, I think so. No other proposals, so if more is needed in model to reflect this, we need text. Ram asked whether privacy stuff should go here. We probably have the answer from the privacy discussions on the requirements document. Slide 16: Application Data Ram said this can be attached to anything, but is hearing people want other stuff which could fit in here. e.g. location data. John observed that there may be some similarity between this and the ECRIT discussion on additional data - should take a look at that. Slide 17: Next Steps The next steps are to produce a further revision of the draft reflecting these discussions and adding use cases. The delivery mechanism is proposed to be kept as a seperate draft. John (as chair) stated that we need input in a number of areas before we can adopt this. We do not currently have this as a milestone - but will ask the ADs, since it probably makes sense to have this as a separate deliverable. Gonzalo clarified that changing or adding milestones is OK, as long as they remain covered by charter text. John noted that there seems to have been less input on this topic than there was on the requirements document, so let's try to get more input on the list. Paul was concerned that it was not really clear at present what wants doing next. John suggested asking specific questions as separate threads on the list. Sohal pointed out that for video you need a lot of additional metadata, beyond just the codec. Wrap-up ================================ John wants to continue the practice of having a couple of interim virtual meetings between IETF meetings, in which case the next one would probably be in mid December. So the authors / editors should try to have the docs revved by then. Hadriel strongly recommended holding a physical face to face interim meeting. John was concerned whether we would have sufficient participation, but will organise a Doodle poll for a meeting sometime in January/February. The meeting was closed at 14.57.