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

Meeting Minutes SIP Recording (siprec) WG
Title Minutes for SIPREC at IETF-interim-2011-siprec-1
State Active
Other versions plain text
Last updated 2011-09-20

Meeting Minutes

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: 

Audio recording session 2: 

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-

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: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-

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: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-

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: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-

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  element, which is 

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 

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-

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

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

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: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
Slides: http://www.ietf.org/proceedings/interim/2011/09/19/siprec/slides/siprec-

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  
element for use within a  element. Ram agreed to check with an XML 
expert on need for the language attribute in the  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 

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.