Subject: [AVT] IETF 59 AVT minutes

From: Magnus Westerlund <[email-masked]>
Date: Thu, 01 Apr 2004 14:12:27 +0200

Hi,

Attached are the final AVT minutes after addressing the comments 
received during the comments period.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
Audio/Video Transport Working Group Minutes

Reported by Magnus Westerlund and Colin Perkins

   The AVT working group had two sessions during the 59th IETF meeting, 
   the first on Tuesday morning, and the second on Wednesday afternoon. 
   During these sessions the WG discussed RTP payload formats for 
   different media codecs, RTCP Extensions for SSM, header compression 
   requirements for MPLS, a NOOP RTP payload format with RTCP request 
   hint, and a new RTP profile for congestion control with TFRC. 

Introduction and Status Update

   The meeting began with a status update from the chairs. Two RFCs 
   have been published since the last meeting (RFC 3611 and RFC 3640) 
   and one draft (draft-ietf-avt-srtp-09.txt) is in the RFC editor's 
   queue. Five AVT drafts that have been reviewed by the IESG and need 
   to be updated to address the review comments:

   	draft-ietf-avt-rtcp-feedback-08.txt draft-burmeister-avt-rtcp-
   	feedback-sim-05.txt draft-ietf-avt-rtp-ilbc-04.txt draft-
   	ietf-avt-ilbc-codec-04.txt draft-ietf-avt-rtp- clearmode-
   	04.txt

   A non-working group draft that has been reviewed by the group (draft-
   jones-avt-audio-t38-03.txt) is also in IESG review, however the ITU 
   has make changes to the underlying reference, and these need to be 
   reflected in the draft before it can advance.

   There are two drafts awaiting AD review (draft-ietf-avt-uncomp-
   video-06.txt and draft-ietf-avt-rtp-retransmission-09.txt) and and 
   one in IETF Last Call (draft-ietf-avt-tcrtp-07.txt). AVT has 24 
   working group drafts and 15 individual drafts that are either being 
   reviewed by AVT, or targetted to become AVT WG documents.

   Roni Even asked if the RFC number for SRTP has been assigned, since 
   the ITU wishes to reference it.  The answer is that it is possible in 
   these cases to get the RFC number, and such requests should be sent 
   to the WG chairs along with motivation for pre-assignment. The 
   earlier in regards to any deadline such requests are expressed, the 
   easier it is to fulfil them. 

   Magnus Westerlund reported on the status of several drafts that were 
   not otherwise discussed:

   - draft-ietf-avt-rfc2833bis-04.txt has received major updates for 
   clarity and to add new events, and needs review.

   - draft-ietf-avt-ulp-09.txt has been updated to address prior 
   comments, and needs review. A third-party IPR notice has been 
   received for RFC 2733 and this draft. The IPR holder is Lucent, who 
   has a general IPR statement (see http://www.ietf.org/ipr.html). 
   Clarification on the status of the IPR relating to these drafts has 
   been sought, and will be made available once received.

   - draft-ietf-avt-uxp-06.txt is awaiting an update to address 
   previous comments.

   - draft-ietf-avt-mpeg1and2-mod-00.txt has not been updated. It needs 
   review to be able to progress towards Draft Standard.

   - draft-ietf-avt-rtp-dsr-codecs-00.txt is the result of merging the 
   three separate DSR drafts. Review is needed, to see if this draft is 
   ready for WG Last Call.

   - draft-ietf-avt-profile-savpf-00.txt needs review by the group, and 
   an update after review comments have been given. It is hoped that it 
   will be ready for WG Last Call after the update. 

   - draft-ietf-avt-rfc3119bis-02.txt has been updated and is planned 
   to go for draft standard. See also interoperability draft. 

   - A new version of draft-ietf-avt-rtp-h264-04.txt was submitted 
   before the meeting, but since then the need for some small updates 
   has been noticed. After the update it is expected to be ready for 
   working group last call.

   - draft-ietf-avt-rtp-jpeg2000-04.txt needs review. Please comment to 
   the mailing list. 

   - draft-kerr-avt-vorbis-rtp-03.txt needs review. Please comment to 
   the mailing list. 

   - draft-herlein-speex-rtp-profile-01 has expired, and needs to be 
   updated if work is desired to progress. 

   - draft-ramalho-rgl-rtpformat-02.txt has expired, and also needs to 
   be updated. Comments were provided, to be reflected in the update.

   - draft-chen-rtp-bv-02.txt needs review. The authors have requested 
   that this draft become an AVT work item: comments are solicited and 
   should be sent to the mailing list.

   - A number of comments on draft-ahmadi-avt-rtp-vmr-wb-00.txt were 
   given 
        during the previous IETF meeting, these need to be 
   addressed in order to progress the draft. 

   - draft-ash-avt-ecrtp-over-mpls-protocol-00.txt is an initial 
   proposal to address the requirements for MPLS header compression 
   identified in draft-ash-avt-ecrtp-over-mpls-reqs-01.txt. This cannot 
   progress until requirements and charter discussion have been 
   completed.

   - draft-clark-avt-rtpmibv2-00.txt  needs an update to address 
   comments given on the draft. Author intends to do this in the near 
   future.

   - draft-finlayson-avt-mpa-robust-interoperability-00.txt is an 
   initial submission, on what needs to be tested to verify 
   interoperability of the Robust MP3 payload format, in order to go to 
   Draft Standard. 

   - draft-perkins-avt-rtp-reactive-fec-00.txt was a proposal on use of 
   RFC 2733 as a retransmission format, intended as an alternative to 
   the RTP payload format for retransmission. However this proposal is 
   IPR encumbered through RFC 2733.

   - draft-tseng-avt-rtcp-streaming-extens-00.txt received a number of  
   comments before and during the last IETF meeting. These need to be 
   addressed if the work is to proceed.

   Finally, the chairs asked for comments on the previously announced 
   intent to advance the RTP specification and Profile for Audio/Video 
   Conferences with Minimal Control (RFC 3550 and 3551) to Full 
   Standard, without changes. No objections was made. 

Updates on behalf of author

   On behalf of John Lazarro, Colin Perkins outlined the status of the 
   RTP payload format for MIDI (draft-ietf-avt-midi-rtp-01.txt) and 
   associated guidelines (draft-ietf-avt-midi-guidelines-01.txt). The 
   current versions are given as candidate for WG last call, to be 
   reviewed by MMA and the working group. Please review and send 
   comments to list.

   Colin also noted that the RTP framing for connection oriented 
   transport (draft-ietf-avt-rtp-framing-contrans-00.txt) is awaiting 
   resolution of the comedia draft in MMUSIC, and accordingly has not 
   been updated.

   Unfortunately an update of Andrea Basso's Requirements for transport 
   of video control commands (draft-basso-avt-videoconreq-00.txt) did 
   not meet the draft deadlines. An update will be submitted after the 
   meeting. This will clarify the terminology, cut down the command list 
   to those used in the IETF. Please review this when it becomes 
   available.

RTP payload format for AMR-WB+ audio codec	

   Ari Lakaniemi discussed draft-sjoberg-avt-rtp-amrwbplus-01.txt. This 
   revision clarifies interoperability scenarios with AMR-WB, specifies 
   how to signal mono and stereo sessions in SDP, and adds offer/answer 
   considerations recommending that one declares also the non-optional 
   parts when using optional features of the AMR-WB+ codec and payload 
   format. 

   The remaining issue is to track the codec development as it is being 
   finalized.  It was noted that the AMR-WB+ codec has been selected as 
   an optional codec to be included in the PSS and MSS services of 3GPP 
   with plans to finalize the specification in May for a 3GPP release 6 
   deadline that has been postponed to at least June.

   Colin Perkins asked why the Code Mode Request (CMR) field is not 
   used? This is primarily because AMR-WB+ is not intended for 
   conversational use, and so is not expected to be used with gateways 
   that might cause rapid mode requests to be transported from the 
   receiver to the sender. Colin asked for clarification of the use 
   cases, and noted that the draft should also consider if it's 
   appropriate to use the CMR fields as a hint for congestion control.

   Dave Lindberg asked if there is a reason for not considering AMR-WB+ 
   for conversational use? The answer is that the AMR-WB+ codec has a 
   longer algorithmic delay then AMR-WB.

   The opinion of the room was that the AMR-WB+ payload format should 
   be accepted as an AVT work item.

Introduction of ATRAC family payload format.

   Matthew Romaine discussed draft-hatanaka-avt-rtp-atrac-family-
   00.txt, a new RTP payload format for all ATRAC audio codecs. The 
   previous attempt for an RTP payload format for only ATRAC-X has been 
   abandoned due to its complexity, and to enable a format that 
   encompass all codec versions. The new format is intended to be much 
   simpler.

   Magnus Westerlund asked if the FrOff field is approriate, since 
   changes in the number of redundant frames will change the buffering 
   needed, and may force a receiver to adapt its playout delay. Colin 
   Perkins remarked that such changes are commonly done before a talk 
   spurt, so the playout delay can easily be various. Magnus' concern 
   about this is that for an audio codec, a lot of the material is 
   continuous without talkspurt-like behaviour, preventing in-band 
   changes of the redundancy offset may be appropriate. Colin remarked 
   that there exists a need to vary the frame offset to adapt to network 
   behaviour anyway, so this shouldn't be a significant problem (RFC 
   2198 allows such changes in redundancy offset also).  

   There have also been comments about the MIME types for the payload 
   format. The proposal is to have one for each codec version. There 
   are a few required parameters, for example a channels parameter that 
   contains different mappings of the channel, not number of channels.

   Regarding the SDP initialization, Magnus Westerlund noted that only 
   the sample rate/channels can go into the "a=rtpmap" SDP attribute. 
   All other parameters need to go into "a=fmtp" line. 

   The draft has made significant progress in regards to previous 
   versions.

3GPP Timed Text

   Jose Rey presented draft-rey-avt-3gpp-timed-text-02.txt.  The draft 
   has been restructured and simplified by removal of advanced 
   fragmentation of modifiers. Unless all modifiers fragments arrive, 
   modifiers can't be applied. The structure has also be changed to be 
   compatible with RFC 3640.

   Colin Perkins asked if it is possible to detect the number of 
   characters that have been lost within a fragmented block? This is 
   not a possible, however no one has raised problems with this. Colin 
   requested that the draft be explicit about the limitation, to be 
   certain it is handled correctly, since the handling differs from 
   other real time text formats.

   The suggestion raised by Magnus Westerlund about the possibility to    
   always have a length field and therefore be able to remove the L 
   flag were presented, but there were no additional comments.

   Another issue is the ability to repeat modifier fragments and sample 
   descriptions: it was asked if this feature should be retained, or 
   disallowed in favour of external methods like FEC or retransmission?  
   No suggestions were made.

   Should it be mandatory to support sample description both in-band 
   and out-of-band? Colin commented that if one relies on inband 
   signalling, one must measure the transport characteristics to 
   provide appropriate reliability and specify what a receiver does if 
   a sample descriptor is not received.  Colin stressed that if one 
   allows inband signalling of sample descriptors at all one needs to 
   address these issues. (Name?) of University of Korea asked why not 
   making inband mandatory. The issue is still that the problems with 
   inband would need to be resolved.  It was also commented that 
   receivers should be able to work without inband sample descriptors.  
   Receiver support of inband is not required, but they should at 
   least be able to discard inband descriptors if the don't support
   them.

   Colin commented that the draft is written assuming data is sourced 
   from a file. As it is possible to generate text on the fly, the 
   draft should be updated to in language reflect that. 

   The authors hope this work can be completed to meet the 3GPP release 
   6 deadline, which may be as early as June 2004. The chairs noted 
   that the draft is still far from complete, and that work will have 
   to proceed rapidly if this deadline is to be met.

   The chairs asked if this draft should be taken as a AVT WG item?  
   The sense of the room was that were were few supporters, but none 
   against. Hence, unless there are objections from the list, this will 
   become an AVT work item.

Payload format for Text Conversation (RFC2793bis)

   Gunnar Hellström presented draft-ietf-avt-rfc2793bis-02.txt, noting 
   that this version is believed to address all comments received to 
   date. Magnus Westerlund raised that one issue that has not been 
   addressed: when using the "audio/t140" format and switching between 
   text and speech, it is possible for a packet to be lost, and for the 
   receiver to be unable to determine if that was a text or a speech 
   packet. This is likely not a problem, but should be better 
   documented. Magnus also noted that the document is also missing a 
   section mapping the MIME parameters onto SDP, and an offer-answer 
   considerations section. 

   Gunnar continued with a presentation of draft-ietf-avt-text-red-
   01.txt. Magnus raised a comment that the PT MIME parameter should 
   reflect how it is actually defined in RFC 2198. Colin was of the 
   opinion that it should say the same thing as the other media versions 
   of RED, see RFC 3555, and any clarifications should be made when RFC 
   2198 is updated.

   ITU study group 16 has need for these documents by November. In 
   order to meet this deadline, updated drafts should be produced, ready 
   for working group last call by early April 2004. 

H.261 and H.263 payload parameters

   Roni Even discussed the RTP updated payload formats for H.261 and 
   H.263: draft-ietf-avt-rfc2032-bis-00.txt and draft-ietf-avt-rfc2429-
   bis-00.txt. These add new codec parameters needed, for example, by 
   video conference and also clarify a number of issues with the older 
   RFCs. 

   An issue raised is how the Annex and profile/level parameters 
   interact, for example which of them overrides the other. The proposal 
   is to not use them together, to avoid this problem.

   Another issue was that only parameters that are known to be used 
   have been included in these drafts. Input from implementors is 
   solicited, asking if the parameters are sufficient or if any are 
   missing. 

   The author list will also need to be trimmed to avoid problems with 
   the current guidelines on number of authors. Colin commented that 
   this is something the contributors will need to agree between 
   themselves on. Magnus noted that correct contact information and the 
   ability to review and sign off on the draft during the final "authors 
   48 hours" period are needed by anyone listed as an author.

   Colin commented that there is need for editorial pass, to check 
   where the RFC 2119 normative language should be used. 

   There is interest to implement these drafts by different companies, 
   and therefore this work should be moved forward. After another update 
   it is hoped that WG last call will be possible. 

Verifying the media path using RTP No-Op & Preconditions 

   Flemming Andreasen discussed draft-wing-avt-rtp-noop-00.txt and its 
   relation to draft-andreasen-mmusic-connectivityprecondition-00.txt. 
   This work was also discussed during the MMUSIC session, however 
   mostly in regards to signalling and usage. The presentation in AVT 
   was more directed towards the RTP related issues. 

   It was noted that Cisco claims IPR in relation to this payload 
   format and it's application, and are willing to license this under 
   reasonable and non-discriminatory terms. Colin Perkins asked for 
   elaboration on the IPR. Flemming made it clear that the patent 
   application is applicable to the RTP payload format, separate from 
   its use with the connectivity preconditions.

   The payload format is intended to be used to open pinholes in NATs 
   and firewalls, to verify connectivity and quality over a media path 
   and to keep alive NAT and firewall bindings. As discussed in MMUSIC, 
   there is some overlap between this proposal, and STUN and ICE.

   Roni Even asked why only the audio/noop MIME type is listed? The 
   answer is that there is no reason for not having it for all media 
   types in use. The draft is simply missing registration of all the 
   media types that are appropriate.

   Dan Romascanu noted that it is not very clear from the draft how you 
   can determine the actual media path characteristics through the use 
   of RTCP, and how to separate the reception quality reports for the 
   NOOP traffic from other media traffic. Flemming noted that the RTP 
   SSRC can be used to separate traffic, and promised to work on the 
   text, clarifying this. 

   Magnus Westerlund and Colin Perkins noted that the draft is unclear 
   on the interactions between its immediate feedback request and the 
   usual RTCP timers (in both the standard A/V profile and in the RTCP 
   feedback profile). Clarification was requested.

   Jonathan Rosenberg was doubtful of the need to request immediate 
   RTCP reports. He supported the functionality of an RTP payload format 
   that is discarded, to keep NAT bindings alive when media is on hold, 
   but asked the group to consider the need for requesting immediate 
   RTCP reports and to clarify the problem and requirements before 
   jumping into the solution space.   

   Jonathan also noted, as he did in the MMUSIC session, that ICE and 
   STUN would still be needed for NAT traversal, and so can't be 
   replaced with this mechanism. 

   Roni Even also commented that the use case for checking the MTU 
   might need feedback, however the QoS diagnostic does look like a 
   different issue. 

   Colin Perkins concluded that the draft must be updated and clarified 
   on use cases, and what problems it solves.

RTCP Extensions for SSM Sessions with Unicast Feedback 

   Jörg Ott discussed draft-ietf-avt-rtcpssm-06.txt. This has been 
   updated to address the behaviour of distribution sources and to 
   clarify how the two ways of specifying RTCP receiver report bandwidth 
   interact. Also, the security considerations and IANA considerations 
   have received some significant updates. Colin Perkins commented that 
   the security section now looks much better, and solicited review from 
   the working group. 

   A remaining issue is to specify how sender reports unicast to the 
   distribution source are to be forwarded, removing the need for the 
   number of sender report block. Otherwise, while there are a few 
   previously discussed issues that still need to be included, the draft 
   is believed to be almost complete. 

Requirements for ECRTP over MPLS

   Jerry Ash discussed draft-ash-avt-ecrtp-over-mpls-reqs-01.txt, which 
   has been updated to address comments raised in the last meeting and 
   on the mailing list. Lars-Erik Johansson, commented that draft has 
   been significantly improved and supported it becoming an working 
   group draft. However, he noted that it would be good if the draft 
   could be enhanced to better explain why ECRTP is the right choice, 
   and explain the issues with using CRTP or ROHC as an alternative. 
   Kristofer Sandlund commented that ECRTP is not that strong against 
   reordering, and that ROHC has better compression efficiency. It would 
   also be better if the draft explained what order of reordering that 
   can be expected. Jerry answered that it is not intended to exclude 
   ROHC from future usage. Colin Perkins clarified that AVT does not 
   have the necessary experience to specify ROHC over MPLS, however the 
   framework must ensure that this work can be done. 

   Allison Mankin asked if ROHC really has become resistant to 
   reordering. Lars-Erik answered that currently no, however this has 
   been discussed and the solution is known. However as there has been 
   no need previously the solution has not been written up. Lars-Erik 
   also commented that ECRTP needs to use lower layers to identify the 
   packet type, which ROHC handles internally. 

   The draft was requested to become an AVT WG item. This seems 
   acceptable with the current maturity of the draft, and was taken as 
   an assumption. It will be expected that an updated draft be produced 
   to address the comments received here. This will also need expert 
   review from the MPLS community. 

   Jerry has also produced an initial draft proposing a protocol to 
   address the requirements (draft-ash-avt-ecrtp-over-mpls-protocol-
   00.txt). Colin commented that AVT is an appropriate temporary home 
   this draft, until we figure out the proper home(s) for it. However 
   the draft would benefit by taking a step backwards, to better explain 
   the rationale for the proposed solution. 

   Allison Mankin, asked what the reason for having SIP calls in the 
   draft. Jerry answered that it was put in there to illustrate the how 
   VoIP and the RSVP extension would fit together. However there are no 
   strong reasons for keeping it in the draft, and it can easily be 
   moved or removed. Allison also stated that there definitely seems to 
   be reasons for keeping the work within AVT for the moment. 

RTP Profile for TCP Friendly Rate Control

   Ladan Gharai presented draft-gharai-avt-tfrc-profile-00.txt, a 
   proposal for using TFRC based congestion control with RTP using RTCP 
   feedback. Her presentation included in a short introduction to TFRC, 
   outlining the new information that needs to transported in RTP and 
   RTCP to support the TFRC algorithm. The initial proposal extends both 
   RTP and RTCP, and therefore needs to be new RTP profile. 

   Technical issues that exist are: 

   - The size of RTCP feedback, since RTCP packets will typically be at 
   least 80 octets.

   - The size of the profile specific additions to the RTP header. The 
   current proposal adds 8 octets to the RTP header.

   - The RTCP feedback rate, as TFRC either sends feedback once per 
   sent packet, or once per RTT, this can be significant bit-rate. Thus 
   the normal RTCP bit-rate restrictions will not provide sufficient 
   bit-rate for a lot of applications. 

   It is also important to clarify the relation to the DCCP protocol. 
   It is clear that DCCP provides more functionality than an RTP profile 
   for TFRC congestion control, and that that functionality is useful 
   and beneficial to developers. However, a new RTP profile will be 
   easier to deploy, as it only involves application-level changes. An 
   RTP profile for TFRC will allow application developers to experiment 
   and gain experience with TFRC congestion control in the short term, 
   with the hope of easing migration to DCCP in the longer term. 

   Anders Klemets asked how the use of AVPF to request retransmission 
   may affect the algorithm? It is clear that retransmission needs to 
   also be congestion controlled, and that the interactions with the 
   changed timing rules of AVPF will definitely need to be considered. 

   A second question was if the TFRC algorithm implies a fixed packet 
   size. Mark Handley answered that TFRC needs to know what the packet 
   size is, it can be varied during a session. Sally Floyd also 
   commented that she is planning to work on TFRC-PS, a variant of TFRC 
   for applications that don't want to change their send rate, but 
   instead vary their packet size. 

   The big question is: does creating an RTP profile for TFRC make 
   sense?

   Brian Rosen commented that the draft would need a strong 
   applicability statement explaining the effects TFRC will have on a 
   media stream, and pointed to the long discussion on the AVT and DCCP 
   mailing lists after the last IETF meeting.

   Mark Handley agreed that creating an RTP profile for TFRC is a good 
   idea, and that it complements DCCP. Where DCCP is a long term 
   solution with more benefits, a RTP profile would be a good short term 
   solution. 

   Joerg Ott also thinks it is a good idea. However he raised concern 
   about the number profiles, and the interaction between a TFRC profile 
   and the current profiles. Colin commented that this is definitely an 
   open issue that will need to be further considered.

   Aaron Falk requested that if this work goes forward, that any 
   findings about the behaviour should be given as input to the DCCP 
   working group, and especially to their user guide document. Tom 
   Phelan also commented that the reverse is also true. For example the 
   discussion in DCCP has already resulted in changes in CCID 3. This 
   work should be tracked also by an RTP profile.

   Mark Handley commented that with the current proposal for RTP header 
   changes, this profile over UDP will actually use 32-bits more than 
   RTP over DCCP. In DCCP this has been achieved through the usage of 4 
   free bits in the DCCP header. There should be made some effort for 
   finding a better way to encode the necessary information into the RTP 
   header. 

   Geetha Srikantan was concerned with the fact that if an ISP is 
   policing the UDP flows, how is a TFRC controlled UDP flow separated 
   from other non-congestion controlled flows? It should at least be 
   clarified what the assumptions are, and what can be expected. 

   Allison Mankin commented with a point she borrowed from Mark 
   Handley: it is difficult to get the implementation of congestion 
   control correct, with a rather large risk that there are bugs within 
   an implementation. DCCP will definitely be easier for an application, 
   since it can be implemented above a known-good congestion control 
   implementation. 

   Colin Perkins concluded that there is certainly interest for 
   performing this work. The WG will need re-chartering to take this 
   aboard. This can be considered while the draft is updated to address 
   comments and clarify the motivation for the work.

				  - * -

---

From: Dave Singer <[email-masked]>
Date: Mon, 5 Apr 2004 10:51:23 -0800

Hi, this question:

I think that many text streams will be very low-bandwidth, and that 
therefore though the cost of duplication seems expensive in terms of 
the multiplier on the stream (i.e. 100% overhead if everything is 
repeated once) and that FEC could achieve better resilience with a 
lower multiplier, nonetheless the overall effect on the session may 
be negligible as we are doubling a very small number.  It may well be 
the most cost-effective solution from a system point of view, rather 
than implementing a more complex FEC algorithm to save very small 
amounts of bandwidth.  So, I think it is fine to say it is allowed; 
it's really easy for a terminal to detect and discard duplicates. 
And the sender/systems analysis can work out the trade-off (and use 
FEC instead if in fact it is available and appropriate).  Requiring 
the decoder to detect and handle duplicates drops out almost free, so 
seems worth having.
-- 
David Singer
Apple Computer/QuickTime

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt