الخلاصة

  • وضع نموذج مستقبل RTP أي SSRC غير معروف في فترة اختبار: لم تكفِ حزمة معقولة واحدة، بينما قدّم تتابع قصير دليلاً ضعيفاً على الاستمرارية.
  • عند قفزة ضخمة رفض المستقبل الرقم الأول وحفظ الرقم الذي ينبغي أن يليه، ولم يُعِد المزامنة إلا إذا وصل ذلك الرقم؛ فحَمى حساب الفقد من دون أن يوثّق هوية المرسل.

صحة الترويسة لم تكن قبولاً للمصدر

لنتخيل أن المستقبل يرى للمرة الأولى SSRC بقيمة 0x4A17 ورقم تسلسل 41,900. الإصدار 2، ونوع الحمولة مفهوم في الجلسة، والحشو والطول متسقان. يمكن أن تكون هذه بداية مصدر حقيقي، كما يمكن أن تكون حركة وصلت إلى التطبيق الخطأ، أو بيانات فُكّت بسياق غير صحيح، أو مصادفة في بضعة بتات سهلة الفحص.

واجه RFC 1889 هذا الفقر في الدليل حين عرّف RTP سنة 1996. وأبقى RFC 3550 الفكرة سنة 2003. فحوص الإصدار ونوع الحمولة والحشو والامتداد والطول تستبعد بعض التفسيرات المستحيلة، لكنها فحوص ضعيفة لمصدر لم يُرَ من قبل. لا تحمل الحزمة المنعزلة ماضياً بداخلها.

لذلك أدخل المستقبل الزمن في القرار. يدخل SSRC الجديد حالة probation حتى تصل أرقام متعاقبة بعدد MIN_SEQUENTIAL. في المثال النموذجي العدد اثنان: تبقى 41,900 ترشيحاً، ثم تنشئ 41,901 أول علاقة بين ملاحظتين.

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

ثمن الحذر دُفع من بداية الوسائط

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

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

كلمة probation دقيقة: إنها سياسة قبول محلية تحت عدم اليقين، وليست authentication قدّمها المرسل.

رقم الستة عشر بتاً يدور ولا ينتهي

بعد القبول لا تصبح الأرقام أعداداً صحيحة عادية. حقل RTP من 16 بتاً؛ بعد 65,535 يعود إلى الصفر. يحفظ المستقبل أعلى رقم وعدد الدورات، ويجمعهما في رقم ممتد تستخدمه تقارير RTCP.

وقد تعيد الشبكة ترتيب الحزم. الرقم المتأخر قليلاً قد يكون حزمة متأخرة أو مكررة، والرقم المتقدم باعتدال قد يكشف فجوة. يرسم مثال RFC 3550 مجالاً مقبولاً بقيمتي MAX_MISORDER 100 وMAX_DROPOUT 3,000.

المهم هو افتراض الزمن خلفهما: خمسون حزمة في الثانية، وثانيتان لإعادة الترتيب، ودقيقة انقطاع. إذا تغير معدل الحزم تغيرت المدة التي تمثلها الأعداد نفسها. نسخ الرقم من دون فرضيته الزمنية يفقد معنى السياسة.

احتاجت القفزة الكبيرة إلى شاهد تالٍ

إذا بلغ المصدر 12,000 ثم وصلت 50,000، فإن عدّ المسافة كلها فقداً ينتج كارثة دقيقة لم تُرصد. واعتبار الحزمة فوراً علامة إعادة تشغيل يمنح شذوذاً واحداً سلطة كتابة التاريخ.

يرفض النموذج القفزة أولاً ويحفظ «الرقم السيئ زائد واحد» في bad_seq. فإذا وصلت 50,001 بعد ذلك، كوّن الرقمان بداية متتابعة. عندها فقط يعيد المستقبل تهيئة الحالة ويتعامل مع الرقم الثاني بوصفه أول ملاحظة مقبولة في حقبة جديدة.

تسأل فترة الاختبار الأولى إن كان SSRC مجهول يستحق حالة طويلة العمر. ويسأل تأكيد القفزة إن كان تاريخ SSRC المعروف ما زال يفسر الحاضر. يستخدم القراران الاستمرارية لأن رسالة صريحة عن إعادة التشغيل ليست مضمونة.

تصفير العدّ اعتراف بفترة مجهولة

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

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

حد الحقبة هو الذي يحدد معنى المقام. تمديد حساب واحد عبر ولادة لم تُرَ لا يحفظ الدليل، بل يستبدله بدقة شكلية.

أصلح RFC 3550 المثال القابل للنسخ

وثّق RFC 3550 إصلاحات في RFC 1889. صار base_seq يبدأ من الرقم المستلم نفسه لا من رقم أقل بواحد. واتضح أن المحفوظ هو الرقم السيئ زائد واحد. وفُصلت خطوات التهيئة الكاملة، واستعيدت كلمات فُقدت في إعداد النص القديم للنشر.

خطأ الواحد يغيّر عدد الحزم المتوقعة، وغموض bad_seq يغيّر أي حزمة تؤكد الحقبة. وقد ينتشر شبه الكود في ملحق أكثر من الفقرة التي تحد حدود استنتاجه.

الابتكار الدائم ليس الأعداد 2 و100 و3,000، بل الحالات المعلنة: مرشّح، وتسلسل صالح، وتأخر مقبول، وانقطاع مشتبه، وبداية جديدة مؤكدة.

لم تكن الاستمرارية توقيعاً

يمكن لمزوّر يرسل أرقاماً متتابعة أن ينجح، ويمكن لمصدر حقيقي أن يفشل بسبب الفقد. عرّف RFC 3711 لاحقاً SRTP لتوفير السرية وتوثيق الرسائل والحماية من إعادة الإرسال مع إدارة مفاتيح مناسبة. هذه طبقة دليل أخرى.

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

المصادر