The AVT working group met twice at the 63rd IETF meeting (August 2005, Paris). Subjects under discussion includes using SMPTE timestamps with RTP, new extensions to RTCP XR, an RTP payload for ECN probing, packet reordering in ECRTP, RTP header compression over MPLS paths, using RTP with TFRC, a FEC streaming framework, RTCP extensions for SSM sessions with unicast feedback, RTP payload formats for EVRC, G.722.1 and VC-1, and codec control messages. The meeting was chaired by Colin Perkins and Magnus Westerlund. There were approximately 80 attendees at each session.

The chairs introduced the meeting, with the usual status review. The group has had four RFCs published since the last meeting, six others are with the RFC editor, and we have eight drafts under IESG review. The new working group charter and milestones have been approved; see the web page for details.

Discussion regarding the use of the media types registry to name RTP payload formats is ongoing, although progress since the last meeting has been limited. Roni Even expressed concern that the discussion is delaying progress of several payload formats; the chairs agreed that this is a significant problem.

draft-singer-rtp-hdrext-00.txt draft-singer-smpte-rtp-01.txt

Dave Singer briefly outlined the contents of the drafts, and requested input from the working group. The main open issue is the registration rules for header extensions, which need to include a date as well as a reverse DNS name. The group accepted both drafts as work items.

draft-ietf-avt-rtcp-xr-mib-02.txt

Amy Pendleton discussed the RTCP XR VoIP metrics MIB, outlining changes since the previous version (see slides). Several implementations exist, and it is believed there are no significant open issues. One item still to do is to incorporate the Session Table into the RTP MIB, otherwise the draft is believed complete.

Colin Perkins asked if incorporating the Session Table into the RTP MIB would cause any backwards compatibility issues? Dan Romascanu commented that the semantics of the MIB change (due to the extra table), but it's otherwise an extension that won't break anything.

Dan Romascanu noted that there are still some places in the draft which refer to the old MIB structure, and need updating. He will propose text to correct these.

Magnus Westerlund and Dan Romascanu noted that it's unclear how the source and destination fields are handled in multiparty conferences. The entries in the Session Table should be clarified, perhaps using the terms "local" and "remote"?

draft-clark-avt-rtcpxr-bis-00.txt

Amy Pendleton discussed new parameter extensions to the RTCP XR block. The feedback from the previous meeting was to define a separate draft for video metrics - this hasn't been done yet, but will occur shortly. The present draft includes basic video metrics, and the more developed high resolution audio metrics (see slides for a summary of the changes).

Colin Perkins and Magnus Westerlund expressed concern about the number of options and possibilities for vendor extensions in the new HR Voice Metrics block. Rajesh Kumar commented that there are various standards for jitter measurement that exist and must be reflected, hence the use of so many options. Colin agreed, stating that he didn't ask to remove all the options, just to use caution in adding only those which fulfil a real need.

Colin Perkins and Dave Oran expressed concern about partial duplication of information between the RTCP XR block and the SDP signalling. Colin was of the opinion that this information can be retrieved from the SDP and doesn't need to be included in RTCP XR. Dave accepted the potential usefulness of this information, but was opposed to duplicating it in a different format: either include the complete SDP data, or rely on the signalling protocol.

draft-alexander-rtp-payload-for-ecn-probing-01.txt draft-babiarz-tsvwg-rtecn-04.txt draft-alexander-rtecn-use-cases-00.txt draft-alexander-congestion-status-preconditions-00.txt

Corey Alexander presented a proposal for an RTP Payload Format for ECN probing, which can be used for congestion-based admission control. The SDP aspects of this were presented in MMUSIC; and the drafts were also discussed in TSVWG.

Dan Wing questioned the use scenario: what is meant by admission control, since there is no guarantee of resource availability? The mechanism will allow the state of the network to be measured, but it's unclear what can be done with that information: a measurement of the congestion state for a particular point in time implies nothing about the future state of the network.

Colin Perkins noted that this proposal uses RTP in a manner that is far from the usual semantics: no media data is conveyed or played out. This implies that it's not an appropriate use of the RTP protocol. Dave Oran agreed, but noted that there is a desire to make probing packets appear similar to data packets. Joerg Ott wondered why appropriately sized and spaced UDP packets can't be used to probe the path, before the RTP flow starts.

Michael Ramalho noted that while this format may not be suitable for admission control, it can be used to provide an indication that some requested level of QoS is not available. Colin Perkins agreed with the concept, but noted that ECN could be applied to standard media streams for that purpose, without needing a new payload format.

Finally, Colin Perkins noted that, for this to be useful, it must be applied to all media types, including text. Colin thought it likely that a MIME registration for this format under the "text" top-level would receive considerable push back during the media types review.

draft-koren-avt-ecrtp-reorder-01.txt

Andrew Johnson discussed packet reordering and ECRTP, explaining how a decompressor can handle various jumps in sequence number that might be caused by packet reordering. The group was asked to consider the draft as a work item: the chairs agreed that it covers appropriate material, but Magnus Westerlund requested that the draft include more details on the protocol changes, use cases, and limitations before it be accepted.

draft-ash-avt-hc-over-mpls-protocol-01.txt

Jerry Ash presented protocol extensions for header compression over MPLS paths, reviewing the changes and outlining the open issues (see slides). Colin Perkins commented that the protocol constants needed to implement this are scattered over several drafts, which makes this hard to follow. Otherwise, this is progressing well, and will become an AVT work item now the new charter is in place.

draft-ietf-avt-tfrc-profile-04.txt

Ladan Gharai outlined the changes to the RTP profile for TFRC since the last draft (see slides).

Dave Oran asked if there is a need to describe how to combine this with the AVPF and SAVPF profiles? Colin Perkins that the timing rules may be difficult; Anders Klemets agreed, but noted that feedback packets might be useful in conjunction the TFRC profile. Should consider defining the TFRC profile to allow AVPF packet types, with different timing rules.

Stephan Wenger commented that he believed the introduction of a second timestamp to be long overdue in RTP, and asked why not add more timing info? e.g. decoding timestamp, presentation timestamp, etc. There was some discussion of the merits of this, but no conclusion was reached.

Magnus Westerlund wondered if additional guidelines were needed for how applications should handle media in conjunction with congestion control. Ladan agreed that this is a difficult subject, but didn't include it to avoid overlap with Tom Phelan's draft on Strategies for Streaming Media Applications with TFRC.

draft-ietf-dccp-tfrc-media-00.txt

Tom Phelan outlined the draft on streaming media and TFRC, explaining some issues that arise when designing congestion controlled streaming media applications. This was discussed more in the DCCP working group.

draft-watson-tsvwg-fec-sf-00.txt

Mark Watson outlined a proposed FEC Streaming Framework, building on work done in RMT and 3GPP to provide an FEC layer that can be used, amongst other things, to provide protection for RTP flows. This was discussed in detail in TSVWG.

draft-ietf-avt-rtcpssm-09.txt

Joerg Ott discussed the RTCP extensions for SSM with unicast feedback, the latest version of which has been reworked to separate the concepts of media source and distribution source. The remaining open issue is how to signal the link from media source to distribution source in SDP: the proposal is to make this a separate session at the SDP level, hiding the details from the receivers. Colin Perkins asked that the draft clarify that there is a single RTP session, despite it being separate at the SDP level, but otherwise there was general agreement on this choice.

Dave Oran asked if there are any exceptions for RTCP packets that don't need to be reflected down the tree (e.g. NACK feedback packets?) and if the document needs to say something about this? Joerg replied that there is some wording related to this about summary reports, but that in the reflection mode you'll get compound packets, and it may not be possible to split out the subpacket when reflecting (e.g. due to authentication). Need to think about it, and include some words.

draft-even-avt-rfc3047-bis-01.txt

Roni Even discussed the updated payload format for G.722.1 (adding 14kHz support to the RFC 3047 format). Magnus Westerlund noted that there is a need for clarifications on how the RTP marker and sequence number are to be handled, but there was otherwise little discussion because the format is not complex. The sense of the room was to accept this draft as an AVT work item.

draft-klemets-avt-rtp-vc1-00.txt

Anders Klemets outlining key features of the VC-1 codec, and described the payload format specification. Discussion related primarily to the coupling of RTP timestamp to decode time, rather than the presentation time. Dave Singer noted that RTP payload formats generally set the RTP timestamp equal to the presentation time and send in decode time order, and there are good consistency and backwards compatibility reasons to stick with this if possible. Dave also had some concern about how one could calculate the presentation time from potentially missing packets, wondering if it's always possible to calculate? Including an explicit presentation time would avoid this problem.

Stephen Wenger also spoke in favour of using the presentation time as the RTP timestamp. He noted that this codec seems similar to MPEG in its timing model, and wondered if the decode time was actually a time or just a sequencing concept. If the only requirement is sequencing, then the RTP sequence number is sufficient, rather than including the decoding timestamp.

Finally, Magnus Westerlund noted that using the decoding time for the RTP timestamp breaks the RTP synchronisation model, since there is no longer have a common timebase for synchronisation between media (but, if the presentation time is used, this is equivalent to the sampling instant used for audio codecs).

The conclusion was to change to using the presentation timestamp.

The sense of the room was to adopt this draft as an AVT work item.

draft-wenger-avt-avpf-ccm-00.txt

The final agenda item was a discussion of open issues with the codec control messages draft, led by Stephan Wenger.

Colin Perkins, Stephan Wenger and Magnus Westerlund discussed the need for the Temporary Max Media Bit Rate (TMMBR) indication, to understand whether the usual RTCP mechanisms can be used to measure the bit rate, rather than requiring the sender to acknowledge the TMMBR message. The conclusion was that the acknowledgement is needed, but the rationale should be clarified.

Dave Oran asked if the TemporalSpatialTradeOff (TSTR) message is not already in SDP? Yes, but there is a need for faster signalling than in a SIP exchange. Again, rationale to be clarified.

Colin Perkins queried why FreezePicture Indication was needed, since it can be derived from the media stream (e.g. SSRC/CSRC will change, to indicate a change of source, and the decoder then parses but doesn't display the stream until it gets to a refresh point). Stephan replied that this is because some gateways don't correctly set the SSRC/ CSRC. Dave Singer also noted that some people don't like freeze picture, so the requirement for this is not universal. Stephan noted that he does not think this feature vital, and may remove it in the next revision.

Dave Singer expressed concern that repeating requests does not always work; might want a method to stop a receiver making repeated requests to a sender that cannot satisfy them.

Colin Perkins concluded by noting that these messages can potentially turn RTCP into a full scale control protocol, rather than a channel to convey presence, reception quality statistics and hints on the desired media coding. The draft needs to clearly set bounds on the appropriate codec control messages, and to understand the limits of what is being enabled.

- + -