Real-time Transport Protocol

Real-time Transport Protocol (בראשי תיבות: RTP) הוא פרוטוקול תקשורת להעברת אותות קול ווידאו בזמן אמת ברשתות תקשורת. פרוטוקול זה מאפשר יישומים אינטרנטיים כגון טלפון מבוסס אינטרנט וועידת וידאו; מדובר באחד הפרוטוקולים המקובלים והנפוצים לצרכים אלו. הפרוטוקול שייך לשכבת היישום של מודל ה-OSI; ברמת שכבת התעבורה, הפרוטוקול פועל לרוב מעל UDP. הפרוטוקול פועל יחד עם פרוטוקול RTCP (RTP Control Protocol), המשמש לבקרה בסיסית על התוכן המועבר ב-RTP, ומרכז נתונים סטטיסטיים כמו גם נתוני איכות שירות (QoS). לפרוטוקול קיימת גם גרסה מוצפנת, SRTP; לעיתים נעשה שימוש בפרוטוקול ZRTP לצורך אותנטיקציה והצפנה. בפרוטוקולי Voice over IP, ישנו שימוש ב-RTP לצורך העברת השמע בשיחות; העברת השמע בעזרת RTP מתאפשרת לאחר קבלת מידע בסיסי על אודות הצדדים המשתתפים בשיחה, המועבר מעל פרוטוקולי איתותים שונים, כדוגמת SIP ,H.323 ,MGCP MEGACO. הפרוטוקול פותח על ידי IETF בשנת 1996, במסגרת קבוצה שעבדה על קביעת סטנדרטים להעברת תוכני מולטימדיה ברשתות תקשורת. התקן פורסם תחילה כ-RFC 1889, ולאחר מכן בגרסה נוספת ב-RFC 3550. פרוטוקול RTP מאפשר העברת נתוני מולטימדיה (שמע ווידאו) בזמן אמת, בין שני משתמשים או יותר. בעזרת הפרוטוקול אפשר מחד להעביר מולטימדיה באופן יעיל ומהיר, ומאידך לשמור על סדר ולטפל באיבוד נתונים. הפרוטוקול בנוי בצורה אבסטרקטית, המאפשרת הוספת פורמטים נוספים ללא שינוי המבנה הליבתי. מדובר באחד הפרוטוקולים בהם נעשה שימוש נרחב ביישומי שמע ווידאו ברשתות תקשורת מודרניות. הפרוטוקול נתמך בשימוש מעל TCP בשכבה הרביעית, אך בפועל מתאר זה אינו מיושם לרוב - זאת בעקבות latency גבוה שיוצר TCP בשכבה הרביעית, הנגרם כתוצאה מהעברת חבילות רבות אודות וידוא ה-session. על כן, לרוב ישנו שימוש בפרוטוקול UDP בשכבת התעבורה; על מנת לפצות על כך ש-UDP לא מבצע סנכרון ובקרה, מומשו מספר שדות בחבילת RTP אשר ממלאים תפקיד זה. הפרוטוקול RTP מחולק למעשה לשני חלקים: העברת המידע אשר מתבצעת תוך שימוש בחבילות RTP. סנכרון, איכות שירות (Qos) וסטטיסטיקות אודות הפרוטוקול, תוך שימוש ב-RTCP. כמות חבילות ה-RTCP הוא יחסית נמוך, ועומד על כ-5% מתוך כלל המידע שעובר. בפרוטוקול, כל העברת מולטימדיה בין מספר גורמים מכונה RTP session, הבנוי מכתובות ה-IP של צדדי השיחה, והפורטים בהם ניתן השירות. מקובל לבחור פורטים עוקבים עבור חבילות ה-RTP וה-RTCP באותו ה-session. מתוך כלל תהליך שיחה/וידאו ברשתות תקשורת, RTP אחראי על העברת המולטימדיה עצמה. על מנת ליצור session-ים בין רכיבי רשת שונים, נעשה שימוש בפרוטוקולי איתותי תקשורת, כדוגמת SIP ,H.323 ,MGCP ,MEGACO. להלן מבנה החבילה בפרוטוקול (RTP בלבד, ללא השכבות שמתחת). בראשית החבילה, כמקובל בפרוטוקולי מודל השכבות, מופיעים שדות מידע כלליים אשר מגדירים את מבנה חבילת המידע בהמשך (כדוגמת אורכי שדות, כמות מזהים וכיוצא בזה). פירושי השדות הייעודיים הם: Version - גרסת הפרוטוקול. (P (Padding - דגל המסמל האם נעשה padding (ריפוד) בסוף המידע, על מנת להשלימו כך שאורך המידע יהיה מוגדר תמיד. (X (Extension - דגל המציין האם יופיע בהמשך החבילה header נוסף, המכונה Extension Header (הסבר בהמשך). (CC (CSRC count - מספר ה-CSRC-ים שיופיע בהמשך החבילה (הסבר בהמשך). (M (Marker - דגל המסמן חשיבות של המידע המועבר; אם הוא דלוק, פירוש הדבר שלמידע זה עדיפות מיוחדת ברמת האפליקציה. (PT (Paylod Type - שדה הקובע את פורמט השמע שיועבר בהמשך. Sequence Number - מספר המייצג את סדר החבילה ב-session נתון. המספר עולה בכל חבילה שנשלחת, ומאפשר סידור החבילות בצד השני כמו גם בדיקת הגעת כלל המידע. ה-Sequence Number של החבילה הראשונה נקבע באקראי. Timestamp - שדה זמן המוצמד לכל בלוק של שמע/וידאו, ומאפשר למשתמש לאגור מידע זה ע"פ סדר כרונולוגי ובמידת הצורך לנגנו לאחור. אופן קביעת הזמן משתנה בין אפליקציות. (SSRC (Synchronization source - מזהה ייחודי לכל session של RTP באורך 32bit, בעזרתו יודעים רכיבי הקצה להבדיל בין session-ים שונים. (CSRC (Contributing source - במקרה בו נדרש שילוב של מספר מקורות שמע (למשל בשיחת ועידה), שדה זה יכול את רשימת מזהי ה-SSRC של כל המקורות (כמותם בהתאם לשדה CC לעיל), וכך יאפשר את שילוב השמע בצורה מסונכרנת. Header Extension - בפרוטוקול מאופשרות הרחבות ייעודיות שונות. כאשר הדגל X לעיל דולק, פירוש הדבר שנעשה שימוש בהרחבה כלשהי, ובשדה זה מפורטים פרטי ההרחבה. רכיבי קצה שלא מכירים הרחבה מסוימת יתעלמו ממנה. SRTP RTSP RDT מדיה וקבצים בנושא Real-time Transport Protocol בוויקישיתוף RFC 3550