1 / 24

Ensuring QoS in Your VoIP Development

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.

christopherruiz
Download Presentation

Ensuring QoS in Your VoIP Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ensuring QoS in Your VoIP Development Choon Shim CTO and Senior VP of Engineering choon@qovia.com , http://www.qovia.com

  2. 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

  3. 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

  4. 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

  5. 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

  6. To reduce bandwidth requirement • Bandwidth requirement by codec and duplex • cRTP reduces 2-5 bytes overhead • VAD reduces up to 50% payload

  7. 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

  8. 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)

  9. 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.

  10. 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

  11. 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.

  12. 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.

  13. 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

  14. 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.

  15. 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

  16. 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.

  17. 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.

  18. 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.

  19. 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

  20. 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.

  21. Problem isolation procedure RTCP 1 Packet monitoring Central QoS server 2 3 Console 6 4 5 SNMP VoIP Network ALARM

  22. 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.

  23. 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.

  24. Q & A • Thank you! Any questions?

More Related