Πρωτόκολλο Μεταφοράς Πραγματικού Χρόνου (RTP)

Καθώς οι υπηρεσίες όπως το ραδιόφωνο μέσω διαδικτύου η διαδικτυακή τηλεφωνία, μουσική και video on demand, τηλεδιάσκεψης κλπ άρχισαν να γίνονται όλο κι πιο διαδεδομένες μέθοδοι, πολλοί άνθρωποι ανακάλυψαν ότι λίγο πολύ κάθε εφαρμογή χρησιμοποιούσε το ίδιο πρωτόκολλο μεταφοράς δεδομένων πραγματικού χρόνου. Σταδιακά έγινε εμφανές ότι θα ήταν καλή ιδέα να υπάρχει ένα γενικό πρωτόκολλο μεταφοράς πραγματικού χρόνου για πολλαπλές εφαρμογές. Έτσι δημιουργήθηκε το πρωτόκολλο μεταφοράς δεδομένων πραγματικού χρόνου (Real - Time Transport Protocol - RTP). Η θέση του RTP στο πρότυπο επικοινωνίας TCP/IP είναι κάπως περίπλοκη. Το RTP αποφασίστηκε να τοποθετηθεί στον χώρο του χρήστη (εφαρμογής) και να λειτουργεί πάνω από το UDP (μεταφοράς). Το πρωτόκολλο αυτό λειτουργεί ως εξής: μια εφαρμογή πολυμέσων αποτελείται από πολλαπλές ροές ήχου, video, κειμένου και πιθανόν άλλων μέσων. Αυτές μεταβιβάζονται στην βιβλιοθήκη RTP η οποία βρίσκεται στο χώρο του χρήστη μαζί με την εφαρμογή.

Η βιβλιοθήκη στην συνέχεια πολυπλέκει τις ροές και τις κωδικοποιεί σε πακέτα RTP, τα οποία στέλνονται μετά μέσω μιας θύρας επικοινωνίας. Στην άλλη άκρη της υποδοχής (στον πυρήνα του λειτουργικού συστήματος) παράγονται πακέτα UDP, τα οποία ενσωματώνονται σε IP πακέτα. Στην συνέχεια τα πακέτα IP τοποθετούνται σε πλαίσια από το επίπεδο πρόσβασης δικτύου




Θέση του RTP στο πρότυπο επικοινωνίας TCP/IP




Ενθυλάκωση στο πρωτόκολλο RTP




Το πρωτόκολλο RTP παρέχει παράδοση δεδομένων απ' άκρο σε άκρο για υπηρεσίες πραγματικού χρόνου (Real-time applications). Αυτές οι υπηρεσίες περιλαμβάνουν τον αναγνωριστικό τύπο του ωφέλιμου φορτίου (payload type identification), αριθμούς ακολουθίας (sequence numbering), χρονοσφραγίδες (timestamping) και επίβλεψη παράδοσης δεδομένων (delivery monitoring). Σχεδιάστηκε από το IETF (Internet Engineering Task Force) όπου η πρώτη του έκδοση ήταν το 1996 ως RFC 1896. Στην συνέχεια αυτό αντικαταστάθηκε από το RFC 3550 το 2003. Είναι UDP based και επιλέγει τυχαίες ζυγές θύρες UDP (ζυγοί αριθμοί 0, 2, 4, 6, 8, 10, κλπ.. ) ξεκινώντας από την 16384 έως την 32767.

Λόγω αυτής της σχεδίασης λοιπόν είναι δύσκολο να προσδιορίσουμε σε ποιο επίπεδο ανήκει το RTP καθότι εκτελείται στον χώρο του χρήστη και συνδέεται με το πρόγραμμα της εφαρμογής, μοιάζει λοιπόν σαφώς με πρωτόκολλο εφαρμογής. Απ' την άλλη πλευρά, είναι ένα γενικό πρωτόκολλο, ανεξάρτητο από την εφαρμογή το οποίο απλώς παρέχει λειτουργίες μεταφοράς, οπότε με αυτήν την προσέγγιση μοιάζει με πρωτόκολλο μεταφοράς. Η πιο ορθή περιγραφή είναι ότι πρόκειται για ένα πρωτόκολλο μεταφοράς το οποίο υλοποιείται στο επίπεδο εφαρμογής. Η βασική λειτουργία του RTP είναι η πολύπλεξη πολλαπλών ροών δεδομένων πραγματικού χρόνου σε μια μόνο ροή πακέτων UDP. Η ροή UDP μπορεί να στέλνεται είτε σε έναν προορισμό (αποκλειστική διανομή - unicast) ή σε πολλούς προορισμούς (πολυδιανομή - multicast). Επειδή το RTP χρησιμοποιεί το τυπικό UDP, τα πακέτα του δεν αντιμετωπίζονται με ειδικό τρόπο από τους δρομολογητές εκτός κι αν ενεργοποιηθούν κάποια από τα χαρακτηριστικά ποιότητας υπηρεσιών του IP. Δηλαδή με απλά λόγια δεν υπάρχουν εγγυήσεις για την παράδοση δεδομένων στον τελικό προορισμό ή τυχόν αλλοίωσης αυτών κατά την διαδρομή τους προς τον τελικό προορισμό.

Το RTP δεν εγγυάται παράδοση πακέτων σε συγκεκριμένο χρόνο ούτε την παράδοση τους στην σωστή σειρά. Άντ' αυτού το RTP είναι υπεύθυνο για την ανάκτηση των χαμένων τμημάτων και για τον επανα-συγχρονισμό αυτών. Αυτό προσφέρει κάποια σχετικά πλεονεκτήματα. Μια εφαρμογή μπορεί να αποδεχτεί ένα μέρος αυτών των πακέτων κι όχι όλα τα πακέτα καθότι υπάρχει ελάχιστος χρόνος για επαναμετάδοση αυτών ειδικά αν πρόκειται για video ή ήχο. Επίσης ο αποστολέας μπορεί να παρέχει πέραν από επαναμεταδόσεις πακέτων, νέα ή ανανεωμένα δεδομένα τα οποία να επιχειρούν να επιδιορθώσουν τις επιπτώσεις μιας πιθανής απώλειας πακέτων. Κάθε πακέτο που στέλνεται σε μια RTP ροή λαμβάνει έναν αριθμό αυξημένο κατά ένα μεγαλύτερο από το προηγούμενο πακέτο. Με αυτόν τον τρόπο δίνεται η δυνατότητα στον παραλήπτη να καθορίσει αν χάθηκε κάποιο πακέτο κατά την διαδρομή του. Αν λοιπόν κάποιο πακέτο χαθεί το μόνο που μπορεί να κάνει ο παραλήπτης είναι να προσεγγίσει τις χαμένες τιμές με παρεμβολή (interpolation). Η αναμετάδοση των πακέτων δεν είναι καλή πρακτική διότι δεν θα φτάσει στο χρονικό διάστημα που πρέπει. Συνεπώς το RTP δεν περιλαμβάνει έλεγχο ροής, σφαλμάτων, επιβεβαιώσεις και τεχνικές αναμετάδοσης πακέτων.

Οι μηχανισμοί που παρέχει το πρωτόκολλο RTP παρέχει οι εξής:


  • Αναγνωριστικό τύπου ωφέλιμου φορτίου (Payload type identification)

  • Αναγνωριστικό πηγής (Source identification)

  • Αριθμούς ακολουθίας (sequence numbering)

  • Χρονοσφαγίδες (Timestamping)

Όλα αυτά είναι απαραίτητα για τις περισσότερες πολυμεσικές εφαρμογές. Μαζί με το RTP είναι και το πρωτόκολλο ελέγχου μεταφοράς δεδομένων (Real Time Transport Control Protocol – RTCP) το οποίο παρέχει έλεγχο για την ποιότητα παράδοσης των δεδομένων και πληροφορίες σχετικά με τους συμμετέχοντες σε μια RTP σύνοδο. Μια RTP σύνοδος τυπικά απαρτίζεται από έναν αριθμό RTP θύρας (UDP θύρα), μια UDP θύρα RTCP και την IP διεύθυνση ενός συμμετέχοντα.


RTP επικεφαλίδα

Μια RTP επικεφαλίδα έχει ελάχιστο μήκος 12 bytes. Πέραν της RTP επικεφαλίδας, άλλες προαιρετικές επεκτάσεις επικεφαλίδας μπορεί να εμπεριέχονται. Μετά από τις επεκτάσεις επικεφαλίδας έχουμε το ωφέλιμο φορτίο RTP. Παρακάτω ακολουθεί η εξήγηση για κάθε πεδίο της επικεφαλίδας:




    Θέση του RTP στο πρότυπο επικοινωνίας TCP/IP
  1. Έκδοση (Version): Έχει μήκος 2 bits και υποδεικνύει την έκδοση του πρωτόκολλου. Η τωρινή έκδοση είναι η version 2.

  2. Συμπλήρωσης (Padding - P): Μήκος 1 bit, χρησιμοποιείται για να εντοπίσει εάν υπάρχουν περιττά padding bytes στο τέλος του RTP πακέτου. Η τεχνική συμπλήρωσης (padding) χρησιμοποιείται για να γεμίσει ένα block συγκεκριμένου μεγέθους, όπως για παράδειγμα σε αλγόριθμους κρυπτογράφησης όπου αυτό είναι υποχρεωτικό. Το τελευταίο byte του padding περιέχει τον αριθμό των padding bytes που προστέθηκαν (συμπεριλαμβανομένου και του ίδιου). Αν το πεδίο πάρει την τιμή 1 τότε περιέχει ένα ή περισσότερα bytes στο τέλος του πακέτου που δεν αφορούν τμήμα του ωφέλιμου φορτίου.

  3. Επέκτασης (Extension - X): Μήκος 1 bit το οποίο υποδεικνύει την ύπαρξη μιας επέκτασης επικεφαλίδας στην κλασσική RTP επικεφαλίδα και στο ωφέλιμο φορτίο. Καθορίζεται από την εφαρμογή ή από κάποιο συγκεκριμένο profile. Αν το πεδίο πάρει την τιμή 1 τότε η σταθερή επικεφαλίδα του πακέτου ακολουθείται από μία ακριβώς προέκταση της επικεφαλίδας.

  4. Αριθμός CSRC (CSRC Count - CC): Μήκους 4 bits αναφέρει πόσες συμβάλλουσες πηγές (Contribute Sources) είναι παρούσες. Το πεδίο αυτό παίρνει τιμές από 0 έως 15.

  5. Σημείωσης (Marker - M): Μήκος 1 bit χρησιμοποιείται στο επίπεδο εφαρμογής και ορίζεται από κάποιο συγκεκριμένο profile. Αν αυτό έχει κάποια τιμή τότε τα δεδομένα έχουν ιδιαίτερη σημασία για την εφαρμογή. Το πως θα μεταφραστεί το marker bit εξαρτάται από ένα προφίλ. Είναι προμελετημένο να επιτρέπεται να σημειώνονται σημαντικά γεγονότα όπως τα όρια ενός πλαισίου μέσα στην ροή των πακέτων.

  6. Αριθμός ακολουθίας (Sequence Number): Μήκος 16 bits, ο αριθμός ακολουθίας αυξάνεται κατά 1 για κάθε RTP πακέτο που στέλνεται και χρησιμοποιείται από τον παραλήπτη για να εντοπίσει κάποια απώλεια πακέτου και για επαναφορά ακολουθίας των πακέτων. Το RTP δεν καθορίζει κάποια ενέργεια σε περίπτωση απώλειας πακέτου. Για παράδειγμα, μια εφαρμογή video θα χρησιμοποιήσει το τελευταίο σε σειρά γνωστό frame για να αντικαταστήσει το frame που χάθηκε. Με βάση το RFC 3550 η αρχική τιμή για τον αριθμό ακολουθίας θα πρέπει να είναι τυχαία για να προστατέψει το plaintext κείμενο από κρυπτογραφικές επιθέσεις. Ενώ το RTP δεν παρέχει καμία εγγύηση για την παράδοση των πακέτων, η ύπαρξη αριθμών ακολουθίας το καθιστά ικανό να εντοπίσει πακέτα που χάθηκαν.

  7. Τύπος ωφέλιμου φορτίου (Payload type - PT): Μήκος 7 bits, υποδεικνύει την δομή του ωφέλιμου φορτίου και καθορίζει πως αυτό μπορεί να μεταφραστεί από την εφαρμογή. Αυτό ορίζεται από κάποιο RTP profile.



  8. Τύπος Εφαρμογή
    0 PCMμ Audio
    1 1016
    2 G721 Audio
    3 GSM Audio
    5-6 DV14 Audio
    7 LPC Audio
    8 PCMA Audio
    9 G722 Audio
    10-11 L16 Audio
    14 MPEG Audio
    15 G728 Audio
    26 Motion JPEG
    31 H.261
    32 MPEG1 Video
    33 MPEG2 Video

    Τύποι ωφέλιμων φορτίων



  9. Χρονοσφαγίδα (Timestamp): Μήκους 32 bits, χρησιμοποιείται για να δώσει στον παραλήπτη την δυνατότητα να αναπαράγει τα ληφθέντα δείγματα σε κατάλληλα χρονικά διαστήματα. Όταν υπάρχουν κάποιες ροές πολυμέσων (media streams), οι χρονοσφραγίδες είναι ανεξάρτητες από κάποια ροή και συνεπώς δεν πρέπει να βασιζόμαστε σε αυτές για τον συγχρονισμό των πολυμέσων. Η διακριτότητα του χρόνου καθορίζεται από την εφαρμογή. Για παράδειγμα μια εφαρμογή ήχου με δειγματοληψία δεδομένων με συχνότητα μια φορά ανά 125 μs (8 kHz, είναι ένας συνήθης ρυθμός δειγματοληψίας στην ψηφιακή τηλεφωνία) θα χρησιμοποιούσε αυτήν την τιμή ως ανάλυση ρολογιού (clock resolution). Η διακριτότητα του ρολογιού (clock granularity) είναι μια από τις λεπτομέρειες που καθορίζονται από το RTP profile της εφαρμογής.

  10. Αναγνωριστικό SSRC (SSRC Identifier): Μήκος 32 bits, το αναγνωριστικό πηγής συγχρονισμού εντοπίζει την πηγή μιας ροής δεδομένων. Κάθε πηγή συγχρονισμού σε μια RTP συνεδρία είναι μοναδική.

  11. Αναγνωριστικά CSRC (CSRC Identifier): Μήκους 32 bits το καθένα, οι αναγνωριστικές συμμετέχουσες πηγές απαριθμούν τις συμβάλλουσες πηγές σε μια ροή η οποία έχει παραχθεί από πολλαπλές πηγές.

  12. Επέκταση επικεφαλίδας (Header extension): Προαιρετικό πεδίο, τα πρώτα 32 bits περιέχουν ένα ανανωριστικό επέκτασης επικεφαλίδας που ορίζεται απο το profile (profile-specific identifier) μήκους 16 bits και ένα πεδίο καθορισμού μεγέθους (length specifier) μήκους 16 bits που υποδεικνύει το μήκος της επέκτασης της επικεφαλίδας σε κομμάτια των 32 bits, εξαιρώντας τα 32 bits της επέκτασης επικεφαλίδας.



Πρωτόκολλο Ελέγχου Μεταφοράς Πραγματικού Χρόνου (RTCP)

Όπως αναφέραμε προηγουμένως το RTP συνοδεύεται μαζί με το πρωτόκολλο RTCP το οποίο παρέχει στους συμμετέχοντες μιας RTP συνόδου ενημέρωση για την ποιότητα των δεδομένων που μεταδίδονται. Το πρωτόκολλο αυτό χειρίζεται την ανάδραση, τον συγχρονισμό, και την διασύνδεση χρήστη αλλά δεν μεταφέρει δεδομένα. Η πρώτη λειτουργία χρησιμοποιείται για την παροχή ανάδρασης προς τις πηγές σχετικά με την καθυστέρηση, την παραμόρφωση χρονισμού, το εύρος ζώνης, την συμφόρηση κλπ. Με την παροχή συνεχούς ανάδρασης, οι αλγόριθμοι κωδικοποίησης μπορούν να προσαρμόζονται συνεχώς έτσι ώστε να παρέχουν την βέλτιστη δυνατή ποιότητα υπό τις τρέχουσες συνθήκες. Για παράδειγμα αν το bandwidth αυξάνεται ή μειώνεται, η κωδικοποίηση μπορεί να αλλάξει από MP3 σε 8μπιτη PCM ή σε κωδικοποίηση δέλτα ανάλογα με τις ανάγκες. Το πρωτόκολλο RTCP εφαρμόζει παρακολούθηση και έλεγχο στην μετάδοση δεδομένων. Επίσης, επιβλέπει το μοίρασμα των πόρων καθώς και τον συγχρονισμό - ομαλό υποβιβασμό των μέσων. Τέλος το RTCP λειτουργεί μαζί με το πρωτόκολλο RTP.


Η κύριες λειτουργείς του RTCP είναι οι εξής:

  • Παρακολούθηση ποιότητας υπηρεσιών (QoS monitoring) καθώς και έλεγχο συμφόρησης (congestion control)

  • Αναγνώριση αποστολέα (source identification)

  • Συγχρονισμός μέσων (inter-media synchronization)

  • Έλεγχος του αριθμού των συμμετεχόντων (control information scaling)


Ένα RTCP πακέτο αποτελείται από το τμήμα της επικεφαλίδας και ακολουθούν δομημένα στοιχεία ανάλογα με τον τύπο του πακέτου. Υπάρχουν βέβαια διάφορα είδη RTCP πακέτων, τα οποία ενσωματώνονται σε ένα UDP πακέτο και είναι τα εξής:


  1. Αναφορά αποστολέα - παραλήπτη (sender - SR / receiver - RR reports)

  2. Περιγραφής πηγή - αποστολέα (Source Description)

  3. Πακέτο αποχαιρετισμού (Goodbye - BYE)

  4. Συγκεκριμένες συναρτήσεις εφαρμογής (Application Specific - APP)




Τύποι RTCP μηνυμάτων




RTCP: Πακέτο αναφοράς αποστολέα


Παρακάτω ακολουθεί αναλυτική εξήγηση των πεδίων στο πακέτο αναφοράς αποστολέα:




    Πακέτο αναφοράς αποστολέα
  1. Έκδοση (Version - V): Πεδίο μήκους 2 bits το οποίο εντοπίζει την έκδοση του RTP η οποία είναι ίδια και στα RTCP πακέτα όπως και στα RTP πακέτα δεδομένων. Η έκδοση που έχει οριστεί είναι η version 2.


  2. Συμπλήρωσης (Padding - P): Πεδίο μήκους 1 bit. Αν αυτό το πεδίο οριστεί τότε αυτό το RTCP πακέτο μεταφέρει κάποια αντίστοιχα padding bytes στο τέλος του πακέτου και τα οποία δεν αποτελούν μέρος του ελέγχου πληροφορίας. Το τελευταίο byte του padding είναι ουσιαστικά ένας μετρητής για το πόσα padding bytes πρέπει να αγνοηθούν. Η τεχνική padding μπορεί να χρειαστεί σε αλγόριθμους κρυπτογράφησης που απαιτούν blocks σταθερού μεγέθους.


  3. Αριθμός αναφορών παραλήπτη (Reception Report Count - RC): Πεδίο μήκους 5 bits, το οποίο περιέχει τον αριθμό των block αναφορών παραλήπτη που περιέχονται σε ένα πακέτο.


  4. Τύπος Πακέτου (Packet Type - PT): Πεδίο μήκους 8 bits το οποίο όταν έχει την τιμή 200 όταν πρόκειται για RTCP πακέτο αναφοράς αποστολέα


  5. Μήκος Πακέτου (Length - L): Πεδίο μήκους 16 bits, το οποίο υποδεικνύει το μήκος του RTCP πακέτου


  6. SSRC Αποστολέα: Πεδίο μήκους 32 bits, όπου αποτελεί την ένδειξη συγχρονισμού πηγής του δημιουργού αυτού του πακέτου αναφοράς αποστολέα




  7. Πακέτο αναφοράς αποστολέα


  8. NTP Χρονοσφραγίδα (NTP Timestamp) - NTS): Πεδίο μήκους 64 bits το οποίο δείχνει την ώρα (ώρα ρολογιού) που στάλθηκε μια αναφορά. Αυτή η πληροφορία μπορεί να χρησιμοποιηθεί σε συνδυασμό με τις χρονοσφραγίδες που επιστρέφονται από άλλους παραλήπτες (στις αναφορές RR) έτσι ώστε να γίνει η μέτρηση του Round-Trip (διάδοσης μετ' επιστροφής) τους.


  9. RTP Χρονοσφραγίδα (RTP Timestamp): Ανταποκρίνεται στον ίδιο χρόνο με την NTP χρονοσφραγίδα αλλά χρησιμοποιεί τις μονάδες μέτρησης με τις RTP χρονοσφραγίδες. Αυτή η αντιστοιχία μπορεί να χρησιμοποιηθεί για τον συγχρονισμό εξωτερικών και εσωτερικών δεδομένων όπου οι πηγές τους συγχρονίζονται με NTP χρονοσφραγίδες. Επίσης μπορεί να χρησιμοποιηθεί κι από παραλήπτες (ανεξάρτητα από τα δεδομένα που έχουν) για να υπολογίσουν την μέση συχνότητα του RTP ρολογιού. Επιπλέον στις περισσότερες περιπτώσεις αυτή η χρονοσφραγίδα δεν θα είναι ίση με άλλες RTP χρονοσφραγίδες σε γειτονικά πακέτα. Συνεπώς η RTP χρονοσφραγίδα θα πρέπει να υπολογιστεί από την αντίστοιχη NTP χρονοσφραγίδα. Αυτό γίνεται χρησιμοποιώντας την σχέση μεταξύ του μετρητή της RTP χρονοσφραγίδας και του πραγματικού χρόνου (που έκανε το πακέτο αυτό) όπως αυτός διατηρείται ελέγχοντας ανά συγκεκριμένα διαστήματα την ώρα κατά την διάρκεια μιας δειγματοληψίας.


  10. Απαρίθμηση πακέτου αποστολέα (Sender's Packet Count - SPC): Πεδίο μήκους 32 bits το οποίο υποδεικνύει τον συνολικό αριθμό των RTP πακέτων δεδομένων που μεταδίδονται από τον αποστολέα από την στιγμή που συνδέεται σε μια RTP σύνοδο (RTP Session) έως την στιγμή που δημιουργείται το πακέτο αναφοράς αποστολέα. Ο συγκεκριμένος μετρητής πρέπει να γίνεται reset αν ο αποστολέας αλλάξει το SSRC αναγνωριστικό του.


  11. Απαρίθμηση bytes αποστολέα (Sender's Octet Count - SOC): Πεδίο μήκους 32 bits το οποίο υποδεικνύει τον συνολικό αριθμό από bytes (εξαιρουμένου της επικεφαλίδας και των padding bits) που μεταδίδονται σε ένα RTP πακέτο δεδομένων από τον αποστολέα την στιγμή που θα αρχίσει η μετάδοση δεδομένων εως ότου δημιουργηθεί το πακέτο αναφοράς αποστολέα. Αυτός ο μετρητής πρέπει να γίνει reset αν ο αποστολέας αλλάξει το SSRC αναγνωριστικό του. Τέλος αυτό το πεδίο μπορεί να χρησιμοποιηθεί για να υπολογίσει το μέσο ρυθμό ωφέλιμων δεδομένων (payload data rate).




  12. Πληροφορίες αποστολέα στο πακέτο αναφοράς αποστολέα (SR)


  13. SSRC_n (Source identifier): Το αναγνωριστικό SSRC πηγής η οποία περιγράφεται απ' τις πληροφορίες του block αναφοράς παραλήπτη


  14. Fraction lost: Αποτελεί το κλάσμα απώλειας των RTP πακέτων μιας πηγής SSRC_n από την στιγμή που στάλθηκε κάποιο προηγούμενο SR ή RR πακέτο. Εκφράζεται ως ένας αριθμός με σταθερά ψηφία, με τα δυαδικά του ψηφία να βρίσκονται στην αριστερή πλευρά του πεδίου (δηλαδή ξεκινάει με δυαδικά και τελειώνει με δεκαδικά).




  15. Εξίσωση υπολογισμού τιμής πεδίου fraction lost


    Ουσιαστικά παίρνουμε το κλάσμα απώλειας, το πολλαπλασιάζουμε με τον αριθμό 256 κι από αυτό προκύπτει ένα γινόμενο το ακέραιο μέρος του οποίου αποτελεί την τιμή αυτού του πεδίου. Αυτό το κλάσμα απώλειας ορίζεται ως αριθμός των πακέτων που χάθηκαν διαιρούμενος με τον αριθμό των πακέτων τα οποία αναμένονται να φτάσουν. Αν το κλάσμα απώλειας είναι αρνητικός αριθμός (προφανώς λόγω διπλότυπων πακέτων, το fraction lost παίρνει την τιμή 0. Επίσης ο παραλήπτης δεν είναι σε θέση να γνωρίζει αν χάθηκαν πακέτα μετά την παραλαβή και του τελευταίου πακέτου. Συνεπώς, αν χαθούν όλα τα πακέτα δεν θα υπάρξει block αναφοράς παραλήπτη.



  16. Συνολικός αριθμός χαμένων πακέτων: Πεδίο μήκους 24 bits το οποίο αποτελεί τον συνολικό αριθμό των RTP πακέτων που έχουν χαθεί σε μια SSRC_n πηγή κατά την διάρκεια μετάδοσης τους. Η τιμή αυτού του πεδίου προκύπτει από τον αριθμό των πακέτων που αναμένει ο παραλήπτης μείον τον αριθμό των πακέτων που παρέλαβε ο παραλήπτης (συμπεριλαμβανομένων διπλότυπων ή καθυστερημένων πακέτων).




  17. Εύρεση συνολικού αριθμού χαμένων πακέτων


    Αυτό σημαίνει ότι τα πακέτα που φτάνουν αργοπορημένα στον παραλήπτη δεν προσμετρούνται σαν χαμένα πακέτα. Ο αριθμός πακέτων που αναμένει ο παραλήπτης είναι ο μέγιστος αριθμός ακολουθίας ενώ ο αριθμός πακέτων που έλαβε ο παραλήπτης, είναι πρώτος αριθμός ακολουθίας του πρώτου πακέτου που έλαβε.


  18. Υψηλότερος επεκτεινόμενος αριθμός ακολουθίας που έχει παραληφθεί EHSN: Πεδίο μήκους 32 bits. Τα λιγότερο σημαντικά (least significant) 16 bits περιέχουν τον μέγιστο αριθμό ακολουθίας σε ένα από τα RTP πακέτα που προέρχονται από μια SSRC_n πηγή. Τα πιο σημαντικά 16 bits επεκτείνουν αυτόν τον αριθμό ακολουθίας με τον αντίστοιχο αριθμό κύκλων που κάνουν οι αριθμοί ακολουθίας.


  19. Inter-arrival Jitter: Πεδίο μήκους 32 bits, το οποίο περιέχει την εκτίμηση της στατιστικής διακύμανσης του χρόνου αφίξεως των εισερχόμενων RTP πακέτων (inter-arrival jitter). Το interarrival jitter ή αλλιώς J είναι η μέση απόκλιση (στρογγυλοποιημένη απόλυτη τιμή) της διαφοράς D όσον αφορά τον χρονικό οριο των πακέτων ανάμεσα σε αποστολέα και παραλήπτη. Στην εξίσωση της επόμενης διαφάνειας αυτό το φαινόμενο αντιστοιχείται με την διαφορά του χρόνου σχετικής διέλευσης (relative transit time) για δυο πακέτα.




  20. Το interarrival jitter πρέπει να υπολογίζεται συνεχόμενα σε κάθε πακέτο i που λαμβάνουμε απο μια πηγή SSRC_n, χρησιμοποιώντας την διαφορά D (χρόνος σχετικής διέλευσης) για τρέχον πακέτο και το προηγούμενο απ' αυτό i-1 πακέτο, (σε σειρά άφιξης κι όχι απαραίτητα ακολουθίας), σύμφωνα πάντα με τον παρακάτω τύπο:




    Όταν μια αναφορά παραλήπτη δημιουργείται, δειγματοληπτείται η τρέχουσα τιμή του J.


  21. Χρονοσφραγίδα τελευταίας αναφοράς παραλήπτη (LSR): Πεδίο μήκους 32 bits τα μεσαία 32 απο τα 64 bits της χρονοσφραγίδας λαμβάνονται ως τμήμα του πιο πρόσφατου πακέτου RTCP αναφοράς αποστολέα απο μια πηγή SSRC_n. Αν δεν έχει φτάσει μια αναφορά αποστολέα (SR) τότε το πεδίο αυτό παίρνει την τιμή 0.


  22. Καθυστέρηση από το τελευταίο SR: Η καθυστέρηση ορίζεται σε μονάδες του 1/65536 δευτερολέπτων. Πρώτα γίνεται η παραλαβή του τελευταίου πακέτου αναφοράς αποστολέα από μια πηγή SSRC_n, ακολουθεί η καθυστέρηση από το τελευταίο SR και τέλος αποστέλλεται αυτό το block αναφορά παραλήπτη. Αν δεν έχει παραληφθεί πακέτο αναφοράς αποστολέα από μια πηγή SSRC_n τότε το πεδίο αυτό παίρνει την τιμή 0.



  23. Πλαίσιο αναφοράς 1 στο πακέτο αναφοράς αποστολέα (SR)

RTCP: Πακέτο αναφοράς παραλήπτη

Η αναφορά παραλήπτη χρησιμοποιείται μη ενεργούς συμμετέχοντες, οι οποίοι δεν στέλνουν RTP πακέτα. Η αναφορά παραλήπτη ενημερώνει τον αποστολέα και τους υπόλοιπους παραλήπτες για την ποιότητα υπηρεσιών. Η δομή του πακέτου αναφοράς παραλήπτη είναι ιδιά με αυτήν του πακέτου αναφοράς αποστολέα με την διαφορά ότι το πεδίο τύπου πακέτου περιέχει την σταθερά 201 και επίσης παραλείπονται οι πληροφορίες αποστολέα. Τα υπόλοιπα πεδία έχουν ακριβώς το ίδιο νόημα όπως και στο πακέτο αναφοράς αποστολέα.





Πακέτο αναφοράς παραλήπτη


RTCP: Πακέτο περιγραφής πηγής

Μια πηγή στέλνει περιοδικά ένα πακέτο περιγραφής πηγής για να παρέχει περισσότερες πληροφορίες για την ίδια. Αυτές οι πληροφορίες μπορεί να περιέχουν το όνομα, την διεύθυνση ηλεκτρονικού ταχυδρομείο (e-mail), τον αριθμό τηλεφώνου, και την διεύθυνση του διαχειριστή αυτής της πηγής.




Πακέτο περιγραφής πηγής


RTCP: Πακέτο Αποχωρισμού (BYE)

Μια πηγή στέλνει πακέτο αποχωρισμού (Bye message) για να τερματιστεί μια ροή. Αυτό το πακέτο δίνει την δυνατότητα στην πηγή να ανακοινώσει την αποχώρηση της από μια σύνοδο. Πιο απλά χρησιμοποιείται από κάποια πηγή για να δηλώσει ότι εγκαταλείπει μια σύνοδο. Το πακέτο αυτό δεν είναι απαραίτητο, αλλά η χρήση συμβάλει στην αποδοτική κατανομή του διαθέσιμου εύρους ζώνης.



Πακέτο Αποχωρισμού (BYE)


RTCP: Πακέτο Συγκεκριμένων Συναρτήσεων Εφαρμογής (APP)

Το πακέτο συγκεκριμένων συναρτήσεων εφαρμογής απευθύνεται σε εφαρμογές οι οποίες απαιτούν την χρήση νέων εφαρμογών. Έχει πειραματική χρήση (για νέες εφαρμογές).



Πακέτο Συγκεκριμένων Συναρτήσεων Εφαρμογής (APP)


Τελευταία ενημέρωση: 26/04/2018





Follow us

 ☰