DOCSLIB.ORG

AVTCORE S. Garcia Murillo Internet-Draft Cosmo Software Intended Status: Standards Track Y

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
AVTCORE S. Garcia Murillo Internet-Draft Cosmo Software Intended Status: Standards Track Y AVTCORE S. Garcia Murillo Internet-Draft CoSMo Software Intended status: Standards Track Y. Fablet Expires: September 9, 2021 Apple Inc. A. Gouaillard CoSMo Software March 08, 2021 Codec agnostic RTP payload format for video draft-gouaillard-avtcore-codec-agn-rtp-payload-01 Abstract RTP Media Chains usually rely on piping encoder output directly to packetizers. Media packetization formats often support a specific codec format and optimize RTP packets generation accordingly. With the development of Selective Forward Unit (SFU) solutions, that do not process media content server side, the need for media content processing at the origin and at the destination has arised. RTP Media Chains used e.g. in WebRTC solutions are increasingly relying on application-specific transforms that sit in-between encoder and packetizer on one end and in-between depacketizer and decoder on the other end. This use case has become so important, that the W3C is standardizing the capacity to access encoded content with the [WebRTCInsertableStreams] API proposal. An extremely popular use case is application level end-to-end encryption of media content, using for instance [SFrame]. Whatever the modification applied to the media content, RTP packetizers can no longer expect to use packetization formats that mandate media content to be in a specific codec format. In the extreme cases like encryption, where the RTP Payload is made completely opaque to the SFUs, some extra mechanism must also be added for them to be able to route the packets without depending on RTP payload or payload headers. The traditionnal process of creating a new RTP Payload specification per content would not be practical as we would need to make a new one for each codec-transform pair. This document describes a solution, which provides the following features in the case the encoded content has been modified before reaching the packetizer: - a paylaod agnostic RTP packetization format that can be used on any media content, - a negotiation Garcia Murillo, et al. Expires September 9, 2021 [Page 1] Internet-Draft Codec agnostic RTP payload format for video March 2021 mechanism for the above format and the inner payload, Both of the above mechanism are backward compatible with most of (S)RTP/RTCP mechanisms used for bandwidth estimation and congestion control in RTP/SRTP/webrtc, including but not limited to SSRC, RED, FEC, RTX, NACK, SR/RR, REMB, transport-wide-CC, TMBR, .... It as illustrated by existing implementations in chrome, safari, and Medooze. This document also describes a solution to allow SFUs to continue performing packet routing on top of this generic RTP packetization format. This document complements the SFrame (media encryption), and Dependency Descriptor (AV1 payload annex) documents to provide an End-to-End-Encryption solution that would sit on top of SRTP/Webrtc, use SFUs on the media back-end, and leverage W3C APIs in the browser. A high level description of such system will be provided as an informational I-D in the SFrame WG and then cited here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 9, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Garcia Murillo, et al. Expires September 9, 2021 [Page 2] Internet-Draft Codec agnostic RTP payload format for video March 2021 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . 3 2. Goals . 6 3. RTP Packetization . 7 4. Payload Multiplexing . 7 5. SDP Negotiation . 8 6. SFU Packet Selection . 9 7. Redundancy Techniques Considerations . 10 7.1. Retransmission Techniques . 10 7.2. Forward Error Correction (FEC) Techniques . 10 7.3. Redundant Audio Data Techniques . 10 8. Alternatives . 11 8.1. Generic Packetization With In-Payload APT . 11 8.2. A Payload Type for Generic Packetization AND Media Format 11 8.3. A RTP Header To Choose Packetization . 13 9. Security Considerations . 13 10. IANA Considerations . 14 10.1. Registration of audio/generic . 14 11. Registration of video/generic . 14 12. References . 15 12.1. Normative References . 15 12.2. Informative References . 16 Authors’ Addresses . 17 1. Introduction As per Figure 1 of [RFC7656], a Media Packetizer transforms a single Encoded Stream into one or several RTP packets. The Encoded Stream is coming straight from the Media Encoder and is expected to follow the format produced by the Media Encoder. A number of Media Packetizer formats have been designed to process a specific format produced by Media Encoder. For instance [RFC6184] is dedicated to the processing of content produced by H.264 Media Encoders, and generates packets following NALUs organization. WebRTC applications are increasingly deploying end-to-end encryption solutions on top of RTP Media Chains. End-to-end encryption is implemented by inserting application-specific Media Transformers between Media Encoder and Media Packetizer on the sending side, and between Media Depacketizer and Media Decoder on the receiving side, as described in Figure 1 and Figure 2. To support end-to-end encryption, Media Transformers can use the [SFrame] format. In browsers, Media Transformers are implemented using Garcia Murillo, et al. Expires September 9, 2021 [Page 3] Internet-Draft Codec agnostic RTP payload format for video March 2021 [WebRTCInsertableStreams], for instance by injecting JavaScript code provided by web pages. Physical Stimulus | V +----------------------+ | Media Capture | +----------------------+ | Raw Stream V +----------------------+ | Media Source |<-- Synchronization Timing +----------------------+ | Source Stream V +----------------------+ | Media Encoder | +----------------------+ | Encoded Stream V +----------------------+ | Media Transformer |<-- NEW: application-specific transform +----------------------+ (e.g. SFrame Encryption) | Transformed Stream +------------+ V | V +----------------------+ | +----------------------+ | Media Packetizer | | | RTP-Based Redundancy | +----------------------+ | +----------------------+ | | | +-------------+ Redundancy RTP Stream Source RTP Stream | V V +----------------------+ +----------------------+ | RTP-Based Security | | RTP-Based Security | +----------------------+ +----------------------+ | | Secured RTP Stream Secured Redundancy RTP Stream V V +----------------------+ +----------------------+ | Media Transport | | Media Transport | +----------------------+ +----------------------+ Garcia Murillo, et al. Expires September 9, 2021 [Page 4] Internet-Draft Codec agnostic RTP payload format for video March 2021 Figure 1: Sender Side Concepts in the Media Chain With Application-level Media Transform These RTP packets are sent over the wire to a receiver media chain matching the sender side, reaching the Media Depacketizer that will reconstruct the Encoded Stream before passing it to the Media Decoder. +----------------------+ +----------------------+ | Media Transport | | Media Transport | +----------------------+ +----------------------+ Received | Received | Secured Secured RTP Stream Redundancy RTP Stream V V +----------------------+ +----------------------+ | RTP-Based Validation | | RTP-Based Validation | +----------------------+ +----------------------+ | | Received RTP Stream Received Redundancy RTP Stream | | | +--------------------+ V V +----------------------+ | RTP-Based Repair | +----------------------+ | Repaired RTP Stream V +----------------------+ | Media Depacketizer | +----------------------+ | Received Transformed Stream V +----------------------+ | Media Transformer |<-- NEW: application-specific transform +----------------------+ (e.g. SFrame Decryption) | Received Encoded Stream V +----------------------+ | Media Decoder | +----------------------+ | Received Source Stream V +----------------------+ | Media Sink |--> Synchronization Information Garcia Murillo, et al. Expires September 9, 2021 [Page 5] Internet-Draft Codec agnostic RTP payload format for video March 2021 +----------------------+ | Received Raw Stream V +----------------------+ | Media Render | +----------------------+ | V Physical Stimulus Figure 2: Receiver Side Concepts in the Media Chain With Application-level Media Transform This generic packetization does not change how the mapping between one or several encoded or dependant streams are mapped to the RTP streams or how the synchronization sources(s) (SSRC) are assigned. Given the use of post-encoder application-specific
Load more

Recommended publications
  • Packetcable™ 2.0 Codec and Media Specification PKT-SP-CODEC
    PacketCable™ 2.0 Codec and Media Specification PKT-SP-CODEC-MEDIA-I10-120412 ISSUED Notice This PacketCable specification is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. Neither CableLabs nor any member company is responsible to any party for any liability of any nature whatsoever resulting from or arising out of use or reliance upon this document, or any document referenced herein. This document is furnished on an "AS IS" basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document referenced herein. 2006-2012 Cable Television Laboratories, Inc. All rights reserved. PKT-SP-CODEC-MEDIA-I10-120412 PacketCable™ 2.0 Document Status Sheet Document Control Number: PKT-SP-CODEC-MEDIA-I10-120412 Document Title: Codec and Media Specification Revision History: I01 - Released 04/05/06 I02 - Released 10/13/06 I03 - Released 09/25/07 I04 - Released 04/25/08 I05 - Released 07/10/08 I06 - Released 05/28/09 I07 - Released 07/02/09 I08 - Released 01/20/10 I09 - Released 05/27/10 I10 – Released 04/12/12 Date: April 12, 2012 Status: Work in Draft Issued Closed Progress Distribution Restrictions: Authors CL/Member CL/ Member/ Public Only Vendor Key to Document Status Codes: Work in Progress An incomplete document, designed to guide discussion and generate feedback, that may include several alternative requirements for consideration.
    [Show full text]
  • Audio/Video Transport Working Group
    Audio/Video Transport Working Group 60th IETF – San Diego 1 - 6 August 2004 Colin Perkins <[email protected]> Magnus Westerlund <[email protected]> Mailing list: <[email protected]> Agenda - Tuesday Introduction and Status Update 15 RTCP XR MIB 15 RTP Payload/Generic FEC-Encoded Time-Sensitive Media 15 RTP Payload Formats for H.261 and H.263 15 RTP Payload Format for JPEG 2000 15 RTP Payload Format for VMR-WB 15 RTP Payload Format for AMR-WB+ 15 RTP Payload Format for 3GPP Timed Text 15 RTP Payload Format for Text Conversation 5 RTP and MIME types 25 Agenda - Wednesday Introduction 5 Framing RTP on Connection-Oriented Transport 10 RTCP Extensions for SSM 15 RTP Profile for RTCP-based Feedback 15 RTP Profile for TFRC 15 Req. for Transport of Video Control Commands 15 Header Compression over MPLS 15 A Multiplexing Mechanism for RTP 15 MRTP: Multi-Flow Real-time Transport Protocol 15 Intellectual Property When starting a presentation you MUST say if: • There is IPR associated with your draft • The restrictions listed in section 5 of RFC 3667 apply to your draft When asking questions or commenting on a draft: • You MUST disclose any IPR you know of relating to the technology under discussion Reference: RFC 3667/3668 and the “Note Well” text Document Status Standards Published: • STD 64: RTP: A Transport Protocol for Real-Time Application, RFC 3550 • STD 65: RTP Profile for Audio and Video Conferences with Minimal Control, RFC 3551 References MUST include STD number, example: H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, Internet Engineering Task Force, July 2003.
    [Show full text]
  • RFC 8872: Guidelines for Using the Multiplexing Features of RTP To
    Stream: Internet Engineering Task Force (IETF) RFC: 8872 Category: Informational Published: January 2021 ISSN: 2070-1721 Authors: M. Westerlund B. Burman C. Perkins H. Alvestrand R. Even Ericsson Ericsson University of Glasgow Google RFC 8872 Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams Abstract The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8872. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.
    [Show full text]
  • Videocodecs in a Nutshell
    Videocodecs in a Nutshell Wie funktioniert’s und was gibt’s neues? darkbit 14.08.2021 14.08.21 1 Gliederung ● Motivation ● Grundlagen moderner Videocodecs am Beispiel von HEVC ● Neue Videocodecs – AOMedia Video 1 (AV1) – Versatile Video Coding (VVC) – Essential Video Coding (EVC) – Low Complexity Enhancement Video Codec (LC EVC) ● Vergleich der Codecs ● Ausblick 14.08.21 Videocodecs in a Nutshell - darkbit 2 Motivation ● Rohvideo ist groß ● Bsp: Spielfilm auf DVD – Pixel hat je 8 Bit für die RGB-Komponenten => 24 bits pro Pixel – Übliche Auflösung 720x576 Pixel => 414‘720 Pixel => ~9,953Mbit pro Bild – 25 Bilder pro Sekunde => 248,825 Mbit/s – 90 Minuten Spielfilmlänge => 1,344 Tbit (168 Gbyte) pro Film – Wir haben aber nur max. 8,5 Gbyte pro DVD (Dual-Layer) – Wir müssen unser Video um mind. 95% komprimieren! ● Ziel eines Videocodecs: Möglichst hohe Kompression bei möglichst geringer visuellen Qualitätseinbußungen. 14.08.21 Videocodecs in a Nutshell - darkbit 3 Motivation CC-BY 3.0 - Blender Foundation CC-BY-SA 3.0 - Rdikeman Anforderungen On-Demand Video Live Video Kompression möglichst hoch auf Kanalbandbreite Encodingspeed irrelevant in Echtzeit Decodingspeed in Echtzeit in Echtzeit Bitrate adaptiv konstant 14.08.21 Videocodecs in a Nutshell - darkbit 4 State of the Art Videocodecs Veröffentlichung Codec Bitraten-reduktion Anwendungen Mai 1996 H.262, MPEG-2 Part 2 DVD, SDTV, Blu-Ray März 2003 AVC (H.264, MPEG-4 -50% gegenüber HDTV, Webvideo, Part 10) H.262 WebRTC, Blu-Ray September 2008 (seit VP8 -5% gegenüber AVC Webvideo, 2010 lizenzfrei) WebRTC Mai 2013 VP9 -20% gegenüber AVC Webvideo, WebRTC Dezember 2013 HEVC (H.265, MPEG-H -20% gegenüber AVC UHD Blu-Ray Part 2) 14.08.21 Videocodecs in a Nutshell - darkbit 5 Patentproblematiken Quelle: Jonatan Samuelsson und Per Hermansson.
    [Show full text]
  • RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
    Network Working Group Y. Kikuchi Request for Comments: 3016 Toshiba Category: Standards Track T. Nomura NEC S. Fukunaga Oki Y. Matsui Matsushita H. Kimata NTT November 2000 RTP Payload Format for MPEG-4 Audio/Visual Streams Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Multipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP). 1. Introduction The RTP payload formats described in this document specify how MPEG-4 Audio [3][5] and MPEG-4 Visual streams [2][4] are to be fragmented and mapped directly onto RTP packets. These RTP payload formats enable transport of MPEG-4 Audio/Visual streams without using the synchronization and stream management functionality of MPEG-4 Systems [6]. Such RTP payload formats will be used in systems that have intrinsic stream management Kikuchi, et al. Standards Track [Page 1] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000 functionality and thus require no such functionality from MPEG-4 Systems.
    [Show full text]
  • Dialogic® Bordernet™ Product Description
    Dialogic® BorderNet™ Virtualized Session Border Controller Product Description Release 3.3.1 Dialogic® BorderNet™ Virtualized Session Border Controller Product Description Copyright and Legal Notice Copyright © 2013-2016 Dialogic Corporation. All Rights Reserved. You may not reproduce this document in whole or in part without permission in writing from Dialogic Corporation at the address provided below. All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a commitment on the part of Dialogic Corporation and its affiliates or subsidiaries (“Dialogic”). Reasonable effort is made to ensure the accuracy of the information contained in the document. However, Dialogic does not warrant the accuracy of this information and cannot accept responsibility for errors, inaccuracies or omissions that may be contained in this document. INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY. Dialogic products are not intended for use in certain safety-affecting situations. Please see http://www.dialogic.com/company/terms-of- use.aspx for more details. Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries, and thus may not function properly in other countries.
    [Show full text]
  • Preview - Click Here to Buy the Full Publication
    This is a preview - click here to buy the full publication IEC 62481-2 ® Edition 2.0 2013-09 INTERNATIONAL STANDARD colour inside Digital living network alliance (DLNA) home networked device interoperability guidelines – Part 2: DLNA media formats INTERNATIONAL ELECTROTECHNICAL COMMISSION PRICE CODE XH ICS 35.100.05; 35.110; 33.160 ISBN 978-2-8322-0937-0 Warning! Make sure that you obtained this publication from an authorized distributor. ® Registered trademark of the International Electrotechnical Commission This is a preview - click here to buy the full publication – 2 – 62481-2 © IEC:2013(E) CONTENTS FOREWORD ......................................................................................................................... 20 INTRODUCTION ................................................................................................................... 22 1 Scope ............................................................................................................................. 23 2 Normative references ..................................................................................................... 23 3 Terms, definitions and abbreviated terms ....................................................................... 30 3.1 Terms and definitions ............................................................................................ 30 3.2 Abbreviated terms ................................................................................................. 34 3.4 Conventions .........................................................................................................
    [Show full text]
  • 2021 TIW DRAFT AGENDA Revi
    24th ITEA Test and Training Instrumentation Workshop Innovating for Tomorrow’s Challenges 5/5/21 REV I 11-May First Day – Tutorials 8:00 a.m. – 12:00 p.m. Morning Tutorials Basics of Aircraft Instrumentation Systems Bruce Johnson, NAWCAD This course will cover a wide variety of topics related to Aircraft Instrumentation. Data, Telemetry, Instrumentation System Block Diagram, Standards, Data Requirements, Transducers / Specifications, Video, 1553 Bus, Using Requirements to Configure an Analog Data Channel, Creating a PCM Map to Obtain a Sample Rate, Telemetry Bandwidth, Record Time, GPS, Audio, Telemetry Attributes Transfer Standard (TMATS), and Measurement Uncertainty - Interpreting the Results. This is great introduction for new hires or a refresher for current employees. IRIG 106-17 Chapter 7 Packet Telemetry Downlink Basis and Implementation Fundamentals Johnny Pappas, Safran Data Systems, Inc. This course will focus on presenting information to establish a basic understanding of the 2017 release of the IRIG 106, Chapter 7, Packet Telemetry Downlink Standard. It will also focus on the implementation of airborne and ground system hardware and methods to handle IRIG 106, Chapter 7, Packet Telemetry data. The presentation will address the implementation of special features necessary to support legacy RF Transmission, data recording, RF Receiving, Ground Reproduction, and Chapter 10 data processing methods. Predictive Analytics for Performance Assessment Mark J. Kiemele, Air Academy Associates Design of Experiments (DOE) is a method that can and should be used not only in the design and development of systems, but also in the modeling and validation of system performance. Building useful prediction models and then validating them can ease the burden of making procurement decisions.
    [Show full text]
  • TANDBERG and H.323
    SIP D50444 revision 1.1 May 2008 TANDBERG and SIP TABLE OF CONTENTS INTRODUCTION ........................................................................................................................................5 WHAT IS SIP?............................................................................................................................................6 Components ...............................................................................................................................................6 User Agent........................................................................................................................................6 Proxy Server.....................................................................................................................................6 Registrar...........................................................................................................................................7 Redirect Server ................................................................................................................................7 Requests for Comments.............................................................................................................................7 SIP Messages.............................................................................................................................................9 SIP Requests ...................................................................................................................................9
    [Show full text]
  • Dialogic® Bordernet™ Virtualized Session Border Controller (SBC) Product Description Document
    Dialogic® BorderNet™ Virtualized Session Border Controller (SBC) Product Description Document July 2013 www.dialogic.com Copyright and Legal Notice Copyright © 2011-2013 Dialogic Inc. All Rights Reserved. You may not reproduce this document in whole or in part without permission in writing from Dialogic Inc. at the address provided below. All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a commitment on the part of Dialogic Inc. and its affiliates or subsidiaries (“Dialogic”). Reasonable effort is made to ensure the accuracy of the information contained in the document. However, Dialogic does not warrant the accuracy of this information and cannot accept responsibility for errors, inaccuracies or omissions that may be contained in this document. INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY. Dialogic products are not intended for use in certain safety-affecting situations. Please see http://www.dialogic.com/company/terms-of-use.aspx for more details. Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries, and thus may not function properly in other countries.
    [Show full text]
  • Network Working Group S. Casner Request for Comments: 3555 Packet Design Category: Standards Track P
    Network Working Group S. Casner Request for Comments: 3555 Packet Design Category: Standards Track P. Hoschka W3C/INRIA/MIT July 2003 MIME Type Registration of RTP Payload Formats Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. Table of Contents 1. Introduction .................................................. 2 1.1. IANA Considerations ...................................... 2 1.2. Terminology .............................................. 3 2. Procedure For Registering MIME Types for RTP Payload Types .... 3 3. Mapping to SDP Parameters ..................................... 5 4. Registrations for "Audio/Video Profile" ....................... 6 4.1. Audio Type Registrations ................................. 6 4.2. Video Type Registrations
    [Show full text]
  • Ict R&D 기술로드맵 2025
    ICT R&D 기술로드맵 2025 ICT융합·방송·콘텐츠 ICT융합 방송·미디어 디지털콘텐츠 ICT R&D 기술로드맵 2025 ICT융합·방송·콘텐츠 ICT융합 방송·미디어 디지털콘텐츠 ICT R&D 기술로드맵 2025 ICT융합·방송·콘텐츠 Contents 01 ICT융합 분야 02 방송·미디어 분야 ● ● Ⅰ. 개념 및 범위 006 Ⅰ. 개념 및 범위 160 Ⅱ. 동향 조사 분석 018 Ⅱ. 동향 조사 분석 162 Ⅲ. 기술 발전 전망 080 Ⅲ. 기술 발전 전망 176 Ⅳ. 대상 기술 선정 096 Ⅳ. 대상 기술 선정 182 Ⅴ. 기술로드맵 124 Ⅴ. 기술로드맵 192 Ⅵ. 기술 확보 전략 130 Ⅵ. 기술 확보 전략 194 03 디지털콘텐츠 분야 ● Ⅰ. 개념 및 범위 210 Ⅱ. 동향 조사 분석 216 Ⅲ. 기술 발전 전망 236 Ⅳ. 대상 기술 선정 242 Ⅴ. 기술로드맵 248 Ⅵ. 기술 확보 전략 250 [참고] 참여 전문가 명단 258 ICT R&D 기술로드맵 2025 ICT융합·방송·콘텐츠 ICT융합 분야 006 018 Ⅰ. 개념 및 범위 Ⅱ. 동향 조사 분석 080 096 Ⅲ. 기술 발전 전망 Ⅳ. 대상 기술 선정 124 130 Ⅴ. 기술로드맵 Ⅵ. 기술 확보 전략 개념 및 범위 Ⅰ ICT R&D 기술로드맵 2025 1.개념 및 정의 ICT 융합의 개념 ICT 융합 분야는 지능정보 기술 등 다양한 ICT 기술을 융합하여 미래사회 문제에 대응하고, 全 산업의‘디지털 전환(Digital Transformation)’을 통해 사람 중심(Human Driven)의 혁신적인 新 융합기술·서비스 실현을 목표로 함 - 기존 산업구조 기반에서 마련된 현재의 기술과의 융합에서 벗어나, ICT 기술을 뒷받침하는 이론에서 파생한 새로운 융합 신기술 발굴 - 미래의 ICT 융합은‘인간을 위한’도구로서, 인간의 편리하고 안전한 삶을 지원하고, 사회 전반의 고민과 과제를 해결하는데 기여하는 사람 중심(Human-Driven)의 핵심기술로 정의함 < ICT융합분야 개념도 > 006 ICT융합 분야 Ⅰ. 개념 및 범위 2.기술분류(Technology Tree) ICT 융합기술의 응용대상 분야 ※ ICT 융합 분야 특성상 융합기술을 활용한 서비스 중점 도출이 유의미하다고 판단하여, 본 로드맵에서 기존 기술분류체계(<참고>)를 기반으로 ICT융합기술 응용 대상 분야를 아래와 같이 새로이 설정하여 이에 따른 기술을 매칭하여 활용 ‘ 혁신성장을 위한 사람 중심의「4차산업혁명 대응계획」’(`18.
    [Show full text]