240 likes | 355 Views
Ensuring QoS in Your VoIP Development. Choon Shim CTO and Senior VP of Engineering choon@qovia.com , http://www.qovia.com. VoIP problems. Outage: - Infrastructure: switch, router, bridge, UPS, etc - VoIP element: call server, SIP server, GW, GK, MCU, handsets.
E N D
Ensuring QoS in Your VoIP Development Choon Shim CTO and Senior VP of Engineering choon@qovia.com , http://www.qovia.com
VoIP problems • Outage: - Infrastructure: switch, router, bridge, UPS, etc - VoIP element: call server, SIP server, GW, GK, MCU, handsets. - Carrier: T1/E1, analog signal trunk lines. • Voice Quality: - Delay: network bandwidth, processing power - Echo: hybrid, acoustic - Jitter: jitter buffer calculation, variable delay - Packet loss: sender base, receiver base - Out of order: complex topology
IP is not designed for carrying real-time media stream. Management was not considered by System/Elements Vendors. Too many moving parts. Too many protocol layers. Too many API layers. Multi vendor products. Roots of the problems
VoIP ready network • Fast network: low latency and jitter • Clean network: few packet loss and retransmit • QoS ready network: Voice packet has priority • Fault tolerant network: redundancy and backup • Manageable network: monitoring and management
Bandwidth • Required bandwidth per call (bps): BW = (V + I + L) * 8 * P Where, V is size of voice sample, I is IP/UDP/RTP overhead, L is data link overhead and P is packets generated per second. Example) (160 + 40 + 18) * 8 * 50 = 87.2 kbps • Required bandwidth total: Total BW = BW * N Where, N is total number of simultaneous calls Example) 87.2 * 50 = 4.36 Mbps => Increase bandwidth
To reduce bandwidth requirement • Bandwidth requirement by codec and duplex • cRTP reduces 2-5 bytes overhead • VAD reduces up to 50% payload
Clean network • Reduce hop counts • Reduce complexity of network topology • Remove duplex mismatch • Remove black hole and loop • Avoid half duplex link • Use common sense for cabling
QoS ready network • Layer 3: • Type of Service (TOS) • RSVP signaling (RFC 2205) • DiffServ (RFC2474) • Multiprotocol Label Switching (MPLS) • Layer 2: - 802.1p and 802.1q - Ethernet Class of Service (COS)
Fault tolerant network -Outage detection • Carrier failure: T1, E1, Analog - No incoming or outgoing calls. - Checking the module LED. - Checking the event log, management console. - Running a loop back test for T1/E1. - Checking with T1 tester. - Receiving an alarm from the call server.
Fault tolerant network –Outage detection (cont) • Infrastructure failure: - No dial tone or bad voice quality - Checking NMS console - Checking SNMP Traps - Testing cables - Testing switches, routers, bridges, etc - Checking UPS power load, power level, connection
Fault tolerant network –Outage detection (cont) • VoIP element failure: - No dial tone. - Checking SNMP trap. - Checking NMS console. - Checking with the vendor management console. - Checking event log, trace, etc.
Outage detection issues • Lack of alarm implementation. • Too many consoles to monitor: NMS, vendor supplied management, third party software, carrier OSS/EOSS. • Too many elements could go wrong. • Carriers are not monitoring the CSU or CPE.
Alarm – Event driven SNMP Trap T1/E1 Analog TE Switch Email/Pager GK Management Server Router Carrier console GW Bridge Server VoIPm Console UPS Environ
Checking vital signs • Blind polling: send a ping to every elements every x minutes. It triggers extra network traffics. Total number of packets per hour N = e * x / 60, where e = number of elements, x is minutes. • Severity base polling: send a ping to critical elements more often. For example) GW: every 5 mins, GK: every 6 mins, Switch: every 10 mins, Terminal element: 30 mins, etc. • Dynamic polling: recalculates number of pings based on the previous faults, traffic or volume. Number of packets N = f(1)..f(e), where f is the function being used for calculating faults, traffic and volume.
Manageable VoIP Network –Voice quality measurement • MOS (Mean Opinion Score): - Subjective measurement of VoIP. - Pre selected voice sample over different media, replayed to mixed group of men and woman, who rate them from 1 to 5. 4 – 5: Toll Quality 3 – 4: Communication quality < 3 : Synthetic quality
Voice quality measurement • PSQM (Perceptual Speech Quality Measurement, ITU-T P.861): - Automated scoring process using an algorithm that enables computer-derived scores to correlate to MOS scores. - Designed for circuit-switched network and does not take into effect important parameters such as jitter and packet loss, which affect voice quality on a VOIP network adversely.
Parameter SCORE 1 2 3 4 5 Latency (ms) <50 50-75 75-100 100-200 >200 Packet/Loss (%) 0 0-1 1-2 2-3 >3 Jitter (ms) <5 5-10 10-50 50-100 >100 Voice quality measurement • PAMS (Perceptual Analysis and Measurement System): - Designed an intrusive listening speech quality assessment tool where speech quality is computed by injecting a speech like signal at one end and analysing the degraded signal at other end of the network.
Voice quality measurement • PESQ: PESQ (ITU–T P.862): - The latest standard for assessing voice quality and is expected to eventually replace PSQM. - It builds on the PSQM and PAMS algorithms by adding additional processing steps to account for signal-level differences and the identification of errors associated with packet loss.
Voice quality measurement • Delay guideline: ITU-T G.114 Acceptable Acceptable under conditions Unacceptable 0 150 400 0 – 150 ms: Good quality and no echo 151 – 400 ms: Acceptable under certain conditions and echo canceling is needed 401+: Unacceptable for real-time voice traffic and planning and testing purposes only
Quality problem detection • Interpret RTCP and RTCP XR. • Packet monitoring by Layer2 switch taping or port mirroring. • Probing and active monitoring by injecting a test packet. • SNMP, RMON or sFlow gathering.
Problem isolation procedure RTCP 1 Packet monitoring Central QoS server 2 3 Console 6 4 5 SNMP VoIP Network ALARM
Central QoS management server • Discover VoIP components/elements dynamically. • Create a topology and aggregate multiple call servers, GW, GK, MCU, SIP Servers, etc. • Collect performance/delay data from various sources. • Calculate variable polling period and injects an active packet. • Make a statistical model to use for assign QoS. • Organize elements/QoS data in the relational DBMS. • Detect voice quality problem and send an alarm to console. • Inject an active test packet to isolate the problem as per console.
Console • Display overall call quality. • Display topology and status display. • Display drill down to detail elements with MOS/PESQ. • Display real time status and quality changes. • Trigger the problem isolation procedure.
Q & A • Thank you! Any questions?