Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Voice over IP
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Quality of service== Communication on the IP network is perceived as less reliable in contrast to the circuit-switched public telephone network because it does not provide a network-based mechanism to ensure that data packets are not lost, and are delivered in sequential order. It is a best-effort network without fundamental [[quality of service]] (QoS) guarantees. Voice, and all other data, travels in packets over IP networks with fixed maximum capacity. This system may be more prone to data loss in the presence of congestion{{efn|IP networks may also be more prone to [[DoS attacks]] that cause congestion.<ref>{{Cite web|url=https://www.continuitycentral.com/feature074.htm|title=VoIP - Vulnerability over Internet Protocol?|website=www.continuitycentral.com}}</ref>}} than traditional [[circuit switched]] systems; a circuit switched system of insufficient capacity will refuse new connections while carrying the remainder without impairment, while the quality of real-time data such as telephone conversations on packet-switched networks degrades dramatically.<ref name=cisco/> Therefore, VoIP implementations may face problems with [[network latency|latency]], packet loss, and [[jitter]].<ref name=cisco>{{cite web|url=http://www.cisco.com/en/US/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html|title=Quality of Service for Voice over IP|access-date= May 3, 2011}}</ref><ref>{{cite journal|last=Prabhakar|first=G.|author2=Rastogi, R. |author3=Thotton, M |title=OSS Architecture & Requirements for VoIP Networks|journal=Bell Labs Technical Journal|year=2005|volume=10|issue=1|pages=31β45|doi=10.1002/bltj.20077|s2cid=12336090| issn = 1089-7089}}</ref> By default, network routers handle traffic on a first-come, first-served basis. Fixed delays cannot be controlled as they are caused by the physical distance the packets travel. They are especially problematic when satellite circuits are involved because of the long distance to a [[Geosynchronous satellite|geostationary satellite]] and back; delays of 400β600 ms are typical. Latency can be minimized by marking voice packets as being delay-sensitive with QoS methods such as [[DiffServ]].<ref name=cisco/> Network routers on high volume traffic links may introduce latency that exceeds permissible thresholds for VoIP. Excessive load on a link can cause congestion and associated [[queueing delay]]s and [[packet loss]]. This signals a transport protocol like [[Transmission Control Protocol|TCP]] to reduce its transmission rate to alleviate the congestion. But VoIP usually uses [[User Datagram Protocol|UDP]] not TCP because recovering from congestion through retransmission usually entails too much latency.<ref name=cisco/> So QoS mechanisms can avoid the undesirable loss of VoIP packets by immediately transmitting them ahead of any queued bulk traffic on the same link, even when the link is congested by bulk traffic. VoIP endpoints usually have to wait for the completion of transmission of previous packets before new data may be sent. Although it is possible to preempt (abort) a less important packet in mid-transmission, this is not commonly done, especially on high-speed links where transmission times are short even for maximum-sized packets.<ref name=ciscoPacket>{{cite web |url=http://www.cisco.com/en/US/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html#wp1029054 |title=Quality of Service for Voice over IP |access-date=May 3, 2011}}</ref> An alternative to preemption on slower links, such as dialup and [[digital subscriber line]] (DSL), is to reduce the maximum transmission time by reducing the [[maximum transmission unit]]. But since every packet must contain protocol headers, this increases relative header overhead on every link traversed.<ref name=ciscoPacket/> The receiver must resequence IP packets that arrive out of order and recover gracefully when packets arrive too late or not at all. [[Packet delay variation]] results from changes in [[queuing delay]] along a given network path due to competition from other users for the same transmission links. VoIP receivers accommodate this variation by storing incoming packets briefly in a [[playout buffer]], deliberately increasing latency to improve the chance that each packet will be on hand when it is time for the [[voice engine]] to play it. The added delay is thus a compromise between excessive latency and excessive [[Dropout (communications)|dropout]], i.e. momentary audio interruptions. Although jitter is a random variable, it is the sum of several other random variables that are at least somewhat independent: the individual queuing delays of the routers along the Internet path in question. Motivated by the [[central limit theorem]], jitter can be modeled as a [[Gaussian random variable]]. This suggests continually estimating the mean delay and its standard deviation and setting the playout delay so that only packets delayed more than several standard deviations above the mean will arrive too late to be useful. In practice, the variance in latency of many Internet paths is dominated by a small number (often one) of relatively slow and congested [[Internet bottleneck|bottleneck links]]. Most Internet backbone links are now so fast (e.g. 10 Gbit/s) that their delays are dominated by the [[Signal transmission|transmission]] medium (e.g. optical fiber) and the routers driving them do not have enough buffering for queuing delays to be significant.<ref>{{Cite web |title=Optical Packet Buffers for Backbone Internet Routers {{!}} Request PDF |url=https://www.researchgate.net/publication/220429109}}</ref> A number of protocols have been defined to support the reporting of [[quality of service]] (QoS) and [[quality of experience]] (QoE) for VoIP calls. These include [[RTP Control Protocol]] (RTCP) extended reports,<ref name=":1">{{Cite IETF |rfc=3611 |title=RTP Control Protocol Extended Reports (RTCP XR) |last=Caceres |first=Ramon |language=en}}</ref> SIP RTCP summary reports, H.460.9 Annex B (for [[H.323]]), [[H.248]].30 and MGCP extensions. The RTCP extended report VoIP metrics block specified by {{IETF RFC|3611}} is generated by an VoIP phone or gateway during a live call and contains information on packet loss rate, packet discard rate (because of jitter), packet loss/discard burst metrics (burst length/density, gap length/density), network delay, end system delay, signal/noise/echo level, [[mean opinion score]]s (MOS) and R factors and configuration information related to the jitter buffer. VoIP metrics reports are exchanged between IP endpoints on an occasional basis during a call, and an end of call message sent via SIP RTCP summary report or one of the other signaling protocol extensions. VoIP metrics reports are intended to support real-time feedback related to QoS problems, the exchange of information between the endpoints for improved call quality calculation and a variety of other applications. ===DSL and ATM=== DSL modems typically provide Ethernet connections to local equipment, but inside they may actually be [[Asynchronous Transfer Mode]] (ATM) modems.{{efn|Technologies such as [[802.3ah]] can be used for DSL connectivity without using ATM.}} They use [[ATM Adaptation Layer 5]] (AAL5) to segment each Ethernet packet into a series of 53-byte ATM cells for transmission, reassembling them back into Ethernet frames at the receiving end. Using a separate [[virtual circuit identifier]] (VCI) for voice over IP has the potential to reduce latency on shared connections. ATM's potential for latency reduction is greatest on slow links because worst-case latency decreases with increasing link speed. A full-size (1500 byte) Ethernet frame takes 94 ms to transmit at 128 kbit/s but only 8 ms at 1.5 Mbit/s. If this is the bottleneck link, this latency is probably small enough to ensure good VoIP performance without MTU reductions or multiple ATM VCs. The latest generations of DSL, [[VDSL]] and [[VDSL2]], carry Ethernet without intermediate ATM/AAL5 layers, and they generally support [[IEEE 802.1p]] priority tagging so that VoIP can be queued ahead of less time-critical traffic.<ref name=cisco/> ATM has substantial header overhead: 5/53 = 9.4%, roughly twice the total header overhead of a 1500 byte Ethernet frame. This "ATM tax" is incurred by every DSL user whether or not they take advantage of multiple virtual circuits β and few can.<ref name=cisco/> ===Layer 2=== Several protocols are used in the [[data link layer]] and [[physical layer]] for quality-of-service mechanisms that help VoIP applications work well even in the presence of [[network congestion]]. Some examples include: * [[IEEE 802.11e]] is an approved amendment to the [[IEEE 802.11]] standard that defines a set of quality-of-service enhancements for wireless LAN applications through modifications to the [[media access control]] (MAC) layer. The standard is considered of critical importance for delay-sensitive applications, such as voice over wireless IP. * [[IEEE 802.1p]] defines 8 different classes of service (including one dedicated to voice) for traffic on layer-2 wired [[Ethernet]]. * The [[ITU-T]] [[G.hn]] standard, which provides a way to create a high-speed (up to 1 gigabit per second) [[Local area network]] (LAN) using existing home wiring ([[Power line communication|power lines]], phone lines and [[Ethernet over coax|coaxial cables]]). G.hn provides QoS by means of Contention-Free Transmission Opportunities (CFTXOPs) which are allocated to flows (such as a VoIP call) that require QoS and which have negotiated a ''contract'' with the network controllers.
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Voice over IP
(section)
Add topic