Xét một ứng dụng mạng đa phương tiện tương tác thời gian thực, chẳng hạn điện thoại Internet. Người nói chuyện trong điện thoại internet tạo ra một tín hiệu audio gồm lúc nói lúc ngừng. Để đảm bảo băng thông, ứng dụng sẽ chỉ tạo ra gói tin trong thời gian nói. Trong thời gian nói, người gửi tạo ra những byte với tốc độ là 8KBps, cứ 20 ms người gửi nhóm các byte vào thành một đoạn. Số lượng byte trong một đoạn là 20ms*8KB/s = 160B. Một hearder đặc biệt được thêm vào mỗi đoạn. Mỗi đoạn cùng với header được đóng gói trong một UDP segment, rồi được gửi tới giao diện socket. Trong thời gian nói, cứ 20ms có một UDP segment được gửi.
Nếu mỗi gói tin (packet) tới được phía nhận (không xảy ra mất mát gói tin), và có độ trễ không đổi, các packet sẽ tới phía nhận một cách định kỳ 20ms, trong thời gian nói. Trong điều kiện này, phía nhận có thể nghe mỗi đoạn ngay khi tới. Nhưng không may mắn là vài packet có thể bị mất và hầu hết các packet không có độ trễ không đổi (thậm chí là ngay cả khi không có tắc nghẽn trên Internet) tức là jitter mạng. Nếu chạy ngay những gói tin ngay khi nó
52 tới phía nhận thì chất lượng audio thu được sẽ rất tồi. Vì vậy, phía nhận phải có các cơ chế để loại bỏ jitter tại phía nhận: phía nhận cố gắng cung cấp khả năng chạy đồng bộ các đoạn (chunk) khi có jitter. Điều này có thể được thực hiện bằng cách kết hợp các cơ chế:
• Chèn một số tuần tự (sequence number) vào mỗi đoạn, phía gửi sẽ tăng số tuần tự lên 1 khi có một gói tin được tạo ra;
• Sử dụng một nhãn (timestamp) cho mỗi đoạn, phía gửi sẽ gán nhãn cho mỗi đoạn chính là thời điểm mà đoạn đó được tạo ra;
• Làm trễ việc chơi (play) ở phía nhận. Thời gian làm trễ phải đủ lâu để các gói tin phải được nhận trước khi tới lượt (thứ tự) chúng được lập lịch chạy. Việc làm trễ có thể theo khoảng thời gian cố định hoặc thay đổi. Các gói tin không tới được phía nhận trước thứ tự chạy của chúng được xem như là bị mất.
Có hai phương pháp làm trễ việc chơi ở phía nhận.