Specifications

IPmux-11 Installation and Operation Manual Chapter 4 Diagnostics and Troubleshooting
Performance Monitoring Statistics 4-13
Table 4-4. Bundle Connection Parameters (Cont.)
Parameter Description
Sequence
Errors
Each packet transmitted by IPmux-11 holds a sequence number. The receiving IPmux-11 checks these
numbers at the receive mechanism and expects to see that each new incoming packet is “in sequence”
relative to the previous one (i.e., packet no. 5 is received after no. 4). When, for some reason, this is
not the case (i.e., next packet is not in sequence relative to the previous one), this means that there had
been a problem with packet flow integrity (and hence data/voice integrity). IPmux will indicate this by
increasing the “Sequence Errors” counter by one.
There may be two reasons for a Sequence Error notification:
Packet or packets are lost somewhere along the network.
Re-ordering of packets by network.
Packet re-ordering may occur due to queuing mechanisms, re-routing by the network, or when the
router updates very large routing tables.
Recommendations
:
• Make sure IPmux-11 traffic has sufficient bandwidth. See Chapter 1 for throughput calculation.
• Make sure Ethernet connection is functioning properly. (See LAN Statistics above.)
• Make sure Ethernet/IP network provides priority (Quality Of Service) to the IPmux traffic. Priority
may be achieved by three means: VLAN tagging, IP TOS marking or by using the constant 2142
decimal value at the “UDP destination Port” field of each TDMoIP packet.
• Verify that the IP network devices (switches/routers/modems/etc.) are capable of handling the IPmux
PPS rate (Packets Per Second). For PPS calculations refer to Chapter 1.
• Make sure the network devices do not drop/loose/ignore packets.
Note: IPmux-11 may support a “reordering mechanism”, which can sort packets back to their original
order in some situations.
Jitter Buffer
Underflows
IPmux-11 is equipped with a “Packet Delay Variation Tolerance” buffer, also called a “jitter buffer”,
responsible for compensating for IP networks delay variation (IP jitter). The jitter buffer is configured in
milliseconds units and exists for each bundle independently.
Explanation:
Packets leave the transmitting IPmux-11 at a constant rate, but the problem is that they are reaching the
opposite IPmux-11 at a rate which is NOT constant, due to network delay variation (caused by
congestion, re-routing, queuing mechanisms, wireless media, half-duplex media, etc.). The TDM
devices at both ends require a constant flow of data, so they can’t tolerate delay variation. Therefore
the jitter buffer is required in order to provide the TDM equipment with a synchronous and constant
flow.
This is done as follows:
• Upon startup, the jitter buffer stores packets up to its middle point (the number of packets correlates
to the buffer’s configured depth in milliseconds). Only after that point it starts outputting the E1/T1
flow towards its adjacent TDM device. The stored packets assure that the TDM device will be fed
with data even if packets are delayed by the IP network. Obviously, if packets are delayed too long,
then the buffer is gradually emptied out until it is underflowed. This situation is called buffer
starvation. Each underflow event increases the jitter buffer underflow counter by one and indicates a
problem in the end-to-end voice/data integrity.
The second functionality of the jitter buffer is that in adaptive mode the jitter buffer is also a part of a
mechanism being used to reconstruct the clock of the far end TDM side.