[VoiceOps] Quality: Required. QoS: Never.

[Mark R Lindsey]

(Notes below from the SIPNOC 2014 BOF on VoIP quality over the public Internet.)

1. Introduction

Customers want quality voice and video. This can be readily provided
using engineered links -- i.e., paths that prioritize, reserve, or
otherwise guarantee that the real-time voice and video packets will
be delivered within the required timing constraints. But because of
the wonderful cost reductions of Internet bandwidth, customers would
prefer to get the quality voice and video services across the Internet,
and not be forced to buy a special link to get that quality.

At SIP Forum's SIPNOC 2014, we held a BoF "Birds of a Feather" session and
Google Hangout to discuss ways to make Voice and Video via the Internet
have better quality. We also had a conversation on the VoiceOps mailing
list about this subject.

The notes below reflect the comments made by folks in both fora.

Editor: Mark R Lindsey, SMTS with ECG, lindsey at e-c-group.com,
tel:+12293160013 http://ecg.co/lindsey


2. Terminology

"Customer" refers to the customer of the ITSP.

"CPE" (Customer Premise Equipment) refers to equipment installed a
customer's site. In the context of this discussion, all CPE is for use
exclusively by the Customer at whose site it is hosted.

"ISP" refers to Internet Service Providers. In this context, both the
ITSP and the Customer purchase service from an ISP to connect to the
Internet and thereby communicate with one another over the Internet.

"ITSP" refers to an "Internet Telephony Service Provider"; but in
general it's any provider of Real Time, Interactive, N-way (N>1), Human
media sessions.

"OTT" (Over the Top) and "BYOB" (Bring Your Own Broadband) refer to a
method of delivering servie where connection between the ITSP and the
Customer is done over the public Internet, as opposed to a link where
guarantees of performance are provided.

3. Miscellaneous Observations

3.1. Some methods of improving the media experience across the Internet
are going to be more expensive than others. Some are thus going to be
most applicable to larger customer sites, while others can be efficiently
applied even to individual users/customers.

3.2. One major OTT/BYOB carrier reported seeing that some major companies
(apparently ISPs) appears to be de-prioritizing VoIP traffic, making it
work worse than typical IP traffic.

4. Detection methods

4.1. Individual Calls

4.1.1. RTCP or RTCP-XR received from individual calls

4.1.2. Monitoring of packets via a box in the middle (e.g., ITSP Border
Element / SBC, or CPE edge device)

4.1.3. RTCP Extended data sent via SIP

4.2. Customer Sites

4.2.1. ICMP ping of customer all sites to detect which customer sites
are having problems (and by extension, which customers' ISPs are having
problems).

4.2.2. Test calls to the customer site, e.g., to a loopback function

5. Quality Improvement Techniques

5.1. Involving multiple ISPs

5.1.1. Multiple ISPs or IP Peering Points at ITSP

5.1.1.1. Maximum number to increase number of options to reach
customers.

5.1.1.2. Ability to manually tune routing to an ITSP customer that has
a static public IP address, to avoid a particular ISP that is having
problems. Example: End customer is on ISP 3. ITPS uses ISP
3 and ISP 3. Dispute or routing problem between ISP 3 and ISP 1 causes
poor performance. So ITSP changes routing so that traffic destined to
customer always exits ITSP network via ISP 2.

5.1.1.3. Advertise smaller blocks of IP space with BGP path preferences
to control how customers' traffic enters the network; i.e., try to groom
all VoIP traffic to enter on the ITSP's via the better ISP du jour.

5.1.1.4. On the ITSP border elements (e.g., SBC) assign different IP
addresses that route in exclusively via a single ISP. E.g., SBC has
customer-facing IP 1 that is only advertised via ISP 1, and a separate
customer-facing IP 2 that is advertised only via ISP 2. Then configure
Customer A SIP CPE to REGISTER via either IP 1, with SRV failover to IP
4. Then for Customer B, it may be better for them to register via IP 2
with failover to IP 1.

5.1.2. Multiple ISPs at Customer Premise. Use one ISP as a preferred
option at the customer premise, then failover to another if the first
one is too degraded as measured by SLA monitoring in the CPE router.

5.2. Codecs

5.2.1. Traditional codecs

5.2.2.1. G.729 instead of G.722 or G.711, simply to reduce the bandwidth
required.

5.2.2. Adaptive Codecs

5.2.2.1. AMR / AMR-WB. Popular with vendors to implement, but relatively
expensive because of Intellectual Property Fees.

5.2.2.2. Opus. Generally considered equal or superior to AMR-WB, but
newer and thought to be considered immature by vendors.

5.2.3. Media Transport tricks.

5.2.3.1. Packetization Time (ptime) changes. It *might* be possible to
reduce packet loss by reducing the packets/second rate of a media stream,
but any reduction in packet loss will bring a proportionate increase in
payload delivery. Much of the equipment in use won't support ptime != 20 ms.

5.2.3.2. Media over TCP. WebRTC includes Media over TCP. There
are studies showing that media over TCP, e.g., in TCP-based VPNs,
improve something. But this probably means that jitter buffers are
maximized. The group's outspoken views are that that
using today's codecs over TCP is likely to make delay much
worse. [http://www.voip-info.org/wiki/view/VOIP+and+VPN] claims that
a study by Sirrix (a German security firm) reported no ill effects of
VPNs on VoIP, but the study is no longer online.

5.3. Changing call path mid-call.  Detect the problem (e.g., via RTCP)
then re-INVITE to change the media flow to another IP address that uses
a different routing path from the customer.

5.4. Customer Premise Equipment

5.4.1. Use a device at Customer Premise that can prioritize Voice
traffic as it exits the VoIP CPE going toward PE router. This can be
done with an application-aware device (SIP ALG) or via DSCP marking
and prioritization.

5.4.1. Use a device at Customer Premise that can manage the PE-to-CE
(ITSP to CPE) TCP flows to ensure that TCP flows slow down enough to allow
the RTP flows. This likely requires an ALG, or, at least, a device that
can recognize the distinct RTP flows that it is trying to protect.

5.5. Traditional QoS

5.5.1. Use QoS prioritization in the core of the network.

5.5.2. Use QoS prioritization at the customer premise, even though the
link between ITSP and Customer is not protected. And use a QoS policy
at the customer premise that matches what's in use in the core.

5.5.3. Strip DSCP markings as packets arrive from untrusted networks,
i.e., ISPs and customer sites outside your control.

5.6. Miscellaneous Recommendations.

5.6.1. Avoid messing with the media as much as possible; in particular
minimize codec conversions.

5.6.2. Stay on the same network end-to-end, whenever possible. E.g., if
you have customers that connect to you using Comcast at their customer
premise, then try to connect the ITSP border element to Comcast.

6. Contributors

     Alex Balashov, Everiste Systems

     Chris Boyd, Gizmo Partners

     Chris Brown, ACS Alaska

     Frank Bulk, Premier Communications

     Ryan Delgrosso

     Jim Gast, TDS Telecom

     Gavin Henry, Suretec

     Jesse Howard, Shoretel

     Faisal Imtiaz, Snappy Telecom

     Eric Jastak

     Brandon Lehmann, BitRadius

     Mark R Lindsey, ECG

     Anthony Orlando

     Gernot Scheichl, Edgewater Networks

     Dan York

     Other anonymous participants in the SIPNOC BoF Session, June
     11, 2014.

     Other anonymous participants in the VoiceOps discussion,
     June, 2014