Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

VoIP Monitor and IPSLA polling architecture

I've been using a competitors IPSLA product until yesterday.
I installed VoIP monitor and setup was a breeze. I was monitoring my 3 shadow routers in 5 minutes!

This discussion is related to Call Paths.
The other IPSLA software only required IPSLA to be enabled on one device.
The other end of the call path only required RTR responder to be enabled on the router.

The RTR responder router, timestamps the UDP packets and send them back to the IPSLA (Shadow) router.
Therefore the shadow router stats include one way latency and jitter in both directions.
So in theory you can display the call path in both directions using IPSLA enabled on ony one router.
I'd like to see the return path data using just a single IPSLA router.

Here are the stats from one of our shadow routers for a test to a router with RTR responder enabled:

Round Trip Time (RTT) for       Index 13112
        Latest RTT: 196 milliseconds
Latest operation start time: 20:50:30.761 GMT Wed Jan 14 2009
Latest operation return code: OK
Over thresholds occurred: FALSE
RTT Values:
        Number Of RTT: 1000             RTT Min/Avg/Max: 195/196/199 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 1000
        Source to Destination Latency one way Min/Avg/Max: 100/100/103 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 95/96/97 milliseconds
        Source to Destination Latency one way Sum/Sum2: 100544/10109402
        Destination to Source Latency one way Sum/Sum2: 96076/9230826
Jitter Time:
        Number of Jitter Samples: 999
        Source to Destination Jitter Min/Avg/Max: 1/1/3 milliseconds
        Destination to Source Jitter Min/Avg/Max: 1/1/2 milliseconds
        Source to destination positive jitter Min/Avg/Max: 1/1/3 milliseconds
        Source to destination positive jitter Number/Sum/Sum2: 220/234/268
        Source to destination negative jitter Min/Avg/Max: 1/1/3 milliseconds
        Source to destination negative jitter Number/Sum/Sum2: 222/234/260
        Destination to Source positive jitter Min/Avg/Max: 1/1/2 milliseconds
        Destination to Source positive jitter Number/Sum/Sum2: 188/195/209
        Destination to Source negative jitter Min/Avg/Max: 1/1/2 milliseconds
        Destination to Source negative jitter Number/Sum/Sum2: 181/194/220
        Interarrival jitterout: 0       Interarrival jitterin: 0
Packet Loss Values:
        Loss Source to Destination: 0           Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 13
MOS score: 4.00
Number of successes: 13
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

As a rule we don't enable IPSLA monitor tests on our production routers, we use dedicated shadow routers instead. In this case we can only see the call path stats in one direction, even though IPSLA stats are available for them in both directions.

What are the chances that VoIP monitor will be updated to support this architecture as well?

Find more posts tagged with

ipsla_configure

ip_sla_manager

Accepted answers

All comments

mcbridea

Hi Art,

This is an interesting use case. I don't have very many people asking for this type of flexibility but I can see it would be very useful. I'll add it to the roadmap but no commitment to dates or releases at this point.

Andy

Network_Guru

Further to this, I'd like to note an issue with the MOS score charts.

Looking at this chart, there are 2 things wrong:

1) As noted in other threads, 95th percentile is not an average, and this word should not appear below this chart
(I noticed this is fixed in NPM charts, but not in the VoIP monitor module)

2) 95th Percentile for MOS scores is meaningless. A meaningful score would be a 5th percentile.
How low did the MOS value get?
This is what VoIP degradation is based on.

Johnvoip

VoipSipSdk

I am now looking for voip solutions. And found information about Voip sdk.
According to their website www.voipsipsdk.com
Voip sdk is based on IETF standards (SIP, STUN, etc.), so it should be compatible with other standard based products such as Asterisk, OpenSER other.

They have all features I need:
# Dynamically loadable codecs
# Registrar support
# Play wav files into conversation
# Record conversation into file
# Hold/Retrieve call
# Forward Call (Blind Call Transfer)
# Transfer Call (Attended Transfer)
# Mute Sound
# VPN support
# Noise reduction
# Auto gain
# Jitter buffer parameters
# Samples on Delphi, C#, VB, VB.NET, C++ 2005, C++ 6.0, HTML (SIP ActiveX)
# Windowless samples on C++ and .NET
# DTMF
# Adaptive silence detection
# Adaptive jitter buffer
# STUN support
# Comes as ActiveX control

But before I will download the evaluation version I would like to hear other people experience.

bschurr

I just loaded a trial version of IP SLA Manager in our lab and am trying to collect the data from our shadow router. We have the same type of architecture with shadow routers located at our node locations. Currently we send the data to another monitoring device for display, but I have not been able to get it to display in Orion.

I was under the impression that I just need to pull SNMP and collect the data I needed from the MIB, but I am not seeing any of the ip sla monitor sessions showing up as resources. Can you shed some light on the process of adding a shadow router. Do I need to have RW capabilities? Other that UDP 161 are there any ports that need to be enabled through a firewall?

chris.smouse

Hi bschurr -

You will need RW capabilities on the shadow router if you plan to create IPSLA operations via SNMP from IPSLA Manager.

but I am not seeing any of the ip sla monitor sessions showing up as resources.

Not sure what you mean here. Are you saying you have created IPSLA operations on your shadow router and they are not reporting any statistics?

If you can provide us more specifics on what you're trying to accomplish, that would help. Is your shadow router on the same subnet as your regular routers, and can your Orion server access the shadow router?