Minutes for SIPREC at IETF-interim-2011-siprec-1
minutes-interim-2011-siprec-1-00

Minutes of the SIPREC WG Interim Virtual Meeting
Session 1: 2011-09-19, 14.00-16.00 GMT/UTC
Session 2: 2011-09-23, 13.00-15.00 GMT/UTC
===============================================
Meeting chaired by John Elwell, Brian Rosen and Andy Hutton.

Minutes produced by John Elwell based on notes from Leon Portman (session 1) and
Andy Hutton (session 2).

Jabber log: There was no Jabber activity.

Audio recording session 1:
https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID=11718572&rKey=3900
b5fa919301e8

Audio recording session 2:
https://workgreen.webex.com/workgreen/lsr.php?AT=pb&SP=MC&rID=11800992&rKey=fa38
8001458e0981

Participants: Brian Rosen, John Elwell, Andy Hutton, Ken Rehor, Leon Portman,
Henry Lum, Ram Mohan, Paul Kyzivat (session 1 only), Parthasarathi (session 1
only), Dan Romascanu, Charles Eckel,
Patrick Mourot, John Stafford, Gonzalo Camarillo, Ofir Roth (session 1 only)

Session 1 started at 14.02

Topic - Administrivia (chairs)
==============================
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-
0.ppt

There were no changes to the published agenda.

The chairs pointed out that milestones would need addressing after the meeting.


Topic - Architecture (Leon Portman)
draft-ietf-siprec-architecture-02
================================================
Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-
1.ppt

Slide 3: It was agreed this should show RTCP as well as RTP (but need not show
SRTP), and that the session between UA-A and UA-B should be shown as a single CS
(even though it comprises two separate SIP dialogs). In answer to a question
from Leon, it was agreed there is no need to delete the metadata arrow, even
though the protocol handles metadata as part of the SIP session.

Slide 4: It was agreed not to show RTC-Web as a special case, but to modify the
existing figure showing an SRC at a decomposed UA to make it more generic, e.g.,
realisable using MEDIACTRL or RTC-Web.

Slide 5: Deferred until after the RTP discussion during session 2.


Topic - Protocol (Henry Lum)
draft-ietf-siprec-protocol-00
================================================
Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-
2.ppt

Slide 5: There were no objections to the proposals. Text describing how
persistent recording might work will be sent to the list for review.

Slide 6: Some people argued in favour of allowing an SRS to establish an RS by
sending the initial INVITE request to the SRC, as an alternative to the SRC
sending the initial INVITE request to the SRS. Some felt that it would be
difficult to convey to the SRC information on what needs to be recorded, and
that it would be difficult to achieve interoperability. Consequently those
people preferred to omit this from the initial deliverables. Others felt that
the Request-URI could convey to the SRC information on what is to be recorded,
e.g., a Request-URI that identifies an SRC and instructs it to do persistent
recording of calls involving a given user. Those people felt that the
provisioning required at the SRS to achieve this would be comparable to
provisioning required at the SRC to achieve an SRC-initiated INVITE request. It
was noted that the architecture draft allows SRS-initiated establishment of an
RS. There was no consensus on whether to include this - further list discussion
is needed.


Topic - Metadata model and format(Ram Mohan)
draft-ietf-siprec-metadata-04
================================================
Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-
3.ppt

Slide 5: There were no objecions to keeping UML in the document as a way of
describing the model, but this should not be normative. Some improved text is
needed to explain how the XML relates to the model, since the two are not
exactly the same. There should also be a reference for UML.

Slide 6: There were no objections to removing ExtensionData from the model, and
dealing with it only in XML. This is because the model is not an on-the-wire
protocol and does not need a compatibility mechanism. Further issues on
representation of extension data in XML will need discussing later.

Slide 8: There were no objections to having associate and dissociate times for a
CS. Leon suggested the possible need to have start and stop times too, but if
this is desired, reasons should be given on the list.

Slide 9: There were no objections to allowing fewer than two (i.e., zero or
more) participants in a CS.

Slide 10: There were no objections to having a single XML element to contain
name and/or address. List proposals are required as to what form that element
should take, e.g., free text with escaping, or structured.

Slides 11/12: There were no objections to modelling association and dissociation
times for participants with media streams as attributes of a UML association
construct. More discussion is required on how to realise this in XML/SDP (see
also ticket #72 and slide 14).

Slide 13: There were no objections to removing the <mode/> element, which is
redundant.

Slide 14 (ticket #72): This concerns how to represent attributes of associations
in XML. There seemed to be a preference for having a separate XML element for
the association class, but there are different ways this could be specified.
More list discussion is needed, together with examples of the different
proposals.


Wrap-up
================================
The agenda for the second session on Friday (2011-09-23, 13.00-15.00 GMT/UTC)
will start with the RTP model (Charles Eckel, slides to be posted) and then will
return to metadata, finishing the slides from today plus any further slides
resulting from list discussion in the meantime.

Session 1 was closed at 16.00.
==============================

Session 2 started at 13.01

Topic - Administrivia (chairs)
==============================
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-
0.ppt

There were no changes to the agenda agreed at the end of session 1.


Topic - RTP (Charles Eckel)
draft-eckel-siprec-rtp-rec-02
================================================
Draft: https://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-
4.ppt

Draft 02 had appeared earlier in the week, and the slides largely reflected
changes between -01 and -02.

Slide 6: Following a question from Ram, it was agreed that additional text is
required on how an SRC should behave in the event of packet loss reported by the
SRS. This will depend on the particular role the SRC takes with respect to RTP.
Charles agreed to post some text to the list for discussion.

Slide 8/9: Brian pointed out that there is a lot of variation in how these
mechanism are deployed, and the advice proposed in the draft might not be
appropriate for all deployments. Therefore in some cases there may be a need for
slightly more relaxed normative language.

Slides 10/11: Andy pointed out that because of NAT traversal there may need to
be keep-alives in both directions, and therefore RTP will not be entirely
unidirectional. However, there is already some text in section 10 on this.

As a general comment, Brian wanted to know whether we are happy to tie down
particular mechanisms out of the several mechanisms that currently exist for
doing things in RTP, like symmetric RTP/RTCP and keep-alive for example. On the
one hand he favours avoiding too many options and is happy with the particular
options chosen to date, but on the other hand doesn't want unnecessarily to rule
out certain existing implementations. Charles explained that MUST seems
reasonable for the well-implemented symmetric RTP, but in case of keep-alive the
present text only makes a recommendation. The issue seems to revolve around
whether we assume new implementations anyway (because of all the new protocol
aspects of SIPREC), although it is possible that new SRS/SRC implementations
might want to inherit existing RTP implementations.

Charles asked whether we needed to say anything about the new AVTEXT client-
mixer and mixer-client audio level drafts, but the consensus was that these,
although nice-to-have, are not essential to SIPREC and need not be mentioned.

Charles will try to get draft-03 out by mid-October, together with agreed text
arising from slide 6. Also this gives time for possible further input from
experts in AVTCORE. It might then be possible to call for adoption as part of
the protocol milestone. This would give time to get it into the protocol draft
before IETF 82.


Topic - Metadata model and format (continued)(Ram Mohan)
draft-ietf-siprec-metadata-04
================================================
Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-
3.ppt

Slides 14 onwards were discussed. Slides 1 to 13 had been covered during the
first session.

Slides 14/15/16/17: Ram explained the 4 approaches to representing associations
(e.g., between session and participant, and between participant and stream) in
XML. Some of the pros and cons of each were mentioned, and it was identified
that there is also an approach based on approach 2 where the association element
has its own unique identifier. In this way it doesn't suffer from the same
drawback as approach 1 that was identified by John on the mailing list, but it
makes it even more verbose. Participants had had insufficient time to digest the
different approaches, some more mailing list discussion is required. When
comparing approaches, considerations such as the frequency of change and the
likely cardinalities of these associations should be taken into account. Ram
agreed to initiate further discussion by identifying pros and cons and possibly
yet more approaches.

Slide 18: Charles pointed out that what is needed here is not the CSRC but the
set of SSRCs that a particular participant contributing to a media stream is
generating. There were no objections to this being part of the association
between participant and stream.

Slide 19: There were no objections to this proposal for representing extension
data in XML.

Slide 20: There were no objections to this proposal for a structured <nameId/>
element for use within a <participant/> element. Ram agreed to check with an XML
expert on need for the language attribute in the <name/> child element. Some
text is needed to deal with different anonymity cases, e.g., anonymous.invalid
domain in the From header field, no P-Asserted-Identity header field, or P-
Asserted-Identity together with a Privacy header field.

Slide 21: There were no objections to use of RFC 4235 syntax for representing
capabilities, subject to clarification on how the bug will be handled. Ram
agreed to contact Paul Kyzivat on this.

Slide 22: This depends on the outcome of discussions on associations. Leon
wanted times to be to millisecond resolution, not just to second.

Slides 23/24: This depends on the outcome of discussions on associations, and
should also pick up the results of the discussion on slide 18.

It was agreed that it is important to resolve the issues around representation
of associations in XML (slides 14-17) as soon as possible and then publish
draft-05.


Wrap-up
================================
The chairs are keen that the issue tracker be used more rigorously from now on,
for all three active WG drafts. The document editors are asked to take care of
ensuring that all issues are recorded on the tracker and updated / closed in a
timely manner.

It was agreed that no further interim is needed before IETF 82. A single 2 hour
slot has been requested on that occasion.

John stood down as co-chair and Andy will take his place alongside Brian.

Session 2 was closed at 14.45.