[siprec] Confirmed minutes of interim meeting

["Elwell, John" <[e-mail]>]

I received only one comment on the minutes, resulting in a change to the very last paragraph. I therefore consider the minutes confirmed.

John
########################

Confirmed minutes of the SIPREC WG interim meeting,
2010-06-22, 14.00-16.00 GMT
===============================================
Meeting chaired by Brian Rosen and John Elwell.

Minutes produced by John Elwell based on notes from Ken Rehor and Henry Lum.

Participants:
Kenneth Rehor, Muthu Arul Mozhi Perumal, Roni Even, John Elwell, Leon Portman, Deepanshu Gautam, Parthasarathi R, Alissa Cooper, Paul Kyzivat, Henry Lum, Dan Romascanu, Raj Jain, Mary Barnes, Tommy Moran, Ram Mohan R, Brian Rosen

WebEX Recording
https://workgreen.webex.com/workgreen/lsr.php?AT=pb&SP=MC&rID=5447812&rKey=7804e72d9d0a1223

Topic - Administrivia (chairs)
==============================
Slides: http://kenrehor.com/ietf/siprec/siprec-0.ppt

Note Well statement.
No changes to published agenda.
Summary of WG status.


Topic - Requirements (Ken Rehor)
================================
Document: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/
Slides: http://kenrehor.com/ietf/siprec/IETF-INTERIM-SIPREC-Req_v3.pptx

Use case 8: Consensus to remove text for "conference based solution".

Use case 12: It was agreed that the issue of separate streams per speaker is a separate issue (dealt with on a later slide). The main issue is whether there is a requirement for real-time recording in support of speech analytics. Leon believes there is a requirement for this. Basically this seemed to come down to being able to record and immediately play back to some application like speech-analytics. There was concern, particularly from the chairs, as to whether this is really part of the charter, since the WG is chartered to do recording, and any play-back applications would be out of scope. Although the solution wouldn't necessarily include anything to prevent such applications, a requirement to support such applications might be considered out of scope. It was agreed to open a tracker issue and take this to the list.

REQ-012/012bis (earlier proposal on list to split existing REQ-012): Consensus to adopt this split.

REQ-013/013bis (earlier proposal on list to split existing REQ-013): These requirements concern support for the ability to use separate Recording Sessions (RS) for different parties and/or different media. There were concerns why such requirements are needed, or whether they could be expressed in a different way. For example, can we remove these requirements, or can we express them in terms of a requirement for the Session Recording Server (SRS) to correlate an RS with a Communication Session (CS) (leaving the issue of whether to use multiple RSs to the solution stage)? It was agreed to take this to the list.

REQ-014/014bis (earlier proposal on list to split existing REQ-014): It seemed some wordsmithing is required (to do with "media" or "media streams" or "modality", so it will be taken to the list.

Use case 10 (high availability): There was a general feeling that high availability solutions are a deployment matter, and as long as the SIPREC solution does not prevent high availability deployments, that is fine. In particular, there was concern that redundant Session Recording Clients (SRC) is out of scope, since failure of the SRC generally implies failure of the collocated UA or B2BUA, necessitating a re-arrangement of the CS, which is in the scope of SIP rather than SIPREC. Redundant SRSs should be achievable, but we may need to ensure that the mechanism allows correlation of RSs at multiple SRSs. This will be taken to the list.

Next steps: Several items above will be taken to the list / put on the tracker. Ken will prepare an 01 version before the cut-off for Maastricht. Depending on the level of issues remaining then, it is hoped to start WGLC before Maastricht.


Topic - Architecture (Leon Portman)
====================================================================
Document: https://datatracker.ietf.org/doc/draft-hutton-siprec-session-recording-arch/
Slides: http://kenrehor.com/ietf/siprec/IETF-INTERIM-SIPREC-arch_v3.pptx

Slide B2BUA as SRC: This included the issue of whether the SRC always reports metadata (in particular changes to metadata) unsolicited, or whether the SRS should poll or have some other mechanism for requesting metadata updates. There was consensus for SRC always to send metadata unsolicited.

Slide Endpoint as SRC: This included issues to do with media code negotiation and dynamic codec negotiation. There was consensus we should not do anything different from normal SIP/SDP, and we could also mention SIP/SDP transcoding capabilities.

The same slide also included an issue to do with addressing. There was consensus that an SRC would be provisioned with a URI for the SRS, which would be resolved through normal RFC 3263 procedures.

Side Mediactrl: This slide shows the case where the SRS is decomposed into an Application Server and a Media Server, with a MEDIACTRL interface between the two. It was noted that the slide (taken from the draft) is in error, in that it should show an outer box around the Application Server and the Media Server, this outer box being the SRS. It was noted that the SRC could similarly be decomposed.
Raj questioned why we needed to show this decomposition in the I-D, and John explained that there had been questions concerning the relationship to MEDIACTRL and these need to be answered satisfactorily. Whether they remain in the published RFC can be decided later.

Discussion then focused on whether MEDIACTRL protocols are relevant to the SIPREC interface, between the SRC and the SRS. Brian thought that we should be reusing features such as pause/resume from MEDIACTRL, but Paul explained that suspending a recording was different from pausing a playback, since you lose any media during the period of suspension. In fact the existing SDP mechanism for hold/retrieve (a=inactive etc.) fits well for the suspension of recording.

Slide Establishing the Recording Session: Brian asked how privacy would be dealt with on persistent recording, and it was clarified that recording can be suspended and resumed, as discussed earlier, within the context of a persistent RS. The slide contained an issue to do with identifying the CSs for persistent recording, and Raj suggested the identifiers of the parties would be more appropriate.

There was also discussion on SRS-initiated recording, and how the SRS addresses the SRC, with no conclusion.

Slide Media Recording Metadata: Leon wanted a more descriptive name for "metadata" - this should be brought to the mailing list. Raj thought additional items of metadata are required - this too should be brought to the mailing list. Paul wanted to see an extensible metadata delivery model, and noted that it might not all be delivered at once, and some but not all will persist after the call is over.

John queried why CS dialog identifiers are needed, and Leon responded that it is for the situation where an RS needs to be established by the SRS in response to filtering of received metadata. Paul pointed out that call identifiers are unreliable where B2BUAs are involved, and there was discussion on using a session identifier, although the proposed WG on that topic has not yet been chartered. There was concern about whether we really need a solution for metadata outside the context of an existing RS, and the complexity that might result, and concern from several people about the assertion that we might need multiple metadata delivery mechanisms to fit different use cases. There was a suggestion that perhaps the requirement for the SRS to control whether to record or not could be solved with persistent recording. Raj stated that he has a requirement for the SRS to initiate an RS based on received metadata, because that exists in the market today. There appears to be nothing in the requirements document for this, and Raj was asked to raise this on the mailing list as something for the requirements document, or point to whatever might already be in the requirements document to cover this.

Slide Multi-party Conference Recording: For the B2BUA SRC/Conference Server case, Brian noted that we should not preclude the obvious case where the SRS is just a regular participant, and if this needs to be hidden from other participants, there are mechanisms from XCON to achieve this.

Slide Additional Flows: Discussion of the Notifications to Recorded UAs issue needs to continue on the mailing list.

There was no opposition to adopting the architecture draft as a WG item - to be confirmed on the list.

Next steps: Chairs to ask for consensus on adopting as a WG item. Authors to update draft with decisions made and pursue remaining issues via tracker and mailing list.

Wrap up (Chairs)
===============
Further processing of the two drafts as indicated above.

Concerning IETF#78 at Maastricht, a 2 hour session has been requested but no agenda has yet been published. John asked what we need to do with the offer from MEDIACTRL people to give a demonstration of MEDIACTRL-enabled recording during the SIPREC session. In view of the fact that we seem to be reaching consensus on how SIPREC relates to MEDIACTRL, this would not seem to be the best way to use our meeting time at IETF#78. John will respond accordingly.