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 
been 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 access 
networks on in backbones that have limited bandwidth or 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, but 
also some comments in support.  There seems to be interest to migrate 
legacy voice channels done over circuit switched connections to instead use 
VoIP, however there was confusion 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 SCID 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.  Although an initial 
list of tasks was presented, some people expressed concern that the scope of 
the work is not clear and that the rationale is poorly defined.  It is 
apparent that the work must start by writing a requirements document which 
defines the goals of the work, and reach agreement on that.


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.


				- * -