Subject: [siprec] Draft minutes of interim call 2010-10-12

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Oct 2010 12:25:41 +0200

Please post any comments on these draft minutes (based on Dave Smith's notes) to the list by 2010-12-22.

John

Minutes of the SIPREC WG Interim Virtual Meeting,
2010-10-12, 14.00-16.00 GMT/UTC
===============================================
Meeting chaired by Brian Rosen and John Elwell.

Minutes produced by John Elwell based on notes from Dave Smith.

Jabber log: http://www.ietf.org/jabber/logs/siprec/2010-10-12.txt

Meeting started at 14.00.

Topic - Administrivia (chairs)
==============================
Slides: http://kenrehor.com/ietf/siprec/IETF78.2/Chairs.pdf

No changes to published agenda.

Participants: Brian Rosen, John Elwell, Ken Rehor, Paul Kyzivat, Leon Portman, Dave Smith, Henry Lum, Parthasarathi R, Ram Mohan R.

Topic - Requirements (Ken Rehor)
draft-ietf-siprec-req-03
================================
Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/
Slides: http://kenrehor.com/ietf/siprec/IETF78.2/IETF-78.2-SIPREC-Req-2010-10-11.pdf

Version -03 had been posted a few hours before the meeting.

1. DTMF 
 a. Do we need to capture DTMF as Metadata and/or as Data?
 b. Include KPML in the discussion
 c. Change wording of REQ-007bis2 (it is not "out-of-band")
 d. Make REQ-007 into only one requirement for recording DTMF (leave for Arch Draft/Doc to address how it is done)
 e. Post to List for discussion of whether KPML is to be considered and whether DTMF is considered data or metadata.

2. REQ-023
 a. Change wording from "a SIP UA" to "an authorized participant in the CS" 
 b. No objections - propose to list.

3. REQ-024
 a. Change wording from "end users" to "participants"
 b. No objections - get confirmation on list.

4. Tracker Ticket # 43
 a. Tracker Ticket # 43: "What special requirements do we need concerning conferences? I suspect we at least need something to do with recording the view of a single participant versus recording the entire conference (including aspects that a given participant might not see)."
 b. Consider to add use cases to describe (1) single participant, versus (2) recording the entire conference 
 c. We probably need to identify in metadata participant participation, if available
 d. SRC may not know participants, for example, where there is separation between SRC & Mixer - this is to be handled at a later Draft phase

5. Tracker Ticket #46
 a. No objection to new wording for REQ-025 (already in -03).

6. Media Delays (Use Case #12)
 a. The SRC to control the timing required (max delay, e.g., 1 to 3 seconds max delay proposed for Speech Analytics use case) to provide CS media to SRS
 b. Discussion on whether we are just concerned with buffering delay at SRC or also transmission delays between SRC and SRS.
 c. Noted that actual delay will depend on deployment environment - however mechanism should not prevent meeting maximum delay requirement when deployed in a suitable environment.
 d. Suggested that SRS might need to tell the SRC what maximum delay it requires.
 b. Post to List for further discussion.

7. Tracker Ticket #35 (more detail needed on security requirements)
a. Identified 3 areas to consider:
  (1) Who SRS exposes recordings to
  (2) How SRC handles participants
  (3) SRC to SRS relationship - this is probably our primary focus
 b. Probably SRC needs to filter its media/metadata to SRS
 c. Consider to leverage other Security specifications:
  - GEOPRIV (how a user specifies his preferences for private information)
  - Telepresence (multiple streams, participant info)
  - SIP standards for security
 d. We should be able to use standard SIP for Integrity and Confidentiality, but probably need more for Authentication and Privacy.
 e. We perhaps need a separate Draft of Security Requirements.
 f. We need to recruit a security SME (Subject Matter Expert) to assist.
 g. Chairs to ask some known experts to contribute.

8. Action Items:
 a. Set deadline of Friday PM, Oct 15 for inputs on Draft-03 and this mtg.
 b. Provide Draft-04 by Monday, Oct 18 (cut-off is Oct 25, but aim for earlier)
 c. See individual action items above; note that security requirements need to be addressed (e.g., perhaps requiring a separate draft initially). It is the most difficult part and may impact our progress.
 d. Authors to initiate the List discussions 

Topic - Metadata model(Ram Mohan / Paul Kyzivat)
================================================
Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/
Slides: http://kenrehor.com/ietf/siprec/IETF78.2/IETF-78.2-SIPREC-Metamodel-2010-10-11.pdf

1. "Received" versus "Recorded" media streams
 a. Seems to be a mistake on slide 3 (perhaps a relationship too many).
 a. Discussion on whether model should include all media from CS, only those media for which recording was requested, or only those media for which recording was requested and accepted. Do we need to model "recorded media stream" at all?
 b. What SRS does with media and metadata after it arrives at the SRS (e.g., discard, mix, record unmixed) is probably outside the scope of SIPREC.
 c. Post questions to List for discussion 

2. What metadata is needed, what is not needed?
 a. Discussion on whether, if media is not recorded, do we still need to identify speaker, identify participants, identify when someone went on hold, who initiated the call, who terminated the call, etc....if available?
 b. Leon asks for this - does anyone else see a need for this?
 c. Continue discussion on list.

3. Communication Session Attributes
 a. Direction of media is clear (although may end up having a matrix). Direction of signalling is more questionable.
 b. Direction of SIP messages in 3PCC situations (e.g., INVITE, BYE) could be incoming to SRC even though the local party has initiated the action through an application.
 c. Leon thinks the information would still be useful, and perhaps we can have an "unknown" value.
 d. Depends where the SRC is located whether information is meaningful or not, e.g., might be more meaningful from point of view of SBC at enterprise boundary - always knows whether call is incoming or outgoing.
 e. Model currently ties participants to media, not to signalling, so it might not be so easy to tie to signalling.
 f. Continue discussion on list.

4. No time for remaining slides. Chair pointed out there has been limited discussion on the list, and relatively few participants in the call. We should really try to stimulate more discussion on the list. Action items:
 a. Authors to initiate stimulate continuation of list discussions
 b. Use a unique title for each thread (but don't use tracker yet - not even a WG item.
 c. More List discussions requested

Wrap-up
================================
Further progressing or requirements and metadata model as indicated above. There was a suggestion of a further interim meeting before IETF#79, but this is not feasible.

The meeting was closed at 16.20.
----