أعاد الطرف معاملًا لا يفهمه، فبدا الجواب اتفاقًا وهو لم يكن كذلك

الخلاصة

• المعامل المجهول يجب أن يُهمل وألا يعود في الجواب؛ نسخه لا يثبت فهمه بل قد يصنع مظهر اتفاق كاذب.
• mode-set-recv وrecvmode تفضيلان من جهة الاستقبال يمكن للمرسل تجاهلهما، أما sendmode فهو إعلان قد يصل بعد وسائط RTP. التنفيذ يحتاج دليله المستقل.

احتوى العرض امتدادًا خاصًا. لم يعرفه الطرف الآخر، لكن وسيط SDP نسخه إلى الجواب حفاظًا على «اكتمال» السجل. قرأ نظام الامتثال التطابق الحرفي كقبول متبادل.

لم يوجد قبول. وُجد نص واحد مرتين، بلا دلالة مشتركة ولا قرار في المرمّز.

عدم الإعادة حماية للمعنى

تقول RFC 5188 إن المعامل المجهول في العرض يجب أن يُتجاهل وألا يُضمّن في الجواب. الغرض ليس حذف المعلومات عبثًا؛ بل منع endpoint من الادعاء ضمنيًا أنه يدعم دلالة لم ينفذها.

لذلك لا تكفي مقارنة العرض والجواب حرفيًا. ينبغي تسجيل capability/version، وما فُهم، وما أُهمل، ومن اتخذ القرار. التطابق قد يكون دليل نسخ آلي، والاختلاف قد يكون السلوك الصحيح.

ينطبق الحد نفسه على الأنظمة الداخلية. إذا حوّلت بوابة الحقل المجهول إلى إعداد محلي أو أعادته بلا parser ومعنى تنفيذي، فقد صنعت سلطة من شكل الرسالة.

التفضيل لا يأمر المرسل

يعبّر mode-set-recv في EVRC-WB عن مجموعة modes يفضّل المستقبل أن يستخدمها المرمّز البعيد. ويعبّر recvmode في EVRC-B عن mode مفضّل. كلاهما receive-only.

يجوز للمرسل البعيد تجاهل الطلب، وعلى المستقبل أن يواصل decoding. تعرض RFC 5188 مثالًا يكون فيه offerer مستعدًا لاستقبال mode 0 بينما يختار answerer الإرسال في mode 4.

إذن يلزم فصل استلام التفضيل، وقرار سياسة المرسل، وsendmode المعلن، وmode المنفذ في frame بعينها. وجود التفضيل في SDP ليس receipt للمرمّز، وعدم تنفيذه ليس وحده مخالفة.

الاتجاه يحدد صاحب القول

mode-set-recv وrecvmode خاصان بالاستقبال، وsendmode خاص بالإرسال. لا فائدة من تفضيل استقبال في stream من نوع sendonly، ولا من إعلان إرسال في recvonly.

نسخ جميع الحقول إلى الاتجاهين يجعل الوثيقة متناظرة ويزيل المالك. يجب أن يحمل كل claim هوية endpoint والاتجاه وpayload ونسخة offer/answer. من دونها يصبح الرقم منفصلًا عن الفعل الذي يفترض أنه يصفه.

الإعلان قد يتأخر عن الوسائط

يعلن sendmode mode الحالي للمرمّز، لكن RTP قد يصل قبل SDP الأولى أو المحدّثة التي تحمله. إذا تغير المرمّز عند T1 ووصل packet عند T2 ثم التحديث عند T3، فإن آخر وثيقة كانت قديمة بين T1 وT3.

ولا يمنح وصول التحديث كل packet سابق timestamp جديدًا. يلزم خط زمني يضم نسخة SDP وانتقال المرمّز وRTP sequence وtimestamp والوصول وإدخال decoder.

التأخر لا يثبت خطأ في الترميز، والتطابق النهائي لا يمحو فترة الاختلاف. الواقع التشغيلي يتطلب reconcile، لا استبدال التاريخ بآخر snapshot.

اسم payload ليس mode ولا جودة

تربط audio/EVRCWB وEVRCWB0 وEVRCWB1 بين payload type وصيغة interleaved/bundled أو header-free أو compact bundled. إنها قواعد تفسير bytes، لا شهادة mode لكل frame.

يتوافق mode 4 و7 في EVRC-WB مع EVRC-B. لذلك ينبغي للـofferer أن يعلن EVRC-B أيضًا كي يستطيع peer قديم اختيار fallback. codec المختار وتفضيل المستقبل وقرار المرسل حقائق مستقلة.

ويجب استخدام clock قدره 16 kHz حتى إذا كانت input أو output مضبوطة على 8 kHz. الرقم في rtpmap مقياس زمن، لا receipt للميكروفون أو النطاق الصوتي.

الغياب قد يكون توافقًا قديمًا

أضافت RFC 5188 recvmode وsendmode إلى تسجيلات EVRC-B في RFC 4788. التنفيذ القديم لا يرسلها ويتجاهلها إن وصلت، ومع ذلك يبقى interoperable.

قد يعني الغياب peer قديمًا، أو field اختياريًا، أو وسيطًا غيّر SDP، أو capture ناقصًا. لا يجوز تحويله تلقائيًا إلى mode 0 أو رفض. القيمة الصحيحة تبقى unknown حتى تصل قرينة أخرى.

EVRCWB1 يحتاج حد جلسة

يفرض EVRCWB1 rate وmode ثابتين طوال الجلسة. التغيير داخل الهوية نفسها ليس مجرد اختيار حر. يجب إثبات نهاية binding القديم وبداية session أو payload جديد ونسبة كل packet إلى أحدهما.

SDP صحيحة لاحقة لا تكفي وحدها. قد تجعل جلستين صحيحتين تبدوان جلسة مخالفة إذا ضاعت الهوية، أو تخفي مخالفة واحدة إذا احتُفظ بالوثيقة الأخيرة فقط.

سجل الإثبات

يبدأ بـsession/change ID ثابت، والأدوار والاتجاهات ونسخ offer/answer والـpayloads والـsubtype والـclock والأسطر الخام rtpmap وfmtp وptime وmaxptime.

ثم يسجل التفضيل وصاحبه، وقرار المرسل، وكل sendmode ووقت وصوله، وانتقال المرمّز، وsequence وtimestamp وmode للـframes ذات الصلة. كما يسجل legacy capability ومعالجة unknown parameters وحد EVRCWB1.

ينتهي بقبول decoder والخرج ونتيجة التطبيق. نجاح decoding لا يثبت التفضيل، والتفضيل لا يثبت الجودة. كل طبقة تشهد لواقعها فقط.

قرار القيادة

لا تكافئ echo بوصفه تفاهمًا. اطلب المعنى المشترك والقرار التنفيذي. ولا تحوّل تفضيل المستقبل إلى سلطة على مرمّز بعيد.

حفظ الاتجاه والنسخة والزمن يمنع الشكل من السيطرة على الواقع. حين يبقى آخر SDP وحده، يمكن للمؤسسة وصف ما كُتب، لكنها لا تستطيع إثبات ما حدث.

المصادر

1. RFC 5188 HTML
2. RFC 5188 نص
3. معلومات RFC 5188
4. Datatracker RFC 5188
5. تاريخ RFC 5188
6. مراجع RFC 5188
7. Errata RFC 5188
8. RFC 4788
9. معلومات RFC 4788
10. RFC 3558
11. معلومات RFC 3558
12. RFC 3264 offer-answer
13. معلومات RFC 3264
14. RFC 4566 SDP
15. RFC 3550 RTP
16. IANA audio/EVRCWB
17. IANA RTP parameters
18. Heng Lu — طبقات الواقع
19. Heng Lu — الحد الأدنى للمواصفة
20. Heng Lu — أولوية الكود العامل