[AVT] Draft minutes for Vienna meeting

[Colin Perkins <csp@csperkins.org>]

Folks,

Attached are draft minutes for the AVT meeting at the 57th IETF in Vienna.
Please send any comments or corrections to the chairs by 1st August.

-- 
Colin Perkins
csp@csperkins.org
Audio/Video Transport Working Group Minutes

Reported by Magnus Westerlund and Colin Perkins 

   The AVT working group met once at the 57th IETF in Vienna. During this
   session the working group discussed the updated charter, current status,
   VoIP congestion control concerns raised by the IAB, the SSM RTCP Extension
   and numerous RTP payload formats. 


Introduction and document status

   The meeting started by Stephen Casner announcing that this will be his
   last meeting as AVT co-chair. Allison Mankin presented Stephen with a
   plaque enumerating the RFCs that Stephen has been shepherding during his
   time as chair for AVT since its start in 1992. The working group showed
   its appreciation for his long service with thundering applause.

   Stephen Casner outlined the current working group status. No RFCs
   relating to AVT have been published since the last meeting, however
   there are a currently 7 in the RFC editor's queue. The RTP specification
   is currently in author's 48 hours and has gone through one substantial
   change. The usage of the SDP RR and RS bandwidth modifier results in
   change to the RTCP interval calculation mechanism. An RTP active sender
   is allowed to take its part of the RR part when the number of senders
   are larger than RS/(RS+RR).  This is a generalisation of the previous
   25% rule that was present.  The senders=0 clause in the example
   algorithm (A.7) has also been removed to prevent senders bandwidth
   bleeding to receivers when RR=0.  
   
   The other AVT drafts in the RFC editor's queue are the AVP profile, the
   RTP profile MIME registration, the SDP bandwidth modifier for RTCP, the
   RTP payload format for EVRC/SMV and the RTP payload format for ETSI ES
   201 108 DSR.

   The specification for Enhanced IP/UDP/RTP header compression is with the
   RFC Editor, but the authors would like to fix one technical shortcoming
   before publication. This can be done if the Area Director and Working
   Group approve of the change. The issue is to include the CSRC list in
   the calculation of the Headers Checksum (HDRCKSUM), to enable header
   validation and prevent error propagation in the CSRC list. The working
   group was given until 18th July (the end of the IETF week) to comment on
   this change. Positive comments were made during the meeting, and there
   were no objections on the mailing list.

   The working group also has a number of drafts in IESG review: Tunnelling
   multiplexed compressed RTP (TCRTP), Secure RTP (which has had some recent 
   modifications in response to AD review), the Payload format for MPEG-4,
   RTCP extended reports, RTCP feedback (draft-ietf-avt-rtcp-feedback-07)
   and associated simulations (draft-burmeister-avt-rtcp-feedback-sim-02),
   and RTP retransmission (draft-ietf-avt-rtp-retransmission-08).

   The drafts of Uneven Level Protection (draft-ietf-avt-ulp-07.txt) and
   Unequal erasure protection (draft-ietf-avt-uxp-05.txt) were not updated
   for this meeting. 

   Colin Perkins noted that ITU-T SG16 Q.14 is working on standards for FAX
   over RTP. He expressed interest in increasing coordination between ITU-T
   and AVT to ensure that solutions developed do not conflict. He also
   noted that a MIME type registration must be done to ensure that the FAX
   over RTP work can be referenced by IETF protocols - such a registration
   should be coordinated with AVT.


Charter Update

   A preliminary updated WG charter with milestones was presented and has
   also be posted to the mailing list. Please review and send any comments
   to the list. The updated charter contains the following items: 

    - Advance RTP and the A/V profile to Full standard RFC
    - Review and revise RTP payload formats for Draft Standard RFC, as
      appropriate
    - Develop new RTP payload formats as needed. 
    - Complete the generic FEC formats (ULP & UXP)
    - Complete the RTCP extensions for SSM sessions 
    - Develop a framing method for use of RTP/RTCP over TCP & TLS 
    - Review applicability of RTP header compression for MPLS 
    - Develop a new RTP profile combining AVPF and SAVP 
    - Coordinate with the DCCP working group to ensure efficient transport
      of RTP over DCCP, and to ensure an appropriate API is developed

   Longer term goals of the working group are to move to Draft Standard 
   the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, 
   the Compressed RTP (CRTP) framework, including Enhanced CRTP, and the
   RTP MIB. Further development of media codecs is not expected to be
   chartered. 


DCCP
http://www.ietf.org/html.charters/dccp-charter.html

   Aaron Falk made a short informational speech about DCCP and its upcoming
   design review. He encouraged people to read the specification, and come
   to the design review. He especially desired people in AVT to comment on
   any API related issues, as this relates to the possible usage of DCCP. 


RTP Payload Format for MIDI
draft-ietf-avt-mwpp-midi-rtp-08.txt
draft-lazzaro-avt-mwpp-coding-guidelines-03.txt

   Colin Perkins outlined some slides from John Lazarro regarding the RTP
   payload format for MIDI. This format has been reviewed by the MMA (the
   MIDI Manufacturers Association) and their comments have been addressed.
   An implementation exists and will be updated in regards to the changes
   during the summer. It is expected that the draft will be ready for
   working group last call before the next meeting. 

   The companion implementation guide for RTP MIDI has been updated to more
   concern the MIDI parts, like recovery journal, than to deal with general
   RTP things. John Lazzaro has requested that this document becomes a AVT
   working group document. A hum was performed with some indication for
   approval and none against.  


RTP framing for TCP and TLS
draft-lazzaro-avt-rtp-framing-contrans-01.txt

   Colin Perkins updated the group on the RTP framing for TCP and TLS. This
   draft has been awaiting resolution of the MMUSIC WG comedia work and the
   rechartering. It can be expected to make progress once the new charter
   is accepted. 


IAB Concerns Regarding VoIP congestion control 
draft-iab-congestion-00.txt

   Sally Floyd made a short presentation on an initial draft of IAB
   recommendations regarding congestion control for Voice over IP flows.
   The basic recommendation is that any flow that is facing persistent high
   rates of packet loss should stop sending. Having congestion control of
   some type will ensure that congestion collapse does not happen, user
   quality can be maintained, and that fairness against other VoIP flows
   and TCP flows can be maintained in a best effort network. 

   The draft does not recommend any particular deployment path for VoIP,
   like best effort, QoS reservations, etc. It also not specifying any
   behaviour, it is only a recommendation that there is a need to address
   these issues. It also tries to address some of the framing problems and
   what assumptions that can be made, like what is fairness, and is the
   network, bit-rate or processor limited. 

   Several questions and comments where raised. One was the need to clarify
   what it means to terminate a connection: in this case stop sending media
   (not necessarily to terminate any signalling relationship). It was asked
   if RTCP information is sufficient for deciding when to terminate the data
   flow, which will need further investigation. 

   Is was also asked why the draft is restricted to VoIP and doesn't address 
   other media types? This is not because other media don't need congestion
   control for other media, rather it's a reaction to the special treatment
   often proposed for voice (e.g. because flows are low bandwidth). This
   special treatment is not considered appropriate.  It was also clarified
   that the document does not address congestion control for multicast. 


RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals 
draft-ietf-avt-rfc2833bis-03.txt

   Henning Schulzrinne presented the current status of the draft. No major
   technical changes have occurred, and it is now believed that all events
   have been tracked down (however, review from someone working in this
   area would be appreciated). The examples in the draft have also been
   improved. Henning believes that the document is ready for WG last call,
   however some more dedicated review would be beneficial. Tom Taylor and
   Flemming Andreasen volunteered to perform a review of the document. The
   goal is to have the draft ready for last call before or around the next
   IETF meeting. 

   This draft was originally intended to become a Draft Standard RFC,
   however so far the interop testing has not progressed. Henning
   questioned the level of interoperability testing that will be needed: if
   every event needs to be tested that will be a futile effort as they are
   over a 100 in total, and from several different systems. Alternatives
   are: 

    - interop testing only needs to show that the basic timing and redundancy 
      mechanisms works
    - to strip all events that can't be tested, which probably will result
      in only DTMF tones will be left
    - the last alternative is to leave this as a proposed standard for all
      future. 

   The chairs will ask the area directors if basic timing and redundancy
   interoperability is sufficient for testing for draft standard. It was
   proposed that the draft be continued to be progressed to WG last call
   and be published as Proposed Standard RFC, while work continues on
   interoperability testing. The only consideration is if any of the
   interoperability will result in technical changes to the document, 
   in that case it might be better to wait. It would be advantageous if
   someone actually doing implementation work using this format could be
   participate in the interoperability testing. 


Payload format for Speex Codec 
draft-herlein-speex-rtp-profile-01.txt

   Phil Kerr presented an update to the RTP payload format for Speex.  The
   format has received extensive comments on the mailing list that need to
   be addressed in next version. Comments in the meeting were regarding the
   usage of the RTP timestamp rate. There has been some consideration that
   a codec parameter for rate may be redundant, since the codec has some
   functionality for recovering sampling rate. Another alternative would be
   to use different RTP payload types and timestamp rates depending on
   codec rate, this is however not without problem as Stephen Casner
   pointed out. The issue needs further investigation. The recovery of the
   timestamp for different frames when performing aggregation also needs to
   be clarified. 


Payload format for Vorbis 
draft-kerr-avt-vorbis-rtp-02.txt

   Phil Kerr presented an update, where the main issue is related to the
   codebooks that the codec uses. One thing introduced in the last version
   is caching of the codebooks. This needs to be clarified, especially in
   cases where the code book needs to transfered. A codebook is not limited
   in size but they are commonly in the size 10-14 kbytes. So far suggested
   mechanism are: 1) Transfer in HTTP, 2) send it RTCP APP packets, 3) Use
   RTP over TCP, 4) try to define a limited set of codebooks that has to be
   cached and are simply referenced. Steve Casner commented that in RTP
   version 1 there was a mechanism to transfer parameters in parallel.
   However this was removed due to synchronisation problems. Having any
   such mechanism is a slippery slope and needs to be threaded carefully. 

   What is the gain from performing application level fragmentation, rather
   than using IP level fragmentation? Need to be further clarified and
   evaluated if enough gain is present to warrant the complexity of the
   mechanism. There has also been a number of other general comments on the
   draft on the mailing list regarding usage of SDP parameters, Path MTU
   discovery, RTP timestamp recovery, and frame aggregation that needs to
   be resolved. 


Internet Low Bit Rate Codec and RTP payload format
draft-ietf-avt-ilbc-codec-02.txt
draft-ietf-avt-rtp-ilbc-02.txt

   Alan Duric presented an update of the codec and payload format. The
   codec has been reviewed by speech coding experts and their comments 
   will be distributed when the last call is announced. As a result of 
   the review the codec specification has been clarified and corrected.
   The new version should be possible to implement based only on the
   description rather then the source code.

   The payload format has an open issue with mode flag if only one side 
   is capable of supporting 20 ms frame length in an SDP Offer/Answer
   negotiation. The proposal to fix this is to include an offer/answer
   section in the draft, specifying bi-directional behaviour for the mode
   flag. A related issue is that ptime can't double as mode flag (this
   should be explained in the text, since it is a common question). 

   As there has been no demand for comfort noise (CN) generation it will
   not be included in the Codec. Henry Sinnreich commented that Voice
   Activity Detection (VAD) and CN generation is important. The counter
   comment was that an external VAD and the generic CN can be used anyway.
   There might also be future work to provide iLBC with VAD and CN. 

   Colin Perkins asked if there is any need for test vectors? The answer
   from Alan is that the codec specification is desired to remain being a
   floating-point defined one and therefore exact test vectors can't be
   used.  However there is a possibility to provide test vector and then
   use PESQ measurements to check how far from the nominal output ones
   implementation produces. If any vector will be provided they will be in
   a separate draft.

   Jon Peterson asked if the mode parameter is a more generic parameter and
   therefore should be defined as such. Alan said that he had seen it in
   some other codecs. Magnus Westerlund commented that any mode parameter
   and their values are codec specific and should therefore be defined as
   such. 


RTP Payload Format for Uncompressed Video 
draft-ietf-avt-uncomp-video-03.txt

   The current status and remaining open issues were presented by Ladan
   Gharai. There have been few technical changes since the last version,
   mostly editorial and related to understanding. The two payload
   parameters sub-sampling and color-mode has been combined into one
   parameter (sampling) to avoid the usage of "impossible" combinations. 

   The remaining open issue is if the currently defined colorimetry values
   are sufficient or if there are more that should be defined? David Singer
   also had an comment that YUV-4:4:2 sampling can have their chroma
   samples in different orders. This needs to be addressed. 

   After the next update the draft is expected to be mature enough for
   working group last call. 


RTP Payload for H.264/JVT Video 
draft-ietf-avt-rtp-h264-02.txt

   Stephan Wenger presented the current status. The video codec itself has
   now been approved by ITU as H.264 and will soon also be approved by
   ISO/IEC. Work will continue in the JVT for professional extensions,
   however the NALU interface will not be changed, so this work is not
   believed to effect the payload format. The updated draft has been
   significantly improved regarding understanding, especially of the
   decoding order number (DON) concept. 

   There are a few remaining open issues. Should we do base64 encoding of
   the parameters sets instead of base16? There does not seem to be any
   formal problem of using this, and it will provide better efficiency. 
   The security consideration needs to be improved and carefully reviewed.
   There is concern over Timing SEI messages, since broken implementations
   may disregard the RTP timestamp. There is need for strong clarifications
   on the problem of doing that. Steve Casner commented that at least the
   blame and cause are on the same side, namely with the decoder. 


RTP Payload format for 3GPP Timed Text 
draft-rey-avt-3gpp-timed-text-00.txt

   Jose Rey presented for the first time a proposal for an RTP payload
   format for the 3GPP timed text format. The timed text format provides
   decorated and timed text, that can be used for karaoke and subtitling.
   There is a need to complete this work fairly quickly as the 3GPP Release
   6 deadline is officially march 2004, and may move to June 2004. 

   Steve Casner commented that the current proposal seems to provide much
   flexibility that does not provide any useful functionality, and only
   complicates the format. Colin Perkins also questioned how this work
   relates to RFC 2793, RTP Payload for Text Conversation. The answer is
   that text conversation does not provide modifiers for style and fonts
   and other decorations as 3GPP Timed Text provides. 

   Joerg Ott raised the most substantial question: should this be a more
   generic work. The applications are not limited to 3GPP mobile phones
   with streaming, and a generic format seams appropriate. David Singer
   commented that he had hoped that the W3C and MPEG work on authoring and
   transport of decorated and timed text would be further progressed at
   this time, and could provide input into this work. However Dave also
   pointed out that there is a strong need to meet the 3GPP deadline.
   Magnus Westerlund further commented that he hoped that people were
   talking about a generic payload format rather than specifying a generic
   set of operations on text (i.e. a text codec) in duplication of work
   ongoing in other standards bodies. David singer further commented that
   there are usually no comments when people standardise multiple different
   codecs, that one generic is enough. The conclusion is that there is need
   to further explore the scope of the work here. The subject should be
   clarified through a mail discussion or internet draft. 

   The request for working group status has been delayed until the open
   issues regarding how generic the work should be can be resolved. 


RTCP Extensions for SSM Sessions with Unicast Feedback 
draft-ietf-avt-rtcpssm-04.txt

   Joerg Ott presented the update of the draft. The format has reverted
   back to using its own RSI RTCP format instead of defining XR extension
   formats. Some editorial issues have not been fixed yet. The authors
   believe there are only a few remaining technical issues for this draft.

   One issue is if the distribution source should be allowed to use only
   the senders RTCP bandwidth part or also the receivers? Steve commented
   that the appropriate thing would be to allow the distribution source to
   use all RTCP bandwidth as it summaries all RTCP. Magnus Westerlund also
   commented that care should be take to define the RTCP behaviour for SSM
   in the draft as the default, however future profiles may redefine this
   behaviour. 

   The second issue is the possible need to have values indicating for
   which sources, or number of sources, the gathered information in RSI
   mode applies to. This may be an unnecessary complication of the format,
   and Magnus Westerlund commented that it only seems to be applicable to
   some of the formats. Joerg asked if there is any need for this feature 
   otherwise the authors plan to go for simplicity here (meaning that the
   receivers have to trust the sender to do the reasonable thing when
   summarising). 

   The third issue is that RTCP BYE packets are reported five times (as is
   done for SSRC collisions). However there seems to be little necessity of
   doing this for normal RTCP BYE packets. Steve Casner commented that it
   seems to be an advantage of having this to work in the same way as
   standard RTCP. Colin commented that there is probably no need to report
   a collision more than one every time you detect it: if the receiver that
   causes the collision does not receive the report packet, the collision
   will continue and a new collision report will be sent after the next
   observation of it by the source. 

   There is significant interest in this work and the authors should do
   their best to meet the December milestone in the preliminary revised
   charter. Colin Perkins pointed out that the definition of the "a=rtcp" 
   attribute contradicts the definition in draft-ietf-mmusic-sdp-nat-05.txt. 
   The intention from the authors was to use it as defined in the SDP NAT
   draft. 

   Colin Perkins noted that while the Security Considerations section has a
   thorough declaration of the problems present with this RTCP extension,
   there is a need to have normative declaration on how these security
   considerations shall be addressed in different applications. If not,
   there will not be possible to have an interoperable implementations. 


Requirements for performing RTP header compression over MPLS networks
draft-ash-e2e-voip-hdr-comp-rqmts-00.txt
draft-ash-e2e-vompls-hdr-compress-01.txt
draft-ash-e2e-crtp-hdr-compress-01.txt

   Jerry Ash presented an introduction and motivation for the work that has
   previously been discussed in the MPLS working group. There are several
   ideas that has been proposed in this context. The main idea is to
   provide RTP/UDP/IP header compression over several hops in backbones
   that have expensive bit-rate costs. Ideas include that one can perform
   header compression from an ingress point in an MPLS network to the
   egress point without doing compression/decompression for each link.
   Instead the MPLS router can forward the compressed packets based on
   either MPLS labels, or the compression context IDs. However the
   scalability of each solution needs to be further investigated. The
   context switch idea could also be applied outside an MPLS network for
   other links. Another part of the complete framework is to ensure that
   the header compression mechanism can handle the long delay that may
   result between the compression and decompression points. So far the
   assumption is that ECRTP will be enough for this. 

   There were several voices raised questioning the need of this work.
   There seems to be interest to migrate legacy voice channels done over
   circuit switched connections to instead use VoIP. Further there was a
   lot of confusion in the public in regards to what End-to-End in the
   presentation meant. However this is either MPLS ingress to egress, or in
   some optimised cases may be through end-to-end if all nodes from end-
   point to end-point support CCID switching and header compression. This
   mechanism will not be media dependent as it will be able to compress the
   header for any RTP transported media. The actual work to be done is not
   clear and some people address concern that it seems to be a very strange
   idea. It is clear that the work must first start with writing an
   requirements document that people agree on and to get the people
   understand what the goals of this work is. 

   Co-coordination with other working groups will be needed, in particular
   the MPLS working group, and it is hoped that the people from other WG
   will participate in also in the initial phases defining requirements.   

				   - * -