a, Giao thức RTP nén (cRTP).
Để giảm mức chiếm dụng băng thông của cuộc gọi G.729, ta sử dụng giao thức cRTP. Ta biết rằng phần header của gói thông tin gồm 40 byte IP/RTP/UDP, giao thức cRTP cho phép nén 40 byte này xuống còn từ 2 byte (nếu không sử dụng trường sửa lỗi UDP) đến 5 byte (nếu sử dụng trường sửa lỗi UDP) trong phần lớn thời gian cuộc gọi.
Hình 3.18: Khuôn dạng gói tin thoại CRTP.
Với cRTP băng thông cuộc gọi VoIP sẽ giảm từ 24kbps xuống còn 11,2kbps, đây là một bước tiến quan trọng đối với các kết nối băng thông hẹp. Ví dụ một kết nối 56kbps có thể mang tới 4 cuộc gọi VoIP G.729 cùng
lúc trong khi không sử dụng cRTP sẽ chỉ mạng được 2 cuộc gọi VoIP 24kbps mà thôi.
Trong thực tế sự khác biệt giữa các gói tin liên tiếp thường không đổi dù trong một vài trường hợp có sự thay đổi trong tiêu đề của các gói tin. Bằng cách duy trì cả tiêu đề không nén đầy đủ và sự khác biệt đầu tiên, cRTP chỉ cần truyền đi một chỉ thị chỉ ra rằng sự khác biệt thứ 2 là bằng không. Trong trường hợp đó bộ giải nén sẽ tạo lại tiêu đề gốc mà không làm mất thông tin một cách đợn giản bằng việc thêm sự khác biệt đầu tiên vào tiêu đề không nén đã được ghi nhớ từ trước đối với mỗi gói tin tới đích.
Theo thống kê, các gói tin nén được gửi đi trong 98% thời gian cuộc gọi. Do đó theo định kỳ một tiêu đề chưa nén gốc phải được gửi đi để xác nhận rằng cả 2 phía đang hoạt động đúng trạng thái. Trong một số trường hợp, sự khác biệt có thể xảy ra trong những trường thông tin mà bình thường nó là hằng số (ví dụ như trường loại tải - Payload type), khi đó không được phép nén tiêu đề IP/UDP/RTP.
b, Các công cụ phân mảnh.
Lý do để sử dụng các công cụ phân mảnh rất đơn giản, đó là để giảm trễ xếp hàng. Các gói tin lớn cần nhiều thời gian hơn để truyền qua các kết nối băng hẹp hơn các gói tin nhỏ. Các công cụ phân mảnh sẽ cắt các gói tin lớn thành các gói tin nhỏ để giảm trễ. Chúng ta có thể thực hiện điều này ở lớp 2 hoặc 3 trong mô hình OSI.
Trong các ứng dụng dữ liệu, trễ gây bởi các kết nối băng hẹp không phải là vấn đề quan trọng. Nhưng trong các ứng dụng thời gian thực thì điều này gây ra nhiều vấn đề: làm giảm chất lượng thoại, mất khung, rơi cuộc gọi…
Ví dụ, một gói tin 1500 byte truyền qua một kết nối 56kbps sẽ cần 214ms. Trong khi đó ITU-T đưa ra khuyến nghị rằng: trễ thoại lớn nhất đơn
hướng là phải nhỏ hơn 150ms. Do đó với một kết nối 56kbps thì gói tin 1500 đã chiếm hết quỹ trễ cho thoại VoiP.
Các công cụ phân mảnh không tự nó làm giảm trễ trên các kết nối băng hẹp mà các router cần có cơ chế xếp hàng các gói tin đã bị phân mảnh thay vì các gói tin gốc.