[siprec] Minutes

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

Below are the draft minutes from yesterday. Also on the Wiki, along with the recording:
http://trac.tools.ietf.org/wg/siprec/trac/wiki/WikiStart

Please let me have any corrections by 2011-07-07.

John
####


Minutes of the SIPREC WG Interim Virtual Meeting
2011-06-23, 13.00-14.00 GMT/UTC
===============================================
Meeting chaired by Brian Rosen and John Elwell.

Participants: Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum, Ram Mohan, Andy Hutton, Paul Kyzivat, Parthasarathi, Dan Romascanu, Charles Eckel, Cullen Jennings

Minutes produced by John Elwell based on notes from Charles Eckel.

Jabber log: There was no Jabber activity.

Recording: https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID=10441082&rKey=a52c98b76fc9f083 

Meeting started at 13.05 GMT.

Topic - Administrivia (chairs)
==============================
Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPREC_Chairs_20110623.ppt 

There were no changes to the published agenda, except for allowing Charles a brief slot at the end on draft-eckel-siprec-rtp-rec-00.

Topic - Protocol (Henry Lum)
draft-portman-siprec-protocol-04
================================================
Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPREC%20Protocol%20-%20Virtual%20Interim%20-%2020110623.ppt

Slide 3: Referring to the removal of INFO, authors to scrub document for stray references to INFO, including occurrences in figures.

Slide 5: On the recording SDP attribute, it was clarified that this is just declarative. Cullen thought more is needed. For example, if a B2BUA needs to indicate recording, it would need to send an SDP offer in each direction. Also, does it mean media being sent or media being received is being recorded, or both? Cullen will send comments to the list. Also Paul mentioned the case of two separate SRCs on the CS path - a user may need to know which SRC, e.g., own or other party's. Again this comment should be raised and discussed on the list.

Slide 6: On the recordpref SDP attribute, it was noted that this would need to be in an offer. There had been a question on the list concerning whether a "no preference" value should be added, or whether this is to be considered the default if the atttribute is not present. Paul was doubtful, particularly for the case of non SIPREC-aware UAs. The authors should refresh the list discussion.

Henry asked whether people are happy with this mechanism for expressing  recording preference? That was the past decision (from Prague). No views were expressed to the contrary.

Slide 7: On the option tag, Cullen stressed the need for us, in accordance with our charter, to specify that the user must be notified, regardless of whether the UA has expressed support for this option. There was discussion as to whether the sending of a recording SDP attribute to a UA that has indicated support for this option is sufficient to replace any in-band notification of recording. In other words, whether a UA is obliged to use receipt of such a notification to render an appropriate indication to the user (including a PSTN gateway UA, which would need to send an in-band tone or announcement to the PSTN). The authors should follow this up on the list, to get the right text.

Slide 8: Concerning the nature of a snapshot request, Charles thought this could be just a simple request, with no parameters. The discussion seemed to lean towards something in the header, rather than in the body. To be continued on the list.

Slide 9: The WG is not yet in a position to adopt this draft, in particular because information on RTP needs to be added (see last agenda item). The issues raised today need to be followed up, and perhaps the next revision will be ready for adoption.


Topic - Metadata model(Ram Mohan)
draft-ietf-siprec-metadata-01
================================================
Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPREC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx

Side 5: On the issue of whether a CSG element needs a start/stop time, Ram explained that the information could be derived from the start/stop times of the CSs that form part of that group (although he was concerned about the complications of overlapping CSs), or could be explicitly indicated for the group. Leon and John thought that implicit should be sufficient. Partha tried to express a point concerning termination of a CSG, but this needs to be raised on the list.

Slide 6: The question is whether an MS needs a global ID or an ID local to a CS. This depends on whether an MS can have a lifetime outside that of a single CS. Henry and Leon were fine with a global ID, but were somewhat uncomfortable with an MS having an extended lifetime. Paul and Ram described situations where the same MS would be recorded from two different SRCs or for two different CSs, and one example would be a multicast stream such as music on hold played to two or more CSs at the same time - labelling it as the same MS might avoid having to store the recording twice. Leon asked whether the fact that the two MSs come from the same Participant would be sufficient to imply they are the same MS, but others doubted that would be the case, particularly for automata.

After much discussion, John asked whether people could live with making the identifier global, notwithstanding the fact that we don't see any likely cases where an MS would have a lifetime beyond a single CS. This would leave the door open for an MS to have an extended lifetime for any corner cases that arise in the future. The meeting seemed to be in agreement with this. John will put out a consensus call on the list.

Slide 7: On the question of how to describe the content of an MS, there was no objection to basing this on the types in the RFC 4796 registry (new values could be specified via the appropriate means if needed). Paul had a slight concern that you might be mixing multiple CS MSs into a single RS media stream and whether this might result in cases not describable in this way, but in the end accepted the consensus. It needs to be discussed on the list whether this is conveyed in XML or in the RS SDP a=content attribute.

Slide 8: Concerning Participant lifetime and  start/stop times, it was felt that considerations are similar to those for CSG, so likewise this needs to be taken to the list.


Topic - Metadata format(Parthasarasi R)
draft-ram-siprec-metadata-format-02
================================================
Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/
Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPREC%20Metamodel%20Format-Interim-Jun23-2011.ppt

Charles had raised on the list the question of whether consideration had been given to non-SIP means (e.g., HTTP) of transporting metadata. It was explained that the issue had been discussed in the past and had been closed. Charles stated that he accepted the past agreements and understands the reasons.

Slide 6: Concerning MS unique ID, discussions on the metadata model draft had already led to agreement that this needs to be global. This leaves the question of format. Similar considerations apply to all elements that require a unique ID. Paul explained that it could, for example, be a UUID but not necessarily in URN format. Or it could be a URN, without specifying content. Specifying a UUID limits the size, at the cost of constraining things in the future. Specifying just a URN is very flexible but does not limit the size. This needs to be brought to the list.

Slide 7: Participant ID is the same issue. Paul says we don't HAVE TO use the same for each element type, but would need good justification for being different. Charles pointed out push-back at IETF80, concerning implications for back-end systems, and perhaps we don't need to specify it in too much detail. But Paul was of the opinion that keeping things open actually makes things more difficult for the SRS to map to whatever scheme is used in the back-end, and might force use of a mapping table rather than algorithmic means. Brian asked about other URN forms that might be candidates. Partha will propose some options and identify pros and cons on the list.

Slide 8: Concerning extension data, Leon wants this to be part of the parent element, not a separate element. After some discussion, there was no objection to making extension data part of the parent element (e.g., if extension data relates to a CS element, it would be part of the CS element).

Slide 9: The issue of a unique ID for extension data can be closed as a result of the decision above.

Slide 10: There was no time for discussion of codec parameters in stream elements - to continue on list.

Slide 11: John had already put out a call for adoption of the metadata format material from this draft into the WG metadata draft. The only list comment to date had been addressed, and there were no objections at the meeting. John will get this confirmed on the list in the next few days and ask the authors of the two drafts to work on the next revision of draft-ietf-siprec-metadata with the format material (updated in accordance with today's discussions) incorporated. This should be available, if possible, before the cut-off date (2011-07-11).

Topic - RTP Model (Charles Eckel)
draft-eckel-siprec-rtp-rec-00
================================
Draft: https://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/
Slides: none

There had been only limited discussion on the list, and so far there had been no input from AVTCORE members, who had been invited to comment. There was agreement in the meeting that it is heading in the right direction. However, it needs greater scrutiny, and Charles asked that in particular people should look at Section 4o on roles.


Wrap-up
================================
The meeting was closed at 14.55 GMT.