Multimedia Stream Adaptation Services

Total Page:16

File Type:pdf, Size:1020Kb

Multimedia Stream Adaptation Services UniversitÄat Ulm Institut furÄ Verteilte Systeme Multimedia Stream Adaptation Services Dissertation zur Erlangung des Doktorgrades Dr. rer. nat. der FakultÄat furÄ Ingenieurwissenschaften und Informatik der UniversitÄat Ulm vorgelegt von Andreas Schorr aus Ulm an der Donau Ulm, Oktober 2006 Multimedia Stream Adaptation Services BY Andreas Schorr A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DR. RER. NAT. AT UNIVERSITY OF ULM JAMES-FRANCK-RING, 89069 ULM, GERMANY OCTOBER, 2006 °c Copyright by Andreas Schorr, 2006 Amtierender Dekan: Prof. Dr. Helmuth Partsch 1. Gutachter: Prof. Dr. Franz J. Hauck 2. Gutachter: Prof. Dr. Michael Weber 3. Gutachter: Dr. Andreas J. Kassler (Assoc. Prof.) Tag der Kolloquiumsprufung:Ä noch nicht bekannt Abstract During the last decade, a clear trend towards all-over-IP multimedia communication has evolved. There exists a great variety of stationary and mobile devices which allow streaming of digital audio and video content over IP networks. But this variety of multimedia enabled devices comes along with a great variety of di®erent hardware and software capabilities and di®erent access network technologies (having heterogeneous properties like bandwidth or packet loss rate). Even if two applications support a common set of media formats, it is often impossible to use such a common format because of resource constraints imposed by the di®erent hardware capabilities and network types. Adaptation of media formats is thus required to allow communication between heterogeneous peers. A second problem is that although quality of service has been a very popular research topic for several years, we still have no end-to-end QoS support for users in the Internet. When QoS cannot be guaranteed, media adaptation is a means to cope with fluctuating resource availability. Performing adaptation at the source or at the sink of a media stream is in many cases the most e±cient solution, but in some cases it is impossible to adapt a media stream on one of the communicating end-terminals because of limited hardware and software capabilities of these devices. In such a case, a stream adaptation node in the network can perform the required adaptation operations. In the context of voice-over-IP, media gateways are used to connect the switched telephony network with the Internet. Such media gateways handle only audio streams and they o®er only static adaptation services, i.e., they do not adapt to changing network conditions, which may occur in networks without QoS guarantees. Furthermore, existing adaptation services support only a limited set of media formats and adaptation operations, and they are usually tightly coupled with a certain communication infrastruture. So it is not possible to ¯nd and request such services using arbitrary legacy applications. This thesis enhances the current state-of-the-art by developing a generic stream-adaptation service that supports a great variety of di®erent adaptation operations, automatically adapts to changing resource availability, and can be easily enhanced with new functionality. Since speci¯c service announcement mechanisms for adaptation services currently do not exist, a mechanism for describing stream-adaptation services is developed which enables the dis- covery of adaptation nodes suitable for speci¯c types of adaptation operations. Using this service description, adaptation services may either be discovered and used directly by end users who are explicitly requesting certain adaptation operations, or they may be used by network operators and service providers to serve the customers' needs transparently while optimising the total network load. In the last part of this thesis, mechanisms for providing novel heterogeneous broadcast streaming services are elaborated. Parts of this work were motivated by the research projects MASA-N (in cooperation with Siemens AG and NEC Europe), POBNET (in cooperation with Siemens AG), AKOM (funded by Deutsche Forschungsgemeinschaft) and the EU-funded DAIDALOS project. TABLE OF CONTENTS List of Figures iv List of Tables vi 1 Introduction 1 1.1 Background . 1 1.2 Problem Statement . 3 1.3 Proposed Solution . 3 1.4 Main Contributions of this Thesis . 5 1.5 Overview of this Thesis . 7 2 Adaptation of Multimedia Streams 9 2.1 De¯nitions . 9 2.2 Media Adaptation . 11 2.2.1 Sender-Driven and Receiver-Driven Adaptation . 11 2.2.2 Transcoding . 13 2.2.3 Media Filtering . 18 2.2.4 Digital Item Adaptation . 21 2.3 Network-Flow Adaptation . 26 2.3.1 Changing Protocols . 26 2.3.2 Changing the RTP Pro¯le . 27 2.3.3 Changing Error Correction Mechanisms . 27 2.3.4 Changing Rate and Congestion Control Mechanisms . 30 2.4 Summary . 31 3 Survey of the Current State of the Art 33 3.1 Adaptation of Multimedia Streams . 33 3.2 Media Gateways . 36 3.3 Service Discovery . 37 3.4 Heterogeneous Broadcast . 38 3.5 Summary . 40 4 A Multimedia-Stream Adaptation Service 41 4.1 Use Cases and Design Decisions . 42 4.2 Architecture and Functional Description . 44 4.2.1 Interworkig Between Subsystems . 45 4.2.2 The Manager Subsystems . 47 4.2.3 Architecture and Functional Description of the Media Manager . 49 4.3 Adaptation-Service Invocation . 57 4.3.1 Session Description . 58 4.3.2 Broker-Initiated Adaptation . 60 i 4.3.3 Terminal-Initiated Adaptation . 65 4.4 Implementation . 67 4.4.1 Usage of Operating-System Modules . 68 4.4.2 E±cient Processing . 68 4.4.3 Error Correction Modules . 70 4.4.4 RTP Payload Format for the Transmission of gBSD Metadata . 75 4.4.5 Dynamic Adaptation Features . 76 4.5 Business Models . 78 4.6 Security Aspects . 80 4.6.1 Privacy . 81 4.6.2 Property Rights . 85 4.7 Summary . 86 5 Performance Evaluation 89 5.1 Processing Time and Scalability . 89 5.1.1 Test Environment . 89 5.1.2 Measurement Results . 90 5.1.3 Comparison with Commercial Products . 99 5.2 Hardware-Supported Video Transcoding . 100 5.3 Application-Layer Error Correction Mechanisms . 102 5.3.1 Test Environment . 102 5.3.2 Measurement Results . 104 5.4 Summary . 107 6 Description of Adaptation Services 109 6.1 Description, registration and discovery of services . 109 6.2 Describing Stream-Adaptation Services . 112 6.2.1 Service Models . 112 6.2.2 Service Properties . 114 6.2.3 A Note on Media-Format Identi¯ers . 117 6.2.4 A Note on Delay, Jitter, Cost, and Quality Reduction . 119 6.2.5 Considering Status Information for Adaptation-Node Selection . 123 6.3 Describing Adaptation Services with SLP Service Templates . 124 6.3.1 SLP Service URL . 125 6.3.2 Limitations of SLP Templates . 125 6.3.3 An SLP-based Description of an Adaptation Service . 126 6.4 Describing Adaptation Services with RDF . 128 6.4.1 RDF Overview . 128 6.4.2 An RDF-based Description of Adaptation Services . 132 6.4.3 Extending the MSAS Schema . 139 6.4.4 Creation of RDF Service Descriptions and Registration via SLP . 139 6.5 Querying for Adaptation Services . 142 6.5.1 Formulating RDF Queries . 142 6.5.2 Transportation of RDF Queries . 149 6.6 Summary . 149 ii 7 Heterogeneous Broadcast Services 151 7.1 Broadcast Services Today . 151 7.2 Announcement of Broadcast Sessions . 153 7.3 Setup of heterogeneous broadcast sessions . 155 7.3.1 Session-Setup Signalling with SDS-based Service Announcement . 156 7.3.2 Session Signalling for SAP-based Service Announcement . 160 7.3.3 Encrypted Broadcast Streams . 161 7.4 Summary . 161 8 Conclusion 163 8.1 Achievements . 163 8.2 Outlook and Future Work . 165 8.3 Final Remarks . 167 Bibliography 169 A SDPng++ Example 181 B XSLT Stylesheet for gBSD Transformation 185 C SLP Service Templates 187 D RDF Schema for Adaptation Services 193 E Media-Format Identi¯ers 217 F Deutschsprachige Zusammenfassung 227 G Deutschsprachiger Lebenslauf 229 iii LIST OF FIGURES Figure Number Page 1.1 Adaptation on a Proxy Node . 4 1.2 Heterogeneous Multicast . 5 2.1 Video Encoder and Decoder . 14 2.2 Sequence of Video Frames . 15 2.3 Spatial Domain Cascaded Video Transcoder . 15 2.4 Fast Video Transcoder . 16 2.5 Optimized Spatial Resolution Video Transcoder . 17 2.6 Scalable Encoding of a Video Frame . 19 2.7 SNR Scalability Video Encoder . 19 2.8 Adaptation of Error Correction Mechanism . 28 2.9 Unequal Erasure Protection . 29 4.1 MSAN Architecture . 44 4.2 Facade Design Pattern Implemented by Service Manager . 45 4.3 MSANMessage Class . 46 4.4 Media Manager Architecture . ..
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]
  • TR-135 Data Model for a TR-069 Enabled STB
    TECHNICAL REPORT TR-135 Data Model for a TR-069 Enabled STB Version: Issue 1 Version Date: December 2007 © The Broadband Forum. All rights reserved. Data Model for a TR-069 Enabled STB TR-135 Notice The Broadband Forum is a non-profit corporation organized to create guidelines for broadband network system development and deployment. This Technical Report has been approved by members of the Forum. This document is not binding on the Broadband Forum, any of its members, or any developer or service provider. This document is subject to change, but only with approval of members of the Forum. This document is provided "as is," with all faults. Any person holding a copyright in this document, or any portion thereof, disclaims to the fullest extent permitted by law any representation or warranty, express or implied, including, but not limited to, (a) any warranty of merchantability, fitness for a particular purpose, non-infringement, or title; (b) any warranty that the contents of the document are suitable for any purpose, even if that purpose is known to the copyright holder; (c) any warranty that the implementation of the contents of the documentation will not infringe any third party patents, copyrights, trademarks or other rights. This publication may incorporate intellectual property. The Broadband Forum encourages but does not require declaration of such intellectual property. For a list of declarations made by Broadband Forum member companies, please see www.broadband-forum.org. December 2007 © The Broadband Forum. All rights reserved.
    [Show full text]
  • MPEG2+4 SDI Codec Manual-V6.Pdf
    QVidium™ TECHNOLOGIES, INC. MPEG2+4 SDI IP Codec Model #QVSDI-11-IP User’s Manual v.6 March 24, 2008 Application Firmware Version 21 © 2007-2008 QVidium™ Technologies, Inc. 12989 Chaparral Ridge Road, San Diego, CA 92130 Phone 858.792.6407 • Fax 858.792.9131 User’s Manual v.6 QVidium™ MPEG2+4 SDI IP Codec Table of Contents 1 Introduction.............................................................................................................3 1.1 Overview...........................................................................................................3 1.2 Network Setup .................................................................................................3 1.3 Ping....................................................................................................................5 1.4 Passwords and Security.................................................................................6 1.5 Resetting to Default Settings .........................................................................6 1.6 Upgrading .........................................................................................................6 1.7 System View.....................................................................................................7 2 Encoder Configuration and Operation.............................................................9 2.1 Configuring the Encoder.................................................................................9 2.2 Starting the Encoder .......................................................................................9
    [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]
  • 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]
  • ABBREVIATIONS EBU Technical Review
    ABBREVIATIONS EBU Technical Review AbbreviationsLast updated: January 2012 720i 720 lines, interlaced scan ACATS Advisory Committee on Advanced Television 720p/50 High-definition progressively-scanned TV format Systems (USA) of 1280 x 720 pixels at 50 frames per second ACELP (MPEG-4) A Code-Excited Linear Prediction 1080i/25 High-definition interlaced TV format of ACK ACKnowledgement 1920 x 1080 pixels at 25 frames per second, i.e. ACLR Adjacent Channel Leakage Ratio 50 fields (half frames) every second ACM Adaptive Coding and Modulation 1080p/25 High-definition progressively-scanned TV format ACS Adjacent Channel Selectivity of 1920 x 1080 pixels at 25 frames per second ACT Association of Commercial Television in 1080p/50 High-definition progressively-scanned TV format Europe of 1920 x 1080 pixels at 50 frames per second http://www.acte.be 1080p/60 High-definition progressively-scanned TV format ACTS Advanced Communications Technologies and of 1920 x 1080 pixels at 60 frames per second Services AD Analogue-to-Digital AD Anno Domini (after the birth of Jesus of Nazareth) 21CN BT’s 21st Century Network AD Approved Document 2k COFDM transmission mode with around 2000 AD Audio Description carriers ADC Analogue-to-Digital Converter 3DTV 3-Dimension Television ADIP ADress In Pre-groove 3G 3rd Generation mobile communications ADM (ATM) Add/Drop Multiplexer 4G 4th Generation mobile communications ADPCM Adaptive Differential Pulse Code Modulation 3GPP 3rd Generation Partnership Project ADR Automatic Dialogue Replacement 3GPP2 3rd Generation Partnership
    [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]
  • 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]
  • 2250 G. Fernando Obsoletes: 2038 Sun Microsystems, Inc
    Network Working Group D. Hoffman Request for Comments: 2250 G. Fernando Obsoletes: 2038 Sun Microsystems, Inc. Category: Standards Track V. Goyal Precept Software, Inc. M. Civanlar AT&T Labs - Research January 1998 RTP Payload Format for MPEG1/MPEG2 Video 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 (1998). All Rights Reserved. Abstract This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms in Section 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added. Hoffman, et. al. Standards Track [Page 1] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998 1. Introduction ISO/IEC JTC1/SC29 WG11 (also referred to as the MPEG committee) has defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard (ISO/IEC 13818)[2].
    [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]