Subject: [AVT] AVT WG Minutes from IEFT 59 in Seoul

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Mar 2004 13:42:49 +0100

Hi AVTers,

Here is a preliminary version of the AVT minutes. Any comments on these 
must be directed to the chairs or the list before the 1st of April as 
they needs to be submitted to the proceedings.

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]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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.
   Issues raised by Magnus Westerlund about the possibility to always have
   a length field 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. 

   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 state 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: Qiaobing Xie <[email-masked]>
Date: Fri, 26 Mar 2004 14:48:15 -0600

...
>      is ready for WG Last Call.

Hi, all,

I'd welcome your review and comments on this draft.

regards,
-Qiaobing Xie

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