‫وزارة التعليم العالي والبحث العلمي‬

‫الهيئة الوطنية للتعليم التقني والفني‬

‫كلية التقنية الصناعية ‪-‬مصراتة‬
‫قسم الهندسة اإللكترونية‬
‫شعبة االتصاالت‬

‫التعامل مع بروتوكول النقل في الزمن الحقيقي وشرح مكوناته‬

‫واجزائه وبرمجته‬

‫إعداد‬
‫خليفة محمد حسونة‬
‫رقم القيد‪13530 :‬‬
‫أستاذ المقرر‬
‫احمد جحا‬
‫الفصل الدراسي‪ :‬خريف ‪2018/2019‬‬
RTP REAL-TIME TRANSPORT PROTOCOL HEADE ‫مكونات الـ‬

:‫ مقسمة كما هو واضح في الشكل التالي‬FIXED ‫ أساسية‬BYTES 12 ‫ من‬RTP HEADER‫يتكون الـ‬

 ‫• ‪ VERSION-1‬ويتكون من ‪ BITS 2‬ويوضع فيه اإلصدار الـ‪ RTP‬المستخدم وحاليا نحن نعمل على اإلصدار الثاني‪.‬‬

‫• ‪ PADDING-2‬ويتكون من ‪ BIT 1‬وهو ‪ FLAG‬يبين إذا كنا سنضيف معلومات إضافية على الـ‪RTP HEADER‬‬
‫وكمثال يمكن أن يستخدم هذا الـ ‪ PADDING‬في حالة كنا نريد إرسال الـ‪ RTP PAYLOAD‬بشكل مشفر وبهذه الحالة‬
‫يضاف الـ‪ PADDING‬والذي سيحتوي على معلومات حول موقع الـ‪ PAYLOAD‬المشفر في أسفل الـ‪RTP‬‬
‫‪.HEADER‬‬

‫• ‪EXTENSION -3‬ويتكون من ‪ BIT 1‬وهو ‪ FLAG‬يبين إذا كان الـ‪ RTP HEADER‬يحتوي على‬
‫‪ EXTENSIONS‬في نهاية الـ‪ RTP HEADER‬أم ال والتي قد تحتوي على معلومات خاصة بالـ‪APPLICATION‬‬
‫الذي يستخدم الـ‪ RTP‬لنقل البيانات‪.‬‬
 ‫• ‪CSRC COUNT -4‬ويتكون من ‪ BITS 4‬وفيه يبين عدد الـ ‪ CONTENT SOURCE IDENTIFIERS‬الملحقة مع‬
‫الـ‪ RTP HEADER‬ويستخدم هذا الـ‪ FIELD‬في حالة كنا نريد دمج أكثر من ‪ RTP STREAM‬في ‪ RTP STREAM‬واحد‬
‫فمن المعروف أنه ال يمكن تحميل أكثر من ‪ PAYLOAD TYPE‬واحد على الـ‪ RTP STREAM‬وبالتالي في حالة كنا نريد‬
‫إرسال الصوت والصورة فال بد من استخدام اثنين من الـ‪ RTP STREAM‬وبالتالي قد تظهر مشاكل الحقة في عملية المزامنة‬
‫بين الصوت والصورة ولحل هذه المشكلة يمكن دمج الـ‪ RTP STREAM‬الخاص بالصوت والـ‪ RTP STREAM‬الخاص‬
‫بالصورة بـ ‪ RTP STREAM‬واحد وتميزها بإعطاء ‪ IDENTIFIER‬خاص لكل منها ويتكون الـ‬
‫‪IDENTIFIER‬للـ‪ CSRC‬من ‪ BITS 32‬وقد يصل عدد الـ‪ CSRC‬التي يمكن تحميلها على الـ‪ RTP HEADER‬إلى ‪16‬‬
‫بحجم أعظمي ‪.32X16 = 480 BITS‬‬

‫• ‪ MARKER-5‬ويتكون من ‪ BIT 1‬وهو ‪ FLAG‬يبين بداية ونهاية اإلرسال لكل مجموعة من البيانات وكمثال في حالة نقل‬
‫صورة ‪ IMAGE FRAME‬على أكثر من ‪ RTP PACKET‬فإن ذلك الـ‪ MARKER‬سيحتوي على قيمة ‪ 1‬في أول‬
‫‪ FRAME‬يتم إرساله لمعرفة بداية ونهاية اإلرسال لتلك الصورة‪.‬‬
‫• ‪ PAYLOAD TYPE-6‬ويتكون من ‪ BITS 7‬توضح فيها نوع البيانات التي سيتم تحميلها على الـ‪ RTP PACKET‬وكما أوضحنا سابقا ال‬
‫يمكن أن يتم تحميل أكثر من نوع من البيانات على نفس الـ‪ RTP STREAM‬ويبين الجدول التالي أنواع الـ‪ RTP PAYLOAD‬التي يمكن‬
‫تحميلها على الـ‪:RTP STREAM‬‬
‫• ‪HTTP://WWW.SOCKETCODER.COM/DOWNLOAD/IMAGES/281RTP_PT.GIF‬‬
‫• ‪ :SEQUENCE NUMBER-7‬ويتكون من ‪ BITS 16‬ويحتوي على الرقم المتسلسل والذي يولد في البداية بشكل عشوائي ويزيد بمقدار‬
‫واحد لكل ‪ RTP PACKET‬يتم إرساله ويستفاد من هذا الرقم لمعرفة موقع الـ‪ RTP PACKET‬عند استالمه إلجراء عملية الترتيب كذلك‬
‫يستفاد منه في اكتشاف فقدان إي من الـ‪ RTP PACKETS‬المرسلة‪.‬‬
‫• ‪ :TIMESTAMP-8‬ويتكون من ‪ BITS 32‬ويحتوي على الوقت الزمني الذي تم فيه تحميل البيانات على الـ‪ RTP PACKET‬ويستفاد من‬
‫هذه البيانات بشكل كبير لتغلب على مشكالت الـ‪ JITTER‬والمزامنة بين عملية اإلرسال واالستقبال والزمن المستغرق بينهما‪.‬‬
‫• ‪ : SSRC IDENTIFIER SYNCHRONIZATION SOURCE-9‬ويتكون من ‪ BITS 32‬ويحتوي على رقم متسلسل يولد عشوائيا‬
‫لتميز كل ‪ RTP STREAM‬عن غيره بحيث ال يتشابه ‪ RTP STREAM‬مع اآلخر على نفس الـ‪ SESSION‬مما قد يؤدي إلى ما يسمى‬
‫بالـ‪.RTP STREAM CONFLICT‬‬
 ‫استخدام الـ ‪RTP In .NET‬‬
‫ضمن ‪Third Party Kits‬مجموعة من الـ ‪ Microsoft‬لكن قدمت ‪RTP Protocol‬للـ ‪ Classes‬أية ‪.NET Framework 3.5‬ال يدعم الـ‬
‫بشكل كامل وقد تم تقسيمه إلى مجموعة ‪RTP Protocol‬والذي يحتوي على نواة الـ ‪ Microsoft Conference XP‬مشروعها المفتوح المصدر‬
‫‪:‬وكما في الشكل التالي ‪RTP‬بناء على كيفية عمل الـ ‪Classes‬من الـ‬
‫بشكل أساسي في عملية إدارة جلسة االتصال والتي يمكن أن يتم فيها ‪RTP Session‬يستخدم الـ ‪ RtpParticipant :‬والـ ‪RTPSession‬أوال الـ‬
‫كذلك يمكن للمشترك ‪ Participants‬الواحدة مجموعة من المشتركين ‪Session‬كما ويمكن أن يتصل بالـ ‪RTP Stream‬إرسال مجموعة من الـ‬
‫‪ CNAME‬الذي يتم اإلرسال له كذلك يتم إضافة ‪Port‬بالعنوان ورقم الـ ‪ RTP Session‬وتميز كل ‪ RTP Session‬الواحد أن يتصل بأكثر من‬
‫‪:‬عن األخرى وكمثال في الدوت نيت ‪ RTP Session‬لتميز محتويات كل‬
‫‪RtpSession rtpSession = new RtpSession(endpoint, new RtpParticipant("My Audio Session",‬‬
‫;)‪ParticipatorName), true, true‬‬
‫‪RTP‬االستقبال وينضم المرسل أو المستقبل إلى الـ ‪ Port‬باإلضافة إلى ‪ Multicast IP‬والذي يحتوي على عنوان ‪Endpoint Object‬إذ يمرر الـ‬
‫واسم المتصل إليه بعد ذلك ‪CNAME‬ولتعريفه يجب أن يتم تمرير الـ ‪RTP Session‬إلى الـ ‪ RtpParticipant Object‬بتمرير الـ ‪Session‬‬
‫فقط ويحدد الثاني إذا كنت ‪RTP Session‬ويحدد في األول أنك تريد االنضمام إلى الـ ‪ False‬أو ‪ True‬بتمرير قيم ‪RTP Session‬نكمل تعريف الـ‬
‫‪ Session.‬تنوي اإلرسال باستخدام تلك‬
‫معين عند حدوث أي منها ‪ Action‬والتي يمكن أن يوضع ‪RTP Session‬وهو مجموعة األحداث التي تحدث داخل الـ ‪RtpEvents:‬ثانيا الـ‬
‫‪:‬وتقسم هذه األحداث إلى ثالثة أقسام وهي‬
 :‫ وهي‬EXCEPTIONS EVENTS ‫• أوال أحداث ترتبط باكتشاف أخطاء أو مشاكل إثناء اإلرسال أو االستقبال ويمكن أن نسميها‬
DUPLICATECNAMEDETECTED-1
2-FRAMEOUTOFSEQUENCE
3-HIDDENSOCKETEXCEPTION
4-INVALIDPACKET
5-INVALIDPACKETINFRAME
6-NETWORKTIMEOUT
7-PACKETOUTOFSEQUENCE
8-RTPPARTICIPANTTIMEOUT
9-RTPSTREAMTIMEOUT
.RECEIVERREPORT ‫ وهو‬RTP RECEIVED DATA‫ عن حالة الـ‬REPORT ‫• ثانيا حدث وحيد لجلب معلومات‬
SESSION RTP PARTICIPANT & STREAM ‫ وإضافة وحذف‬SESSION ‫• ثالثا أحداث تتعلق باالنضمام إلى‬
:‫ وهي‬ADD/REMOVE EVENTS
RTPPARTICIPANTADDED-1- •
2-RTPPARTICIPANTDATACHANGED
3-RTPPARTICIPANTREMOVED
4-RTPSTREAMREMOVED
5-RTPSTREAMADDED
 ‫ثالثا الـ‪ RTPSENDER‬والـ ‪ RTPLISTENER :‬يمكن اإلرسال مباشرة بعد تعريف الـ‪ RTP SESSION‬ولتعريف الـ‪ RTPSENDER‬يجب‬ ‫•‬
‫أن يمرر له الـ‪ RTP SESSION‬الذي قمنا بتعريفه سابقا ويضاف إليها أيضا الـ‪ PAYLOAD TYPE‬الذي سيتم إرساله على الـ‪RTP SESSION‬‬
‫ولتمييز الـ‪ RTP SENDER‬في الـ‪ SESSION‬عن غيره يمكن أن يتم تعريف ‪ HASH TABLE‬لذلك اختياريا أو قيمة ‪ NULL‬وتمريره لدالة‬
‫‪ CREATERTPSENDER‬وكما يلي كمثال‪:‬‬

‫‪RTPSENDER RTPSENDER = RTPSESSION.CREATERTPSENDER("MY VOIP SENDER",‬‬ ‫•‬

‫)‪;PAYLOADTYPE.DYNAMICAUDIO, NULL‬‬
‫أو يمكن تعريفه بالشكل التالي بحيث تدعم عملية ‪ FEC – FRAME ERROR CORRECTION‬للـ‪ RTP PACKET‬وذلك لدعم إمكانية‬ ‫•‬
‫تصحيح الـ‪ PACKET‬عند وصوله مع وجود أخطاء بدال من طلب إعادة اإلرسال له ويصبح الشكل العام لدالة كما يلي كمثال‪:‬‬
‫‪RTPSENDER RTPSENDER = RTPSESSION.CREATERTPSENDERFEC("MY VOIP SENDER WITH FEC",‬‬ ‫•‬
‫;)‪PAYLOADTYPE.DYNAMICAUDIO, NULL, CDATAPX, CFECPX‬‬
‫)‪;RTPSENDER.SEND(BUFFER‬‬
‫وأما بخصوص االستقبال بالـ ‪ RTPLISTENER‬فتعمل هذه الدالة ضمن الـ‪ RTP SESSION‬وذلك بربط تلك الدالة بحدث االنضمام إلى الجلسة‬ ‫•‬
‫وفي هذه الحالة بمجرد انضمامك إلى الجلسة يتم تنفيذ الحدث وبدأ االستقبال ولتنفيذ ذلك يجب أوال عمل ‪ HOOK‬للـ‪ RTP EVENTS‬التي قمنا‬
‫بتعريفها سابقا وعند بدأ إرسال بيانات ما من قبل أي طرف من األطراف يتم تنفيذ الحدث وبدأ االستقبال ويمكنك الوصول إلى محتويات البيانات‬
‫المستقبلة من خالل الخاصية ‪ FRAME.BUFFER‬والمستلمة من الـ ‪: FRAMERECEIVEDEVENTARGS‬‬
‫‪PRIVATE VOID FRAMERECEIVED(OBJECT SENDER, RTPSTREAM.FRAMERECEIVEDEVENTARGS‬‬ ‫•‬
‫)‪EA‬‬
‫{‬
‫;‪BYTE[] BUUFER = EA.FRAME.BUFFER‬‬
‫}‬
‫• رابعا الـ‪ RTCP‬وهو مختصر لـ‪ :REAL-TIME TRANSPORT CONTROL PROTOCOL‬ومن أهم استخداماته أنه‬
‫يعمل مع الـ‪ RTP‬إلدارة التحكم في العمليات التي تتم في أنظمة المؤتمرات وكذلك تقديم تقارير عن حالة تلك العمليات وتقسم إلى‪:‬‬
‫• ‪-1‬تقارير اإلرسال ‪ SR‬وتقارير االستقبال ‪RR‬‬
‫• ‪-2‬تفاصيل مرسل البيانات ‪SOURCE DESCRIPTION SDES‬‬
‫• ‪-3‬إدارة االنضمام والخروج ل\ومن مجموعة ‪.ADD REMOVE MEMBERSHIP‬‬
‫• ‪-4‬تعريف ‪ APPLICATION-DEFINED APP‬جديد على الـ‪.RTP SESSION‬‬
‫• ويمكن أن نستفيد من كل ذلك من خالل الـ‪ RTCP NAMESPACE‬وكمثال يمكن استخدام الـ ‪RTCPLISTENER‬‬
‫‪ CLASS‬لتعامل مع البيانات التي يتم استقبالها من خالل الـ‪ RTP SESSION‬و إدارة عمليات الـ‪ MEMBERSHIP‬والتي‬
‫ذكرناها سابقا وأيضا تقديم معلومات عن حالة شبكة االتصال والتي تربط المرسل بالمستقبل‪ ,‬وسأقدم بدروس الحقة معلومات أكبر‬
‫عن استخدامات الـ‪ RTCP PROTOCOL‬في إدارة أنظمة الـ‪.CONFERENCING‬‬
‫وفي الختام نشكركم على كل معلومة اخدناها في هذا‬ ‫•‬
‫الفصل‬