Audio Codec Selection:

What is a Codec?

• Compresses audio for transmission
• Balances quality vs bandwidth
• Both sides must support same codec
• Negotiated at call establishment

Available Audio Codecs:

G.711u (PCMU) - Uncompressed Quality

• Bandwidth: ~87 Kbps (64 Kbps + overhead)
• Quality: Excellent (toll quality)
• Latency: Very low
• CPU: Minimal
• Use Case: LAN, high-bandwidth connections, best quality
• Compatibility: Universal support

G.711a (PCMA) - European Standard

• Bandwidth: ~87 Kbps
• Quality: Excellent (identical to G.711u)
• Difference: Companding algorithm (EU standard)
• Use Case: Same as G.711u, especially in Europe
• Compatibility: Universal support

G.729 - Low Bandwidth

• Bandwidth: ~31 Kbps (8 Kbps + overhead)
• Quality: Good (near toll quality)
• Latency: Moderate
• CPU: Moderate
• Use Case: Bandwidth-constrained links, many concurrent calls
• Compatibility: Widely supported
• License: May require licensing fees

Opus - Modern Adaptive

• Bandwidth: 6-510 Kbps (adaptive)
• Quality: Excellent (better than G.711 at high bitrate)
• Latency: Very low
• CPU: Low-moderate
• Use Case: Modern systems, variable bandwidth, best quality/bandwidth ratio
• Compatibility: Newer systems (check provider support)

G.722 - Wideband

• Bandwidth: ~87 Kbps
• Quality: HD voice (7 kHz vs 3.4 kHz)
• Latency: Low
• CPU: Low
• Use Case: HD voice, conference calls
• Compatibility: Moderate (growing)

Video Codec Selection:

H.264 - Standard Video

• Bandwidth: 512 Kbps - 2 Mbps
• Quality: Good to excellent
• Resolution: Up to 1080p
• Compatibility: Universal
• Use Case: Standard video calls

VP8 - Open Standard

• Bandwidth: Similar to H.264
• Quality: Comparable to H.264
• Resolution: Up to 1080p
• Compatibility: WebRTC, modern systems
• License: Royalty-free

VP9 - Improved Efficiency

• Bandwidth: 25-50% less than H.264
• Quality: Better than VP8
• Resolution: Up to 4K
• Compatibility: Newer systems
• Use Case: Bandwidth-constrained video

Video Considerations:

• Most trunks don't support video (voice only)
• Check provider capabilities
• Requires significantly more bandwidth
• May need separate video-enabled trunk

Codec Negotiation & Priority:

How Codec Selection Works:

1. Your PBX offers list of codecs (in priority order)
2. Provider responds with matching codecs
3. First mutually supported codec is used
4. No match = call fails

Configuring Priority:

Priority 1: Opus (best quality/bandwidth if supported)
Priority 2: G.711u (best quality, high bandwidth)
Priority 3: G.711a (best quality, EU)
Priority 4: G.729 (low bandwidth fallback)

Different Scenarios:

High Bandwidth, Best Quality:

1. G.711u
2. G.711a
3. Opus
(Skip G.729)

Low Bandwidth, Cost Savings:

1. G.729
2. Opus (adaptive, might use less)
3. G.711u (fallback)

Modern Systems:

1. Opus (adaptive, best choice)
2. G.722 (HD voice)
3. G.711u (fallback)

Maximum Compatibility:

1. G.711u (everyone supports)
2. G.711a (almost everyone)
3. G.729 (widely supported)
4. Opus (newer systems)

Provider-Specific:

• Some providers only support specific codecs
• Check provider documentation
• Prioritize what they support
• Test all supported codecs

Bandwidth Calculation:

Per Call Bandwidth (one-way):

G.711u/a:

Codec: 64 Kbps
IP/UDP/RTP Overhead: ~23 Kbps
Total: ~87 Kbps per call
Bidirectional: ~174 Kbps per call

G.729:

Codec: 8 Kbps
IP/UDP/RTP Overhead: ~23 Kbps
Total: ~31 Kbps per call
Bidirectional: ~62 Kbps per call

Opus (adaptive):

Codec: 6-128 Kbps (variable)
Overhead: ~23 Kbps
Total: ~29-151 Kbps per call
Bidirectional: Variable based on conditions

Total Bandwidth Calculation:

G.711 Example:
10 concurrent calls = 10 × 174 Kbps = 1.74 Mbps
Add 20% buffer = 2.09 Mbps recommended

G.729 Example:
10 concurrent calls = 10 × 62 Kbps = 620 Kbps
Add 20% buffer = 744 Kbps recommended

Bandwidth Recommendations:

Small Office (1-5 concurrent calls):

• G.711: 1 Mbps minimum
• G.729: 400 Kbps minimum

Medium Office (5-20 concurrent calls):

• G.711: 5 Mbps minimum
• G.729: 2 Mbps minimum

Large Office (20-100 concurrent calls):

• G.711: 20+ Mbps minimum
• G.729: 8+ Mbps minimum
• Consider QoS and dedicated circuit

Quality vs Bandwidth Trade-off:

High Bandwidth Available:
→ Use G.711 (best quality)
→ ~87 Kbps per call

Limited Bandwidth:
→ Use G.729 (good quality)
→ ~31 Kbps per call
→ 65% bandwidth savings

Variable Bandwidth:
→ Use Opus (adaptive)
→ Adjusts to conditions
→ Best quality for available bandwidth

DTMF Transmission Methods:

What is DTMF?

• Dual-Tone Multi-Frequency
• Touch-tone keypad tones (0-9, *, #)
• Used for IVR navigation, voicemail PIN, transfers

Three Transmission Methods:

RFC2833 (RTP Event) - Recommended

• Sends DTMF as RTP events
• Separate from audio stream
• Most reliable over IP
• Standard method
• Best compatibility

SIP INFO - Alternative

• Sends DTMF in SIP INFO messages
• Out-of-band signaling
• Less common
• Used by some providers

Inband - Legacy

• DTMF tones in audio stream
• Susceptible to codec issues
• Can be distorted by compression
• Least reliable over IP
• Last resort

RFC2833 Configuration:

How It Works:

1. User presses key on phone
2. Phone detects DTMF tone
3. Converted to RTP event
4. Sent as separate RTP packets (not audio)
5. Receiving end regenerates DTMF tone

Configuration:

DTMF Mode: RFC2833
RTP Payload Type: 101 (standard)
Duration: 100-250ms

Advantages:

• Codec-independent (works with G.729)
• Reliable transmission
• Not affected by compression
• Industry standard
• Universal support

Troubleshooting:

• Verify both sides use RFC2833
• Check RTP payload type matches (usually 101)
• Ensure RTP packets not blocked by firewall
• Verify no packet loss on RTP stream

Testing:

• Call automated system (bank IVR, etc.)
• Press keys, verify detected
• Test voicemail PIN entry
• Test call transfers

SIP INFO Method:

How It Works:

1. User presses key
2. Phone detects DTMF
3. Sent as SIP INFO message
4. Out-of-band (not in RTP stream)
5. Receiving end processes INFO message

Configuration:

DTMF Mode: SIP INFO
INFO Content-Type: application/dtmf-relay
Duration: Per SIP INFO message

When to Use:

• Provider requires SIP INFO
• RFC2833 not supported
• Alternative to Inband
• Specific compatibility requirements

Advantages:

• Codec-independent
• Separate from audio
• Can carry additional info
• Works through some firewalls better

Disadvantages:

• Less universal support
• Requires SIP ALG handling
• May fail through some NAT devices
• Not as reliable as RFC2833

Troubleshooting:

• Verify SIP INFO enabled on both sides
• Check firewall allows SIP INFO messages
• Review SIP logs for INFO message delivery
• Test with provider support

Inband DTMF:

How It Works:

1. User presses key
2. Phone generates DTMF tone
3. Tone transmitted in audio stream
4. Receiving end detects tone in audio
5. Decoded back to digit

Configuration:

DTMF Mode: Inband
Codec: G.711 (required for reliability)
Detection: Tone detection algorithm

Challenges:

• Compressed codecs (G.729) distort tones
• Packet loss corrupts tones
• Echo cancellation can remove tones
• Jitter affects tone duration
• Least reliable method

When to Use:

• Legacy systems requirement
• RFC2833 and SIP INFO unavailable
• Last resort only
• Testing/troubleshooting

Requirements for Inband:

• Must use G.711 codec (uncompressed)
• Disable echo cancellation during DTMF
• Low packet loss (<1%)
• Low jitter (<20ms)
• Good network quality

Not Recommended:

• Modern VoIP systems
• G.729 or compressed codecs
• Poor network quality
• Long distance connections

Network Address Translation (NAT):

What is NAT?

• Translates private IP to public IP
• Allows multiple devices behind router
• Common in business networks
• Requires special handling for VoIP

NAT Issues with VoIP:

• SIP packets contain IP addresses in body
• RTP streams use dynamic ports
• One-way audio (can't hear caller)
• Call setup failures
• Registration issues

NAT Settings:

External IP Address:

Auto-Detect: PBX discovers public IP automatically
Manual: Enter public IP (e.g., 203.0.113.45)
When to Use: Behind NAT/router

Local Network:

Format: 192.168.1.0/24 or 10.0.0.0/8
Purpose: Defines internal network range
Why: Helps PBX distinguish internal vs external

NAT Mode:

Options: Yes, No, Auto, Force_rport
Recommended: Auto or Yes
Effect: Rewrites SIP headers for NAT traversal

Configuration Example:

NAT: Enabled
External IP: 203.0.113.45 (auto-detect)
Local Network: 192.168.1.0/24
External Media Address: Same as External IP
External SIP Address: Same as External IP

STUN and TURN Servers:

STUN (Session Traversal Utilities for NAT):

• Helps discover public IP address
• Tests NAT type
• Enables NAT traversal
• Free public STUN servers available

STUN Configuration:

STUN Server: stun.l.google.com:19302
Or: stun.thevoco.com:3478
Purpose: Discover external IP
When: Behind NAT, dynamic IP

TURN (Traversal Using Relays around NAT):

• Relays media through server
• Used when direct connection fails
• More expensive (bandwidth costs)
• Fallback when STUN insufficient

When to Use STUN/TURN:

Use STUN:

• Behind NAT
• External IP changes (DHCP)
• Symmetric NAT
• Remote workers on home networks

Use TURN:

• STUN fails
• Strict firewalls
• Symmetric NAT (both sides)
• Enterprise security policies

Configuration Priority:

1. Direct Connection (no NAT, best)
2. STUN (discover IP, good)
3. TURN (relay, acceptable)

Testing:

• Test with and without STUN
• Compare call quality
• Check if one-way audio resolved
• Monitor for issues

Firewall Port Configuration:

Required Ports:

SIP Signaling:

Protocol: UDP/TCP
Port: 5060 (unencrypted)
Port: 5061 (TLS encrypted)
Direction: Bidirectional
Requirement: Must be open

RTP Media (Audio/Video):

Protocol: UDP
Port Range: 10000-20000 (typical)
Or: 16384-32767 (alternative)
Direction: Bidirectional
Requirement: Must be open for audio

Port Forwarding Configuration:

Router/Firewall Rules:

External Port 5060 → Internal PBX IP:5060 (SIP)
External Port 10000-20000 → Internal PBX IP:10000-20000 (RTP)

Example Configuration:

PBX Internal IP: 192.168.1.100
External IP: 203.0.113.45

Rule 1 (SIP):
External: 203.0.113.45:5060
Internal: 192.168.1.100:5060
Protocol: UDP/TCP

Rule 2 (RTP):
External: 203.0.113.45:10000-20000
Internal: 192.168.1.100:10000-20000
Protocol: UDP

Port Range Sizing:

RTP uses 2 ports per call (send + receive)
10 concurrent calls = 20 ports minimum
Recommendation: 10000-20000 (10,000 ports)
Supports: ~5,000 concurrent calls

Security Considerations:

• Restrict source IPs if possible (provider IPs only)
• Use TLS (port 5061) for encryption
• Monitor for scanning/attacks
• Implement rate limiting
• Use fail2ban or similar

SIP Application Layer Gateway (ALG):

What is SIP ALG?

• Router/firewall feature
• "Helps" with SIP NAT traversal
• Modifies SIP packets automatically
• Often causes more problems than it solves

Problems with SIP ALG:

• Incorrectly rewrites SIP headers
• Corrupts SIP packets
• Breaks registration
• Causes one-way audio
• Interferes with proper NAT handling
• Inconsistent implementation across vendors

Symptoms of SIP ALG Issues:

• Registration fails intermittently
• One-way audio on some calls
• Calls drop after few minutes
• RTP packets to wrong IP
• SIP responses to wrong port

Recommendation: DISABLE SIP ALG

How to Disable:

Common Routers:

Cisco: No ip nat service sip udp port 5060
Linksys: Advanced Settings > SIP ALG > Disable
Netgear: Advanced > WAN Setup > NAT Filtering > Disable
Asus: WAN > NAT Passthrough > SIP Passthrough > Disable
pfSense: System > Advanced > Disable SIP ALG

Alternative if Can't Disable:

• Use non-standard SIP port (5061, 5062)
• Use TCP instead of UDP
• Use VPN tunnel
• Replace router with one that allows disable

After Disabling:

• Configure NAT settings in PBX properly
• Set external IP
• Configure local network range
• Test thoroughly

Quality of Service Overview:

What is QoS?

• Prioritizes VoIP traffic over other data
• Ensures voice packets delivered first
• Reduces latency, jitter, packet loss
• Essential for good call quality

Why QoS Matters:

• VoIP is real-time (delay-sensitive)
• Packet loss = choppy audio
• Jitter = inconsistent quality
• Latency = delay in conversation
• Competing traffic (downloads, streaming) affects quality

QoS Metrics:

Latency (Delay):

• Good: < 150ms
• Acceptable: 150-300ms
• Poor: > 300ms
• Target: < 100ms for excellent quality

Jitter (Variation):

• Good: < 20ms
• Acceptable: 20-50ms
• Poor: > 50ms
• Target: < 10ms for best quality

Packet Loss:

• Good: < 0.5%
• Acceptable: 0.5-1%
• Poor: > 1%
• Target: < 0.1% for excellent quality

Bandwidth:

• G.711: ~87 Kbps per call
• G.729: ~31 Kbps per call
• Rule: 2x calculated bandwidth for headroom

DSCP (Differentiated Services Code Point):

What is DSCP?

• Marks packets for priority
• Value in IP header
• Tells routers how to handle packet
• Industry standard for QoS

DSCP Values for VoIP:

Voice (RTP Audio):

DSCP: EF (Expedited Forwarding)
Value: 46 (decimal) or 0x2E (hex)
Binary: 101110
Priority: Highest
Use: Audio RTP streams

SIP Signaling:

DSCP: CS3 or AF31
Value: 24 or 26 (decimal)
Priority: High
Use: SIP registration, call setup

Video:

DSCP: AF41
Value: 34 (decimal)
Priority: High
Use: Video calls (if supported)

Configuration in PBX:

RTP DSCP: 46 (EF)
SIP DSCP: 26 (AF31)
Enable: Yes
Apply to: All VoIP traffic

Router Configuration:

Priority Queue 1 (Highest):
- DSCP EF (46) - Voice
- 30% of bandwidth minimum
- Low latency queue

Priority Queue 2:
- DSCP AF31 (26) - Signaling
- 10% of bandwidth

Normal Queue:
- All other traffic
- Remaining bandwidth

Traffic Shaping & Prioritization:

Three-Tier Priority:

Tier 1: Voice (Highest)

Traffic: RTP audio packets
DSCP: EF (46)
Bandwidth: Reserved (30% minimum)
Latency: < 10ms
Jitter Buffer: Minimal
Packet Loss: < 0.1%

Tier 2: Signaling (High)

Traffic: SIP messages
DSCP: AF31 (26)
Bandwidth: 10% reserved
Latency: < 100ms
Purpose: Call setup/teardown

Tier 3: Everything Else (Normal)

Traffic: HTTP, email, file transfers
DSCP: Default (0)
Bandwidth: Best effort
Can be delayed: Yes

Bandwidth Allocation:

Example: 10 Mbps Link

Voice (G.711, 10 calls):
Reserved: 3 Mbps (30%)
Calculated need: 1.74 Mbps
Headroom: Yes (plenty)

Signaling:
Reserved: 1 Mbps (10%)
Actual use: < 100 Kbps
Headroom: Yes

Data:
Remaining: 6 Mbps (60%)
Best effort: Yes
Note: Can use more if voice not active

Traffic Shaping Rules:

1. Voice always goes first (no exceptions)
2. Signaling second (fast call setup)
3. Data uses remaining bandwidth
4. Voice can burst beyond reserved amount
5. Data throttled if voice needs bandwidth

End-to-End QoS Implementation:

Network Layers:

Layer 1: PBX Configuration

Action: Mark packets with DSCP
Setting: RTP = EF (46), SIP = AF31 (26)
Result: Packets marked for routers

Layer 2: Access Switch

Action: Trust DSCP markings
Action: Prioritize EF traffic
Config: Priority queues by DSCP
Result: VoIP prioritized on LAN

Layer 3: Router/Firewall

Action: Enforce QoS policy
Action: Shape traffic to WAN
Config: Bandwidth allocation, priority queues
Result: VoIP prioritized over WAN

Layer 4: ISP/Carrier

Action: Honor DSCP markings (if business service)
Action: Prioritize EF traffic
Result: VoIP prioritized across internet
Note: Consumer ISPs may not honor DSCP

Implementation Steps:

Step 1: Configure PBX

Enable DSCP marking
Set RTP to EF (46)
Set SIP to AF31 (26)
Test: Capture packets, verify DSCP set

Step 2: Configure Switches

Create VoIP VLAN (optional but recommended)
Trust DSCP markings from PBX
Priority queues: EF highest
Test: Monitor queue statistics

Step 3: Configure Router

Create traffic classes (Voice, Signaling, Data)
Assign DSCP to classes
Priority queuing: Voice first
Bandwidth allocation: 30% voice minimum
Test: Monitor during peak usage

Step 4: ISP Coordination

Business internet: Request QoS support
Verify: DSCP honored across connection
Alternative: Dedicated voice circuit
Test: End-to-end latency/jitter monitoring

VLAN Segregation (Recommended):

VLAN 10: Voice (phones, PBX)
VLAN 20: Data (computers, servers)
VLAN 30: Guest (WiFi, visitors)

Benefits:
- Physical separation
- Guaranteed bandwidth per VLAN
- Enhanced security
- Easier QoS implementation

SIP Transport Protocol:

UDP (User Datagram Protocol):

Port: 5060
Overhead: Lowest
Latency: Lowest
Reliability: No built-in retransmission
Packet Loss: Can lose packets
Use Case: Standard VoIP (most common)
Best For: Stable networks, low latency required

TCP (Transmission Control Protocol):

Port: 5060
Overhead: Higher
Latency: Slightly higher
Reliability: Guaranteed delivery
Packet Loss: Automatic retransmission
Use Case: Unreliable networks, NAT issues
Best For: Traversing firewalls, long distance

TLS (Transport Layer Security):

Port: 5061
Overhead: Highest
Latency: Highest
Reliability: Guaranteed delivery
Security: Encrypted
Use Case: Security required, compliance
Best For: Sensitive industries, HIPAA, financial

Comparison:

Speed: UDP > TCP > TLS
Reliability: TLS = TCP > UDP
Security: TLS > TCP = UDP
NAT Traversal: TCP > TLS > UDP
Resource Usage: UDP < TCP < TLS

When to Use Each:

Use UDP (Default):

• Stable network
• Low latency required
• Standard configuration
• Most providers default to UDP

Use TCP:

• UDP blocked by firewall
• Traversing strict NAT
• Network packet loss issues
• Provider requires TCP

Use TLS:

• Security/compliance required
• HIPAA, financial services
• Encrypted signaling needed
• Provider offers TLS

SIP Session Timers:

What are Session Timers?

• Keep-alive mechanism for calls
• Periodic refresh during call
• Detects and cleans up stale sessions
• Prevents "zombie" calls

Configuration:

Session Expires:

Value: 1800 seconds (30 minutes) typical
Range: 300-3600 seconds
Purpose: How long before refresh needed
Recommendation: 1800 (provider default)

Minimum Session Expires:

Value: 90 seconds typical
Purpose: Shortest allowed refresh interval
Recommendation: 90-300 seconds

Session Refresher:

Options: UAC (caller), UAS (callee), Auto
Purpose: Who sends refresh
Recommendation: Auto (negotiate)

Why Session Timers Matter:

• Detects hung calls
• Frees up trunk resources
• Prevents billing issues
• Cleans up after network failures

Typical Configuration:

Session-Expires: 1800
Min-SE: 90
Refresher: UAC
Enable: Yes

Troubleshooting:

• Calls drop at exact intervals (e.g., every 30 minutes)
• Likely session timer expiration
• Increase Session-Expires value
• Verify both sides support session timers

SIP Authentication Methods:

Digest Authentication (Standard):

Method: MD5 hash
Fields: Username, password, realm, nonce
Security: Moderate (password not sent in clear)
Use: Standard SIP registration

Configuration:

Auth Username: sipuser123
Password: SecureP@ss123
Auth ID: sipuser123 (may differ from username)
Realm: sip.provider.com

IP Authentication:

Method: IP address whitelist
Fields: Source IP address
Security: Moderate (IP can be spoofed)
Use: Peer trunks, trusted networks

Configuration:

Allowed IPs: 203.0.113.45, 203.0.113.46
No credentials needed
Provider whitelists your IP

Certificate Authentication (TLS):

Method: X.509 certificates
Fields: Certificate, private key
Security: High (mutual TLS)
Use: High-security requirements

Configuration:

Client Certificate: cert.pem
Private Key: key.pem
CA Certificate: ca.pem

Best Practices:

• Use strong passwords (16+ characters, random)
• Rotate credentials periodically (annually)
• Store securely (password manager)
• Different passwords per trunk
• Monitor for auth failures (could be attacks)

Custom SIP Headers:

What are Custom Headers?

• Additional fields in SIP messages
• Provider-specific information
• Call routing hints
• Billing codes
• Custom metadata

Common Use Cases:

Account Code Header:

Header: X-Account-Code
Value: PROJECT-12345
Purpose: Billing/cost allocation

CLI Manipulation:

Header: P-Asserted-Identity
Value: <sip:[email protected]>
Purpose: Trusted caller ID

Routing Header:

Header: X-Route-Hint
Value: PREMIUM
Purpose: Priority routing

Provider-Specific:

Header: X-Provider-API-Key
Value: abc123xyz789
Purpose: Provider authentication/tracking

Configuration:

Custom Header 1:
Name: X-Account-Code
Value: {account_code}
Apply: Outbound calls

Custom Header 2:
Name: X-Department
Value: {department}
Apply: All calls

Dynamic Variables:

• {caller_id}: Caller ID number
• {called_number}: Destination number
• {extension}: Extension making call
• {timestamp}: Current timestamp
• {call_id}: Unique call identifier

Advanced: Header Manipulation:

Remove Headers:
- Remove: User-Agent (privacy)
- Remove: Server (security)

Modify Headers:
- Rewrite: Contact (NAT traversal)
- Rewrite: Via (proxy handling)

SIP Message Logging:

Enable SIP Debug:

Settings > Trunks > [Trunk] > Debug
Enable: SIP Debug
Level: Full (all messages)
Duration: 30 minutes (auto-disable)

What SIP Debug Shows:

• REGISTER messages (registration)
• INVITE messages (call setup)
• 200 OK responses (success)
• BYE messages (hangup)
• Error codes (failures)
• Full SIP headers and body

Reading SIP Messages:

Successful Registration:

REGISTER sip:provider.com SIP/2.0
→ 401 Unauthorized (challenge)
REGISTER with auth
→ 200 OK (success)
Result: Registered

Call Setup:

INVITE sip:[email protected]
→ 100 Trying
→ 180 Ringing
→ 200 OK (answered)
ACK
→ Call established

Common Error Codes:

• 401 Unauthorized: Bad credentials
• 403 Forbidden: Access denied
• 404 Not Found: Number invalid
• 408 Request Timeout: Network issue
• 480 Temporarily Unavailable: Trunk busy
• 486 Busy Here: Destination busy
• 503 Service Unavailable: Provider issue

Network Testing Tools:

Ping Test (Latency):

Tool: ping sip.provider.com
Measure: Round-trip time (RTT)
Good: < 50ms
Acceptable: 50-150ms
Poor: > 150ms
Action: Check network path, ISP quality

Traceroute (Path):

Tool: traceroute sip.provider.com
Shows: Network hops to destination
Check: Number of hops (fewer better)
Look for: Packet loss, high latency hops

Bandwidth Test:

Tool: iperf, speedtest
Measure: Available bandwidth
Calculate: Calls × codec bandwidth
Example: 10 calls × 87 Kbps = 870 Kbps minimum

Jitter Test:

Tool: VoIP quality test apps
Measure: Packet delay variation
Good: < 10ms
Acceptable: 10-30ms
Poor: > 30ms

Packet Loss Test:

Tool: Extended ping, mtr
Measure: % of packets lost
Good: < 0.5%
Acceptable: 0.5-1%
Poor: > 1%
Action: Check network equipment, ISP

DNS Lookup:

Tool: nslookup sip.provider.com
Check: DNS resolution working
Verify: Resolves to correct IP
Speed: Resolution should be < 100ms

Port Connectivity:

Tool: telnet sip.provider.com 5060
Or: netcat, nmap
Check: Port 5060/5061 reachable
Verify: No firewall blocking

Call Quality Monitoring:

MOS Score (Mean Opinion Score):

Scale: 1.0 - 5.0
5.0: Perfect (equivalent to landline)
4.0-4.5: Good (most VoIP)
3.5-4.0: Acceptable (minor issues)
< 3.5: Poor (noticeable problems)
< 2.5: Unacceptable (call quality very poor)

R-Factor:

Scale: 0 - 100
> 80: Good
70-80: Acceptable
< 70: Poor
Calculation: Based on latency, jitter, packet loss

Real-Time Metrics:

During Call:

• Current jitter
• Current packet loss
• Current latency
• Current MOS score
• Codec in use

Post-Call Reports:

Call Quality Report:
Duration: 5:23
Codec: G.711u
Avg Jitter: 8ms
Max Jitter: 23ms
Packet Loss: 0.3%
Latency: 45ms
MOS Score: 4.2 (Good)

Threshold Alerts:

Alert if:
- Jitter > 30ms
- Packet Loss > 1%
- Latency > 150ms
- MOS < 3.5
Action: Investigate, fix network

Historical Trending:

• Track quality over time
• Identify patterns (time of day, specific trunks)
• Proactive problem identification
• Capacity planning

Packet Capture Analysis:

Tools:

• Wireshark: GUI packet analyzer (most popular)
• tcpdump: Command-line capture
• tshark: Wireshark command-line
• sngrep: TUI SIP packet analyzer

Capturing VoIP Traffic:

Wireshark:

Capture Filter: port 5060 or portrange 10000-20000
Display Filter: sip or rtp
Save As: capture.pcap

tcpdump:

Command: tcpdump -i eth0 -s 0 -w voip.pcap port 5060 or portrange 10000-20000
Interface: eth0 (network interface)
Output: voip.pcap file

What to Look For:

SIP Messages:

• Registration success/failure
• Call setup sequence
• Error responses
• Header information

RTP Streams:

• Audio packets flowing
• DSCP marking (QoS)
• Packet timing (jitter)
• Packet loss

Common Issues Identified:

One-Way Audio:

Symptom: RTP flows one direction only
Cause: NAT/firewall blocking return path
Evidence: No RTP packets in reverse direction

High Jitter:

Symptom: Irregular packet spacing
Cause: Network congestion, no QoS
Evidence: RTP timestamps show high variance

Packet Loss:

Symptom: Missing RTP sequence numbers
Cause: Network congestion, bad equipment
Evidence: Gaps in RTP sequence numbers

DSCP Verification:

Check: IP header DSCP field
Expected: 46 (EF) for RTP audio
Actual: Check if marked correctly
Issue: If 0, QoS marking not working