Internet Engineering Task Force J. Jaeggli Internet-Draft Nokia Intended status: Informational August 2008 Expires: February 2, 2009 IETF Streaming Media, Current Status draft-jaeggli-ietf-streaming-media-status-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 2, 2009. Abstract This document describes the operation of the audio streaming service provided for the IETF from IETF 62 up to the most recent (IETF 72) meeting. Efforts associated with meetings prior to IETF 62 back to IETF 49 as well as a proposal for the current effort were detailed in the now expired draft draft-jaeggli-ietftv-ng-01.txt. The purpose of this document is to inform future efforts to deliver streaming media services for remote or local participants of the level of service and the technology that was employed. Jaeggli Expires February 2, 2009 [Page 1] Internet-Draft IETF Streaming August 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Current Service . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Archival Storage . . . . . . . . . . . . . . . . . . . . . . . 5 5. Shortcomings of the Existing Service . . . . . . . . . . . . . 5 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Jaeggli Expires February 2, 2009 [Page 2] Internet-Draft IETF Streaming August 2008 1. Introduction Since IETF 62 there has been an audio stream provided for each of the 8 scheduled meeting rooms. This service has been provided by volunteers with the financial support variously of the IETF chair , the IAD and by the Internet society. This audio streaming service supplanted a earlier effort which provided video/audio streaming and recording for two of the 8 parallel rooms. This draft is intended to document the service as it is currently run with the hope that this will be useful if future planning and or the requirements for a production service. 2. History The situation prior to IETF 62 is described in the now expired draft draft-jaeggli-ietftv-ng-01.txt. The decision to move away from the video production and ip multicast streaming model was done on the basis of a couple of considerations most notably, the cost both monetary and in human capital of delivering the existing service, the inability to scale beyond two rooms without a significant larger effort, and finally the limitations on remote usage that ip multicast placed on on the audience of potential participants There are essentially three sets potential consituents for the streaming/recording of IETF meetings. Participants local to the IETF monitor the activities of other working groups, remote participants monitor working groups in which they have an interest, and finally users of the archive, either for timeshifting purposes or for purposes of historical couriosity. To the extent that all three groups were being served poorly by the the pre-62 service, our goals in providing a new service included increasing the usability for all three groups. It was proposed that for a new service that IP multicast transport would be abandoned in favor of tcp http based mp3 streaming. This approach has been demostrated to work in number of challenging enviroments. In contrast to the multicast transport will likely to work in situations where the participants did not have control over their own network. Because of the ubitiquity of httpd streamed internet radio stations, client support for this streaming model is essentially ubiquitous. The service moved from mixed video/audio/slides to audio only. While this may have been a functional step back, it substially reduced the volunteer staffing requirements to the point that instead of using an average of 6 volunteers to cover two meeting rooms, a single Jaeggli Expires February 2, 2009 [Page 3] Internet-Draft IETF Streaming August 2008 volunteer can under most circumstances manage all 8 parallel meetings. 3. Current Service The current service consists of the following components: o A webserver which hosts the streaming schedule and the playlists for the 8 channels, plues a unified 8 channel playlist o One or more servers running the icecast-2 http streaming server. Client requests on the basis of the playlists are made to these systems and the audio encoders are connected to them. As configured presently bandwidth requirements run approximately 64kb/s per client and 8xx64Kb/s for the audio streaming servers o One encoder/recorder per stream. In the present setup each encoder is a compact linux system running the muse internet radio application and displaying to an internaly hosted vnc session o one or more management workstations. The managment station is used to remotely control the local vnc sessions on each of the encoders visually inspect the audio meter and filter settings in the muse application as well as initiate or halt recordings based on the schedule or other considerations (meetings run over). o Line or microphonephone level feed in each of the 8 rooms to be recorded. This facility is provided by the AV contractor or faciltiy used for the meeting. In some cases it must be specially arraigned ahead of time.variouslly this has been provisioned directly on in-room mixers (most venues) via a centralized audio distribution system (as in toronoto or seoul) or via a mix as in chicago. Historically the final responsiblity for securiing this resource has been in the hand s of the secretariate function as that is where the contractual relationship with the contractor has resided. o Network connectity for the encoders, is required and has been traditionaly provided as part of the delivery of the IETF network In total, the live audience for the service has remained relatively small notwithstanding the considerable improvement in feasibility of participation. Time shifting considerations, as well as the effort required to participate in working group activities have in practice limited maximum concurrency in remote partipants to around 100 simultanious users and generally much lower. That is to say that local working group participation is approximately an order of Jaeggli Expires February 2, 2009 [Page 4] Internet-Draft IETF Streaming August 2008 magnitude higher than remote. exceptions exist for particulary high interest topics where people who might not otherwise participate in a working group (journalists for example) choose to tune in for monitoring purposes. 4. Archival Storage Archival storage has been provided up to this point first by the University of Oregon's Wideolab project and more recently by the Network Startup Resource Center also at the University of Oregon. This facility provides access to raw recordings during and after the IETF meeting proper. At the time of this document, recordings back to IETF 49 (62 for audio only) require approxmiately 350GB of storage. The secretariat during the Neustar era maintained a backup (not publicly available) of the archive. Usage of the the archive is sporadic, but peaks for a month or two following a given meeting. To some extent the usability of the current archive is compromised by the lack of post-production (noted in shortcomings). 5. Shortcomings of the Existing Service The existing service has a number of notable shortcomings. Some of these are a product of decisions made in order to minimize the outlay of effort and capital required to field the service. Others have become apparent as a product of operational experience. It would be desirable to be able to alter some of the elements of the service in order to address some of the more egregious limitations. o Lack of direct control. Due to the headless nature of the systems used for recording there is no interface to manage the recording present in the the working group. working group chairs have little idea if their session is in fact being recorded, if the remote participants are recieving reasonable quality audio, if the speakers are being picked up by the microphones etc. moreover sessions that meet outside of scheduled hours are at the mercy of volunteers as to whether recording of their meeting occurs or not. One way to address this would be to provide web interfaces to the recording system in order facilitate direct control of the recorders. The current software platflorm and work flow does not support this however. o Limited attention... In order to deliver the service in a cost- effective fashion the volunteer particpation was scaled back to a single operator at a time. this results in divided attention and a Jaeggli Expires February 2, 2009 [Page 5] Internet-Draft IETF Streaming August 2008 non-zero error rate in terms of issues like failure to initiate recordings, inability to debug issues with more than one audio stream in parallel and dividing time between the management workstation located in the noc and the recorders located in the meeting rooms. o Lack of post-production. When video was being recorded, post- production involved removing the recorded material prior to and after the break-up of each working group, due the availability of visual queues and the a fact that week resulted in only about 80 hours of video post-production for a given IETF meeting could be performed in a couple of days. With the adavent of the recording of 8 parallel tracks of recording the jump to 320 hours or more worth of audio recording has made post-productio of the audio infeasible given the current amount of volunteer time available. o Audio only, no slides, no back channel. The are considerations driven by the choice of streaming technology and the complexity of interoperating with the multiple platforms used to present at the IETF. Making more material available during the meeting proper would require more equipement, more rigorous standardization of process or probably both. o Equipment aging. The equipment purchased in 2004 has aged fairly gracefully but is being to suffer from attrition. Moreover, some of the considerations that drove equipment choices in 2004 have changed. One of the requirements for the 2004 purchase was that the choosen servers be checkable as luggage, which due to increased baggaged restrictions becomes increasing infeasable (the 8 recorders and power-supplies weigh approximately 48lb)s. While smaller encoder systems are now feasible, the requirements for such systems should be considered in the context of future plans for the service 6. Conclusion As when the transition from mutlicast to the audio streaming service was made there are both challanges and oportunites in the present situation. The service as it stands now requires little enough effort to deliver that it can be handled at the current service level by one person.Even so it needs an update. It could be expanded to include new services if there is energy to do so. Some effort should be made to preserve the legacy that is the present in the recorded materials from IETF 49 to present. Jaeggli Expires February 2, 2009 [Page 6] Internet-Draft IETF Streaming August 2008 7. Acknowledgements The current IETF streaming effort has been generously support by a large cast of characters Including the present and previous IETF chairs, the Internet Society, thesecretariat in several of it's forms, the University of Oregon, and numerous volunteers who have expended time energy and capital to keep this service going. . 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations This document does not engender any security considerations. Author's Address Joel Jaeggli Nokia 313 Fairchild Drive Mountain View, CA 94043 Phone: +1 650 625 2013 Email: joel.jaeggli@nokia.com Jaeggli Expires February 2, 2009 [Page 7] Internet-Draft IETF Streaming August 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Jaeggli Expires February 2, 2009 [Page 8]