Minutes of the SIPREC WG Meeting, IETF#80, Prague 2011-03-31, 09.00-11.30 GMT/UTC+2 =============================================== Meeting chaired by Brian Rosen and John Elwell. Minutes produced by John Elwell based on notes from Ken Rehor and Michael Procter. Jabber log: http://www.ietf.org/jabber/logs/siprec/2011-03-31.txt Meeting started at 09.00. Topic - Administrivia (chairs) ============================== Slides: http://www.ietf.org/proceedings/80/slides/siprec-5.ppt No changes to published agenda. Topic - Requirements (Ken Rehor) draft-ietf-siprec-req-08 ================================ Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ Slides: http://www.ietf.org/proceedings/80/slides/siprec-3.pptx There were no objections to the fixes detailed in the slides, and therefore the editors will go ahead and submit -09 to satisfy the AD comments. Topic - Architecture (Andy Hutton) draft-ietf-siprec-architecture-01 ================================ Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/ Slides: http://www.ietf.org/proceedings/80/slides/siprec-2.ppt Slide 3: Open issue: Figure to show how to decompose SRC? Partha would like an additional figure and will provide ASCII art for review on the list. Slide 4: Addition of Conference Focus Interaction diagram. No objection. Slide 5: Removal of Metadata Supported indication. No objection. Slide 6: Removal of Metadata Content and reference the Metadata Model draft instead. No objections. Slide 7: Metadata delivery. The sense of the room was to mention delivery by SIP, but leave the particular methods to the protocol draft, and to state that non-SIP methods are out of scope. Slide 8: Security Considerations, removal of statement on decryption / re- encryption. No objection. Slide 9: Security Considerations, removal of statement on SRTP. No objection. The editor will produce -02 in the next few days and WGLC can be anticipated within the next couple of months. Topic - Metadata model(Parthasarasi R) draft-ram-siprec-metadata-04 ================================================ Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ Slides: http://www.ietf.org/proceedings/80/slides/siprec-0.ppt Note that this has already been adopted as a WG item but there has been no opportunity to post draft-ietf-...-00. Slide 5: Open item: Optional start/stop time attribute for Recording Session to be added? There was considerable discussion on this, with points being raised about how to determine that the RS has really ended, the impact of persistent recording sessions, metadata updates continuing after the SIP session has finished, etc.. To be taken to the list. Slide 6: Open item: Optional start/stop time attribute for Communication Session Group to be added? This too should be taken to the list, since some of the same considerations will apply. Slide 7: Open item: Optional start/stop time attribute for Communication Session to be added? There were no objections to adding it, although it was mentioned that we need to be clear what that time is (e.g., time of sending the BYE request, receiving the 200 OK response). Slide 7: Open item: Should session state attribute indicate trying/proceed/early/confirmed/terminated? There was consensus not to include this. Slide 8: Open item: Optional start/stop time attribute for Participant to be added? There seemed to be a feeling in the room that this is needed, but it was not clear exactly what it means and how it relates to things like a participant starting/stopping involvement in a CS and a participant starting/stopping involvement in a media stream. More discussion is needed to clarify this. Slide 9: Open item: Media stream: Codec params text change. Although there wasn't any objection to changing codec params text to refer to RS SDP (as opposed to CS SDP), it was not clear to everyone why this was needed at all. Therefore it will be taken to the mailing list. Slide 10: Open item: Media stream: Need to model unrecorded media streams (offered certain types, not accepted by SRS)? The room concensus was "yes". The next steps are that the editors will post a draft-ietf-...-00 shortly reflecting what has been agreed to date. Topic - Metadata format(Parthasarasi R) draft-ram-siprec-metadata-format-01 ================================================ Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/ Slides: http://www.ietf.org/proceedings/80/slides/siprec-1.ppt Slide 4: There was considerable discussion on the lifetime of ids and the need for them to be globally unique with an unlimited lifetime. Hadriel Kaplan believes the UUID basis is too complicated and forces a particular representation in the database. Joe Hildebrand explained that the authors are still discussing processing semantics, and nailing down the syntax can be left until later. He also explained that having an id that can be allocated on the sending side without fear of collision can save a round trip. Hadriel Kaplan also suggested having a single unique id for the parent element, and not one for each leaf, but Paul Kyzivat explained that this would prevent referring to an element in a completely different context (although there is no requirement for this yet). The topic came up again in the context of slide 12, where a couple of people explained that a single unique identifier at the top level would suffice, with just local identifiers for the lower levels. Thereby a partial update would require the unique identifier plus one or more local identifiers. Joe Hildebrand noted that this would raise issues if there are multiple sources of metadata. He also noted there are other solutions for a globablly unique ID - not just UUIDs. This issue needs further discussion, and there is still opportunity for alternative proposals (this is still an individual draft). Slide 16: Extension Data Element Example. Brian Rosen claimed it would not work, but Joe Hildebrand explained that it could be made to work, but depends on implementation. Concerning namespaces, Joe explained that it might use the namespace of extensionData, or if it is specific to a particular application it would have its own namespace. Paul Kyzivat pointed out that the type of a parent is not clear just from a UUID, so this might lead to an ugly database type. References perhaps need to be typed. More mailing list discussion is needed, following on from Peter St. Andre's posts before the meeting. Slide 18: Open issue: Codec parameter in stream element. John Elwell (from floor) disliked duplication, but thought there was a need to consider what information needs to be passed up to the application at the SRS, e.g., the media type would be needed. So this could result in a small amount of duplication to provide this in the XML for the application. Paul Kyzivat was most concerned about the direction attribute, since it is hard to figure out from the RS SDP the direction of the CS media. Paul also felt that the SRS could pass information from the RS SDP up to the application if needed, without necessarily requiring that information in XML. Hadriel Kaplan disliked duplication, although the need for information in XML might depend on the RTP model. Will continue discussion on relationship between information in XML and information in SDP on the mailing list. Slide 19: Open issue: Multiplexing different participants' streams on same port. The chair suggested this was more of a protocol topic, and the impact on the metadata format can be decided later. The chairs asked whether there was interest in creating a separate milestone for this topic, or whether to merge into another document, e.g., combining with the metadata model, or merging the model into the architecture document and merging the metadata format with the protocol document. We need to look at it from the point of a newbie trying to make sense of the different RFCs. To dicuss on the mailing list. In summary, it is too early to consider adopting the current draft for any milestone, but we need to dig deeper into issues of partial updates and extension data, and tied to both of these the issue of identifiers. Topic - Protocol (Leon Portman) draft-portman-siprec-protocol-03 ================================================ Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://www.ietf.org/proceedings/80/slides/siprec-4.pptx Slide 3: It was noted that INFO needs to be removed from the next version, based on past consensus. Slide 4: Metadata Snapshot Support. There was some discussion on whether re- INVITE could be used as an alternative to UPDATE, and the consensus seemed to be that the particular method used should not matter. Hadriel Kaplan suggested using INFO for the cases where a simultaneous offer-answer exchange is not required, but that had been discussed before and there had been concerns about having to define and implement an INFO-package. Charles Eckel asked about requesting a refresh of the full metadata, and Leon concerned this is the use case we are considering. Partha had another concern, which he was invited to raise on the list. Slide 5: Multiplexing media streams from different parties on the same port. There was considerable discussion as to whether or not we need to tie things down, either by specifying multiplexing or by specifying no multiplexing. Paul Kyzivat mentioned a situation where streams would already be multiplexed on the CS, and therefore would be passed on in this form to the SRS. This raised the question of what we understand as the RTP model - is the SRC an endpoint, a translator or a mixer? It seems we should first try to model RTP and include it in the architecture document. The AD also stressed the need to ensure that SIPREC, CLUE and RTC-Web are all on the same page. Slide 6: Recording awareness: SDP attribute a=recording-aware. There was an inconclusive discussion about whether this should be at the SDP layer or the SIP layer, although several people were leaning towards the SIP layer. One consideration is how non-audio indications (for hearing-impaired users) are handled. Discussion to continue on the list. Slide 7: Recording indications: on/off/paused: session or media level? There was consensus for media level. Slide 8: Recording preferences: record/norecord/pause/resume: session or media level? There was consensus this should be a per-medium indication (e.g., permit recording of audio but not video), but there were doubts as to whether SDP would be the correct place. One concern was that if this is a command, it does not fit the semantics of SDP. To be taken to list and to seek expert advice on whether appropriate for SDP. Slide 9: There was no substantive discussion on these open items. In summary, there are still some items to tie down, and we are not quite in a position to adopt this as a WG item. However, there was no opposition in the room to the general direction of this draft. Wrap-up ================================ The chairs suggested a virtual interim meeting mid-May to progress the various drafts. The meeting was closed at 11.27.