الخلاصة

  • لم ترسل RFC 3952 عدداً صريحاً لإطارات iLBC؛ كان المستقبِل يقسم طول حمولة RTP على 38 أو 50 بايتاً وفق النمط المتفق عليه عبر SDP.
  • تقترح Errata قُدمت في 2026 وما زالت Reported استبدال 32/50 بـ38/50، وهو فصل مهم بين طول متسق وعقد جلسة صحيح وصوت وصل فعلاً.

القسمة تحتاج إلى ذاكرة سابقة

يُنتج نمط 20 ملي ثانية إطاراً من 38 بايتاً، وينتج نمط 30 ملي ثانية إطاراً من 50. سمحت RFC 3952 بجمع عدة إطارات في حمولة واحدة من دون خانة للعدد. إذا كان النمط معروفاً تكفي القسمة.

لكن 76 بايتاً تعني إطارين فقط إذا كان المقسوم عليه 38، و100 تعني إطارين إذا كان 50. الحزمة تحفظ الطول؛ أما النمط فيسكن في حالة الجلسة. لذلك يمكن أن يكون الالتقاط كاملاً على مستوى البايتات وناقصاً على مستوى المعنى.

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

التفاوض كان يختار المقسوم عليه

ظهر iLBC في SDP بصيغة iLBC/8000، وحمل a=fmtp قيمة mode. غيابها يعني افتراض 30 ملي ثانية. وكانت القيمة ثنائية الاتجاه: لا بد أن ينتهي الطرفان إلى النمط نفسه.

يعرض المرسِل تفضيله، ويمكن للمجيب كتابة القيمة الأخرى. النتيجة هي النمط الأقل استهلاكاً للنطاق. ورغم أن 30 أكبر عدداً، فإن 50 بايتاً كل 30 ملي ثانية أقل في الثانية من 38 كل 20؛ لذلك تنتهي أمثلة الاختلاف في النص إلى mode 30.

قدّمت RFC 2327 بنية SDP، وقدّمت RFC 3264 نموذج العرض والجواب، بينما قدّمت RFC 3550 تسلسل RTP وتوقيته. نجاح إحداها لا يثبت الأخرى: اتفاق الجلسة لا يثبت امتثال كل حزمة، ورقم التسلسل لا يعلن حجم إطار iLBC.

ظهر 32 في موضع كان ينتظر 38

تذكر الفقرتان 2 و3.1 من RFC 3952 أن إطار 20 ملي ثانية يبلغ 38 بايتاً، وهو ما ينسجم مع تعريف الترميز في RFC 3951. لكن الفقرة 3.2 طبعت المقسوم عليه 32/50 عند شرح حساب العدد.

تسجل صفحة التصحيحات Errata 8866، المقدمة في 3 أبريل 2026، وتقترح 38/50. حالتها الرسمية Reported لا Verified. الاتساق الداخلي يؤيد 38 بقوة، لكن سلامة التحرير تقتضي ألا تتحول قرينة قوية إلى ادعاء بأن الإجراء اكتمل.

ولا يثبت هذا السطر حادثاً في شبكة أو عيباً في منتج. إنه يثبت احتمالاً معرفياً أضيق: قارئ الوثيقة كاملة يجد 38 في أكثر من موضع، وأداة تنسخ جملة واحدة قد ترث 32. البايتات المنقولة لا تتغير؛ الذي ينحرف هو السياق الذي يفسرها.

الباقي صفر ليس حكماً على المكالمة

إذا كان mode 20، فإن 114 على 38 تساوي ثلاثة بلا باقٍ. هذا إيصال لصحة الطول فقط. لا يثبت صحة كل إطار، أو هوية المرسِل، أو تحقق SRTP، أو قبول مخزن التذبذب، أو نجاح المفكك، أو سماع المتلقي.

تفصل RFC 3711 حماية SRTP عن التأطير. قد تكون الحمولة موثقة تشفيرياً لكن النمط المحلي قديماً، وقد يكون طول غير محمي قابلاً للقسمة من دون أن يثبت هوية. وجود باقٍ يثير الشك في اختلاف النمط أو نوع الحمولة أو التلف أو نقص الالتقاط، لكنه لا يختار السبب وحده.

تسجل بيانات RFC Editor الوثيقة كتجريبية صدرت في ديسمبر 2004. درسها أن ضغط التمثيل لا يمحو الحالة بل ينقلها. إذا لم تُحفظ حالة التحكم مع الوسائط، تتحول وفرة البايتات المحفوظة إلى سجل بلا مفتاح تفسير.

المصادر