SPECIFYING REQUIREMENTS FOR VOIP CALLS
MANAGING AUDIO QUALITY AND CLARITY
FACTORS AFFECTING AUDIO CLARITY
This is the degree to wc a sys or a portion of a sys accurately reproduces, at its output, the essential characteristics of the signal impressed upon its input or the result of a prescribed operation on the signal impressed upon its input.
This is the result of electrical impedance mismatches on the transmission path.
Echo is always present.
Two components affect echo:
-amplitude - loudness of the echo
-delay - time between spoken voice and echoed sound
Can be controlled using suppressors or cancelers.
this is the variation in the arrival of coded speech packets at the far end of the VOIP network.
varying arrival times can cause gaps in re-creation/playback of voice-signal and are undesirable and annoy the listener.
network congestion, improper queuing or config errors can cause the unevenness in a steady stream of sent pkts.
use playout delay buffer or dejitter buffer to resolve this by buffering the pkts and playing them out in a steady stream to the digital signal proc (DSP) to be converted back to an analog audio stream. This buffer however affects overall absolute delay which can affect VOIP. Entire words in a conversation can be cut off.
This is the time between spoken voice and the arrival of electronically delivered voice at the other end.
Results from multiple factors including distance (propagation delay), coding, compression, serialization and buffers.
Two types of delay:
Fixed delay components are predictable and add directly to the overall delay on the connection. These components include:
-coding - the time it takes to translate an audio signal into a digital signal.
-packetization - the time it takes to put digital voice info into pkts and remove the info from the pkts.
-serialization - the insertion of bits into a link
-propagation - the time it takes a pkt to traverse a link.
These arise from queuing delays in the egress trunk buffers that are located on the serial port connected to the WAN.
3 bands of one-way delay are specified by the ITU-T recomm G.114, ie, the acceptable network delay for voice apps:
1. 0 - 150 ms
acceptable for most user apps
2. 150 - 400 ms
acceptable as long as admins are aware of the transmission time and its impact on the transmission quality of user apps.
3. 400 ms
Above 400 ms is unacceptable for general network planning purposes.
might be exceeded in some exceptional circumstances.
G.114 recomm is for conns that are adequately controlled, implying that echo cancelers are in use. Echo cancelers are reqd when one-way delay exceeds 25ms.
For private networks a 200ms goal is reasonable and 250ms delay is the limit.
Unstable network, network congestion or too much variable delay in the network, may cause voice pkts to be dropped. Lost voice pkts are not recoverable since retransmission is not an option thus leading to gaps in conversations.
Industry standard codec algorithms used in Cisco DSPs will correct for 20 to 50 ms of lost voice packets thru the use of Packet Loss Concealment(PLC) algorithm which analyzes missing packets and generates a reasonable replacement packet to improve the voice quality. Cisco VOIP tech uses 20 ms samples of voice payload per VOIP pkt as default.
Only a single packet can be lost at any time, if more, then gaps are experienced.
This refers to the purposeful design of the tel that allows the user to hear the spoken audio from the ear-piece. Without this, it would seem as if the tel was faulty.
This is the low-volume audio that is heard from the far-end of the connection.
Bandwidth saving devices such as voice activity detection (VAD) can eliminate background noise altogether.
AUDIO QUALITY MEASUREMENT
Audio quality can be measured using:
Mean opinion score (MOS) defined in ITU-T recomm P.800 - average opinion of group of testers is calculated to create MOS score.
Uses subjective testing
Perceptual Speech Quality Measurement (PSQM).Automated method for measuring speech quality ''in service'' or as it goes along. Defined in ITU P.861. Usually resides with IP call management systems sometimes integrated into SNMP systems.
Has over 90% accuracy.
Both of these measurement methods are not recommended for modern voip networks. they do not measure problems such as jitter and delay.
3. Perceptual Evaluation of Speech Quality (PESQ):
Cisco Qos Mechs:
use to provide effective priority service.
provided thru IP traffic management, queuing, and shaping.
Cisco IOS features that address reqs of e2e QoS and service differentiation of voice pkt delivery:
-Header compression: - results in decreased consumption of available bandwidth, reduction in delay is also realized. (RTP or TCP header compression)
-Frame relay traffic shaping (FRTS): delays excess traffic using a buffer or queuing mech, to hold pkts and shape the flow when the data rate of the source is higher than expected.
-FRF.12 or higher: ensures predictability for voice traffic, aiming to provide better thruput on low-speed Frame Relay links by interleaving delay-sensitive traffic on one virtual circuit (VC) with fragments of a long frame on another VC utilizing the same interface.
-PSTN fallback: provides a mech to monitor congestion in the IP network and either redirect calls to the PSTN or reject calls based on the network congestion.
-IP RTP Priority and Frame Relay IP RTP Priority: provide a strict priority queuing scheme that allows delay-sensitive data such as voice to be dequeued and sent before pkts in other queues are dequeued.
Works with WFQ and CBWFQ.
Useful of slow WAN links like FR, Multilink PPP (MLP), T1 ATM.
-IP-to-ATM class of service (CoS):
-Low latency queuing (LLQ):
-Multilink PPP (MLP):
-Resource Reservation Protocol (RSVP):
QoS features provide improved and more predictable network operations by implementing these features:
-support guaranteed bandwidth - QoS designs the ntwk in such a way that necessary bandwidth is always available to support voice and data traffic.
-improve loss characteristics - design FR network such that discard eligibility is not a factor when it comes to frame pkts, keeping voice below the CIR.
-avoid and manage ntwk congestion - by ensuring that WAN and LAN infra can support vol of data traff and voice calls.
-shape ntwk traffic - using traff shaping tools
-set traff priorities across the ntwk - marking voice traff as priority and queuing it first.
LLQ provides strict priority qing in conjunction with CBWFQ - it configs the priority status for a class within CBWFQ in wc voice pkts receive priority over all other traff.
TRANSPORTING MODULATED DATA OVER IP NTWK
FAX AND MODEM PASS-THROUGH
Data sent in pkts to remote locs is assembled using a PAD (pkt assem/disassem) into individual pkts of data. Each pkt has unique id marking it as independent and has own dest add.
Fax xmissns are designed to op across a 64kbps pulse code modulated (PCM)-encoded voice circuit. In pkt ntwks, the 64-kbps stream is compressed into much smaller data rate by passing it thru a dig sig proc (DSP). A relay or pass-thru mech has to be in place since the codecs used in the DSP are normally for voice pkts.
THREE METHODS FOR CARRYING FAX OVER PKT NTWK:
- FAX RELAY: involves terminating and xmitting the data on the gtwy.
T.30 fax from PSTN is demod at the sending gtwy. Demod fax is enveloped in pkts, sent over the ntwk and remod into a T.30 fax at the receiving end.
Cisco IOS supports T.38 and Cisco fax relay (proprietary).
- FAX PASS-THRU: invs sending the packet in-band in a Reliable Transport Protocol (RTP) stream. Mod fax info is passed in-band e2e over a voice speech path in IP ntwk.
- STORE-AND-FORWARD FAX:uses T.37 to receive and convert faxes to files. Enables faxes to be delivered via computers rather than fax machines.
also known as voice band data, which refers to the xport of fax or modem signals over a voice channel thru pkt ntwk encoding - min set of coders for VBD is G.711 mu-law and a-law with VAD disabled.
Fax pass thru - simplest tech for sending fax over IP ntwk. Gateway does not distinguish fax calls from voice calls. Fax traff is carried btwn the two endpoints in RTP pkts using uncompressed format resembling the G.711 codec.
A constant 64-kbps (payload) stream is taken plus its IP overhead e2e for the duration of the call. IP overhead for voice traffic is 16-kbps but when switched to pass-thru, the packetization period is reduced from 20ms to 10ms.
Table below compares a G.711 VoIP call that uses 20 ms packetization with a G.711 fax pass-through call that uses 10 ms packetization:
Fax pass-thru is susceptible to jitter, packet loss and latency across the IP ntwk.
The two endpoints need to clock synchronously for this to work predictably.
Performance could be an issue. Redundant recoding (1X or one repeat of the original pkt) is used to mitigate pkt loss, this then doubles the amount of data transferred in each pkt and this in turn imposes a limitation on the number of ports that can run pass-thru at the same time.
One fax pass-thru session with redundancy needs as much bandwidth as two G.711 calls without VAD.
Fax pass-thru does not support the shift from G.Clear to G.711. With G.Clear also configd, the gtwy cannot detect a fax-tone.
Call-control protocols that support fax pass-thru:
Same tech as fax-thru, only modem sig this time.
-does not support switch from G.Clear to G.711
-VAD and echo cancellation need to be disabled.
-represses processing functions like compression, echo cancellation, VAD, high-pass filter.
-issues redundant pkts to protect against pkt drop.
-provides static jitter buffers of 200ms to protect against clock skew.
-Discriminates modem sig from fax sig
-reliably maintains modem connection across the pkt ntwk.
In Cisco Fax Relay mode, gtwys terminate T.30 fax signaling by spoofing a virtual fax machine to the locally attached fax machine. The gtwys use a Cisco proprietary fax relay to communicate btwn themselves.
Unlike fax pass-thru, fax relay demods the fax bits at the local gtwy, sends the info across the voice ntwk using the fax relay protocol, and then remods the bits back to tones at the far gtwy. The fax machines at both ends are not aware of a demod/remod taking place.
Cisco methods for fax relay:
- Cisco Fax Relay -- proprietary and default on most platforms if a fax method is not explicitly configd.
- T.38 Fax Relay: based on T.38 standard, it is real-time fax xmission. Can be configd for H.323, SIP and MGCP.
Features of T.38:
-Fax relay PLC
-MGCP-based fax (T.38) and DTMF relay
-SIP T.38 fax relay
-T.38 fax relay for the T.37/T.38 fax gtwy
-Ti38 for VOIP H.323
Demods a mod sig at one voice gtwy and passes it as pkt data to another voice gtwy, where the sig is remod and sent to a receiving mod. On detection of the mode answer tone, the gtwys switch into mod pass-thru mode and then if the the call menu (CM) sig is detected, the two gtwys switch to mod relay mode.
Two methods are used:
-Modem Pass-through: mod traff is carried btwn the two gtwys in RTP pkts, using uncompressed voice codec, G.711 mu-law, or a-law. Remains susceptible to pkt loss, jitter and latency in the IP ntwk. Pkt redundancy can be used to mitigate effects of pkt loss.
- Modem Relay: The mod sigs are demod at one gtwy, converted to digi form, and carried in Simple Packet Relay Transport (SPRT) protocol, which runs over UDP pkts to the other gtwy, where the mod sig is re-created, re-mod and passed to the receiving modem.
The call starts as a voice-call, switches into mod pass-thru mode, and then into mod relay mode.
Mod relay significantly reduces the effects of pkt loss, latency and jitter on the mod session. Also reduces the amount of bandwidth used.
Features of mod relay:
-modem tone detection and signaling
-dynamic and static jitter buffers
-clock slip buffer management
Gateway Controlled Modem Relay:
new feature supported from Cisco IOS release 12.4(4)T. It is non-negotiated, bearer switched mode for modem transport that does not involve call-agent-assisted negotiation during the call-setup.
The xmitting gtwy is referred to as 'on-ramp gateway', the terminating gtwy as 'off-ramp gtwy'.
-On-ramp faxing: a gateway that handles incoming calls from from a standard fax machine or the PSTN converts a traditional G3 fax into an email message with a TIFF attachment.
Off-ramp faxing: a gtwy that handles outgoing calls from a ntwk to a fax machine or a PSTN converts an email with TIFF attachment to a traditional fax format.
Facilitated with SMTP.
Gateway signaling protocol
FAX and MODEM PASS-THRU OP:
-terminating gtwy detects called terminal identification [CED] tone from called fax machine
-terminating gtwy exchanges the codec that was negotiated during the voice call setup for a G.711 codec and turns off echo cancellation and VAD
-this switchover is communicated to the originating gtwy
-originating gtwy allows the fax machs to xfer modem sigs as though they were traversing the PSTN.
-if voice codec is G.711, all that needs to be done is to turn off echo cancellation and VAD
IF PASS-THRU IS SUPPORTED, THIS IS WHAT OCCURS:
-DSP detects fax or modem : DSP listens for the 2100-Hz CED tone to detect fax or modem on the line.
-internal event alerts the call control stack
-call control stack on the OGW advises DSP to send a named signaling event [NSE] to the TGW informing the TGW of the request to change codec.
-terminating gtwy loads the new codec
NSEs are Cisco proprietary.
CISCO FAX RELAY
When a DSP is put into voice mode at the beginning of a VOIP call, the DSP is informed by the call control stack whether fax relay is supported or not and if it is Cisco fax relay of T.48 fax relay. If CFR is supported:
1. A voip call is established:
-voip call is est as if normal speech.
-call control procedures are followed, after wc human speech is expected to be received and processed.
2. CED tone is detected:
-if fax answer or calling tone [ANSam (modified ANSwer tone) or CED] is heard, the DSP does not interfere with the speech processing.
-the ANSam or CED tone causes a switch to modem pass-thru, if enabled, to allow the tone pass cleanly to the remote fax.
3. A digital info sig [DIS] is sent
4. RTP pkt is received
5. RTP pkts are sent to the TGW
T.38 RELAY OPERATION:
T.38 pass-through and relay uses special protocol enhancements on call control protocols:
1. H.323 T.38 fax relay
What occurs in a H.245 message flow:
-voip call is established - call control procedures are followed, DSp is put into voice mode, human speech is expected to be received and processed.
-CED tone is detected
if ANSam or CED is detected the DSP does not interfere with the speech. ANSam or CED tone causes a switch to modem pass-thru, if enabled, to allow the tone to pass cleanly to the remote fax.
-a DIS message is sent
a normal fax mach after generating a CED or hearing a CNG, sends a DIS msg with the capabilities of the fax mach.
the DSP in the Cisco IOS gw attached to the fax mach that generated the DIS (normally the TGW) detects the HDLC flag sequence at the start of the DIS message initiates fax relay switchover.
DSP also triggers an internal event to notify the call control stack that fax relay switchover is reqd.
the call control stack then instructs the DSP to change the RTP payload type to 96 and to send this payload type to the OGW.
-ModeRequest msg is sent from the detecting TGW to the OGW and the OGW responds with a ModeRequestAck.
-the OGW sends a closeLogicalChannel msg to close its UDP port and the TGW responds with a closeLogicalChannelAck msg while it closes the voip port.
-an openLogicalChannel is sent by the OGW that indicates which UDP port to send the T.38 UDP info on the OGW and the TGW responds with a openLogicalChannelAck msg.
-the TGW sends a closeLogicalChannel msg to close its UDP port and the OGW responds with a closeLogicalChannelAck msg while it closes the voip port.
-an openLogicalChannel is sent by the TGW that indicates which UDP port to send the T.38 UDP stream on the TGW and the OGW responds with a openLogicalChannelAck msg.
-T.38 encoded UDP msgs are sent back and forth
T.38 uses data redundancy to accommodate pkt loss. The level of redundancy can be configd on the IOS GWs.
The T.38 Annex B standard defines the mech that is used to switch over from voice mode to T.38 fax mode during a call.
2. SIP T.38 fax relay
T.38 Annex D procedures are used here for the changeover from voip to the fax mode during a call.
Events during a T.38 fax relay call flow:
-a voip call is est
-CED is detected
-DIS msg is sent
-TGW detects a fax V.21 flag sequence and sends an INVITE msg with T.38 details in the Session Description Protocol [SDP] field to the OGW or the SIP proxy server.
-the INVITE msg is received by the OGW and sends back a 200 OK msg.
-TGW acknowledges the 200 OK msg and sens an ACK directly to the OGW.
-OGW starts sending T.38 UDP pkts instead of voip UDP pkts across the same ports.
-at the end of the fax xmission another INVITE msg can be sent to return to the voip mode.
3. MGCP T.38 fax relay
Two modes of implementation:
1. Gateway-controlled mode:
2. Call agent-controlled mode:
Call flow for MGCP T.38 fax relay:
-a call is est as a voice call
-gateways' capabilities are advertised in SDP exchange during connection establishment
-support for T.38 fax relay is checked
-connection is reverted to voice call upon completion
A fax relay MGCP event allows the gw to notify the call agent of the status(start, stop or failure) of T.38 processing for the connection. this event is sent in both modes of implementation.