With the current separation of the Internet and the PSTN, a certain amount of redundancy is provided. An Internet outage does not necessarily mean that a voice communication outage will occur simultaneously, allowing individuals to call for emergency services and many businesses to continue to operate normally. In situations where telephone services become completely reliant on the Internet infrastructure, a single-point failure can isolate communities from all communication, including Enhanced 911 and equivalent services in other locales.
PSTN integration
E.164 is a global numbering standard for both the PSTN and PLMN. Most VoIP implementations support E.164 to allow calls to be routed to and from VoIP subscribers and the PSTN/PLMN. VoIP implementations can also allow other identification techniques to be used. For example, Skype allows subscribers to choose “Skype names” (usernames) whereas SIP implementations can use URIs similar to email addresses. Often VoIP implementations employ methods of translating non-E.164 identifiers to E.164 numbers and vice-versa, such as the Skype-In service provided by Skype and the ENUM service in IMS and SIP.
Echo can also be an issue for PSTN integration. Common causes of echo include impedance mismatches in analogue circuitry and acoustic coupling of the transmit and receive signal at the receiving end.
Security
Voice over Internet Protocol telephone systems (VoIP) are susceptible to attacks as are any internet-connected devices. This means that hackers who know about these vulnerabilities can institute denial-of-service attacks, harvest customer data, record conversations and break into voice mailboxes.
Another challenge is routing VoIP traffic through firewalls and network address translators. Private Session Border Controllers are used along with firewalls to enable VoIP calls to and from protected networks. Skype uses a proprietary protocol to route calls through other Skype peers on the network, allowing it to traverse symmetric NATs and firewalls. Other methods to traverse NATs involve using protocols such as STUN or ICE.
Many consumer VoIP solutions do not support encryption, although having a secure phone is much easier to implement with VoIP than traditional phone lines. As a result, it is relatively easy to eavesdrop on VoIP calls and even change their content. An attacker with a packet sniffer could intercept your VoIP calls if you are not on a secure VLAN.
There are open source solutions, such as Wireshark, that facilitate sniffing of VoIP conversations. A modicum of security is afforded by patented audio codec’s in proprietary implementations that are not easily available for open source applications, however such security through obscurity has not proven effective in other fields. Some vendors also use compression to make eavesdropping more difficult. However, real security requires encryption and cryptographic authentication which are not widely supported at a consumer level. The existing security standard Secure Real-time Transport Protocol (SRTP) and the new ZRTP protocol are available on Analogue Telephone Adapters(ATAs) as well as various soft-phones. It is possible to use IPsec to secure P2P VoIP by using opportunistic encryption. Skype does not use SRTP, but uses encryption which is transparent to the Skype provider. In 2005, Skype invited a researcher, Dr Tom Berson, to assess the security of the Skype software, and his conclusions are available in a published report.
The Voice VPN solution provides secure voice for enterprise VoIP networks by applying IPSec encryption to the digitized voice stream.
Securing VoIP
To prevent the above security concerns the government and military organizations are using; Voice over Secure IP (VoSIP), Secure Voice over IP (SVoIP), and Secure Voice over Secure IP (SVoSIP) to protect confidential, and/or classified VoIP communications. Secure Voice over IP is accomplished by encrypting VoIP with Type 1 encryption. Secure Voice over Secure IP is accomplished by using Type 1 encryption on a classified network, like SIPRNet. Public Secure VoIP is also available with free GNU programs.
Caller ID
Caller ID support among VoIP providers varies, although the majority of VoIP providers now offer full Caller ID with name on outgoing calls.
In a few cases, VoIP providers may allow a caller to spoof the Caller ID information, potentially making calls appear as though they are from a number that does not belong to the caller Business grade VoIP equipment and software often makes it easy to modify caller ID information. Although this can provide many businesses great flexibility, it is also open to abuse.
Compatibility with traditional analogue telephone sets
Some analogue telephone adapters do not decode pulse dialling from older phones. The VoIP user may use a pulse-to-tone converter, if needed.
Fax handling
Support for sending faxes over VoIP implementations is still limited. The existing voice codec’s are not designed for fax transmission; they are designed to digitize an analogue representation of a human voice efficiently. However, the inefficiency of digitizing an analogue representation (modem signal) of a digital representation (a document image) of analogue data (an original document) more than negates any bandwidth advantage of VoIP. In other words, the fax “sounds” simply don’t fit in the VoIP channel. An alternative IP-based solution for delivering fax-over-IP called T.38 is available.
The T.38 protocol is designed to work like a traditional fax machine and can work using several configurations. The fax machine could be a traditional fax machine connected to the PSTN, or an ATA box (or similar). It could be a fax machine with an RJ-45 connector plugged straight into an IP network, or it could be a computer pretending to be a fax machine. Originally, T.38 was designed to use UDP and TCP transmission methods across an IP network. The main difference between using UDP and TCP methods for a FAX is the real time streaming attributes. TCP is better suited for use between two IP devices. However, older fax machines, connected to an analogue system, benefit from UDP near real-time characteristics.
There have been updated versions of T.30 to resolve the fax over IP issues, which is the core fax protocol. Some new fax machines have T.38 built-in capabilities which allow the user to plug right into the network with minimal configuration changes. A unique feature of T.38 is that each packet contains a copy of the main data in the previous packet. This is an option and most implementations seem to support it. This forward error correction scheme makes T.38 far more tolerant of dropped packets than VoIP. With T.38, two successive lost packets are needed to actually lose any data. The data you lose will only be a small piece, but with the right settings and error correction mode, there is a high probability that you will receive the whole transmission.
Tweaking the settings on the T.30 and T.38 protocols could also turn your unreliable fax into a robust machine. Some fax machines pause at the end of a line to allow the paper feed to catch up. This is good news for packets that were lost or delayed because it gives them a chance to catch up. However, were this to happen on every line, your fax transmittal would take a long time. The end system can completely buffer the incoming fax data before displaying or printing the fax image.
Support for other telephony devices
Another challenge for VoIP implementations is the proper handling of outgoing calls from other telephony devices such as DVR boxes, satellite television receivers, alarm systems,
conventional modems and other similar devices that depend on access to a PSTN telephone line for some or all of their functionality.
These types of calls sometimes complete without any problems, but in other cases they fail. If VoIP and mobile substitution becomes very popular, some ancillary equipment makers may be forced to redesign equipment, because it would no longer be possible to assume a conventional PSTN telephone line would be available in consumer’s homes.
Video Over IP
Professional video over IP systems use some existing standard video codec to reduce the program material to a bitstream (e.g., an MPEG transport stream), and then to use an Internet Protocol(IP) network to carry that bitstream encapsulated in a stream of IP packets. This is typically accomplished using some variant of the RTP protocol.
Carrying professional video over IP networks has special challenges compared to most non-time-critical IP traffic. Many of these problems are similar to those encountered in voice over IP, but to a much higher level of engineering requirements. In particular, there are very strict quality of service (QoS) requirements which must be fulfilled for use in professional broadcast environments.
Packet Loss
Since even well-engineered IP networks tend to have a small residual packet loss rate caused by low-probability statistical congestion events and amplification of bit errors in the underlying hardware, most professional solutions use some kind of forward error correction to ensure that the encoded video stream can be reconstructed even if a few packets are lost. This is typically applied at the packet level, since the encapsulated video bitstream is typically only designed to tolerate low levels of bit or burst errors, rather than the loss of whole packets. Resending packets is not an option because of the sequential nature of the underlying video signal. For live video, a resent packet would arrive well after the arrival of the next frame of video.
Network Delay Variation
Network delay variation can be kept to a minimum by using a high-speed network backbone, and ensuring that video traffic does not encounter excessive queue delays. This is typically done by either ensuring that the network is not too close to its full capacity, or that video traffic is prioritized using traffic engineering techniques.
The remaining delay variation can be removed by buffering, at the expense of added time delay. If forward error correction is used, a small proportion of packets arriving after the deadline can be tolerated, since they can be dealt with by being discarded on receipt, and then treated in the same way as lost packets. Added time delay is particularly unwelcome in PTZ cameras as it makes operator control difficult at values over 250ms.
Timing Reconstruction
The other problem presented by latency variation is that it makes synchronization more complex by making the recovery of the underlying timing of the video signal far more difficult. This is typically solved by genlocking both ends of the system to external station sync signals, typically generated from sources such as GPS or atomic clocks, thus only requiring the extraction of coarse timing information at the receiving end in order to achieve high-quality video synchronization. The extraction of coarse timing data is typically done using a phase locked loop with a long time constant.
Adequate Bandwidth
Even with packet loss mitigation, video over IP will only work if the network is capable of carrying the content with some reasonable maximum packet loss rate. In practice, this means that video over IP will not work on overloaded networks. Since IP does not of itself offer any traffic guarantees, this must be applied at the network engineering level. One approach to this is the “quantity of service” approach which simply allocates sufficient bandwidth to video-carrying traffic that it will not congest under any possible load pattern. Other approaches include dynamic reduction in frame rate or resolution, network admission control, bandwidth reservation, traffic shaping, and traffic prioritization techniques, which require more complex network engineering, but will work when the simple approach of building a non-blocking network is not possible.
Use by Security Industry
Within the security products industry, IP-based Closed Circuit Television (CCTV) is making gains on the analogue market. Key components of IP-based CCTV remain consistent with analogue technologies: image capture, with a combination of IP-based cameras or analogue cameras using IP-based encoders; image transmission; Storage and Retrieval, which uses technologies such as RAID arrays and iSCSI for recorded and indexed video; and video management, which affords web browser-enabled management and control of IP-based CCTV systems.
One key advantage of IP-based CCTV is the ability to use network infrastructure, providing adequate bandwidth and availability of switching and routing, rather than coaxial cabling. However, running bandwidth-intensive surveillance video over corporate data networks is a point of organizational contention, depending on the potential impact on network performance.
A class of companies (including Aimetis, Milestone Systems, videoNEXT, Verint and others) produce Video Management Software to help manage capture and storage of video content. Digital video also makes possible Video Content Analysis, which allows automatic detection and identification of various kinds of objects or motion. Companies in this market include Aimetis, VideoIQ, ObjectVideo, and Cernium.
Also another emerging model is off-site storage of video surveillance video. These online surveillance providers are utilizing cloud computing based technologies to consolidate multi-site surveillance video over the web. ByRemote, Iveda Solutions and Secure-I provide these services from an off-site data centre.
Several manufacturers of CCTV equipment, such as Dallmeier, Axis Communications, General Electric, Bosch, Pelco, Siemens and Sanyo are steadily integrating IP network technology into their product portfolios.
No comments:
Post a Comment