For Packet Voice to be a realistic replacement for standard public
switched telephone network (PSTN) Telephony services, the received quality of
Packet Voice must be comparable to that of basic telephone services. This means
consistently high-quality voice transmissions. Like other real-time
applications, Packet Voice has a wide bandwidth and is delay sensitive. For
voice transmissions to be intelligible (not choppy) to the receiver, voice
packets cannot be dropped, excessively delayed, or suffer varying delay
(otherwise known as jitter). This document describes various Quality of Service
(QoS) considerations that help troubleshoot choppy voice issues. The main
reasons for choppy voice problems are lost and delayed voice packets.

The information in this document applies to all Cisco voice gateways
software and hardware versions.

The information presented in this document was created from devices in
a specific lab environment. All of the devices used in this document started
with a cleared (default) configuration. If you are working in a live network,
ensure that you understand the potential impact of any command before using
it.

Choppy voice quality is caused by voice packets being either variably
delayed or lost in the network. When a voice packet is delayed in reaching its
destination, the destination gateway has a loss of real-time information. In
this event, the destination gateway must predict what the content of the missed
packet can possibly be. The prediction leads to the received voice not having
the same characteristics as the transmitted voice. This leads to a received
voice that sounds robotic. If a voice packet is delayed beyond the prediction
capability of a receiving gateway, the gateway leaves the real-time gap empty.
With nothing to fill up that gap at the receiving end, part of the transmitted
speech is lost. This results in choppy voice. Many of the choppy voice issues
are resolved by making sure that the voice packets are not very delayed (and
more than that, not variably delayed). Sometimes, voice activity detection
(VAD) adds front-end clipping to a voice conversation. This is another cause of
choppy (or clipped) voice.

The various sections in this document show how to minimize the instance
of choppy voice. Most of these measures require assuring the introduction of
minimum jitter in your voice network.

Before you consider applying any measures for minimizing jitter,
provision sufficient network bandwidth to support real-time voice traffic. For
example, an 80 kbps G.711 VoIP call (64 kbps payload + 16 kbps header) sounds
poor over a 64 kbps link because at least 16 kbps of the packets (which is 20
percent) are dropped. The bandwidth requirements vary based on the codec used
for compression. Different codecs have different payloads and header
requirements. Usage of VAD also affects the bandwidth requirement. If Real Time
Protocol (RTP) header compression (cRTP) is used, it can further lower the
bandwidth requirement.

For example, the bandwidth required for a voice call using the G.729
codec (default 20 byte payload) with cRTP, is like this:

There are two important components in prioritizing voice. The first is
classifying and marking interesting voice traffic. The second is prioritizing
the marked interesting voice traffic. The two subsections here discuss various
approaches to classifying, marking, and prioritizing voice.

Classification and Marking

In order to guarantee bandwidth for VoIP packets, a network device must
be able to identify the packets in all the IP traffic that flows through it.
Network devices use the source and destination IP address in the IP header, or
the source and destination UDP port numbers in the UDP header, to identify VoIP
packets. This identification and grouping process is called classification. It
is the basis for providing any QoS.

Packet classification can be processor intensive. Therefore,
classification needs to be done as far out towards the edge of the network as
possible. Because every hop still needs to make a determination on the
treatment a packet should receive, you need to have a simpler, more efficient
classification method in the network core. This simpler classification is
achieved through marking or setting the Type of Service (ToS) byte in the IP
header. The three most significant bits of the ToS byte are called IP
Precedence bits. Most applications and vendors currently support setting and
recognizing these three bits. Marking is evolving so that the six most
significant bits of the ToS byte, called the Differentiated Services Code Point
(DSCP), can be used. Refer to the Request for Comments (RFC).

Differentiated Services (DiffServ) is a new model in which traffic is
treated by intermediate systems with relative priorities based on the ToS
field. Defined in RFC 2474 and
RFC 2475, the
DiffServ standard supersedes the original specification for defining packet
priority described in RFC 791. DiffServ increases the number of definable priority
levels by reallocating bits of an IP packet for priority marking. The DiffServ
architecture defines the DiffServ field. It supersedes the ToS byte in IP V4 to
make Per-Hop Behavior (PHB) decisions about packet classification and traffic
conditioning functions such as metering, marking, shaping, and policing. In
addition to the previously mentioned RFCs,
RFC 2597
defines the Assured Forwarding (AF) classes. This is a breakdown of the DSCP
fields. For more information on DSCP, refer to
Implementing
Quality of Service Policies with DSCP.

In the example above, any VoIP call that matches the
dial-peer voice 100 voip command has all of its
voice payload packets set with IP Precedence 5. This means that the three most
significant bits of the IP ToS byte are set to 101.

In the example above, any VoIP call that matches the
dial-peer voice 100 voip command has all of its
media payload packets (voice packets) set with Expedited Forwarding (EF) bit
pattern 101110. All the signaling packets are set with AF bit pattern
011010.

Note: The ip qos dscp command is supported since
Cisco IOS® Software Release 12.2(2)T. The IP Precedence is no longer available
in Cisco IOS Software Release 12.2T. However, the same is achieved by the
ip qos dscp command. IP precedence 5 (101) maps to
IP DSCP 101000. For more information, refer to
Classifying
VoIP Signaling and Media with DSCP for QoS.

Modular QoS CLI to Classify and Mark Packets

The recommended classification and marking method to use is the modular
QoS CLI. This is a template-based configuration method that separates the
classification from the policy. This allows multiple QoS features to be
configured together for multiple classes. Use a
class-map command to classify traffic based on
various match criteria and a policy-map command to
determine what needs to happen to each class. Apply the policy to incoming or
outgoing traffic on an interface by issuing the
service-policy command. This configuration example
shows how to use modular QoS CLI to classify and mark packets:

In this configuration example, any traffic that matches Access Control
List (ACL) 100 is classified as "class voip" and set with IP Precedence 5. This
means that the three most significant bits of the IP ToS byte are set to 101.
ACL 100 matches the common UDP ports used by VoIP. Similarly ACL 101 matches
H.323 signaling traffic (Transmission Control Protocol (TCP) port 1720). All
other traffic is set with IP Precedence 0. The policy is called "mqc". It is
applied to incoming traffic on Ethernet 0/0.

Prioritizing

After every hop in the network is able to classify and identify the
VoIP packets (either through port/address information or through the ToS byte),
those hops then provide each VoIP packet with the required QoS. At that point,
configure special techniques to provide priority queuing to make sure that
large data packets do not interfere with voice data transmission. This is
usually required on slower WAN links where there is a high possibility of
congestion. Once all the interesting traffic is placed into QoS classes based
on their QoS requirements, provide bandwidth guarantees and priority servicing
through an intelligent output queuing mechanism. A priority queue is required
for VoIP.

Note: Use any queuing mechanism that effectively gives VoIP high priority.
However, Low Latency Queuing (LLQ) is recommended because it is flexible and
easy to configure.

LLQ uses the modular QoS CLI configuration method to provide priority
to certain classes and to provide guaranteed minimum bandwidth for other
classes. During periods of congestion, the priority queue is policed at the
configured rate so that the priority traffic does not use up all the available
bandwidth. (If the priority traffic monopolizes the bandwidth, it prevents
bandwidth guarantees for other classes from being met.) If you provision LLQ
correctly, the traffic that goes into the priority queue should never exceed
the configured rate.

LLQ also allows queue depths to be specified to determine when the
router needs to drop packets if there are too many packets that wait in any
particular class queue. There is also a
class-default command that is used to determine
treatment of all traffic not classified by a configured class. The
class-default is configured with a fair-queue
command. This means that each unclassified flow is given an approximately equal
share of the remaining bandwidth.

In this example, any traffic that matches ACL 100 is classified as
"class voip" (meaning voice traffic). It is given a high priority up to 32
kbps. ACL 100 matches the common UDP ports used by VoIP. Access-list 101
matches the H.323 signaling traffic (TCP port 1720). Class data1 matches web
traffic (TCP port 80 as seen in Access List 102) and guarantees 64 kbps. Class
data2 matches Telnet traffic (TCP port 23 as seen in ACL 103) and guarantees 32
kbps. The default class is configured to give an equal share of the remaining
bandwidth to unclassified flows. The policy is called "llq". It is applied to
outgoing traffic on Serial1/0, which has a total bandwidth of 256 kbps.

Note: By default, the total guaranteed bandwidth and priority bandwidth for
all classes needs to be less than 75 percent of the interface bandwidth. Modify
this percentage by issuing the max-reserved bandwidth
interface command.

This table compares different software queuing mechanisms with their
respective benefits and limitations.

Software Queuing Mechanism

Description

Benefits

Limitations

First-In-First-Out (FIFO)

Packets arrive and leave the queue in exactly the same
order.

Simple configuration and fast operation.

No priority servicing or bandwidth guarantees
possible.1

Weighted Fair Queuing (WFQ)

A hashing algorithm that flows into separate queues where weights
are used to determine how many packets are serviced at a time. You define
weights by setting IP Precedence and DSCP values.

Simple configuration. Default on links less than 2
Mbps.

No priority servicing or bandwidth guarantees
possible.1

Custom Queuing (CQ)

Traffic is classified into multiple queues with configurable
queue limits. The queue limits are calculated based on average packet size,
Maximum Transmission Unit (MTU), and the percentage of bandwidth to be
allocated. Queue limits (in number of bytes) are de-queued for each queue.
Therefore it provides the allocated bandwidth statistically.

Has been available for a few years. It allows approximate
bandwidth allocation for different queues.

No priority servicing is possible. Bandwidth guarantees are
approximate. There are a limited number of queues. Configuration is relatively
difficult.1

Priority Queuing (PQ)

Traffic is classified into high, medium, normal, and low priority
queues. The high priority traffic is serviced first, followed by medium, normal
and low priority traffic.

Modular QoS CLI is used to classify traffic. Classified traffic
is placed into reserved bandwidth queues or a default unreserved queue. A
scheduler services the queues based on weights so that the bandwidth guarantees
are honored.

Similar to LLQ, except that there is no priority queue. Simple
configuration and ability to provide bandwidth guarantees.

Modular QoS CLI with priority queue is used to classify traffic.
Classified traffic is placed into a priority queue, reserved bandwidth queues,
or a default unreserved queue. A scheduler services the queues based on weights
so that the priority traffic is sent first (up to a certain policed limit
during congestion) and the bandwidth guarantees are met.

Simple configuration. Ability to provide priority to multiple
classes of traffic and give upper bounds on priority bandwidth utilization. You
can also configure bandwidth guaranteed classes and a default
class.

No mechanism to provide multiple levels of priority yet, all
priority traffic is sent through the same priority queue. Separate priority
classes can have separate upper priority bandwidth bounds during congestion.
However, sharing of priority queue between applications can potentially
introduce jitter.4

Even if queuing works at its best and prioritizes voice traffic, there
are times when the priority queue is empty and a packet from another class is
serviced. Packets from guaranteed bandwidth classes must be serviced based on
their configured weight. If a priority voice packet arrives in the output queue
while these packets are being serviced, the voice packet can wait a significant
amount of time before it is sent. Voice packets experience serialization delay
when they have to wait behind larger data packets.

Serialization delay can introduce the worst form of jitter for voice
packets. If the voice packets have to wait behind a data packet that is as
large as 1500 bytes, on a slower link, this translates to a huge delay. The
serialization delay is vastly different if the data packet is 80 bytes, as
shown in this example:

Therefore, a voice packet potentially has to wait up to 187.5 ms before
it is sent if it gets stuck behind a single 1500-byte packet on a 64 kbps link.
On the other hand, another voice packet has to wait for only 10 ms at the
destination gateway. This results into a huge jitter that occurs due to the
variance in the inter-packet delay. On the originating gateway, voice packets
are usually sent every 20 ms. With an end-to-end delay budget of 150 ms and
strict jitter requirements, a gap of more than 180 ms is unacceptable.

Introduce a mechanism of fragmentation that ensures that the size of
one transmission unit is less than 10 ms. Any packets that have more than 10 ms
serialization delay need to be fragmented into 10 ms chunks. A 10 ms chunk or
fragment is the number of bytes that is sent over the link in 10 ms. Calculate
the size by using the link speed, as shown in this example:

It takes 10 ms to send an 80-byte packet or fragment over a 64 kbps
link.

In case of multiple ATM or Frame Relay Permanent Virtual Circuits
(PVCs) on a single physical interface, configure fragmentation values (on all
PVCs) based on the PVC that has the lowest bandwidth available. For example, if
there are three PVCs that have a guaranteed bandwidth of 512 kbps, 128 kbps,
and 256 kbps, then configure all three PVCs with a fragment size of 160 bytes
(the lowest speed is 128 kbps that requires a 160-byte fragment size). These
values are recommended for different link speeds:

Note: No fragmentation is required if the fragment size is larger than the
link MTU size. For example, for a T1 link with a 1500-byte MTU, the fragment
size is 1920 bytes. Therefore, no fragmentation is required. The packet
fragmentation size should never be lower than the VoIP packet size. Do not
fragment VoIP packets. Fragmenting these packets causes numerous call setup and
quality issues.

There are currently three link fragmentation and interleaving
mechanisms available. For further explanation of various delays introduced in a
packet network, refer to
Understanding
Delay in Packet Voice Networks. This table lists their benefits and
limitations:

Link Fragmentation and Interleaving (LFI)
Mechanism

Description

Benefits

Limitations

MTU fragmentation with WFQ

Interface level command to change MTU size or IP MTU size. Used
to fragment large IP packets to specified MTU size. LFI uses WFQ to interleave
real-time packets in between the fragments.

Simple configuration.

Fragments are reassemble only by the receiving application.
Therefore, inefficient use of the network. Only IP packets with the Do not
Fragment (DF) bit not set can handle fragmentation well. Highly processor
intensive. Not recommended.

Multilink Point-to-Point Protocol (MLPPP) LFI

On point-to-point serial links, MLPPP must first be configured,
then a fragmentation size must be set in ms. Interleaving must also be enabled
on the multilink interface.

Packets are fragmented on one end of the link and reassembled at
the other. Several links can be combined to act as a large virtual
pipe.

Only available on links configured for PPP. Solutions for PPP
over Frame Relay or PPP over ATM are also supported in Cisco IOS Software
Release 12.1(5)T or later.

Frame Relay Fragmentation (FRF.12)

On Frame Relay PVCs, the frame-relay
traffic-shaping command must be enabled and a fragmentation size
set under the map-class.

Packets are fragmented on one end of the PVC and reassembled at
the other.

Only available on Frame Relay PVCs with the
frame-relay traffic-shaping command
enabled.

A regular voice conversation consists of several moments of silence. A
typical voice conversation consists of 40 to 50 percent silence. Since there is
not any voice going through the network for 40 percent of a voice call, some
bandwidth can be saved by deploying VAD. With VAD, the gateway looks out for
gaps in speech. It replaces those gaps with comfort noise (background noise).
Thus, an amount of bandwidth is saved. However, there is a trade-off. There is
a small time (in order of milliseconds), before the codecs detect speech
activity followed by a period of silence. This small time results in the
front-end clipping of received voice. To avoid activation during very short
pauses and to compensate for clipping, VAD waits approximately 200 ms after
speech stops before it stops transmission. Upon restarting transmission, it
includes the previous 5 ms of speech along with the current speech. VAD
disables itself on a call automatically if ambient noise prevents it from
distinguishing between speech and background noise. However, if the bandwidth
is not an issue, turn the VAD off.

Tune VAD Parameters

There are two parameters that dictate the functioning of VAD. These are
the music-threshold and voice
vad-time commands.

music-threshold

An initial threshold is decided which governs when VAD needs to become
active. This is controlled by defining the music-threshold
threshold_value command on a voice-port,
as shown in this example. The range for this is from -70 Decibels Per Milliwatt
(dBm) to -30 dBm. The default value for this is -38 dBm. Configuring a lower
value (towards -70 dBm) results in VAD becoming active at a much lower signal
strength (the volume must drop really low before it is considered as silence).
Configuring a higher value (closer to -30 dBm) results in VAD becoming active
for even a small drop in voice signal strength. It drives the playout to play
comfort noise packets more often. However, this sometimes leads to minor
clipping of audio.

Once the VAD becomes active, the component of background noise and
comfort noise is controlled by configuring the voice vad-time
timer_value command under the global
configuration, as shown in this example. This is the delay time in milliseconds
for silence detection and suppression of voice packet transmission. The default
value for the holdover time is 250 msec. This means that within 250 msec,
comfort noise begins. The range for this timer is 250 msec to 65536 msec. If a
high value is configured for this, comfort noise comes into play much later
(background noise continues to be played). If this is configured for 65536
msec, then the comfort noise is turned off. A higher value for this timer is
desired for smoother transition between background noise and comfort noise. The
downside to configuring the voice vad-time command
to a high level is that it does not achieve the desired 30 to 35 percent
bandwidth saving.

A typical scenario for setting up VoIP calls is either over a
frame-relay link or over a PPP link. These are configuration examples for these
scenarios.

VoIPoFR - QoS Configuration Example

In this example (which contains only relevant sections of the
configuration), it is assumed that the frame-relay circuit speed is 256 kbps.
The guaranteed Committed Information Rate (CIR) on PVC 100 is 64 kbps and on
PVC 200 is 192 kbps. PVC 100 is used to carry both data and voice. PVC 200 is
used only to carry data. A maximum of four simultaneous voice calls exists at
any given time. Configure fragmentation on both PVCs based on the CIR of the
lowest-bandwidth-voice-PVC (PVC carrying voice). Based on the examples in this
document, that means the fragmentation size is decided based on PVC 100's CIR
(which is 64 kbps). As shown in the table of the Serialization Delay section,
for a 64 kbps link, a fragmentation size of 80 bytes is required. The same
fragmentation size needs to be configured for PVC 200.

VoIP Over PPP - QoS Configuration Example

In this example (which contains only relevant sections of the
configuration), it is assumed that the QoS needs to be configured for a
point-to-point fractional T1 controller (that has twelve channels). A maximum
of four simultaneous voice calls exists at any given time. The configuration
task involves configuring this serial interface with PPP encapsulation, making
it part of a multilink group, creating a multilink interface (that belongs to
the same multilink group), and configuring all the QoS on the multilink
interface. For further details about the configuration of VoIP over PPP, refer
to
VoIP
over PPP Links with Quality of Service (LLQ / IP RTP Priority, LFI,
cRTP).

There are always some uncontrolled entities in a network that
contribute towards further delays and jitter in the received voice packets. By
modifying the jitter buffer on the terminating gateway the uncontrolled jitter
is resolved in the voice network.

The jitter buffer is a time buffer. It is provided by the terminating
gateway to make the playout mechanism more effective. This is a functional
diagram of the playout mechanism:

When the playout control receives a voice packet, it analyzes the RTP
timestamp. If the voice packet is delayed beyond the holding capacity of the
jitter buffer, then the packet is immediately dropped. If the packet is within
the buffering capability, it is placed in the jitter buffer. The location of
this packet in the jitter buffer depends on the RTP timestamp calculated for
that packet. In the event there is no available voice packet, the playout
control tries to conceal it (predicts the missed out packet). If VAD is
enabled, comfort noise is played.

The responsibility of the playout control is to handle the events of
lost packets, duplicated packets, corrupted packets, and out-of-sequence
packets. These events are handled by time aligning the jittered voice packets,
playing comfort noise (if VAD is configured), or even regenerating dual tone
multifrequency (DTMF) tones to be played out to the host.

The concealment of a voice packet is done by either prediction
concealment or by silence concealment. Prediction concealment is based on the
previous packet and the next packet (if available). It works best with low
bitrate codecs (5 kbps to 16 kbps). Loss of voice packets for a high bitrate
codec (32 kbps to 64 kbps) can potentially result in poor prediction
concealment. Prediction concealment starts when there are low and infrequent
delays or a lesser number of packet loss. Too much prediction concealment can
lead to robotic voice quality. Silence concealment is the worst form of
prediction concealment. It comes into play when there is no information
available to predict. It is simply a background concealment. It starts when
there are high delays and more number of packet loss. Too much silence
concealment leads to choppy voice quality. The prediction concealment is good
for 30 msecs after which the silence conceal comes into play.

The jitter buffer is confined by a high water mark and a low water
mark. The high water mark is the upper time limit within which a packet is
expected to arrive for on-time playout. Packets that arrive after the high
water mark are marked as late packets or lost packets. The low water mark is
the minimum time within which a packet is expected to arrive for on-time
playout. Packets that arrive before the low water mark are considered early
packets (it can still be played out on time).

If the terminating gateway continues to see an increment in the arrival
of late packets, it increases the high water mark. This value for high water
mark remains the same throughout the duration of the call. This is increased up
to a maximum defined in the configuration. In a similar manner, the terminating
gateway observes the number of early packets received. If these packets start
to frequent the gateway, it reduces the low water mark. This value remains the
same throughout the duration of the call. This mode of jitter buffer is
referred to as "adaptive mode," where the terminating gateway adapts its jitter
buffer based on the traffic pattern. The other mode is "fixed mode." In the
fixed mode, there is one initial value for the low water mark and the high
water mark. This value is based on the estimated received delay ( see the
show voice call <port-number> section of
this document).

From the show call active voice brief
command output, you see that whatever is received on the Telephony leg
(rx:7044) is transmitted to the IP leg (tx:7044). The same is true for packets
received on the IP legs (26165) that are forwarded to the Telephony leg
(26157). The difference in the number of packets received on the IP leg versus
the number of packets transmitted on the Telephony leg is contributed to late
packets that do not make it in time.

This output of the show call active voice
command (without the "brief" keyword), points to further details about
parameters that directly identify jitter.

The show voice call
port-number command provides useful
information. Make sure to be either consoled in the gateway, or if you are
Telneted into a gateway, make sure you have issued the terminal
monitor command from the exec level.

Note: This command is not available on the AS5x00/AS5x50 platforms.

In this output, the value for Rx Delay Est (ms) is 71. This is the
current jitter buffer value. A value for the high water mark and low water mark
is deduced on this. An average initial value for the high water mark is 70
msec, while that for the low water mark is 60 msec. Once an initial value is
set, the gateway keeps track of any early packets or late packets received. As
is seen in the output here, the prediction concealment drops are close to 250
ms, while the silence concealment are 30 ms. There is always a higher value for
prediction concealment since silence concealment is only a worse case scenario
of Prediction concealment. For every Prediction concealment drop, there is an
increase in the buffer overflow discard.

If you see buffer discard, it does not necessarily mean that you see
an increase in the high water mark. The high water mark is the upper limit of
the jitter buffer. It changes only if a trend is observed. In other words,
there should be a continuous flow of late packets. This results in an increase
of the jitter buffer. In the output here, such a trend is present. Therefore,
the high water mark is increased from 70 msec to 161 msec. If this value is not
changed (and if you still see 14 late packets), it implies that these are
sporadic late packets, not forming a trend.

From the output of the show call active
voice command, look out for lost packets. For every lost packet,
you see two packets that are out of sequence. This is seen on the Rx Non-Seq
Pkts output. Since it is not a positive value, it is concluded that there has
not been any packet losses either.

Observe the Tx Comfort Pkts and Rx Comfort Pkts. As from the example
outputs, it is concluded that the phone connected to this router mostly keeps
quiet since you have lots of Tx Comfort Pkts. At the same time, you have zero
Rx Comfort Pkts, which means that the other end continuously speaks.

Compare the output here with the previous command output. There is an
increased number of Rx Late Pkts (from 14 to 26). However, there is no
increment in the high water mark value. This indicates that the 12 packets are
sporadically delayed. The Buffer Overflow discard is increased to 910 msecs.
However, since there is no trend observed, the high water mark is not
increased.

In the output here, you have a Rx Early Pkts: 3. This means that a
packet arrives much before it is expected. As seen from the output here, the
Jitter buffer has stretched itself to accommodate for any more early packets by
reducing the low water mark from 60 to 51.

The QoS guidelines covered in this document take care of the choppy or
deteriorated voice quality issue. The configuration of playout-delay buffer is
a workaround for improper QoS implementation in the network. Only use this as a
stop-gap fix or as a tool for troubleshooting and narrowing down of the jitter
problems introduced in the network.

The jitter buffer is configured for either fixed mode or adaptive mode.
Under the adaptive mode, the gateway allows you to configure a minimum value
for the jitter buffer, a maximum value, and a nominal value. The jitter buffer
expects the packets to arrive within the nominal value range. The nominal value
has to be either equal to or more than the minimum, and equal to or less than
the maximum. The buffer expands up to the maximum value configured. This can
extend up to 1700 msec. One issue with configuring high maximum value is the
introduction of end-to-end delay. Choose the value of maximum playout-delay
such that it does not introduce unwanted delay in the network. This output is
an example of the jitter buffer configured for adaptive mode:

Under the fixed mode, the gateway looks at the configured value for
nominal. Although it allows you to configure the minimum and the maximum value
for playout-delay, it is ignored when configured for fixed mode. When in the
fixed mode, the high water mark value or the low water mark value always
remains constant. It is based on the nominal value and based on Rx Delay Est
(ms) value. So it is possible that under the fixed mode, you configure the
value as 200 msec. However, if the estimated received delay is close to 100 ms,
that is what the high water mark and the low water mark is set to for the
entire duration of the call.