Audio/Video Transport Extensions (avtext) Minutes for IETF 80 in Prague Chairs: Keith Drage (keith.drage@alcatel-lucent.com) Magnus Westerlund (magnus.westerlund@ericsson.com) Notetakers: Peter Musgrave Bill VerSteeg State of the WG --------------- The Chairs opened this first ever AVTEXT WG meeting. The Note Well, followed by today's WG agenda was presented. Then a milestone review was performed noting that the RAMS scenarios work milestone is coming up pretty soon. The Chairs are also working on the publication request of the "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)" (draft-ietf-avtext-multicast-acq-rtcp-xr). RTP Header Extension for Audio Level Indication ----------------------------------------------- Drafts: draft-ietf-avtext-mixer-to-client-audio-level-01 draft-ietf-avtext-client-to-mixer-audio-level-01 Jonathan Lennox presented this work which is a WG item of AVTEXT. The work is mostly done as they have been discussed a lot in AVT. The changes in the latest version of the documents are mostly editorial, one important change is the addition of some pseudo code for level calculation and an example renderer. Peter Musgrave commented that the render implementation and how it is done is a matter of taste and thus don't add a lot of value. However, the calculator code is good example. A WG consensus call was already in progress on this issue. Keith noted that there hasn't been much input to this call. The chairs made a poll of the room for each piece of pseudo code. There was 10 for and 2 against keeping the Audio Level Calculator code. Thus clear preference for leaving that in. For the Audio Level Render there was no one for and 3 to 5 against so a preference for removing it. The next issue to verify WG consensus on was the removal of the "Design Choices" section from the mixer-to-client-audio-level draft. The chairs poll of the room indicated that no one was against removing it from the document. Next open issue was what to do with "Levels in non-audio". Are the WG fine with leaving them unspecified? Unknown asked if we know what level means for video? Jonathan answered that we don't know. David Singer stated that if so we should ban its usage for know so that we can in the future assign a meaning if we find out. Jonathan, so we should ban it for now. Unknown stated, if there is no meaningful semantics, then say it now. Then we moved on to the next issue that it has been suggested that one should use ITU.P56.1993 for level measurements. Paul Coverdale, commented that this will give you active speech level, do you want that or RMS. Jonathan answered that he had assumed RMS. Paul commented that there are multiple methods, and it is not providing active speech level. Jonathan concluded that it is the client to mixer that specifies this, and that it needs to be clarified. On to the discussion if there is desirable to have an optional noise floor indication. Jonathan stated that he was personally moderately in favor. Stephen Botzko asked if there is a definition of how to measure? Jonathan responded that a robust definition is needed but currently they don't have one. Stephen Botzko responded that unless you can define it it should not be put into the specification, which Jonathan agreed to. There was no additional comments on this from the room. Keith asked the authors how they perceive the status is. Jonathan answered that client to mixer is ok. It needs a definition of noise floor, other than that there are only editorial and procedural changes needed. Enrico Marocco answered that the Mixer to client draft is ready for WG last call. The chairs asked the room for how many have read the mixer to client document. About 10 indicated that they had read the draft. Support for multiple clock rates -------------------------------- Draft: draft-petithuguenin-avtext-multiple-clock-rates-00 Marc Petit-Huguenin presented the background and history of the draft. The intention is to ask for WG adoption. He went to brief outline the main changes since previous versions. Magnus Westerlund (as individual) commented that if we go with switching SSRC and BYE does it really work? First of all are switching SSRCs supported by these poor implementations that doesn't handle timestamp changes. Secondly, how well does the implementations handle multiple SR in the same RTCP compound packet? From an RTP specification is appears unclear on how to do it as it affects the RTCP scheduling algorithm. Marc responded that it we are missing an understanding how existing implications. Jonathan commented that RTCP BYE is unreliable and one needs to consider what happens if it gets lost. Also if multiple SSRCs are already in use, switching SSRC is difficult. Associating the old stream to the new stream may be problematic. CNAMES can help, but not always sufficient. Marc commented that we should discuss on the mailing list as this appears to be rebooted and needs some help. Marc continued with the slides. Keith as chair raised that the Milestone for this is Dec 2011. Thus we should really consider adopting some text as WG item for this issue. So the question to the WG, are this document in the right direction or is there an alternative? Colin Perkins and Magnus Westerlund both indicated that it is in the right direction. Marc indicated that he will update the draft prior to do a WG adoption call on the mailing list. Considerations and Guidelines for Deploying RAMS ------------------------------------------------ Draft: draft-begen-avtext-rams-scenarios-00 Ali Begen presented the slides. The intended status was questioned. Keith stated that this document doesn't really meet the criteria for BCP, so it should be informational. Robert Sparks comments that if it is desirable to change the intended status talk to the ADs. The chairs made a poll of the room of how many that had read it. Only 4 indicate that they had read it. Keith noted that this needs input from the RAMS interested people, for example if there are more scenarios of interest. The chairs will poll for WG adoption soon. SRTP Store-and-Forward ---------------------- Drafts: draft-mattsson-srtp-store-and-forward-04 draft-naslund-srtp-saf-04 John Mattsson presented his slides. Keith asked if anyone considers this proposal useful. There was no one finding it so, 2 against. Eric Rescorla commented that there has been concerns raised before and he has not seen anything that resolved the concerns he has. Can't see how one does this in feasible way with the key-management. Richard Barnes commented that this was discussed in Stockholm and there has been no updates to the draft since then to address the issues. Roni Even commented that Dan Wing had some uses cases where it did not work, should consult with him prior to moving forward. Glen Zorn asked how real-time and store and forward really connects. The chairs concluded that there is no interest in this. This will be confirmed on the mailing list. The authors can continue as individual drafts to address the issues raised, and see if they can build support round a future working group proposal. RTP Splicing ------------ Draft: draft-xia-avtext-splicing-for-rtp-00 Jinwei Xia presented the general concept and what the major changes are. The questions to the WG was about if this should be adopted as WG item and if there is any open issues. Khan asked about the trust relation between the media servers and the splicer and how that is established. Jinwei replied that RTP isn't used to establish that relation ship but that it will be necessary if SRTP is used. Roni Even commented that the mechanism to insert the splicer is out of scope. Jonathan Lennox commented that by definition a splicer is a Man-in-the-middle. Splicer must have access to keying material. Charles Eckel raised a new question if the term "main video" has some specific meaning? Jinwei's answer was not captured. Magnus Westerlund (as individual contributor) commented that there are a number of issues to work out here. Draft needs to consider a number of details. He have posted to detailed comments to the mailing list. Keith asked the meeting if we want to adopt a milestone for this work? This question resulted in some comments. Magnus Westerlund (as individual contributor) sees a need for another doc revision. Need to see more details. Colin Perkins followed up with that people will still build splicers. There does seem to be interest and there are no other drafts. Keith commented that this appears to be mostly about using what we have as tools. Is time better spent on core work. Or are there sufficient interest in this work? Keith called for a show of hands for a milestone which covers this subject area, i.e. for an information draft about how to use existing tools. The result was around 25 in favor and 1 or 2 against. A strong preference in the WG for creating a milestone, the chairs will confirm on the mailing list and then go forward to request approval of the milestone with the Area Director. The meeting ended.