CODEWITHSUNDEEP
iphoneiosnetwork-programmingvoip
gavdotnet
gavdotnet

Reputation: 2224

How can I determine the quality of a voip call before it starts?

I need to check whether or not a device can support voip calls at a certain level of quality. My approach (of which I accept there may be a better one) is to conduct an Internet connection speed test on a user's iOS device immediately before the call is placed. The speed test should, as accurately as possible, determine whether the impending voip call will be of good or poor quality.

The voip call includes live video (similar to Skype).

I'm aware of the following techniques to measure connection speed:

  1. Download or upload a file and measure how long it takes.

    as outlined here. Will measuring download or upload speed give an accurate picture of what voip call quality will be like for the immediate call? Also, files may be cached or speeds may even be throttled by the ISP.

  2. Use ICMP packets (ie. ping) a reliable server (eg. google.com).

    One potential problem with this approach is that (I've heard that) some routers are configured to give ICMP packets a lower priority than others. Therefore they cannot be used as an accurate measure of bandwidth/speed/reachability etc. Is this so?

Is measuring network connection speed an effective way to predict voip call quality? If so, what is an effective and quick (ie. less than 3 seconds) way to measure Internet connection speed for this purpose?

Upvotes: 2

Views: 1652

Answers (1)

ChuckCottrill
ChuckCottrill

Reputation: 4444

The actual data of a VoIP call is carried over RTP, which really only takes 24-64Kbps (depending upon codec) and requires UDP addresses going each way. Occasional RTCP packets are sent to report status, metrics, etc, but are not really needed.

SIP is used for call setup and teardown.

The RTCP packets carry (minimal) call quality metrics.

Several parameters influence call quality, including choice of codec, available bandwidth, network latency, packet loss (RTP is over UDP so no retransmission), and jitter (inter-packet arrival delay, out of order delivery).

(Cicso) Switches implement RED, a technique to reduce queue depth by randomly discarding network packets. For TCP network connections, that is acceptable, because TCP has retransmission through a sliding window protocol. And many UDP based protocols implement application retransmission. But RTP does not afford that luxury. So random discard of voice packets impairs the connection quality. One solution to RED would be to tunnel VoIP over a TCP connection, but that wasn't the choice made.

Congested networks are a huge source of VoIP call quality problems, and that can be measured during the initial few seconds of a call. Dropped packets due to jitter and delayed packets (high network latency) are two main causes of call quality degredation. I worked on a VoIP quality of service monitor system, and we observed the worst calls had high jitter and high latency (above ~70ms is bad). Avoid high latency, congested networks. Choice of coded can have a huge impact on quality. Higher compression codecs lose more to packet loss than less 'efficient' codecs, so pick a codec that uses higher bandwidth (good luck).

IP networks need QoS guarantees to provide best VoIP quality. And until TCPIP is redefined to include QoS, VoIP will have (potential) problems.

Your approach is close. But you want to measure:

  1. UDP
  2. Packet loss
  3. Congestion
  4. Latency
  5. Packet jitter

You need to timestamp and number your packets, and detect high latency, interarrival jitter, avoid measuring over TCP (packet retransmission will skew your quality numbers, and TCP reorders packets, even though it introduces delay). You also want to know the quality on both. You might find that codec selection would be a huge factor in improving the calls.

The company I worked for building the monitor (Telchemy) licensed their VQMon software as a product to measure quality, so the tool you want already exists.

Upvotes: 3

Related Questions