Minutes of the SIPREC WG Interim Virtual Meeting 2011-07-28, 15.20-17.20 GMT/UTC-4 =============================================== Meeting chaired by Brian Rosen and John Elwell. Minutes produced by John Elwell based on notes from Andy Hutton and Christian Schmidt. Jabber log: http://www.ietf.org/jabber/logs/siprec/2011-08-28.txt Audio recording: http://www.ietf.org/audio/ietf81/ietf81-2101-20110728-1256- pm.mp3 Meetecho recordings: See individual topics below. Meeting started at 15.23 Topic - Administrivia (chairs) ============================== Slides: http:http://www.ietf.org/proceedings/81/slides/siprec-2.ppt Meetecho recording: http://77.238.22.57/ietf81/5550707/28_Jul_2011at21_18_38sec/part_0/player.jnlp There were no changes to the published agenda. The chairs pointed out that the architecture draft (draft-ietf-siprec- architecture-02) needs a thorough review before WGLC. The milestone for IESG submission is getting close. Topic - Metadata modeland format(Ram Mohan) draft-ietf-siprec-metadata-03 ================================================ Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ Slides: http://www.ietf.org/proceedings/81/slides/siprec-1.pptx Meetecho recording: http://77.238.22.57/ietf81/5550707/28_Jul_2011at21_18_38sec/part_1/player.jnlp Slide 6: There were no objections to addition of optional associate / dissociate time attributes. Slide 7: There were no objections to having a Participant object unconstrained to the lifetime of a CS or CSG, i.e., it can exist outside a CS or CSG. Concerning the question of associate/dissociate times for a participant in a CS, people seemed more conformatable with associate/dissociate times rather than with start/stop times for the Participant object. However, as this concept was quite new, it needs more list discussion. Also, some clarification is needed as to what exactly is a Participant object, and what the implications are on the model of having times as attributes of associations. Proposals are invited on the list. Slide 8: Concerning capabilities (RFC 3840), it appeared that these should relate to an association between a Participant and a CS, not to a Participant, because a Participant involved in two CSs could have different capabilities in each. Paul Kyzivat suggested that all Contact header field parameters should be included, not just capabilities, and this would have the added advantage of being able to use the coding in the dialog event package (although he had noticed a small bug there). Leon Portman was in favour of having capabilities, and indeed all Contact header field parameters. Hadriel Kaplan stressed the importance of not depending on this information, because it won't always be available. So it has the potential for interoperability issues. Brian Rosen (as individual) preferred to have all information from Contact in here, but noted Hadriel's concerned. There were no objections to including callee capabilities and the rest of the Contact header field parameters. Encoding will require list discussion. Slide 9: There was no objection to including provision for multiple identifiers per Participant in the XML. However, Hadriel Kaplan pointed out that the SRC is in the best position to understand the reliability of received idenditifiers in SIP and should choose whether to include these in the metadata or not. Adam Roach, however, felt that which identifier to trust (out of From or P-Asserted- Identity) could be very subjective and might be something that should be deferred to the person playing back the recording. Brian Rosen said that just having the two identifiers recorded could help in finding a recording. Paul Kyzivat pointed out that different display-names could be received, and also asked whether the metadata should indicate the source of an identifier (From or P-Asserted-Identity). Hadriel also raised the issue of how to handle a P-Asserted-Identity identifier marked as private. Brian Rosen (as individual) thought this would be a relatively rare case, although it could occur. So in summary, there was no objection to including multiple identifiers, but more work is needed on the details, and in particular on the privacy question raised by Paul. Slide 10: Charles Eckel wanted to make sure we don't put dynamic information on current speaker into the metadata, since RTP can provide this information, but Ram confirmed this was not the intention. Hadriel Kaplan pointed out that the initial INVITE request will not have any information to map CSRC to Participant, since it will only be available from CS RTCP, and therefore a re-INVITE would be necessary. So it is another case where the SRS cannot rely on having all information. Charles would nevertheless like to see this information available from day one. There were no objections to including it. Slide 12: It was clarified that the open issue concerns start/stop time for the association between a Participant and a Media Stream, i.e., the send and recv elements. Paul Kyzivat suggested the start/stop times are redundant, unless one is concerned about the difference between the actual start/stop time or the time the metadata update is received. It was agreed to discuss this on the list along with the other open issue regarding association between Participant and CS. Slide 14: Three options for unique ID formats had been proposed on the list by Paul Kyzivat, and although there seemed to be a convergence on the list towards option 3, it was felt that a concrete proposal (text) is needed. Also Paul should seek the opinion of XML experts. Leon Portman suggested that the format did not need to be standardized, but it was pointed out that unique identifiers are needed for the case of different SRCs recording to the same SRS. Slide 15: There were no objections to the approach on the slide, i.e., all receiving Participants must be explicitly indicated, no participation by default. In summary, Ram will produce a further version to address the closed issues and other comments that had been received and resolved. Topic - Protocol (Henry Lum) draft-portman-siprec-protocol-05 ================================================ Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://www.ietf.org/proceedings/81/slides/siprec-0.pptx Meetecho recording: http://77.238.22.57/ietf81/5550707/28_Jul_2011at21_18_38sec/part_2/player.jnlp Slide 7: On the purpose of the snapshot request, Leon Portman wanted it for cases where metadata has been lost (perhaps because of failure of one of the components on the SRS) but the RS and the capturing of media still continue. Hadriel Kaplan wants to keep the protocol simple, but is OK with having the snapshot mechanism for this purpose if it really is going to be used. Adam Roach is happy to use the mechanism for state synchronization, but not for recovery from syntax errors, and Henry agreed. Also Adam said we need to think carefully about what sort of information accompanies the snapshot request, particularly if it is to be displayable to a user. John Elwell (as individual) asked whether the mechanism could be used to recover from loss of a received update, and Adam and Hadriel were basically in agreement. Several people liked the idea of having a sequence number in the XML, at least for debugging. In summary, everyone seems to be in favour of having the snapshot mechanism for synchronization purposes, e.g., recovery from loss of metadata in the SRS or loss of an update. There was also consensus that when a snapshot is sent, the SDP should be sent too. Slide 8: People were comfortable that including in XML the label from the SDP a=label attribute was not inconsistent with the transport-agnostic nature of the XML metadata. Slide 9: The issue was whether we needed option tags for the RS, in addition to the SRC/SRS feature tags. The motivation might be for inclusion in the Require header field to ensure failure of RS establishment if the far end is not SIPREC compliant. Adam Roach stated that he had suggested this. Hadriel Kaplan was in agreement. Paul Kyzivat had no objection, although he thought we could get the same effect by attaching a metadata body part with handling required. Andy Hutton, however, noted that metadata would not always be present. In summary, there was no objection to adding the option tags. Slide 10: This concerned the need to allow an SRS-initiated RS. John Elwell (as individual) offered to send a more detailed proposal to the list. Hadriel Kaplan was concerned not to complicate the protocol, and perhaps make it a later extension. Paul Kyzivat asked about whether the SRC would know what it is to do on receipt of an INVITE for an RS. Andy Hutton said that this had always been there (it is in the architecture document), and that he wants to keep this and will help in provision of text. Disussion on adoption of this draft as a WG item was deferred until after the RTP discussion. Topic - RTP Issues (Charles Eckel) draft-eckel-siprec-rtp-rec-01 ================================ Draft: https://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/ Slides: http://www.ietf.org/proceedings/81/slides/siprec-3.ppt Meetecho recording: http://77.238.22.57/ietf81/5550707/28_Jul_2011at21_18_38sec/part_3/player.jnlp Slide 4: Proposal to add normative text where appropriate, with view to accommodating in the protocol draft. Seems reasonable, but doesn't need to be discussed now. Slide 6: Charles pointed out that the draft was trying to explain how to use the translator/endpoint/mixer models, and pointing out the implications, without recommending a particular one. Roni Even thought that we might wish to recommend one, but not mandate one. There had been some list discussion on this. In the absence of further feedback, Charles will consider adopting option 2 on the slide (subdivide translator into two - forwarder and tranlator). Roni also pointed out that there was no mention of RTCP BYE, which might be useful in relation to the earlier discussions on stop times. Slide 7: There was no objection to adding something on the case concerning more than 31 sources. Slide 8/9: Charles stated that there had been a little push-back on the list on use of the AVPF profile, i.e., some people had preferred to use FIR rather than the AVPF PLI. The proposal on slide 9 was to recommend PLI for picture loss and use FIR only in cases where not sending a decoder refresh point would render video unusable (e.g., when a new user joins a conference or when streams are switched). Roni Even pointed out that FIR would be needed when recording is started, i.e., when an SRS joins. Hadriel Kaplan had a concern that this applies only to the mixer case, since in the translator case the SRS is really a second class citizen, and cannot send feedback or even decide to use AVPF. That is a matter between the CS participants, and the SRC cannot control this. Charles asked whether this was good reason why an SRC should not be a translator, but Hadriel said that other models would be a huge cost and not realistic from a market perspective. Charles asked whether, if the two CS endpoints support AVPF, this could be used also on the RS. Roni explained that RTCP receiver and sender reports would be generated anyway, so it is a matter for the SRC how it handles RTCP reports from the SRS, and likewise how it handles different profiles on the CS and RS legs. Hadriel stated that there will be implementations of SRC that will not forward RTCP reports from the SRS, and he would be concerned about mandating anything. In conclusion, more work is needed in this area, in particular concerning iimitations of different approaches. Slides 10/11: There was no objection to reworking the text on symmetric RTP/RTCP as indicated. Gonzalo Camarillo pointed out that we had not specifically asked RTP experts (from AVTCORE) to attend this meeting, so we might need to run through some of these points again in future. Charles summarised by saying that he has had some great feedback so far, and the draft will need at least one more iteration, with further involvement of RTP experts. Wrap-up ================================ Returning to the protocol draft (draft-portman-siprec-protocol-05), the chairs asked whether this could be adopted as a WG document in fulfilment of the protocol milestone, even though RTP text needs more work before it can be incorporated. There was no objection to adopting the protocol draft as a WG item. Hadriel Kaplan announced that Acme Packet intend to test SIPREC kit at the next SIPit in Monte Carlo at end of October. Hadriel Kaplan also suggested we hold a face-to-face interim meeting, perhaps in Boston. The chairs had in mind a virtual meeting in early September, leaving time for a second one before IETF82, but Hadriel felt that some of the work needed more detailed discussion that would require more time and would benefit from being face-to-face. From a show of hands, only about 5 people seemed to be interested. However, the chairs will conduct Doodle polls for both a face-to- face and a double virtual meeting. The meeting was closed at 17.05.