Subject: [siprec] Draft minutes 2010-12-16

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Dec 2010 09:09:19 +0100

Please let me have any corrections.

John

###################################

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.