DOCSLIB.ORG

Webrtc UDP Firewall Traversal

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

WebRTC UDP Firewall Traversal Tirumaleswar Reddy Technical Leader Summary I received my Bachelor of Engineering in Computer Science and Engineering from Mysore University, and Master of Computer Science from Illinois institute of Technology. I have 14+ years of industry experience. I have worked on SIP, Firewall, IPS, Identity, Cloud Web Security, OpenDNS. I have 5 patents issued and 26 patents pending in USPTO in the areas of Security, SDN, Cloud, Policy, SFC and Identity. I have co-authored over 8 RFC and several IETF WG documents. My recent work and interests include SFC, DDOS, DNS Privacy, WebRTC, STUN and TURN. 3 Agenda • Introduction • WebRTC • Problem statement • STUN and TURN • ICE • Solutions for FW traversal • Challenges • Conclusion 4 Introduction • Firewalls are installed to enforce ‘security policy’ • Policy used to mean • protocols and port numbers • filtering of incoming unsolicited traffic • Now security policy includes • malware detection • anti-phishing • content filtering and more 6 Introduction • UDP is often blocked • SIP ALG to permit media session • UDP need not traverse Enterprise firewall • NTP, DNS, Bonjour stay inside Enterprise network • UDP is used by bots • Firewall cannot determine end of UDP session, other than inactivity time out • UDP used for DDoS attacks 7 Introduction request DNS server reply request attacker reply DNS server victim Source IP = request victim’s IP reply DNS server 8 Introduction • FW tracks the TCP state. • FW is capable of terminating TCP connection or drop packets if there is a protocol violation. • FW checks for invalid segments sent after the connection has been established. • FW supports TCP configuration for • Idle session timeout • Timeout for TCP session after a FIN • Timeout for TCP session after a SYN and no further data 9 Before WebRTC 10 After WebRTC After WebRTC: interactive audio/video in your browser, without plugins 11 After WebRTC 12 WebRTC: browser architecture 13 WebRTC After WebRTC: Media sent directly between browsers (P2P). 14 Problem statement DTLS/SRTP STUN TURN DTLS/SCTP UDP IP • Enterprise Firewalls may block WebRTC media streams over UDP. • Firewall typically inspects signaling messages (SIP) to allow media over UDP. • WebRTC does not define signaling protocol. • Spark traffic is getting blocked. • If UDP is blocked then WebRTC media streams can be sent over TCP. • TCP's user experience is worse than UDP. • How to get WebRTC media streams over UDP traverse through FW ? 15 The basics of Voice over IP (VoIP) network core (registrars, proxies, …) Bob Address: B Alice Port: Pb Address: A Port: Pa 16 The basics of VoIP network core (registrars, proxies, …) Bob Address: B Alice Port: Pb Address: A Port: Pa 17 The basics of VoIP network core (registrars, proxies, …) … MEDIA over SRTP … Bob Address: B Alice Port: Pb Address: A Port: Pa 18 And then NATs were born … ERROR Alice Bob NAT/Firewall NAT/Firewall Private Address: A Address: XA Address: XB Address: B Impossible for Bob to initiate a media connection to Alice Impossible for Alice to initiate a media connection to Bob 19 Problem Summary • The signaling path works because the server has a known publicly routable IP address. • The media path breaks because • Peers have private non-routable IP addresses. • Firewall configured to block UDP. • IPv6 could solve the problem, except firewalls still exist there. 20 STUN to the rescue • STUN [RFC5389] binding request exchanged with the server opens a NAT pinhole. • Client learns the NAT mapping from the STUN server in the binding response. • Remote peer can send traffic to this address. 21 STUN to the Rescue STUN Alice Bob NAT/Firewall NAT/Firewall Private Address: A Address: XA Address: XB Address: B Alice learns XAp from the STUN server, and sends it to Bob. Bob can initiate a media connection to Alice via XAp. 22 TURN to the Rescue • STUN doesn't work for all NATs. Some NATs only accept from the original server. • Address-Dependent Mapping • TURN [RFC5766] server allocates a public address for the client to advertise. • All P2P data is relayed via the TURN server, so restrictive NAT pinhole works. • Often more overhead than P2P connectivity: processing time on relay, additional latency. 23 TURN to the Rescue Address: Address: Alice TA TB Bob Private Address: A TURN TURN Address: B Alice and Bob get addresses from their TURN servers. The media connection is relayed via TA and TB. 24 ICE Functionality 25 What is ICE [RFC5245] ? • Each peer can have multiple "candidate" addresses. • Interactive Connectivity Establishment is how the peers pick a candidate pair to use. • Basically, test connectivity for all pairs and pick the best candidate pair that works. 26 What is a Candidate? TURN Server TURN Server Bob NAT/Firewall Allocated IP: 192.168.1.34 IP: 1.4.7.4 IP: 45.67.89.34 Port: 4567 Port: 7865 Port: 45678 HOST RFLX RELAY 27 Candidate Gathering TURN Server Allocating TURN Allocate Request RELAY port and reports back where request came from (RFLX) Bob NAT/Firewall IP: 192.168.1.34 IP: 1.4.7.4 TURN Server Allocated Port: 4567 Port: 7865 IP: 45.67.89.34 HOST RFLX Port:RELAY 45678 28 Checklist TURN TURN Server Server Agents gather their candidates HOST RFLX RELAY RELAY RFLX HOST 29 Checklist TURN TURN Server Server Need to check connectivity from host candidate Alice Bob HOST HOST RFLX RFLX RELAY RELAY 30 Checklist TURN TURN Server Server .. and from RELAY candidate. Not possible to send from Alice RFLX, that “just” happens. Bob HOST HOST RFLX RFLX RELAY RELAY 31 Checklist TURN TURN Server Server And checks from the other directions as well. (This is important, more on that later) Alice Bob HOST HOST RFLX RFLX RELAY RELAY 32 Connectivity Check STUN Binding Request STUN Binding Response 33 Connectivity Checks TURN TURN Server Server HOST to HOST is a nice start. If that works all is good. Alice Bob HOST HOST RFLX RFLX RELAY RELAY 34 Connectivity Checks TURN TURN Server Server No “pinhole” packet dropped “Pinhole” open to allow answers back in Alice HOST HOST RFLX RFLX RELAY RELAY 35 Connectivity Checks TURN TURN “Pinhole” allow Server Server answer back in “Pinhole” open to allow answers back in Alice Bob HOST HOST RFLX RFLX RELAY RELAY 36 Connectivity Checks TURN TURN Server Server “Pinhole” open to allow answer back in Retrying connectivity check Alice Bob HOST HOST RFLX RFLX RELAY RELAY 37 Concluding TURN TURN Server Server Success! P2P Media Alice without need for relay! Bob HOST HOST RFLX RFLX RELAY RELAY 38 Concluding TURN TURN Server Server Alice Bob Dependent on the NAT/FW media might take many paths 39 Main Steps • Gather candidates • Exchange candidates (WebRTC signaling, SIP, XMPP etc.) • Create checklist and do connectivity checks • Stop, conclude and send media 40 IETF RFCS, DRAFTS AND I-DS 41 RFCs, drafts and I-Ds Individual Drafts Nombis SIP Dual Stack Peer Adopted Drafts TURN Fairness Redirect ICE SIP SDP Trickle ICE Mobility SIP TURNBis Discovery Trickle ICE Server ICE SIP MICE Selection Core RFCs options ICE IANA 3rd party TURN TCP (RFC 5768) Registry ICEBis Auth (RFC 6062) (RFC 6336) [RFC7635] TURN IPv6 TURN ICE (RFC 6156) ICE TCP (RFC 5766) (RFC 5245) (RFC 6544) STUN (RFC 5389) STUN DTLS Security ALPN (RFC7350) rtcWEB (RFC 7443) STUN STUNbis Consent Origin Freshness [RFC7675] PMTUd DISCUSS PATH Data DANE 42 Solutions for Enterprise Firewall traversal • STUN Inspection • TURN Extension • SDN 43 STUN inspection • Based on STUN inspection outcome, either allow or deny the WebRTC connection • WebRTC uses STUN messages to perform connectivity checks. • Relies on RFC7675: STUN usage for consent freshness 44 RFC7675:STUN usage for consent freshness • ICE checks for the duration of the media session. • Media stopped if consent check fails. 45 STUN inspection STUN Server Firewall × Bob Alice Open pinhole* in firewall to allow STUN request from Alice to anywhere Enterprise 46 STUN inspection ICE Connectivity Checks STUN Request ice-ufrag:X34$:57er, ID = 500 STUN Request × Bob Firewall Alice STUN response ID=100 Enterprise Convert pinhole to full flow and store ice username (X34$:57er) and transaction id. Firewall will terminate flow after 30 seconds on inactivity from Alice. 47 STUN inspection ICE Connectivity Checks STUN Request ice-ufrag:57er:X34$, ID = 500 Bob Firewall Alice STUN response ID=500 Enterprise 48 STUN inspection ICE Connectivity Checks STUN Request ice-ufrag:57xx:Y34$, ID = 100 Bob Firewall× Alice Enterprise 49 STUN inspection • ASA • 9.6.1, March 2016 release • CLI: inspect stun • This CLI command is used to enable or disable STUN inspection. • Inspection scope will be configured via access-lists. • STUN inspection will not kick-in • If client uses (D)TLS with the TURN server. • Enterprise network need not deploy a STUN or TURN server. 50 TURN • TURN client can indicate start and end of UDP flow. • Firewall can be configured to permit UDP traffic to TURN servers. • TURN client authenticates to the server using long-term credentials (username/password). 51 TURN FW blocks traffic to external STUN Server STUN server Internet Firewall Remote Peer WebRTC client TURN Server Enterprise Network 52 TURN RFC 7635: STUN Extension for Third Party Authorization • Enterprise TURN server can identify business related media session. 53 Third party authorization for TURN using OAuth OAuth TURN Client TURN Client Resource Owner Authorization Server (e.g.: WebRTC server) Authorization server Authorization Server Resource Server TURN Server 54 55 Third party authorization for TURN using OAuth WebRTC Server (2) (1) Access Token AS-RS, Request (3) Access Token AUTH Keys + Session Key WebRTC client TURN Server (4) Allocate request + Access Token (5) Allocate response 56 STUN Attribute : ACCESS-TOKEN struct { opaque { uint16_t nonce_length; opaque nonce[nonce_length]; opaque { ushort key_length; opaque mac_key[key_length]; uint64_t timestamp[8]; uint32_t lifetime; } encrypted_block; opaque mac[mac_length]; } token; 57 Advantages of RFC7635 • No long-term TURN user credentials to keep secret; even if discovered, credential usefulness is limited • TURN username contains no externally-identifying information and helps to provide privacy.
Recommended publications
  • User Datagram Protocol - Wikipedia, the Free Encyclopedia Página 1 De 6

    User Datagram Protocol - Wikipedia, the Free Encyclopedia Página 1 De 6

    User Datagram Protocol - Wikipedia, the free encyclopedia Página 1 de 6 User Datagram Protocol From Wikipedia, the free encyclopedia The five-layer TCP/IP model User Datagram Protocol (UDP) is one of the core 5. Application layer protocols of the Internet protocol suite. Using UDP, programs on networked computers can send short DHCP · DNS · FTP · Gopher · HTTP · messages sometimes known as datagrams (using IMAP4 · IRC · NNTP · XMPP · POP3 · Datagram Sockets) to one another. UDP is sometimes SIP · SMTP · SNMP · SSH · TELNET · called the Universal Datagram Protocol. RPC · RTCP · RTSP · TLS · SDP · UDP does not guarantee reliability or ordering in the SOAP · GTP · STUN · NTP · (more) way that TCP does. Datagrams may arrive out of order, 4. Transport layer appear duplicated, or go missing without notice. TCP · UDP · DCCP · SCTP · RTP · Avoiding the overhead of checking whether every RSVP · IGMP · (more) packet actually arrived makes UDP faster and more 3. Network/Internet layer efficient, at least for applications that do not need IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · guaranteed delivery. Time-sensitive applications often IPsec · ARP · RARP · RIP · ICMP · use UDP because dropped packets are preferable to ICMPv6 · (more) delayed packets. UDP's stateless nature is also useful 2. Data link layer for servers that answer small queries from huge 802.11 · 802.16 · Wi-Fi · WiMAX · numbers of clients. Unlike TCP, UDP supports packet ATM · DTM · Token ring · Ethernet · broadcast (sending to all on local network) and FDDI · Frame Relay · GPRS · EVDO · multicasting (send to all subscribers). HSPA · HDLC · PPP · PPTP · L2TP · ISDN · (more) Common network applications that use UDP include 1.
  • Routing Loop Attacks Using Ipv6 Tunnels

    Routing Loop Attacks Using Ipv6 Tunnels

    Routing Loop Attacks using IPv6 Tunnels Gabi Nakibly Michael Arov National EW Research & Simulation Center Rafael – Advanced Defense Systems Haifa, Israel {gabin,marov}@rafael.co.il Abstract—IPv6 is the future network layer protocol for A tunnel in which the end points’ routing tables need the Internet. Since it is not compatible with its prede- to be explicitly configured is called a configured tunnel. cessor, some interoperability mechanisms were designed. Tunnels of this type do not scale well, since every end An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 point must be reconfigured as peers join or leave the tun- network without prior configuration. This category includes nel. To alleviate this scalability problem, another type of ISATAP, 6to4 and Teredo. We present a novel class of tunnels was introduced – automatic tunnels. In automatic attacks that exploit vulnerabilities in these tunnels. These tunnels the egress entity’s IPv4 address is computationally attacks take advantage of inconsistencies between a tunnel’s derived from the destination IPv6 address. This feature overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a eliminates the need to keep an explicit routing table at vehicle for traffic amplification to facilitate DoS attacks. the tunnel’s end points. In particular, the end points do We exhibit five attacks of this class. One of the presented not have to be updated as peers join and leave the tunnel. attacks can DoS a Teredo server using a single packet. The In fact, the end points of an automatic tunnel do not exploited vulnerabilities are embedded in the design of the know which other end points are currently part of the tunnels; hence any implementation of these tunnels may be vulnerable.
  • Problems of Ipsec in Combination with NAT and Their Solutions

    Problems of Ipsec in Combination with NAT and Their Solutions

    Problems of IPsec in Combination with NAT and Their Solutions Alexander Heinlein Abstract As the Internet becomes more and more a part of our daily life it also evolves as an at- tractive target for security attacks, often countered by Internet Protocol Security (IPsec) to establish virtual private networks (VPNs), if secure data communication is a primary objective. Then again, to provide Internet access for hosts inside Local Area Networks, a public IP address shared among all peers is often used, achieved by Network Address Translation (NAT) deployment. IPsec, however, is incompatible with NAT, leading to a variety of problems when using both in combination. Connection establishments origi- nating from the outside are blocked and NAT, as it modifies the outer IP header, breaks IPsec’s security mechanisms. In the following we analyze problems of NAT in combination with IPsec and multiple approaches to solve them. 1 Introduction The current TCP/IP protocols originate from a time where security was not a great concern. As the traditional Internet Protocol (IP) does not provide any guarantees on delivery, the receiver cannot detect whether the sender is the same one as recorded in the protocol header or if the packet was modified during transport. Moreover an attacker may also easily replay IP packets or read sensitive information out of them. In contrast, today, as the Internet becomes more and more a part of our everyday life, a more security aware protocol is needed. To fill this gap the Internet Engineering Task Force (IETF) worked on a new standard for securing IP, called Internet Protocol Security (IPsec).
  • Hybrid ATA with FXS and FXO Ports

    Hybrid ATA with FXS and FXO Ports

    Hybrid ATA with FXS and FXO ports HT813 The HT813 is an analog telephone adapter that features 1 analog telephone FXS port and 1 PSTN line FXO port in order to offer backup lifeline support using a PSTN line. The integration of a FXO and FXS port enables this hybrid ATA to support remote calling to and from the PSTN line. For added flexibility, the FXS port extends VoIP service to one analog device. Users can convert their analog technology to VoIP thanks to the HT813’s ultra-compact size, HD voice quality, advanced VoIP functionality, high-end security protection and multiple auto provisioning options. These advanced features also allow service providers to offer high quality IP service to customers looking to upgrade to VoIP. Supports 2 SIP Dual 100Mbps LAN Lifeline support (FXS 3-way voice profiles through 1 and WAN ports port will be hard- conferencing per FXS port and 1 FXO relayed to FXO port) port port in case of power outage Automated & secure Supports T.38 Fax Failover SIP server Strong AES encryption provisioning options for reliable Fax- automatically with security using TR069 over-IP switches to certificate per unit secondary server if main server loses connection www.grandstream.com Telephone Interfaces One (1) RJ11 FXS port, One (1) RJ11 FXO PSTN line port with lifeline support Network Interface Two (2) 10/100Mbps ports (RJ45) with integrated NAT router LED Indicators POWER, LAN, WAN, FXS, FXO Factory Reset Button Yes Voice, Fax, Modem Caller ID display or block, call waiting, flash, blind or attended transfer, forward,
  • NAT Tutorial

    NAT Tutorial

    NAT Tutorial Dan Wing, [email protected] IETF77, Anaheim March 21, 2010 V2.1 1 Agenda • NAT and NAPT – Types of NATs • Application Impact – Application Layer Gateway (ALG) – STUN, ICE, TURN • Large-Scale NATs (LSN, CGN, SP NAT) • IPv6/IPv4 Translation (“NAT64”) • NAT66 2 Agenda • NAT and NAPT – Types of NATs • Application Impact – Application Layer Gateway (ALG) – STUN, ICE, TURN • Large-Scale NATs (LSN, CGN, SP NAT) • IPv6/IPv4 Translation (“NAT64”) • NAT66 3 NAT • First described in 1991 • 1:1 translation – Does not conserve IPv4 addresses • Per-flow stateless • Today’s primary use is inside of enterprise networks – Connect overlapping RFC1918 address space draft-tsuchiya-addrtrans-00 4 NAT Diagram • Hosts seem to have multiple IPv4 addresses – almost like “ghosts” 192.168.0.2 10.1.1.2 192.168.0.1 10.1.1.1 192.168.0.3 10.1.1.3 5 NAPT • Described in 2001 (RFC3022) • 1:N translation – Conserves IPv4 addresses – Allows multiple hosts to share one IPv4 address – Only TCP, UDP, and ICMP – Connection has to be initiated from ‘inside’ • Per-flow stateful • Commonly used in home gateways and enterprise NAT 6 NAPT Diagram • Hosts share an IPv4 address 192.168.0.2 157.55.0.1 Internet 192.168.0.3 192.168.0.1 7 NAPT complications • NAPT requires connections initiated from ‘inside’ • Creates state in the network (in the NAPT) – This is bad – NAPT crashes -> connections break • When to discard state? – TCP RST? Spoofed RSTs? – Timeout? 8 Terminology • “NAT” is spoken/written instead of “NAPT” – Even though NAPT is often more accurate – The more accurate
  • Guidelines for the Secure Deployment of Ipv6

    Guidelines for the Secure Deployment of Ipv6

    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
  • Datagram Transport Layer Security Dtls Protocol

    Datagram Transport Layer Security Dtls Protocol

    Datagram Transport Layer Security Dtls Protocol Lipless Arie expertised bootlessly. Kermit still hilltop bulgingly while Cesarean Silvain mutualising that serigrapher. Which Patsy homologating so wrongly that Stefano carcasing her Morley? Display real time to the connection close messages back its communications security layer datagram transport dtls protocol is located somewhere After sending state alive at all connections except you enable smart, it must not recommend contacting your. Ipsec can defend against almost has with transport layer datagram transports. Cbc ciphers must not apply settings, dtls with unlimited data packets. All local network layer transport receiver responds to allocate state. Please enter a transport datagram layer security protocol deadlocks could derive from. Dtls protocol secured with ssl certificate errors, also supported extensions, through reference to. Both against denial of sequence number to syslog over time taken by maintaining a different ip office of service to use with saying that your tunnel? Tls features of using ssl protocol to find commands shown when replay. Dtls payload in another thread, and hacking just slightly different os sockets interface mtu that works and provisioning processes, each of output generated. Registration flag for dtls protocol identifier, but it can be taken to. Ssl protocol needs to facilitate certification authority can present certificate checks udp protocols. Tls will cause connection state machine translated for dtls api and servers including ehs headset and may treat receipt; login attempts and authorization server. This attack is datagram layer datagram transport security dtls protocol to attack. Can improve your site may be found or esp payload of the next generation must be used, transferring this service provision information, will detail the.
  • HT801/HT802 Analog Telephone Adaptors Administration Guide

    HT801/HT802 Analog Telephone Adaptors Administration Guide

    Grandstream Networks, Inc. HT801/HT802 Analog Telephone Adaptors Administration Guide COPYRIGHT ©2021 Grandstream Networks, Inc. http://www.grandstream.com All rights reserved. Information in this document is subject to change without notice. Reproduction or transmittal of the entire or any part, in any form or by any means, electronic or print, for any purpose without the express written permission of Grandstream Networks, Inc. is not permitted. The latest electronic version of this user manual is available for download here: http://www.grandstream.com/support Grandstream is a registered trademark and Grandstream logo is trademark of Grandstream Networks, Inc. in the United States, Europe and other countries. CAUTION Changes or modifications to this product not expressly approved by Grandstream, or operation of this product in any way other than as detailed by this User Manual, could void your manufacturer warranty. WARNING Please do not use a different power adaptor with your devices as it may cause damage to the products and -void the manufacturer warranty. P a g e | 1 HT801/HT802 Administration Guide Version 1.0.29.8 GNU GPL INFORMATION HT801/HT802 firmware contains third-party software licensed under the GNU General Public License (GPL). Grandstream uses software under the specific terms of the GPL. Please see the GNU General Public License (GPL) for the exact terms and conditions of the license. Grandstream GNU GPL related source code can be downloaded from Grandstream web site from: http://www.grandstream.com/support/faq/gnu-general-public-license/gnu-gpl-information-download P a g e | 2 HT801/HT802 Administration Guide Version 1.0.29.8 Table of Content DOCUMENT PURPOSE ................................................................................................
  • TR-069 CPE WAN Management Protocol V1.1

    TR-069 CPE WAN Management Protocol V1.1

    TECHNICAL REPORT TR-069 CPE WAN Management Protocol v1.1 Version: Issue 1 Amendment 2 Version Date: December 2007 © 2007 The Broadband Forum. All rights reserved. CPE WAN Management Protocol v1.1 TR-069 Issue 1 Amendment 2 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
  • IP Intercom User Manual

    IP Intercom User Manual

    IP Intercom User Manual Single button Dual button 1 / 50 Safety Notices 1. Please use the specified power adapter. If special circumstances need to use the power adapter provided by other manufacturers, please make sure the voltage and current provided in accordance with the requirements of this product, meanwhile, please use the safety certificated products, otherwise may cause fire or get an electric shock. 2. When using this product, please do not damage the power cord, or forcefully twist it、Stretch pull or banding, and not to be under heavy pressure or between items, Otherwise may cause the power cord damage, thus lead to fire or get an electric shock. 3. Before use, please confirm the temperature and environment humidity suitable for the product work. (Move the product from air conditioning room to natural temperature, which may cause this product surface or internal components produce condense water vapor, please open power use it after waiting for this product is natural drying). 4. Non-technical staff not remove or repair, improper repair or may cause electric shock, fire or malfunction, etc，Which can lead to injury accident, and also can cause your product damage. 5. Do not use fingers, pins, wire and other metal objects, foreign body into the vents and gaps. It may cause current through the metal or foreign body, which even cause electric shock and injury accident. If any foreign body or objection falls into the product please stop usage. 6. Please do not discard the packing bags or stored in places where children could reach, if children trap his head with it, may cause nose and mouth blocked, and even lead to suffocation.
  • Zscaler and Cisco SD-WAN (Viptela) Deployment Guide

    Zscaler and Cisco SD-WAN (Viptela) Deployment Guide

    Zscaler Internet Access (ZIA) and Cisco SD-WAN Deployment Guide July 2020 Version 3.2 Table of Contents 1 Document Overview ..................................................................................... 6 1.1 Document Audience ...................................................................................................... 6 1.2 Hardware Used .............................................................................................................. 6 1.3 Software Revisions ........................................................................................................ 6 1.4 Request for Comments .................................................................................................. 6 1.5 Document Prerequisites ................................................................................................ 7 1.6 Document Revision Control ........................................................................................... 8 1.7 Cisco Design Overview .................................................................................................. 9 1.7.1 GRE and IPsec Tunnels ................................................................................................... 10 1.7.2 Tunnel Liveliness .............................................................................................................. 10 1.7.3 Transport-side vs Service-side Tunnels ............................................................................ 12 1.7.4 Traffic Redirection ...........................................................................................................
  • Certified Webrtc Integrator (CWI™) Program

    Certified Webrtc Integrator (CWI™) Program

    Certified WebRTC Integrator (CWI™) program Overview The WebRTC School™ is ‘the’ place to learn all about WebRTC, also known as Web Real-Time- Communications. There is so much information on the internet about WebRTC that is hard to read, poorly presented and also lacking in detail, making it difficult for people to learn about this most important specification. So the WebRTC School™ with its lively, clear and fully animated eLearning program has become the best place to enroll to learn about WebRTC. Who would benefit from the Certified WebRTC Integrator (CWI™) program? People who need to understand the underlying infrastructure that helps to make the WebRTC ‘magic’ happen. Covering protocols, media flows, signaling, NAT traversal techniques and security plus various use case scenarios this program can be taken as a standalone course or used to complement the Certified WebRTC Developer (CWD™) program. What’s in the Certified WebRTC Integrator (CWI™) program? Once you’ve enrolled, you’ll see 10 modules. You can work through the modules in order or simply choose the ones you are most interested in. The modules are listed here but for more detail, please look further into this document. 1. Introduction to WebRTC 2. Media Flows in WebRTC 3. WebRTC Protocols 4. IETF WebRTC Standards effort 5. WebRTC Media Stack 6. Signaling 7. WebRTC NAT Traversal 8. Security 9. WebRTC ‘Use Cases’ 10. Status of WebRTC and ‘What’s next’ How long will it take to work through? Total Running time for this program is approximately 3 hours from the start to finish though the time will vary based on the student’s own experience and of course, how much time they want to spend on the material and if they want to replay some modules.