Minutes of the SIPREC WG Interim Virtual Meeting 2010-12-16, 14.00-16.00 GMT/UTC =============================================== Meeting chaired by Brian Rosen and John Elwell. Participants: Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum, Ram Mohen, Andy Hutton, Alan Johnston, Mary Barnes, Hadriel Kaplan, Gonzalo Camarillo, Paul Kyzivat, Dave Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel, PM, Raj Jain. Minutes produced by John Elwell based on notes from Andy Hutton. Jabber log: http://www.ietf.org/jabber/logs/siprec/2010-12-16.txt (There was no activity) Meeting started at 14.05. Topic - Administrivia (chairs) ============================== Slides: http://kenrehor.com/ietf/siprec/IETF79.1/Chairs.pdf No changes to published agenda. Topic - Requirements (Ken Rehor / Leon Portman) draft-ietf-siprec-req-05 ================================ Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ Slides: http://kenrehor.com/ietf/siprec/IETF79.1/IETF-79.1-SIPREC-Req-2010-12- 15.pdf Concerning issues #59 and #60, there was no objection to proceeding as proposed on the slides, i.e., accepting the text changes (as proposed in the tickets). There were no further open issues on the requirements draft and the meeting was of the opinion that, with the above two issues fixed, the draft will be ready for WGLC. The chairs will seek confirmation on the list this week of the resolution of the two issues and the editors will produce -06 on Monday 2010-12- 20, after which a WGLC will be started (3 weeks because of the holiday period). Requirements will be renumbered in -06. Topic - Metadata model (Ram Mohan) draft-ram-siprec-metadata-02 ================================================ Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Metamodel%20- %20Virtual%20Interim-Dec16-2010.pdf A recurring theme during the discussion was that many of the items proposed as arguments of objects were not readily available from standardized SIP signalling on the CS, and therefore standardizing these within the metadata might be problematic. The consensus was that we should probably declare these out of scope for the initial version of SIPREC, with the possibility of standardizing extensions to SIPREC if and when additional items of metadata become feasible. In the meantime, conveyance as non-standardized "application data" might be possible. Examples of attributes to which such considerations applied included direction, termination reason, participant type, internal/external, etc.. It was noted that SALUD might provide a solution for the last of these (Alert-Info header field). Concerning the Recording Session object, it was noted that there had been a decision not to create a requirement for delivering the purpose of the recording, so Recording Reason might not be needed. Concerning the Communication Session Group object, it was unclear whether we need a unique CS group ID - it might only be needed if two different SRCs try to put CSs into the same CS group. Leon believes it is needed. Paul observed that some things may show up when we represent the data in the protocol but don't need to be in the model. It was unclear to what extent we can define this and how we would guarantee uniqueness, but that was thought to be a problem to be solved by the solution draft. The conclusion was that we probably need to keep the CS Group ID attribute in the model for now, and see whether it can be addressed satisfactorily in the solution. Concerning the issue of whether a CS object can be associated with multiple CS Group objects, use cases for this were unclear. Ram will solicit use cases on the list. Concerning the CS Retention and Force Deletion attributes, these seem not to be required, because passing retention policy from SRC to SRS has been ruled out of scope. It could be done as "application data" if needed. Concerning the Participant object, it was clarified that the Name attribute corresponds to the SIP display-name. It was noted that we may need >1 identifier (e.g., from From, PAI, Contact and header fields). Most of the open items seemed to be candidates for "application data", with the possible exception of participant role. Concerning the Media Stream object, it was questioned how much is needed, given that some parameters will be in-line. However, it depends whether we are talking about parameters of the CS, as opposed to parameters of the RS (the two can be different if the SRC performs transcoding). During this last discussion, Brian made the suggestion of including the entire SDP from the CS as metadata, or even the entire INVITE message. Brian was asked to bring this new proposal to the list. There was insufficient time to discuss the issue concerning media offered but rejected - will continue on the list. In conclusion, it was agreed that we require more discussion on some of the issues and a revised draft, before we will be in a position to consider adoption as a work item. Ram particularly asked that people should study the use cases (new in -02) and see if they make sense. Topic - Protocol (Henry Lum / Leon Portman) draft-portman-siprec-protocol-01 ================================================ 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 On the issue of establishing the session, discussion mainly focused on the use of REFER for asking a conference focus to act as SRC. Alan pointed out that RFC 4508 might be relevant. It was asked whether the REFER mechanism could apply to the B2BUA case too? It was also questioned whether the REFER mechanism is within the scope of SIPREC - it had been ruled out of scope during earlier discussions on the architecture draft. However, it was suggested there might be no harm in showing informatively how you could use existing mechanisms such as REFER. It was noted that the document should concentrate on the protocol and not repeat things from the architecture document by showing different architectural arrangements. On the issue of delivering metadata, discussion was mainly about use of INVITE/re-INVITE/UPDATE versus using an INFO package. The following points were made: - in many cases where metadata changes there will also need to be an offer- answer exchange, and hence re-INVITE or UPDATE will be needed anyway; - UPDATE could also be used without an offer-answer exchange if only the metadata changes; - however, it was pointed out that this would not constitute an update of the RS, so might be considered an inappropriate use of UPDATE; - there was some interest in having an INFO package; - however, an INFO package would not allow metadata to be conveyed in an INVITE/re-INVITE/UPDATE at the same time as offer-answer; - the SRS might require metadata in the INVITE/re-INVITE in order to make a decision on accepting the request; - concern about having two separate mechanisms for conveying metadata. Leon/Henry will lead further discussions on the list. There seemed to be no strong motivation for the third option, an event package, but it is too early to rule it out. There was some discussion on the proposal for a new content-disposition - this may or may not be needed, and might depend on whether we are to use a new header field. There was insufficient time for discussion of the remaining issues on the slides. Wrap-up ================================ A Doodle poll had been in operation for a pair of 2-hour interim virtual meetings in late January. It was agreed to schedule two meetings - the second can be cancelled if not needed. Dates to be announced. The meeting was closed at 16.05.