كيف RTP (بروتوكول النقل في الوقت الحقيقي) العمل في الصوت عبر بروتوكول الإنترنت؟

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

ما هو RTP؟

بروتوكول النقل في الوقت الفعلي (RTP) بروتوكول RTP هو البروتوكول الذي ينقل بيانات الصوت والفيديو الفعلية في مكالمة VoIP. بينما يقوم بروتوكول SIP بإنشاء المكالمة وإدارتها وإنهاؤها، فإن بروتوكول RTP هو الذي ينقل الصوت نفسه - الصوت الرقمي للمحادثة - كتدفق من الحزم الصغيرة عبر الإنترنت في الوقت الفعلي.

ببساطة: بروتوكول SIP هو رنين الهاتف والاتصال؛ وبروتوكول RTP هو الصوت الذي ينتقل عبر الخط بمجرد الرد.

الفكرة الأساسية: بث الصوت على شكل حزم بيانات

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

بروتوكول النقل في الوقت الحقيقي (RTP) هو البنية التي تغلف كل حزمة من تلك الحزم. وهو يضيف المعلومات اللازمة لتحويل تدفق فوضوي من حزم الإنترنت إلى كلام سلس ومفهوم في الطرف الآخر.

تحتوي كل حزمة RTP على ثلاثة أشياء تجعل الصوت في الوقت الفعلي ممكناً:

• رقم تسلسلي — لذلك يعرف الجهاز المستقبل الترتيب الصحيح، حتى لو وصلت الحزم مشوشة.
• طابع زمني — حتى يمكن تشغيل الصوت بالسرعة المناسبة والبقاء متزامنًا (وهذا أمر بالغ الأهمية عند وجود فيديو أيضًا).
• الحمولة — الصوت المضغوط الفعلي، المشفر بواسطة أي برنامج ترميز تم التفاوض عليه في المكالمة (G.711، Opus، وما إلى ذلك).

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

لماذا يخالف الصوت المباشر القواعد المعتادة للإنترنت؟

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

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

لهذا السبب يتجاوز معدل نقل البيانات في الوقت الحقيقي (RTP) UDPوليس بروتوكول TCP. يُعدّ بروتوكول UDP بروتوكول نقل "أرسل وانسَ" - فهو يرسل الحزم دون انتظار تأكيد أو إعادة طلب الحزم المفقودة. أما بروتوكول RTP فيتقبّل اختفاء بعض الحزم من حين لآخر، وذلك لأنه يُستخدم في نقل الصوت في الوقت الفعلي. انقطاع بسيط أفضل دائماً من التأخير. يقوم دماغك بملء فجوة مدتها 20 مللي ثانية دون أن يلاحظ ذلك؛ فهو لا يستطيع تحمل نصف ثانية من التأخير.

هذه المفاضلة - تفضيل السرعة والتوقيت على التسليم المثالي - هي أهم شيء يجب فهمه بشأن بروتوكول RTP. إنه بروتوكول مصمم بناءً على حقيقة أن التوقيت هو كل شيء في المحادثة.

بروتوكول النقل في الوقت الحقيقي (RTP) لا يسير بمفرده أبدًا: مجموعة البروتوكولات

يتم تضمين بروتوكول RTP دائمًا داخل بروتوكولات أخرى، حيث يتولى كل منها مهمة مختلفة. في مكالمة VoIP نموذجية، تبدو الطبقات كالتالي:

• إب (بروتوكول الإنترنت) — يتولى معالجة العناوين والتوجيه عبر الشبكة.
• UDP (بروتوكول مخطط بيانات المستخدم) — طبقة النقل السريعة التي لا تتطلب مصافحة والتي يعتمد عليها بروتوكول النقل السريع RTP.
• RTP — يقوم بتنظيم حزم الصوت باستخدام أرقام التسلسل والطوابع الزمنية.
• بروتوكول التحكم في الوقت الحقيقي (RTCP) — بروتوكول RTP المرافق. لا ينقل الصوت؛ بل يراقب جودة المكالمات في الوقت الفعلي، ويبلغ عن فقدان الحزم والارتعاش والتأخير إلى كلا الطرفين حتى يتمكنا من التكيف.

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

SIP مقابل RTP: الفرق الذي يُربك الجميع

هذه هي النقطة الأكثر شيوعًا للالتباس في تقنية VoIP، لذا يجدر توضيحها بشكل واضح.

SIP (بروتوكول بدء الجلسة) بروتوكول SIP هو بروتوكول الإشارة. فهو يحدد الطرف الآخر، ويتفاوض على برنامج الترميز المستخدم، ويرن الهاتف، ثم ينهي المكالمة في النهاية. مراقبة.

RTP هي وسيلة إعلامية. بمجرد أن يُنشئ بروتوكول SIP المكالمة، ينقل بروتوكول RTP الصوت الفعلي. يمكن تشبيه بروتوكول SIP بالنادل الذي يأخذ طلبك ويُحضر الفاتورة؛ أما بروتوكول RTP فهو الوجبة نفسها.

بشكل حاسم ، يتم السفر عبر بروتوكول SIP وبروتوكول RTP بشكل منفصل غالبًا ما يحدث ذلك عبر منافذ مختلفة، وأحيانًا حتى عبر مسارات شبكة مختلفة. قد تتمتع المكالمة بإشارة SIP مثالية (اتصال ناجح) ولكن بإشارة RTP سيئة (صوت متقطع أو أحادي الاتجاه). لهذا السبب، تُعد مشكلة "تم الاتصال ولكن لم أسمع المتصل" شائعة جدًا في تقنية VoIP، فهي دائمًا تقريبًا مشكلة في RTP، وليست في SIP. يُعد الصوت أحادي الاتجاه، على وجه الخصوص، العرض الكلاسيكي لحظر حزم RTP في اتجاه واحد، عادةً بسبب جدار الحماية أو خلل في إعدادات NAT.

ما علاقة RTP بجودة المكالمات؟

لأن بروتوكول النقل في الوقت الحقيقي (RTP) هو الذي ينقل الصوت الفعلي، فهو الذي يحدد جودة المكالمات. وتُعزى غالبية شكاوى جودة الصوت عبر بروتوكول نقل الصوت عبر الإنترنت (VoIP) إلى ثلاثة مشاكل على مستوى بروتوكول النقل في الوقت الحقيقي:

غضب — وصول الحزم على فترات غير منتظمة. تسمح الطوابع الزمنية لبروتوكول النقل في الوقت الحقيقي (RTP) لجهاز الاستقبال بتشغيل "مخزن مؤقت للارتعاش" يعمل على تنعيم هذا التباين، ولكن الارتعاش المفرط يطغى على المخزن المؤقت ويتسبب في انقطاع الصوت.

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

كمون — إجمالي التأخير من المتحدث إلى المستمع. بروتوكول النقل في الوقت الحقيقي (RTP) بحد ذاته ذو تكلفة منخفضة، لكن كل قفزة، وكل عملية تحويل ترميز، وكل مخزن مؤقت تضيف أجزاء من الثانية. بعد حوالي 150 مللي ثانية في اتجاه واحد، تبدأ المحادثة في الشعور بأنها غير طبيعية - يتحدث الناس في وقت واحد.

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

لماذا أصبحت تقنية RTP أكثر أهمية من أي وقت مضى بالنسبة لوكلاء الصوت الذين يعملون بالذكاء الاصطناعي؟

هذا هو الجزء الذي لا يكتب عنه أحد تقريباً - وهو الجزء الذي أصبحت فيه RTP ذات أهمية بالغة.

يعتمد كل وكيل صوتي يعمل بالذكاء الاصطناعي - سواءً كان مبنيًا على Pipecat أو Vapi أو Retell أو أي منصة مخصصة - على بروتوكول النقل في الوقت الحقيقي (RTP) لنقل الصوت بين المتصل ومنصة الذكاء الاصطناعي. فعندما يتحدث شخص ما مع وكيل ذكاء اصطناعي عبر الهاتف، ينتقل صوته كحزم RTP إلى المنصة، حيث يُحوّل إلى نص مكتوب (STT)، ثم يُعالج بواسطة نموذج لغة مبسطة (LLM)، ويُعاد تركيبه إلى كلام (TTS)، ثم يُعاد كحزم RTP. ويُمثل بروتوكول RTP طبقة النقل في طرفي هذه العملية.

كما أن تقنية الصوت المدعومة بالذكاء الاصطناعي أقل تسامحاً مع مشاكل زمن الاستجابة (RTP) مقارنةً بالمحادثة البشرية. وذلك لسببين:

تم استنفاد ميزانية زمن الاستجابة بالفعل. تتطلب محادثة الذكاء الاصطناعي الطبيعية أن يبقى إجمالي زمن الرحلة ذهابًا وإيابًا - نقل RTP بالإضافة إلى تحويل النص إلى كلام (STT) بالإضافة إلى معالجة اللغة الطبيعية (LLM) بالإضافة إلى تحويل النص إلى كلام (TTS) - أقل من 800 مللي ثانية تقريبًا. وتستهلك معالجة الذكاء الاصطناعي وحدها ما بين 300 و500 مللي ثانية من هذا الوقت. لذا، فإن مسار وسائط RTP يكاد يكون معدومًا. كل قفزة إضافية أو عملية تحويل ترميز في طبقة RTP تُضعف بشكل مباشر سلاسة المحادثة التي يقدمها النظام.

تتدهور جودة التعرف على الكلام مع فقدان الحزم. يستوعب المستمع البشري الكلمة ذهنياً مع وجود انقطاع بسيط في منتصفها. أما نموذج تحويل الكلام إلى نص، فغالباً ما يعجز عن ذلك؛ إذ قد يؤدي فقدان حزمة بيانات RTP إلى تحويل كلمة تم التعرف عليها بشكل صحيح إلى خطأ في النسخ، مما ينتج عنه استجابة خاطئة من نموذج LLM. لذا، فإن سلامة نقل بيانات RTP أهم بالنسبة للمستمع الآلي منها بالنسبة للمستمع البشري.

لهذا السبب يُعد اختيار برنامج الترميز (البرنامج الصوتي) بالغ الأهمية بالنسبة للصوت المُعتمد على الذكاء الاصطناعي. G.711 — استخدام برنامج ترميز غير مضغوط — يعني أن الناقل يمرر بروتوكول النقل في الوقت الحقيقي (RTP) مباشرةً دون إعادة ترميز، متجنبًا بذلك التأخير الذي يتراوح بين 5 و20 مللي ثانية والذي تضيفه برامج الترميز المضغوطة عند كل عملية تحويل. بالنسبة لوكلاء الذكاء الاصطناعي، يُعد الحفاظ على مسار RTP نظيفًا وخاليًا من إعادة الترميز أحد العوامل القليلة التي يمكنك التحكم بها بشكل كامل في زمن الاستجابة.

إذا كنت تقوم بالبناء صوت AIطبقة RTP ليست مجرد بنية تحتية يمكنك تجاهلها، بل هي جزء لا يتجزأ من ميزانية زمن الاستجابة ودقة البيانات. (للاطلاع على الصورة الكاملة لكيفية ترابط هذه المكونات، راجع دليلنا حول ربط SIP لوكلاء الذكاء الاصطناعي وانهيار مقارنة بين WebRTC و SIP في روبوتات الصوت.)

كيف يتناسب بروتوكول النقل في الوقت الحقيقي (RTP) مع شبكة الاتصالات؟

عندما يكون للـ إنهاء الصوت يقوم مزود خدمة مثل IDT Express بتوصيل مكالمتك، بينما ينقل بروتوكول RTP الصوت فعليًا عبر شبكته. وتتمثل مهمة مزود الخدمة، على مستوى بروتوكول RTP، في نقل هذه الحزم بأقل قدر من الفقد والتشويش والتأخير الإضافي، وذلك بتوجيهها عبر أقصر مسار نظيف وتجنب إعادة الترميز غير الضرورية التي قد تزيد من التأخير.

هذا هو الفرق بين شركة اتصالات بالجملة وبائع تجزئة يعمل فوقها: عدد أقل من نقاط التوجيه، ووصلات مباشرة، وتمرير G.711، كلها عوامل تُحافظ على نقاء بث RTP، وهو ما يسمعه المتصلون فعليًا. هندسة الاتصالات الجيدة تعتمد، إلى حد كبير، على معالجة جيدة لبروتوكول RTP.

نسخة قصيرة

بروتوكول SIP يربط المكالمة، بينما ينقل بروتوكول RTP الصوت. ينتقلان بشكل منفصل، ولهذا السبب قد يتم الاتصال بسلاسة ولكن بجودة صوت رديئة - فمشاكل الصوت غالباً ما تكون مشاكل متعلقة ببروتوكول RTP.

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

وفي عام 2026، تزداد أهمية بروتوكول النقل في الوقت الحقيقي (RTP) أكثر من أي وقت مضى: فهو طبقة الوسائط الأساسية لكل وكيل صوتي يعمل بالذكاء الاصطناعي، حيث تكون دقة زمن الاستجابة ونسبة فقدان الحزم فيه أعلى بكثير من أي محادثة بشرية. سواء كنت تدير نظام VoIP تقليديًا أو تبني منصة اتصال تعتمد على الذكاء الاصطناعي، فإن جودة مسار RTP لديك هي التي تحدد جودة مكالماتك.

الأسئلة المتكررة

ما هو بروتوكول RTP في تقنية VoIP؟

بروتوكول النقل في الوقت الحقيقي (RTP) هو البروتوكول الذي ينقل بيانات الصوت والفيديو في مكالمات VoIP. يقوم بتقسيم تدفق الصوت إلى حزم صغيرة، تحمل كل منها رقم تسلسلي وطابعًا زمنيًا، ويرسلها عبر بروتوكول UDP ليتم تجميعها لاحقًا في صوت مسموع عند الطرف المتلقي. يتولى بروتوكول RTP معالجة الوسائط (الصوت نفسه)، بينما يتولى بروتوكول SIP معالجة الإشارات (إنشاء المكالمة وإنهاؤها).

ما الفرق بين بروتوكول SIP وبروتوكول RTP؟

يقوم بروتوكول بدء الجلسة (SIP) بإنشاء المكالمة وإدارتها وإنهاؤها، وهو طبقة الإشارة. أما بروتوكول النقل في الوقت الحقيقي (RTP) فينقل الصوت الفعلي بمجرد اتصال المكالمة، وهو طبقة الوسائط. يعمل هذان البروتوكولان بشكل منفصل، وغالبًا عبر منافذ شبكة مختلفة، ولهذا السبب قد تنجح مكالمة VoIP (في حال عمل بروتوكول SIP) ولكن بدون صوت أو بصوت أحادي الاتجاه (في حال فشل بروتوكول RTP).

هل يستخدم بروتوكول RTP بروتوكول TCP أم UDP؟

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

لماذا لا يوجد صوت في مكالمة VoIP الخاصة بي على الرغم من أنها متصلة؟

غالباً ما تكون هذه مشكلة في بروتوكول RTP، وليست مشكلة في بروتوكول SIP. اتصال المكالمة يعني أن إشارات SIP تعمل بشكل صحيح. أما عدم وجود صوت، أو وجوده في اتجاه واحد فقط، فيعني أن حزم RTP محظورة - عادةً بواسطة جدار حماية أو جهاز NAT سمح بإشارات SIP ولكنه يحجب تدفق وسائط RTP. يُمكن حل معظم هذه الحالات بفحص قواعد جدار الحماية لنطاق منافذ RTP والتأكد من إعدادات اجتياز NAT.

ما الذي يسبب ضعف جودة مكالمات RTP؟

تُسبب ثلاثة عوامل على مستوى بروتوكول النقل في الوقت الحقيقي (RTP) معظم مشاكل جودة الصوت عبر الإنترنت (VoIP): التذبذب (وصول الحزم على فترات غير منتظمة)، وفقدان الحزم (فقدان عدد كبير من الحزم، مما يُسبب فجوات مسموعة)، والتأخير (التأخير المفرط بين المُتحدث والمُستمع). يعمل مُخزن التذبذب على تخفيف التباين الطفيف، ويتحمل بروتوكول النقل في الوقت الحقيقي فقدانًا طفيفًا، لكن المشاكل المُستمرة تُؤدي إلى تدهور جودة المكالمة. يُمكن السيطرة على هذه العوامل الثلاثة من خلال تقليل عدد نقاط التوجيه في الشبكة، وتجنب إعادة الترميز غير الضرورية، واستخدام شبكة مُشغل مُصممة هندسيًا بشكل جيد.

لماذا يُعدّ بروتوكول النقل في الوقت الحقيقي (RTP) مهمًا لوكلاء الصوت الذين يعملون بالذكاء الاصطناعي؟

ينقل بروتوكول النقل في الوقت الحقيقي (RTP) الصوت بين المتصل ونظام الذكاء الاصطناعي في كل وكيل صوتي يعمل بالذكاء الاصطناعي. يُعدّ الصوت المُحوسب أقل تسامحًا مع مشاكل بروتوكول النقل في الوقت الحقيقي مقارنةً بالمحادثات البشرية، وذلك لأن إجمالي زمن الاستجابة (نقل بروتوكول النقل في الوقت الحقيقي بالإضافة إلى تحويل الكلام إلى نص، ونمذجة اللغة، وتحويل النص إلى كلام) يجب أن يبقى أقل من 800 مللي ثانية تقريبًا لإجراء محادثة طبيعية، ولأن نماذج التعرف على الكلام تتأثر بفقدان الحزم بشكل أكبر من المستمعين البشريين. يُحافظ استخدام ترميز G.711 على مسار بروتوكول النقل في الوقت الحقيقي سريعًا وسلسًا، مما يُحسّن بشكل مباشر استجابة الوكيل الصوتي ودقة النسخ.

تقوم شركة IDT Express بتصميم شبكة الاتصالات الخاصة بها لتوفير توصيل RTP نظيف - أقل عدد من القفزات، وتمرير G.711، ووصلات مباشرة تحافظ على وضوح صوت مكالمتك. استكشف تقنية SIP Trunking مع IDT Express →