Minutes from IETF85 for XRBLOCK WG =========================================================================== Chairs: Dan Romascanu > Shida Schubert 1230-1330 FRIDAY, November 1, 2012. Room: 209 Note-takers: Keith Drage, Roni Even Action items =========================================================================== QoE - Discuss what information is needed in SDP. - Discuss the registiry(ies) needed to address different Mos types and calculations. TS Decodability Statistics - Chair to confirm if decodability is ready for WGLC Synchronization Delay and Offset - Author needs to clarify that the impelentation needs to decide the reference stream. - Kevin will post some comments on the list about signed or unsigned. - Kevin will post some comments on the beginning of session. Loss Concealment - Author needs to clarify the concealment types. - The draft will only cover audio not video (consensus in the room). - Chair will confirm that loss concealment will continue by now with audio only on the list. Summary Statistics - Colin will make point about DT-3 Concealed Seconds - The draft will cover audio only, will spin off another draft if needed for video. - Chair will look into IPR related to the draft before moving forward with the merge of concealed seconds and loss concealment draft. Jitter Buffer - Kevin will post some comments on the list. XRBLOCK Status Update ------------------------------------------------------------------------------ Chairs presenting. Presenter name change only. RTCP XR Blocks for QoE ----------------------------------------------------------------------------- draft : http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-qoe-02.txt presenter : Roland Schott ** Slide 3: Open issue 1 Paul Coverdale: If trying to report on QoE metric then need to refer back to the algorithm used. So final question on slide, do need to reference the specific algorithm. Chair: Does this need a registry? Paul C: Don't know but do need to tie it down to specific algorithm. Alan Clark: Agrees with Paul. If do subjective test then also affected by reference conditions. Really need to know what subjective test it was. Point on email list, for all these things depends on the methodology and conditions of test. Therefore need to have something to report the conditions of test, e.g. narrowband, wideband etc. Make sense to have a registry. Bernoit Clare? Remind that wrote an RFC which contains a nice registry with all this information. Need a template to explain the metric. ** Slide 4: Open issue 2 Alan Clark. Practival point in use of SDP. From the perspective of endpoints they have access to SDP. One of the application areas is for its use by probes; SIP can be encrypted in the network. If rely too much on what is in SDP then makes this difficult for the probes without the security key. Prefer to have the information in the XR block itself. Probe may not be even on the path of the signalling. Colin Perkins: Doesn't work if don't have the SDP. All rely on payload format and this information is in the SDP. The protocol design reason is that there is only a 4 or 5 bit field and most bits are already assigned. SDP make it more flexible to add more MOS types and payload types otherwise the fields in the XR are not big enough. Given that we need the SDP anyways,use it. Alan Clark: Have to do this all the time without SDP where the signalling is unavailable and therefore disagree with Colin. Colin Perkins: Does not think it is appropriate to define a standard that relies on guesswork. Continue discussion on list. Chair: Need to fix some issues before going to WGLC. Colin: Agree. Question on whether we need SDP is the wrong one. Question is what do you need in the SDP. RTCP XR Report Block for TS Decodability Statistics ----------------------------------------------------------------------------- drafft : http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-decodability-00.txt presenter : Rachel Huang Chair: Asked how many have read. 3 people have read. Who believes should not go to last call. None. RTCP XR Report Block for Synchronization Delay and Offset ----------------------------------------------------------------------------- draft : http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-synchronization-01.txt presenter : Rachel Huang ** Slide 3: Issue : reference stream choosen Colin: Just make clear in the draft that it is the implementation that decides which is the reference stream. ** Slide 4: Issue : signed or unsigned Kevin Gross: Standard timestamp is unsigned. This would therefore be non-standard. Intended to research to see if there was a standard signed. Colin Perkins. Basically offset from timestamp so doesn't matter if not standard. Chair: Timestamp name is misleading, really interval. Currently find value in both arguments. Need to research. Kevin Gross: Technically have plenty of bits to make it signed. Chair: Investigate more before making a decision. Roni Even: Clarify in the document that it is not a timestamp but a delta, otherwise find something that is a timestamp. Kevin Gross: Also have couple more comments to send to the list. ** Slide 5: Issue : beginning of session Colin Perkins: Last one does not work. Does not care which of the other two is chosen. Qin Wu: preferes second. Kevin Gross: Not yet a description of how we expect this information to be used. The use affects how we collect the information. Need more on applicability. Chair: Do we need both mechansims. Kevin Gross: Doubt it. Chair: Clarify and discuss more the use case. Glenn Zorn: Kevin's comment makes no sense at all. Quantum theoretical like. Seems apparent that you should know when a session starts. Receiver has to know that. For third, none of those make sense. Seems like intuitively should be difference in time when last stream completes initialisation and first one. Chair: Kevin to put comment on list and continue the discussion. RTCP XR Report Block for Loss Concealment ----------------------------------------------------------------------------- draft : http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-loss-conceal-02.txt presenter : Glen Zorn Has anybody read the draft: 5 raised hands. ** Slide 3: SHould we miss out video loss concealment? Roni Even: Should we just be more general and report on sender based concealment or receiver based concealment. If want to go into specifics then need more information. Sender based loss concealment is sending information forward in the stream that can be used. Colin Perkins: Sender already knows if FEC is used. If using FEC for loss concealment already have info to know. Don't see any need for general sender based concealment. Roni Even: This metric doesn't report the quality, only the time the concealment occurred. This is only a very limited subset even for the audio. Alan Clark: Enhanced came from Alan Clark back in 2002. Tere were not so many vareity of algorithms then. Tends to agree with some fo the comments made. Should extend to cover range of things used today. If have a number of losses then gives up and gives silence anyway so need to know that. What are the metrics for? To understand the configuration they are using at the moment is able to deal with the issues that are occurring. Kevin Gross: What does the Xrblock give you that packet loss doesn't? Glenn: Nothing to do with that, This provides what action was taken to conceal the loss. Glenn proposed to only specify the spec for Audio and spinn off another document if needed for video. Chairs: Who objects to Glenn's proposal (to issue an audio only draft). Colin Perkins: Supported. But more information might be needed. Roni Even: Supported. RTCP XR Report Block for Summary Statistics ----------------------------------------------------------------------------- draft : http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-summary-stat-01.txt presenter : Glen Zorn ** Slide 3: Qin Wu: More straightforward to only allow one option. DT-3 is simpler. Glen: Need to explain in the draft about using DT-3. If not send you cannot report back. Colin Perkins: Just for clarification this is the number of packets discarded. What happens if report with multiple sets of discards. Which one do believe. Need to tighten up the language. No need for DT-3, since it may cause ambiguity. Chairs: Asked Colin to make point on the list. Glen; This affects this draft but also affects a different draft. Will post new version at some point. RTCP XR Report Block for Concealed Seconds ----------------------------------------------------------------------------- draft : http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-concsec-00.txt presenter : Qin Wu Chair: Same issue as previous in separating out the video. - conclusion to limit the spec to cover audio. Glenn: Proposal that combine the two drafts. Chance that use one without the other is small. IPR question: Concealed seconds has Cisco IPR ??? Not clear. Chairs to look into this. RTCP XR Report Block for Jitter buffer ----------------------------------------------------------------------------- draft : http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-jb-00.txt presenteer : Varun Sing Chairs asked how many had read: 4 Kevin Gross: Will put some comments on the list - not ready to go.