Ensuring QoS in Your VoIP Development
Upcoming SlideShare
Loading in...5
×
 

Ensuring QoS in Your VoIP Development

on

  • 543 views

 

Statistics

Views

Total Views
543
Views on SlideShare
543
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ensuring QoS in Your VoIP Development Ensuring QoS in Your VoIP Development Presentation Transcript

  • Ensuring QoS in Your VoIP Development Choon Shim CTO and Senior VP of Engineering [email_address] , 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
  • Roots of the problems
    • 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.
  • 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
    29.4 87.2 110.4 Full duplex 78.4 174.4 220.8 Half duplex G.729 (20 ms) G.711 (20 ms) G.711 (10 ms) Link Type (Sample time)
  • 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 Switch Router T1/E1 UPS GK GW TE Bridge Analog Environ Server Management Server SNMP Trap Email/Pager Carrier console VoIPm Console
  • 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):
    • - A utomated 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.
  • 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.
    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
    • 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 Central QoS server RTCP Packet monitoring SNMP ALARM Console VoIP Network 1 2 3 4 5 6
  • 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?