قراءة في شرح LACNIC: ما الذي لا يحسبه معدل ترميز الصوت؟

الخلاصة

• يشرح مقال César Díaz المنشور في مدونة LACNIC بتاريخ 26 أغسطس 2026 انتقال الاتصالات إلى IP، ويذكر صراحة أن ترويسات البروتوكولات وبيانات التحكم تُضاف إلى الصوت. ليس المقال إعلاناً عن سياسة جديدة.
• في نموذج لصوت أحادي القناة، مستمر وفي اتجاه واحد، مع حزمة كل 20 ms، ينتج G.729 بمعدل 8 kbit/s تدفقاً قدره 24 kbit/s مع الترويسات الأساسية لـ IPv4، أو 32 kbit/s مع IPv6.
• تقليل حجم الصوت لا يقلل بالضرورة عدد الحزم. وإطالة فترة التجميع توفر في الترويسات، لكنها تتطلب قبول أثر مختلف على التأخير وفقد الصوت.

رقم صحيح، لكنه يخص جزءاً من الرحلة

عندما يتحدث مورّد عن معدل الترميز، فهو يصف كمية البيانات التي تمثل الصوت. أما من يخصص سعة للنقل فيحتاج إلى معرفة ما يخرج فعلاً من الجهاز، وبأي وتيرة. استخدام الرقم الأول للإجابة عن السؤال الثاني يغيّر معنى الوعد قبل أن تبدأ المكالمة.

ينبّه شرح LACNIC المنشور في 26 أغسطس إلى هذا الفرق. يقارن César Díaz بين صوت G.711 بمعدل 64 كيلوبت في الثانية وبدائل تستخدم معدلات أقل، لكنه لا يتجاهل ترويسات IP وبيانات التحكم. لذلك ليست القضية تصحيح خطأ منسوب إليه. القضية هي متابعة أثر التحفظ الذي كتبه حتى يصل إلى حساب السعة.

لنأخذ مثالاً محدداً من RFC 3551. يحتوي إطار G.729 على 10 بايتات تمثل 10 ملي ثانية من الكلام. ويجمع الإعداد الافتراضي إطارين في حزمة واحدة: 20 بايتاً لكل 20 ملي ثانية، أي 50 حزمة في الثانية أثناء الإرسال المستمر. لا يثبت هذا المثال أن عضواً في LACNIC يستخدم تلك الإعدادات.

تضاف إلى هذه الحمولة ترويسة RTP الأساسية البالغة 12 بايتاً، وترويسة UDP البالغة 8 بايتات، والحد الأدنى لترويسة IPv4 وهو 20 بايتاً. تصبح الحزمة 60 بايتاً. وحاصل 60 × 50 × 8 يساوي 24 ألف بت في الثانية.

لم يتوقف المرمّز عن إنتاج صوت بمعدل 8 كيلوبت. نحن نحسب الآن حزمة تحتوي ذلك الصوت وأجزاء أخرى.

ما الذي يبقى بعد الضغط؟

الجدول التالي حساب توضيحي، وليس قياساً لشبكة حية. يفترض صوتاً أحادي القناة مستمراً في اتجاه واحد، وفترة 20 ms، وترويسات أساسية غير مضغوطة، بلا خيارات أو امتدادات. وتبلغ ترويسة IPv6 الأساسية 40 بايتاً.

الترميز	الصوت وحده	الحزم في الثانية	حزم IPv4 كاملة	حزم IPv6 كاملة
G.711	64 kbit/s	50	80 kbit/s	88 kbit/s
G.729	8 kbit/s	50	24 kbit/s	32 kbit/s

انخفضت بيانات الصوت إلى الثمن، لكن تدفق حزم IPv4 انخفض من 80 إلى 24، أي بمعامل يقارب 3.33. بقي عدد الحزم 50 في الثانية في الحالتين. ومن ثم لا يثبت انخفاض البايتات انخفاضاً مماثلاً في العمل الذي ينفذه الجهاز لكل حزمة. ولا يقدم الجدول اختباراً لقدرة جهاز بعينه.

أما زيادة IPv6 هنا فمحددة: عشرون بايتاً إضافياً، خمسون مرة في الثانية، تساوي 8 كيلوبت في الثانية. لا يمكن تحويل هذا الفرق وحده إلى حكم على كلفة IPv6 الإجمالية أو جدوى نشره.

ويستبعد النموذج عمداً الإشارات، وRTCP، والإضافات الأمنية، والأنفاق، وتأطير طبقة الوصلة، والتكرار وهوامش السعة. تتغير حركة البيانات عند استخدام كبح الصمت. وللمحادثة اتجاهان ينبغي بحثهما على حدة؛ هذا حساب لاتجاه واحد فقط. وقد يكون عدّاد حمولة الصوت وعدّاد حزم IP صحيحين معاً رغم اختلاف نتيجتيهما.

التجميع ينقل جزءاً من التكلفة إلى الوقت

يمكن خفض عدد مرات إرسال الترويسة من دون تغيير المرمّز. في نموذج G.729 وIPv4 نفسه، تعطي حزمة كل 10 ms معدل 40 kbit/s، وكل 20 ms معدل 24، وكل 40 ms معدل 16. يظل معدل الصوت 8 kbit/s، لكن تكلفة الترويسة تتكرر بوتيرة مختلفة.

يحتاج تجميع كلام أكثر إلى الانتظار قبل إرساله. وعند ضياع حزمة، تضيع معها مدة أطول من الصوت. يوضح RFC 3551 أن فترة التجميع الأطول تقلل عبء الترويسات، لكنها تزيد التأخير وتجعل أثر الفقد أكثر وضوحاً. لذلك لا تختار خانة السعة وحدها الإعداد المناسب.

ولا يضمن RTP وصول البيانات في موعدها. معلومات التسلسل والتوقيت تساعد في تفسير التدفق، لكنها لا تعادل ضماناً لجودة المحادثة. ينبغي اختبار التطبيق والمسار المقصودين بدلاً من افتراض النتيجة من مواصفات البروتوكول.

يوفر مقال LACNIC مدخلاً مفيداً لهذه المحاسبة. وهو لا يثبت ازدحاماً إقليمياً ولا يفرض مرمّزاً معيناً. قيمته التشغيلية تزداد عندما يحتفظ المشغّل بالتحفظ المتعلق بالترويسات داخل الميزانية، لا في هامش الشرح فقط.