Κεφάλαιο 6. ικτυακές εφαρµογές πολυµέσων. Κεφάλαιο 6: Στόχοι. Εφαρµογές Πολυµέσων και Ποιότητα Υπηρεσίας

Κεφάλαιο 6 ικτυακές εφαρµογές πολυµέσων Εφαρµογές Πολυµέσων και Ποιότητα Υπηρεσίας Εφαρµογές πολυµέσων (multmeda applcatons): ήχος και βίντεο µέσω δικτύου (εφαρµογές συνεχών µέσων ) Πηγή των ακόλουθων διαφανειών είναι οι διαφάνειες που συνοδεύουν ως διδακτικό υλικό το βιβλίο των J.F. Kurose and K.W. Ross: Computer Networkng: A Top-Down Approach Featurng the Internet, 2η έκδοση Computer Networkng: A Top Down Approach Featurng the Internet, 2 nd edton. Jm Kurose, Keth Ross Addson-Wesley, July 2002. 6-1 Ποιότητα Υπηρεσίας (Qualty of Servce) QoS το δίκτυο παρέχει στην εφαρµογή το επίπεδο απόδοσης που απαιτείται για να λειτουργεί η εφαρµογή 6-2 Κεφάλαιο 6: Στόχοι Αρχές Ταξινόµηση εφαρµογών πολυµέσων Προσδιορισµός υπηρεσιών δικτύου που χρειάζονται οι εφαρµογές Βέλτιστη δυνατή αξιοποίηση της υπηρεσίας βέλτιστης προσπάθειας Μηχανισµοί παροχής Ποιότητας Υπηρεσίας (Qualty of Servce, QoS) Πρωτόκολλα και Αρχιτεκτονικές Πρωτόκολλα για την υπηρεσία βέλτιστης προσπάθειας RTP, SIP, H.323 Αρχιτεκτονικές που παρέχουν εγγυήσεις QoS Ενοποιηµένες υπηρεσίες, ιαφοροποιηµένες υπηρεσίες 6-3 Κεφάλαιο 6 6.1 ικτυακές εφαρµογές πολυµέσων 6.2 Εφαρµογές µετάδοσης αποθηκευµένου ήχου και βίντεο µε συνεχή ροή RTSP 6.3 Αξιοποιώντας την υπηρεσία βέλτιστης προσπάθειας: ένα παράδειγµα ιαδικτυακού τηλεφώνου 6.4 Πρωτόκολλα για διαδραστικές εφαρµογές πραγµατικού χρόνου RTP, RTCP SIP 6.5 Πέρα από τα όρια της βέλτιστης προσπάθειας 6.6 Μηχανισµοί χρονοπρογραµµατισµού και αστυνόµευσης 6.7 Ενοποιηµένες 6.8 Πρωτόκολλο RSVP 6.9 ιαφοροποιηµένες 6-4 1

Άθροισµα δεδοµένων Κατηγορίες εφαρµογών πολυµέσων: 1) Εφαρµογές µετάδοσης αποθηκευµένου ήχου και βίντεο µε συνεχή ροή (Streamng stored audo/vdeo) 2) Εφαρµογές ζωντανής µετάδοσης ήχου και βίντεο µε συνεχή ροή (Streamng lve audo/vdeo) 3) ιαδραστικές εφαρµογές µετάδοσης ήχου και βίντεο σε πραγµατικό χρόνο (Real-tme nteractve audo/vdeo) Jtter: η µεταβλητότητα της καθυστέρησης των πακέτων που ανήκουν στην ίδια ροή Βασικά χαρακτηριστικά: ευαισθησία ως προς τις καθυστερήσεις καθυστέρηση από άκρο σε άκρο (ολική) µεταβλητότητα καθυστέρησης ανοχή ως προς τις απώλειες: περιστασιακές απώλειες προκαλούν µικρές ανωµαλίες Σε αντίθεση µε τα δεδοµένα που παρουσιάζουν ανοχή στις καθυστερήσεις όχι όµως στις απώλειες 6-5 Εφαρµογές µετάδοσης αποθηκευµένων πολυµέσων µε συνεχή ροή Συνεχής ροή (Streamng): τα µέσα είναι αποθηκευµένα στην πηγή µεταδίδονται στον clent συνεχής ροή: ο clent αρχίζει την αναπαραγωγή πριν ολοκληρωθεί η παραλαβή των δεδοµένων χρονικός περιορισµός για τα δεδοµένα που δεν έχουν µεταδοθεί ακόµη από τον server: πρέπει να φθάσουν στον clent έγκαιρα για την αναπαραγωγή τους 6-6 Εφαρµογές µετάδοσης αποθηκευµένων πολυµέσων µε συνεχή ροή Συνεχής ροή: Εφαρµογές µετάδοσης αποθηκευµένων πολυµέσων µε συνεχή ροή 1. εγγραφή βίντεο 2. αποστολή βίντεο καθυστέρηση δικτύου 3. παραλαβή βίντεο, αναπαραγωγή στον clent χρόνος συνεχής ροή: τη χρονική αυτή στιγµή, ο clent αναπαράγει ένα µέρος του βίντεο που έλαβε προηγουµένως, ενώ ο server εξακολουθεί να στέλνει µέρη του βίντεο που έπονται ιαδραστικότητα (Interactvty): ο clent µπορεί να ελέγξει τη λειτουργία µε εντολές όπως pause, rewnd, fast forward κλπ (όπως σε ένα VCR, για παράδειγµα) συχνά χρησιµοποιείται το RTSP 6-7 6-8 2

Εφαρµογές ζωντανής µετάδοσης πολυµέσων µε συνεχή ροή Παραδείγµατα Ζωντανή µετάδοση ραδιοφωνικής εκποµπής στο ιαδίκτυο Ζωντανή µετάδοση αθλητικού γεγονότος στο ιαδίκτυο Συνεχής ροή χρονικοί περιορισµοί ως προς την αναπαραγωγή αντίστοιχοι µε αυτούς σε εφαρµογές µετάδοσης αποθηκευµένων πολυµέσων µε συνεχή ροή η αναπαραγωγή µπορεί να αρχίσει µε καθυστέρηση µερικών δεκάδων δευτερολέπτων από τη στιγµή που ο χρήστης θα ζητήσει τη µετάδοση ιαδραστικότητα αδύνατη η λειτουργία fast forward δυνατές οι λειτουργίες rewnd, pause ιαδραστικές εφαρµογές µετάδοσης πολυµέσων σε πραγµατικό χρόνο Παραδείγµατα ιαδικτυακή τηλεφωνία (IP telephony) Βιντεοδιάσκεψη (vdeo conference) Απαιτήσεις καθυστέρησης από άκρο σε άκρο: αυστηρότερες από ότι για εφαρµογές streamng stored multmeda ή streamng lve multmeda ήχος: καθυστερήσεις < 150 msec δεν γίνονται αντιληπτές 150 msec < καθυστερήσεις < 400 msec αποδεκτές καθυστερήσεις > 400 msec επηρεάζουν τη δυνατότητα επικοινωνίας Σηµείωση: η καθυστέρηση από άκρο σε άκρο περιλαµβάνει εκτός από τις καθυστερήσεις στο δίκτυο και καθυστερήσεις στο επίπεδο εφαρµογής (καθυστέρηση πακετοποίησης) 6-9 6-10 Εφαρµογές πολυµέσων στο ιαδίκτυο Με ποιο τρόπο θα πρέπει να εξελιχθεί το ιαδίκτυο ώστε να παρέχει καλύτερη υποστήριξη πολυµέσων; IP: υπηρεσία βέλτιστης προσπάθειας καµία εγγύηση ως προς καθυστερήσεις, απώλειες Οι εφαρµογές πολυµέσων απαιτούν Ποιότητα Υπηρεσίας και επίπεδο απόδοσης ώστε να είναι αποτελεσµατικές Οι εφαρµογές πολυµέσων στο ιαδίκτυο χρησιµοποιούν τεχνικές στο επίπεδο εφαρµογής για να µετριάσουν (όσο καλύτερα γίνεται) την επίδραση των καθυστερήσεων και απωλειών Φιλοσοφία ενοποιηµένων υπηρεσιών: Ριζικές αλλαγές στο ιαδίκτυο ώστε οι εφαρµογές να είναι σε θέση να δεσµεύουν bandwdth από άκρο σε άκρο Απαιτεί νέο, πολύπλοκο λογισµικό σε hosts και δροµολογητές Lassez-fare: καµία σηµαντική αλλαγή περισσότερο bandwdth όπου απαιτείται διανοµή περιεχοµένου, multcast στο επίπεδο εφαρµογής επίπεδο εφαρµογής Φιλοσοφία διαφοροποιηµένων υπηρεσιών: Λιγότερες αλλαγές στην υποδοµή του ιαδικτύου ύο κλάσεις υπηρεσιών 6-11 6-12 3

Συµπίεση ηχητικού σήµατος Συµπίεση σήµατος βίντεο Το αναλογικό σήµα δειγµατοληπτείται µε σταθερό ρυθµό τηλέφωνο: 8000 δείγµατα/s µουσική CD: 44100 δείγµατα/s Κάθε δείγµα κβαντίζεται π.χ. 2 8 =256 δυνατές τιµές κβάντισης Κάθε τιµή κβάντισης παριστάνεται µε bts 8 bts για 256 τιµές Παραδείγµατα PCM: 8000 δείγµατα/s 8 bts/δείγµα = 64000 bps (τηλεφωνία) 44100 δείγµατα/s 16 bts/ δείγµα 2 κανάλια = 1,411 Mbps (µουσική CD) Ο δέκτης µετατρέπει το ψηφιακό σήµα σε αναλογικό: υποβάθµιση ποιότητας σήµατος Παραδείγµατα ρυθµών Τηλεφωνία IP: 5,3-13 kbps MP3: 96, 128, 160 kbps Βίντεο: ακολουθία εικόνων που προβάλλονται µε σταθερό ρυθµό π.χ. 24 εικόνες/sec Η ψηφιακή εικόνα είναι ένας πίνακας από pxels Κάθε pxel παριστάνεται µε bts Πλεονασµός χωρικός χρονικός Παραδείγµατα: MPEG 1 (CD-ROM) 1,5 Mbps MPEG 2 (DVD) 3-6 Mbps MPEG 4 (χρησιµοποιείται συχνά στο ιαδίκτυο) < 1 Mbps Έρευνα: κωδικοποίηση πολλαπλών επιπέδων (mult-layer) προσαρµογή των επιπέδων στο διαθέσιµο bandwdth 6-13 6-14 Κεφάλαιο 6 6.1 ικτυακές εφαρµογές πολυµέσων 6.2 Εφαρµογές µετάδοσης αποθηκευµένου ήχου και βίντεο µε συνεχή ροή RTSP 6.3 Αξιοποιώντας την υπηρεσία βέλτιστης προσπάθειας: ένα παράδειγµα ιαδικτυακού τηλεφώνου 6.4 Πρωτόκολλα για διαδραστικές εφαρµογές πραγµατικού χρόνου RTP, RTCP SIP 6.5 Πέρα από τα όρια της βέλτιστης προσπάθειας 6.6 Μηχανισµοί χρονοπρογραµµατισµού και αστυνόµευσης 6.7 Ενοποιηµένες 6.8 Πρωτόκολλο RSVP 6.9 ιαφοροποιηµένες 6-15 Εφαρµογές µετάδοσης αποθηκευµένων πολυµέσων µε συνεχή ροή Streamng stored multmeda: Το αρχείο ήχου/βίντεο είναι αποθηκευµένο στον server Ο χρήστης (clent) ζητά το αρχείο ήχου/βίντεο Μερικές δεκάδες δευτερόλεπτα µετά την αίτηση ο clent αρχίζει να λαµβάνει το αρχείο Παρέχεται συνήθως η δυνατότητα διαδραστικότητας Meda Player αποσυµπίεση αποµάκρυνση jtter διόρθωση/συγκάλυψη σφαλµάτων γραφική διεπαφή χρήστη (GUI) περιλαµβάνει κουµπιά ελέγχου (ένταση ήχου, pause/resume, rewnd, κλπ) για διαδραστικότητα 6-16 4

Πολυµέσα στο ιαδίκτυο: απλούστερη προσέγγιση Πολυµέσα στο ιαδίκτυο: συνεχής ροή από web server Web Browser (2) αρχείο ήχου/βίντεο Meda Player (1) αίτηση/απόκριση HTTP για αρχείο ήχου/βίντεο Web Server ήχος ή βίντεο αποθηκευµένα σε αρχείο το αρχείο µεταφέρεται ως αντικείµενο HTTP λαµβάνεται εξ ολοκλήρου από τον clent µετά µεταβιβάζεται στον meda player Μειονέκτηµα: ο Web browser λειτουργεί ως ενδιάµεσος µεταξύ meda player και server µεγάλες καθυστερήσεις έως την αναπαραγωγή του ήχου/βίντεο 6-17 Web Browser (2) µετά-αρχείο Meda Player (1) αίτηση/απόκριση HTTP για µετά-αρχείο (meta fle) Web Server (3) το αρχείο ήχου/βίντεο ζητείται και αποστέλλεται µέσω HTTP ο browser ζητεί και λαµβάνει το αρχείο µετά-αρχείο (meta fle) (αρχείο περιγραφής παρουσίασης του αντικειµένου) ο browser εκκινεί τον meda player στον οποίο µεταβιβάζει το µετά-αρχείο ο meda player επικοινωνεί µε τον server ο server στέλνει τον ήχο/βίντεο στον meda player µε streamng 6-18 Πολυµέσα στο ιαδίκτυο: συνεχής ροή από streamng server Streamng Server: επιλογές Web Browser (2) αρχείο περιγραφής παρουσίασης Meda Player (1) αίτηση/απόκριση HTTP για αρχείο περιγραφής παρουσίασης (3) το αρχείο ήχου/βίντεο ζητείται και αποστέλλεται Web Server Streamng Server Υπάρχουν διάφορες επιλογές όσον αφορά την παράδοση ενός αρχείου ήχου/βίντεο από τον streamng server στον meda player: προσωρινή αποθήκευση (bufferng) στον clent καθυστέρηση έναρξης αναπαραγωγής για την αποµάκρυνση του jtter χρήση UDP έναντι χρήσης TCP Ηαρχιτεκτονική αυτή επιτρέπει τη χρήση µεταξύ streamng server και meda player πρωτοκόλλων διαφορετικών από το HTTP Μπορεί επίσης να χρησιµοποιηθεί UDP αντί για TCP 6-19 6-20 5

Άθροισµα δεδοµένων Πολυµέσα συνεχούς ροής: προσωρινή αποθήκευση στον clent µετάδοση βίντεο µε σταθερό ρυθµό µεταβλητή καθυστέρηση δικτύου καθυστέρηση αναπαραγωγής στον clent παραλαβή βίντεο από τον clent αποθηκευµένο βίντεο αναπαραγωγή βίντεο µε σταθερό ρυθµό στον clent χρόνος Η προσωρινή αποθήκευση στην πλευρά του clent και η καθυστέρηση αναπαραγωγής αντισταθµίζουν τη µεταβλητότητα της καθυστέρησης (jtter) 6-21 Πολυµέσα συνεχούς ροής: προσωρινή αποθήκευση στον clent από το δίκτυο µεταβλητός ρυθµός πλήρωσης x(t) buffer στον clent προσωρινά αποθηκευµένο βίντεο σταθερός ρυθµός απορροής d προς αποσυµπίεση και αναπαραγωγή Ο buffer του clent γεµίζει µε µεταβλητό ρυθµό x(t) (fll rate) και αδειάζει µε σταθερό ρυθµό d (dran rate) 6-22 Πολυµέσα συνεχούς ροής: UDP ή TCP; Πολυµέσα συνεχούς ροής: ρυθµός του clent UDP ο server στέλνει µε ρυθµό κατάλληλο για τον clent (αδιαφορώντας για τη συµφόρηση στο δίκτυο) συχνά, ρυθµός αποστολής = ρυθµός κωδικοποίησης = σταθ. = d οπότε, x(t) = d ρυθµός απωλειών πακέτων µικρή καθυστέρηση αναπαραγωγής (2-5 δευτερόλεπτα) για την αντιστάθµιση του jtter ανάκαµψη από σφάλµατα εφόσον το επιτρέπουν οι χρονικοί περιορισµοί TCP ο server στέλνει µε το µέγιστο δυνατό ρυθµό που επιτρέπει το TCP ο ρυθµός πλήρωσης εµφανίζει διακυµάνσεις λόγω ελέγχου συµφόρησης και ροής στο TCP µεγαλύτερη καθυστέρηση αναπαραγωγής για την εξοµάλυνση του ρυθµού παράδοσης του TCP HTTP/TCP διέρχεται ευκολότερα από frewalls 6-23 ρυθµός κωδικοποίησης 1,5 Mbps ρυθµός κωδικοποίησης 28,8 kbps Ορυθµός µε τον οποίο µπορεί να λαµβάνει ο clent εξαρτάται από το είδος πρόσβασης στο δίκτυο π.χ. 28,8 kbps dalup 100 Mbps Ethernet Ο server διαθέτει πολλαπλά αντίγραφα ενός βίντεο µε διαφορετικούς ρυθµούς κωδικοποίησης 6-24 6

Έλεγχος µέσων συνεχούς ροής από τον χρήστη: RTSP RTSP: έλεγχος out of band HTTP εν σχεδιάσθηκε για συνεχή µέσα εν υποστηρίζει την αλληλεπίδραση του χρήστη µε τον server δεν παρέχει εντολές για fast forward, pause κλπ. RTSP [RFC 2326]: Πρωτόκολλο clent-server στο επίπεδο εφαρµογής Επιτρέπει τον έλεγχο παρουσίασης από το χρήστη: rewnd, fast forward, pause, resume κλπ. Το RTSP: δεν ορίζει µεθόδους συµπίεσης για ήχο/βίντεο δεν ορίζει τον τρόπο ενθυλάκωσης του ήχου/βίντεο σε πακέτα για µετάδοση στο δίκτυο δεν επιβάλλει περιορισµούς στον τρόπο µεταφοράς των µέσων: µπορεί να χρησιµοποιηθεί UDP ή TCP δεν καθορίζει τον τρόπο µε τον οποίο ο meda player αποθηκεύει τον ήχο/βίντεο Το FTP χρησιµοποιεί ένα κανάλι ελέγχου out-of-band : Ένα αρχείο µεταφέρεται µέσω µίας σύνδεσης TCP (κανάλι δεδοµένων) Πληροφορία ελέγχου (αλλαγή καταλόγου, διαγραφή αρχείου κλπ.) µεταφέρεται µέσω µίας ξεχωριστής σύνδεσης TCP (κανάλι ελέγχου) Τα κανάλια ελέγχου ( out-ofband ) και δεδοµένων ( nband ) χρησιµοποιούν διαφορετικούς αριθµούς θύρας Τα µηνύµατα του RTSP στέλνονται επίσης out-ofband : Τα µηνύµατα ελέγχου του RTSP χρησιµοποιούν διαφορετικό αριθµό θύρας από το meda stream αριθµός θύρας 554 Το meda stream θεωρείται n-band 6-25 6-26 Παράδειγµα RTSP Σενάριο: ο web browser ζητά και λαµβάνει το αρχείο περιγραφής παρουσίασης (meta fle) ο browser εκκινεί τον meda player εγκαθιδρύεται RTSP sesson µεταξύ meda player και streamng server µεταφορά δεδοµένων από τον streamng server στον meda player Παράδειγµα Meta fle <ttle>twster</ttle> <sesson> <group language=en lpsync> <swtch> <track type=audo e="pcmu/8000/1" src = "rtsp://audo.example.com/twster/audo.en/lof"> <track type=audo e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audo.example.com/twster/audo.en/hf"> </swtch> <track type="vdeo/jpeg" src="rtsp://vdeo.example.com/twster/vdeo"> </group> </sesson> 6-27 6-28 7

Λειτουργία του RTSP Παράδειγµα ανταλλαγών µηνυµάτων στο RTSP C: SETUP rtsp://audo.example.com/twster/audo.en RTSP/1.0 Transport: rtp/udp; compresson; port=3056; mode=play S: RTSP/1.0 200 OK Sesson: 4231 C: PLAY rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Sesson: 4231 Range: npt=0- C: PAUSE rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Sesson: 4231 Range: npt=37 C: TEARDOWN rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Sesson: 4231 S: RTSP/1.0 200 OK 6-29 6-30 Κεφάλαιο 6 6.1 ικτυακές εφαρµογές πολυµέσων 6.2 Εφαρµογές µετάδοσης αποθηκευµένου ήχου και βίντεο µε συνεχή ροή RTSP 6.3 Αξιοποιώντας την υπηρεσία βέλτιστης προσπάθειας: ένα παράδειγµα ιαδικτυακού τηλεφώνου 6.4 Πρωτόκολλα για διαδραστικές εφαρµογές πραγµατικού χρόνου RTP, RTCP SIP 6.5 Πέρα από τα όρια της βέλτιστης προσπάθειας 6.6 Μηχανισµοί χρονοπρογραµµατισµού και αστυνόµευσης 6.7 Ενοποιηµένες 6.8 Πρωτόκολλο RSVP 6.9 ιαφοροποιηµένες 6-31 ιαδραστικές εφαρµογές µετάδοσης πολυµέσων σε πραγµατικό χρόνο ιαδικτυακή τηλεφωνία από PC σε PC από PC σε τηλέφωνο Dalpad Net2phone Βιντεοδιάσκεψη µε Webcams Θα εξετάσουµε ένα παράδειγµα ιαδικτυακής τηλεφωνίας από PC σε PC 6-32 8

ιαδικτυακή τηλεφωνία ένα σήµα φωνής αποτελείται από εναλλασσόµενες περιόδους οµιλίας (talk spurts) και περιόδους σιωπής (slent perods) πακέτα παράγονται µόνο κατά τη διάρκεια των talk spurts ρυθµός γένεσης πληροφορίας: 64 kbps (8 kbytes/sec) κατά τη διάρκεια ενός talk spurt η εφαρµογή παράγει 160 bytes δεδοµένων κάθε 20 msec σε κάθε 160 bytes δεδοµένων προστίθεται µία επικεφαλίδα επιπέδου εφαρµογής δεδοµένα και επικεφαλίδα ενθυλακώνονται σε ένα UDP segment η εφαρµογή στέλνει ένα UDP segment κάθε 20 msec κατά τη διάρκεια ενός talkspurt 6-33 ιαδικτυακή τηλεφωνία: απώλειες και καθυστέρηση πακέτων απώλειες δικτύου: ένα πακέτο (datagram) χάνεται λόγω συµφόρησης στο δίκτυο (υπερχείλιση στους buffers των δροµολογητές) απώλειες καθυστέρησης: ένα πακέτο που φθάνει στον παραλήπτη καθυστερηµένα (µετά τον προγραµµατισµένο χρόνο αναπαραγωγής) θεωρείται ότι έχει χαθεί κάθε πακέτο υφίσταται καθυστερήσεις στους δροµολογητές και τις ζεύξεις του δικτύου (επεξεργασία, αναµονή στην ουρά, µετάδοση, διάδοση) και στα τερµατικά συστήµατα (αποστολέα, παραλήπτη) τυπική τιµή µέγιστης ανεκτής καθυστέρησης: 400 ms ανοχή στις απώλειες: ανάλογα µε τη µέθοδο κωδικοποίησης της φωνής και τη µέθοδο συγκάλυψης των απωλειών, οι εφαρµογές αυτές µπορούν να ανεχθούν ρυθµό απωλειών πακέτων µεταξύ 1% και 10% 6-34 άθροισµα δεδοµένων ιαδικτυακή τηλεφωνία: µεταβλητότητα καθυστέρησης (jtter) µετάδοση µε σταθερό ρυθµό µεταβλητή καθυστέρηση δικτύου (jtter) καθυστέρηση αναπαραγωγής παραλαβή από τον clent αποθηκευµένα δεδοµένα αναπαραγωγή µε σταθερό ρυθµό στον clent Θεωρείστε τις καθυστερήσεις από άκρο σε άκρο (end-to-end) δύο διαδοχικών πακέτων: η διαφορά µπορεί να είναι µικρότερη ή µεγαλύτερη από 20 msec Για την αποµάκρυνση του jtter χρησιµοποιούνται σε συνδυασµό αριθµοί ακολουθίας, χρονοσφραγίδες (tmestamps) και καθυστέρηση αναπαραγωγής χρόνος ιαδικτυακή Τηλεφωνία: σταθερή καθυστέρηση αναπαραγωγής ο παραλήπτης επιχειρεί να αναπαράγει κάθε κοµµάτι των 160 bytes ακριβώς q msecs µετά από τη στιγµή που παρήχθη το κοµµάτι εάν ένα κοµµάτι έχει χρονοσφραγίδα t, τότε ο χρόνος για την αναπαραγωγή του είναι t+q εάν το κοµµάτι φθάσει µετά το χρόνο t+q, δηλαδή καθυστερηµένα για την αναπαραγωγή, ο παραλήπτης το απορρίπτει Επιλογή της τιµής του q: µεγάλη τιµή q: λιγότερες απώλειες πακέτων µικρή τιµή q: καλύτερη διαδραστική επικοινωνία 6-35 6-36 9

Σταθερή καθυστέρηση αναπαραγωγής Ο αποστολέας παράγει ένα πακέτο κάθε 20 msec κατά τη διάρκεια του talk spurt Το πρώτο πακέτο λαµβάνεται τη χρονική στιγµή r Περίπτωση 1: η αναπαραγωγή αρχίζει τη χρονική στιγµή p Περίπτωση packets 2: η αναπαραγωγή αρχίζει τη χρονική στιγµή p πακέτα παραγόµενα packets generated πακέτα λαµβανόµενα packets receved πακέτα r p απώλεια loss p' καθυστέρηση playout schedule αναπαραγωγής p' - r p r playout καθυστέρηση schedule αναπαραγωγής p - r p r tme χρόνος 6-37 Προσαρµοστική καθυστέρηση αναπαραγωγής (1) Στόχος: ελαχιστοποίηση της καθυστέρησης αναπαραγωγής υπό τη συνθήκη χαµηλού ρυθµού απωλειών λόγω καθυστέρησης Προσέγγιση: προσαρµοστική ρύθµιση της καθυστέρησης αναπαραγωγής: εκτίµηση της καθυστέρησης δικτύου, ρύθµιση της καθυστέρησης αναπαραγωγής στην αρχή κάθε talk spurt οι περίοδοι σιωπής συµπιέζονται και επιµηκύνονται τα πακέτα αναπαράγονται κάθε 20 msec κατά τη διάρκεια του talk spurt t = χρονοσφραγίδα πακέτου r = χρονική στιγµή λήψης πακέτου από τον παραλήπτη p = χρονική στιγµή αναπαραγωγής πακέτου στον παραλήπτη r t = καθυστέρηση δικτύου για το πακέτο d = εκτίµηση της µέσης καθυστέρησης δικτύου µετά τη λήψη του πακέτου υναµική εκτίµηση της µέσης καθυστέρησης στον παραλήπτη: d = όπου u σταθερά (π.χ. u = 0.01) ( 1 u) d 1 + u( r t ) 6-38 Προσαρµοστική καθυστέρηση αναπαραγωγής (2) Εκτίµηση της µέσης απόκλισης της καθυστέρησης, v : v = ( 1 u) v 1 + u r t d Οι εκτιµήσεις d and v υπολογίζονται για κάθε λαµβανόµενο πακέτο, χρησιµοποιούνται όµως µόνο στην αρχή κάθε talk spurt Η χρονική στιγµή αναπαραγωγής για το πρώτο πακέτο ενός talk spurt (έστω πακέτο ) είναι: p = t + d + Kv όπου K θετική σταθερά Τα υπόλοιπα πακέτα στο talkspurt αναπαράγονται περιοδικά Προσαρµοστική καθυστέρηση αναπαραγωγής (3) Για την εφαρµογή της µεθόδου απαιτείται ο προσδιορισµός του πρώτου πακέτου σε κάθε talkspurt Στην περίπτωση χωρίς απώλειες, ο παραλήπτης εξετάζει τις διαδοχικές χρονοσφραγίδες διαφορά διαδοχικών χρονοσφραγίδων > 20 msec έναρξη talk spurt Στην περίπτωση µε απώλειες, ο παραλήπτης πρέπει να εξετάσει και τις χρονοσφραγίδες και τους αριθµούς ακολουθίας διαφορά διαδοχικών χρονοσφραγίδων > 20 msec και συνεχόµενοι αριθµοί ακολουθίας έναρξη talk spurt 6-39 6-40 10

Ανάκαµψη από απώλειες πακέτων (1) Ανάκαµψη από απώλειες πακέτων (2) forward error correcton (FEC): απλή µέθοδος για κάθε οµάδα από n κοµµάτια δηµιουργείται ένα πλεονάζον κοµµάτι, εφαρµόζοντας xor στα n αρχικά κοµµάτια µεταδίδονται n+1 κοµµάτια, µε αποτέλεσµα την αύξηση του απαιτούµενου bandwdth κατά ένα παράγοντα 1/n εάν χαθεί το πολύ ένα κοµµάτι, τότε τα n αρχικά κοµµάτια µπορούν να ανακατασκευασθούν από τα n+1 λαµβανόµενα κοµµάτια Η καθυστέρηση αναπαραγωγής πρέπει να είναι τουλάχιστον ίση µε το χρόνο που απαιτείται για να ληφθούν και τα n+1 κοµµάτια Επιλογή της τιµής του n: Για µεγάλες τιµές του n, µικρότερη σπατάλη bandwdth µεγαλύτερη καθυστέρηση αναπαραγωγής µεγαλύτερη πιθανότητα να χαθούν 2 ή περισσότερα κοµµάτια εύτερη µέθοδος FEC παράλληλη αποστολή δεύτερου audo stream χαµηλότερης ποιότητας (πλεονασµός) π.χ. κύριο audo stream κωδικοποιηµένο µε PCM στα 64 kbps και πλεονάζον audo stream κωδικοποιηµένο µε GSM στα 13 kbps Εάν δεν έχουµε απώλειες γειτονικών πακέτων, ο παραλήπτης µπορεί να συγκαλύψει τις απώλειες Αρχική ροή πακέτων Πλεονασµός Απώλεια πακέτου Ανακατασκευασµένη ροή πακέτων 6-41 6-42 Ανάκαµψη από απώλειες πακέτων (3) Εφαρµογές πολυµέσων στο ιαδίκτυο: Σύνοψη Interleavng (διάπλεξη) τα κοµµάτια τεµαχίζονται σε µικρότερες µονάδες για παράδειγµα 4 µονάδες των 5 msec ανά κοµµάτι ένα πακέτο περιέχει µικρές µονάδες από διαφορετικά κοµµάτια Αρχική ροή πακέτων ιαπλεγµένη ροή Απώλεια πακέτου Ανακατασκευασµένη ροή πακέτων εάν χαθεί ένα πακέτο, εξακολουθούµε να έχουµε το µεγαλύτερο µέρος κάθε κοµµατιού δεν απαιτείται πλεονασµός αυξάνεται η καθυστέρηση αναπαραγωγής 6-43 χρησιµοποιούν UDP ώστε να αποφεύγουν τον έλεγχο συµφόρησης του TCP (καθυστερήσεις) για κίνηση µε ευαισθησία στις καθυστερήσεις (tme-senstve) προσαρµοστική καθυστέρηση αναπαραγωγής στην πλευρά του clent ώστε να αντισταθµίζονται οι καθυστερήσεις η πλευρά του server επιδιώκει να ταιριάξει το bandwdth του audo/vdeo stream µε το διαθέσιµο bandwdth στη διαδροµή µεταξύ clent και server επιλογή µεταξύ streams µε διαφορετικούς ρυθµούς δυναµικός ρυθµός κωδικοποίησης από τον server ανάκαµψη από σφάλµατα (επάνω από UDP) FEC, nterleavng επαναµεταδόσεις εφόσον το επιτρέπει ο χρόνος συγκάλυψη σφαλµάτων µε επανάληψη γειτονικών δεδοµένων 6-44 11

Κεφάλαιο 6 6.1 ικτυακές εφαρµογές πολυµέσων 6.2 Εφαρµογές µετάδοσης αποθηκευµένου ήχου και βίντεο µε συνεχή ροή RTSP 6.3 Αξιοποιώντας την υπηρεσία βέλτιστης προσπάθειας: ένα παράδειγµα ιαδικτυακού τηλεφώνου 6.4 Πρωτόκολλα για διαδραστικές εφαρµογές πραγµατικού χρόνου RTP, RTCP SIP 6.5 Πέρα από τα όρια της βέλτιστης προσπάθειας 6.6 Μηχανισµοί χρονοπρογραµµατισµού και αστυνόµευσης 6.7 Ενοποιηµένες 6.8 Πρωτόκολλο RSVP 6.9 ιαφοροποιηµένες 6-45 Real-Tme Protocol (RTP) [RFC 3550] το πρωτόκολλο RTP καθορίζει µία δοµή για πακέτα που µεταφέρουν δεδοµένα ήχου και βίντεο ένα πακέτο RTP παρέχει αναγνώριση του είδους του ωφέλιµου φορτίου (payload type) του πακέτου αρίθµηση σειράς των πακέτων πληροφορία χρονισµού (χρονοσφραγίδων) το RTP τρέχει στα τερµατικά συστήµατα τα πακέτα RTP ενθυλακώνονται µέσα σε UDP segments διαλειτουργικότητα (nteroperablty): εάν δύο εφαρµογές ιαδικτυακής τηλεφωνίας τρέχουν RTP, τότε ενδεχοµένως να είναι σε θέση να συνεργασθούν 6-46 Το RTP τρέχει επάνω από το UDP Παράδειγµα RTP Οι βιβλιοθήκες του RTP παρέχουν µία διεπαφή επιπέδου µεταφοράς που επεκτείνει το UDP: αριθµός θύρας, διεύθυνση IP είδος ωφέλιµου φορτίου αριθµός ακολουθίας πακέτου χρονοσφραγίδα dentfer πηγής (SSRC) 6-47 Θεωρείστε την αποστολή φωνής κωδικοποιηµένης µε PCM (64 kbps) µε RTP Η εφαρµογή συλλέγει τα κωδικοποιηµένα δεδοµένα σε κοµµάτια, π.χ. κάθε 20 msec παράγεται ένα κοµµάτι µε 160 bytes Το κοµµάτι αυτό µαζί µε την επικεφαλίδα RTP αποτελούν το πακέτο RTP, το οποίο ενθυλακώνεται µέσα σε ένα UDP segment Ηεπικεφαλίδα RTP υποδεικνύει τη µέθοδο κωδικοποίησης της φωνής σε κάθε πακέτο ο αποστολέας µπορεί να αλλάξει µέθοδο κωδικοποίησης κατά τη διάρκεια µίας διάσκεψης Η επικεφαλίδα RTP περιέχει επίσης αριθµούς ακολουθίας και χρονοσφραγίδες 6-48 12

RTP και QoS Το RTP δεν παρέχει κανένα µηχανισµό που να διασφαλίζει την έγκαιρη παράδοση των δεδοµένων ούτε παρέχει άλλες εγγυήσεις QoS Η ενθυλάκωση σε πακέτα RTP γίνεται αντιληπτή στα τερµατικά συστήµατα µόνο: οι ενδιάµεσοι δροµολογητές αγνοούν εάν ένα datagram µεταφέρει ένα πακέτο RTP ή όχι Οι δροµολογητές που παρέχουν υπηρεσία βέλτιστης προσπάθειας δεν καταβάλλουν καµία ιδιαίτερη προσπάθεια για να διασφαλίσουν την έγκαιρη άφιξη των πακέτων RTP στον προορισµό RTP Streams Το RTP επιτρέπει να ανατίθεται ένα ανεξάρτητο RTP stream από πακέτα σε κάθε πηγή (π.χ. µία κάµερα ή ένα µικρόφωνο) Για παράδειγµα, σε µία βιντεοδιάσκεψη µε δύο συµµετέχοντες µπορούν να ανοιχθούν τέσσερα RTP streams: δύο streams για τη µετάδοση του ήχου (ένα σε κάθε κατεύθυνση) και δύο streams για το βίντεο Ορισµένες τεχνικές κωδικοποίησης (π.χ. MPEG 1 και MPEG 2) πολυπλέκουν τον ήχο και το βίντεο σε µία µόνο ροή κατά τη διαδικασία της κωδικοποίησης Στην περίπτωση αυτή έχουµε ένα µόνο RTP stream προς καθεµία από τις δύο κατευθύνσεις Στην περίπτωση ενός multcast sesson µε περισσότερους από έναν αποστολείς και παραλήπτες, όλοι οι αποστολείς και πηγές συνήθως στέλνουν τα RTP streams στο ίδιο δένδρο multcast µε την ίδια διεύθυνση multcast 6-49 6-50 Επικεφαλίδα RTP Payload Type Sequence Number Tmestamp Synchronzaton Source dentfer ιάφορα Πεδία Επικεφαλίδα RTP Payload Type (7 bts): Υποδεικνύει τη χρησιµοποιούµενη µέθοδο κωδικοποίησης. Με το πεδίο αυτό ο αποστολέας πληροφορεί τον παραλήπτη για την αλλαγή της µεθόδου κωδικοποίησης κατά τη διάρκεια µίας διάσκεψης. Payload type 0: PCM µ-law, 64 kbps Payload type 3: GSM, 13 kbps Payload type 7: LPC, 2.4 kbps Payload type 26: Moton JPEG Payload type 31: H.261 Payload type 33: MPEG2 vdeo Sequence Number (16 bts): Αυξάνεται κατά ένα µε κάθε αποστελλόµενο πακέτο RTP. Μπορεί να χρησιµοποιηθεί για την ανίχνευση απωλειών πακέτων και για την επαναδιάταξη των πακέτων στη σειρά. Επικεφαλίδα RTP (συνέχεια) Tmestamp (32 bts): Αναφέρεται στη στιγµή δειγµατοληψίας του πρώτου byte των δεδοµένων που περιέχονται σε ένα πακέτο RTP στην περίπτωση του ήχου, το ρολόι των χρονοσφραγίδων συνήθως αυξάνεται κατά ένα για κάθε περίοδο δειγµατοληψίας (π.χ. κάθε 125 µsecs για ρολόι δειγµατοληψίας µε συχνότητα 8 KHz) εάν η εφαρµογή χρησιµοποιεί 160 κωδικοποιηµένα δείγµατα στο ωφέλιµο φορτίο του πακέτου RTP, τότε η τιµή του πεδίου tmestamp αυξάνεται κατά 160 για κάθε πακέτο RTP όσο η πηγή είναι ενεργή. Το ρολόι των χρονοσφραγίδων εξακολουθεί να αυξάνεται µε σταθερό ρυθµό όσο η πηγή είναι αδρανής SSRC (32 bts): Προσδιορίζει την πηγή του RTP stream. Κάθε stream σε ένα RTP sesson πρέπει να έχει ξεχωριστό SSRC. 6-51 6-52 13

Real-Tme Control Protocol (RTCP) RTCP (συνέχεια) αποστολέας Συνοδεύει το πρωτόκολλο RTP Κάθε συµµετέχων σε ένα RTP sesson µεταδίδει περιοδικά πακέτα ελέγχου RTCP προς όλους τους άλλους συµµετέχοντες Κάθε πακέτο RTCP περιέχει αναφορές (reports) αποστολέα και/ή αναφορές παραλήπτη αναφορά στατιστικών που είναι χρήσιµες στην εφαρµογή Οι στατιστικές περιλαµβάνουν τον αριθµό των απεσταλµένων πακέτων, τον αριθµό των απολεσθέντων πακέτων, µεταβλητότητα χρόνου µεταξύ αφίξεων (nterarrval jtter) κλπ. Η πληροφορία αυτή ανάδρασης µπορεί να χρησιµοποιηθεί για τον έλεγχο της απόδοσης και για διαγνωστικούς σκοπούς Ο αποστολέας µπορεί να τροποποιήσει τις µεταδόσεις του µε βάση την πληροφορία ανάδρασης RTCP παραλήπτης -Ένα RTP sesson έχει συνήθως µία µοναδική διεύθυνση multcast Όλα τα πακέτα RTP και RTCP που ανήκουν στο sesson χρησιµοποιούν την διεύθυνση multcast - Τα πακέτα RTP και RTCP διακρίνονται µεταξύ τους µε τη χρήση ξεχωριστών αριθµών θύρας - Για τον περιορισµό της κίνησης, κάθε συµµετέχων µειώνει την κίνηση RTCP που παράγει µε την αύξηση του αριθµού των συµµετεχόντων RTP RTCP ιαδίκτυο RTCP παραλήπτης 6-53 6-54 Πακέτα RTCP Συγχρονισµός των RTP streams Πακέτα αναφοράς παραλήπτη (recever report): SSRC του RTP stream, ποσοστό απολεσθέντων πακέτων RTP, αριθµός ακολουθίας µε µέγιστη τιµή, µέσο jtter ενδοαφίξεων Πακέτα αναφοράς αποστολέα (sender report): SSRC του RTP stream, χρονοσφραγίδα NTP (απόλυτος χρόνος), χρονοσφραγίδα RTP, αριθµός απεσταλµένων πακέτων RTP, αριθµός απεσταλµένων bytes ωφέλιµου φορτίου Πακέτα περιγραφής πηγής (source descrpton): SSRC του σχετιζόµενου RTP stream, διεύθυνση e-mal του αποστολέα, όνοµα αποστολέα, κλπ. Παρέχει απεικόνιση µεταξύ SSRC και του ονόµατος του χρήστη/host Το RTCP µπορεί να συγχρονίσει διαφορετικά RTP streams σε ένα RTP sesson Θεωρείστε µία εφαρµογή βιντεοδιάσκεψης όπου κάθε αποστολέας παράγει ένα RTP stream για βίντεο και ένα για ήχο Οι χρονοσφραγίδες των πακέτων RTP αναφέρονται στα ρολόγια δειγµατοληψίας του βίντεο και του ήχου δεν αναφέρονται στον απόλυτο χρόνο (wallclock tme) Κάθε πακέτο RTCP sender report περιέχει: χρονοσφραγίδα ΝTP (απόλυτος χρόνος δηµιουργίας του πακέτου RTCP) χρονοσφραγίδα RTP (χρόνος δηµιουργίας του πακέτου RTCP σε µονάδες χρόνου RTP) Οι παραλήπτες µπορούν να χρησιµοποιήσουν αυτή τη σχέση για να συγχρονίσουν την αναπαραγωγή του ήχου και του βίντεο 6-55 6-56 14

Κλιµάκωση αναγκών σε εύρος ζώνης στο RTCP Sesson Intaton Protocol (SIP) [RFC 3261] Το RTCP επιχειρεί να περιορίσει την κίνησή του στο 5% του sesson bandwdth Παράδειγµα Έστω ότι υπάρχει ένας αποστολέας ο οποίος στέλνει βίντεο µε ρυθµό 2 Mbps Το RTCP επιχειρεί να περιορίσει την κίνησή του σε 100 kbps Το RTCP δίνει 75% του ρυθµού αυτού στους παραλήπτες και το υπόλοιπο 25% στον αποστολέα Τα 75 kbps µοιράζονται εξίσου µεταξύ των παραληπτών: Με R παραλήπτες, κάθε παραλήπτης στέλνει κίνηση RTCP µε ρυθµό 75/R kbps Ο αποστολέας στέλνει κίνηση RTCP µε ρυθµό 25 kbps Κάθε συµµετέχων προσδιορίζει την περίοδο µετάδοσης πακέτων RTCP υπολογίζοντας το µέσο µέγεθος πακέτου RTCP (σε ολόκληρο το sesson) και διαιρώντας µε τον παραχωρηµένο ρυθµό Αναπτύχθηκε από το IETF Μακροπρόθεσµο όραµα του SIP Όλες οι τηλεφωνικές κλήσεις και οι βιντεοδιασκέψεις πραγµατοποιούνται µέσω του ιαδικτύου Για την αναγνώριση ενός χρήστη χρησιµοποιείται ένα όνοµα ή µία διεύθυνση e-mal παρά ένας αριθµός τηλεφώνου Η κλήση µπορεί να προωθηθεί στον καλούµενο ανεξάρτητα από το που βρίσκεται και από την συσκευή IP που χρησιµοποιεί (personal moblty) 6-57 6-58 που παρέχει το SIP Εγκαθίδρυση κλήσης Παρέχει µηχανισµούς ώστε ο καλών να µπορεί να γνωστοποιήσει στον καλούµενο ότι θέλει να εγκαθιδρύσει µία κλήση Παρέχει µηχανισµούς ώστε ο καλών και ο καλούµενος να διαπραγµατευθούν το είδος του µέσου και της κωδικοποίησης Παρέχει µηχανισµούς για τον τερµατισµό κλήσης Προσδιορισµός τρέχουσας διεύθυνσης IP του καλούµενου Απεικονίζει έναν µνηµονικό dentfer στην τρέχουσα διεύθυνση IP ιαχείριση κλήσης Προσθήκη νέων µέσων κατά τη διάρκεια µίας κλήσης Αλλαγή κωδικοποίησης κατά τη διάρκεια της κλήσης Πρόσκληση νέων συµµετεχόντων σε µία διάσκεψη Μεταφορά κλήσης (call transfer) και κλήση σε αναµονή (on hold) Alce Εγκαθίδρυση κλήσης σε γνωστή διεύθυνση IP 167.180.112.24 tme 193.64.210.89 INVITE bob@193.64.210.89 c=in IP4 167.180.112.24 m=audo 38060 RTP/AVP 0 port 5060 port 5060 port 38060 200 OK c=in IP4 193.64.210.89 m=audo 48753 RTP/AVP 3 ACK port 5060 GSM µ Law audo port 48753 tme Bob Bob's termnal rngs Το µήνυµα SIP INVITE της Alce υποδεικνύει τον δικό της αριθµό θύρας & διεύθυνση IP. Υποδεικνύει τη µέθοδο κωδικοποίησης που προτιµά να λάβει η Alce (PCM µ-law) Το µήνυµα 200 OK του Bob υποδεικνύει τον δικό του αριθµό θύρας, διεύθυνση IP & προτιµώµενη µέθοδο κωδικοποίησης (GSM) Τα µηνύµατα SIP µπορούν να σταλούν επάνω από TCP ή UDP Προεπιλεγµένος αριθµός θύρας SIP: 5060 6-59 6-60 15

Εγκαθίδρυση κλήσης (συνέχεια) Παράδειγµα µηνύµατος SIP ιαπραγµάτευση Codec: Έστω ότι ο Bob δεν διαθέτει κωδικοποιητή PCM µ-law Ο Bob θα στείλει µήνυµα απόκρισης 606 Not Acceptable και ένα κατάλογο των κωδικοποιητών που είναι σε θέση να χρησιµοποιήσει Η Alce µπορεί τότε να στείλει ένα νέο µήνυµα INVITE, αναγγέλλοντας έναν κατάλληλο κωδικοποιητή Απόρριψη κλήσης: Ο Bob µπορεί να απορρίψει την κλήση µε µηνύµατα απόκρισης όπως busy, gone, payment requred, forbdden Για τη µετάδοση των µέσων µπορεί να χρησιµοποιηθεί το RTP ή κάποιο άλλο πρωτόκολλο INVITE sp:bob@doman.com SIP/2.0 Va: SIP/2.0/UDP 167.180.112.24 From: sp:alce@hereway.com To: sp:bob@doman.com Call-ID: a2e3a@pgeon.hereway.com Content-Type: applcaton/sdp Content-Length: 885 c=in IP4 167.180.112.24 m=audo 38060 RTP/AVP 0 Σηµειώσεις: σύνταξη παρόµοια µε αυτή µηνύµατος HTTP sdp = sesson descrpton protocol Call-ID: µοναδικό για κάθε κλήση Στην περίπτωση αυτή, η διεύθυνση IP του Bob είναι άγνωστη. Θα χρειαστούν ενδιάµεσοι SIP servers. Η Alce στέλνει και λαµβάνει µηνύµατα SIP χρησιµοποιώντας τον αριθµό θύρας 5060. Η Alce προσδιορίζει στην επικεφαλίδα Va: ότι ο SIP clent στέλνει και λαµβάνει µηνύµατα SIP επάνω από UDP 6-61 6-62 Μετάφραση ονόµατος και τοποθεσία του χρήστη SIP Regstrar server Οκαλώνθέλεινα καλέσει τον καλούµενο, του οποίου γνωρίζει µόνο το όνοµα ή τη διεύθυνση e-mal Χρειάζεται να αποκτήσει τη διεύθυνση IP του host που χρησιµοποιεί ο καλούµενος: ο χρήστης περιφέρεται πρωτόκολλο DHCP ο χρήστης έχει διάφορες συσκευές IP (PC, PDA, συσκευή αυτοκινήτου) Το αποτέλεσµα µπορεί να εξαρτάται από: την ώρα της ηµέρας (δουλειά, σπίτι) τον καλούντα (µπορεί κανείς να µην θέλει να λαµβάνει κλήσεις από τον εργοδότη στο σπίτι) την κατάσταση του καλούµενου (κλήσεις στέλνονται στο φωνητικό ταχυδροµείο όταν ο καλούµενος συνοµιλεί µε κάποιον άλλο) παρεχόµενες από SIP servers: SIP regstrar server SIP proxy server 6-63 Όταν ο Bob ξεκινά τον SIP clent, ο clent στέλνει ένα µήνυµα SIP REGISTER στον regstrar server του Bob (παρόµοιαλειτουργίααπαιτείται από εφαρµογές Instant Messagng) Μήνυµα Regster: REGISTER sp:doman.com SIP/2.0 Va: SIP/2.0/UDP 193.64.210.89 From: sp:bob@doman.com To: sp:bob@doman.com Expres: 3600 Regstrar server ανάλογος µε DNS authortatve name server 6-64 16

SIP Proxy server Η Alce στέλνει το µήνυµα nvte στον δικό της proxy server το µήνυµα περιέχει τη διεύθυνση sp:bob@doman.com Ο proxy server ευθύνεται για τη δροµολόγηση των µηνυµάτων SIP στον καλούµενο πιθανώς µέσω πολλαπλών proxy servers Ο καλούµενος στέλνει την απόκριση µέσω των ίδιων proxy servers Ο proxy server επιστρέφει το µήνυµα απόκρισης στην Alce το µήνυµα περιέχει τη διεύθυνση IP του Bob Σηµείωση: Ο proxy server είναι ανάλογος µε τον τοπικό DNS server 6-65 Παράδειγµα Ο jm@umass.edu (διεύθ. IP 217.123.56.89) θέλει να κάνει µία κλήση στον keth@upenn.edu (διευθ. IP 197.87.54.21) (1) Ο Jm στέλνει µήνυµα INVITE στον SIP proxy server του umass (2) Ο proxy server προωθεί την αίτηση στον regstrar server του upenn SIP proxy umass.edu 1 8 SIP regstrar upenn.edu SIP regstrar eurecom.fr (3) Ο server του upenn SIP clent SIP clent 197.87.54.21 επιστρέφει απόκριση επανακατεύθυνσης υποδεικνύοντας 217.123.56.89 να δοκιµάσει keth@eurecom.fr (4) Ο proxy server του umass στέλνει µήνυµα INVITE στον regstrar του eurecom (5) O regrstrar του eurecom προωθεί το µήνυµα INVITE στο 197.87.54.21, όπου τρέχει ο SIP clent του keth (6-8) Ο SIP clent του keth στέλνει απόκριση SIP στον SIP clent του jm (9) τα µέσα στέλνονται απευθείας µεταξύ των clents Σηµείωση: υπάρχει επίσης ένα µήνυµα SIP ack µεταξύ των δύο clents που δεν φαίνεται στο σχήµα 6-66 2 3 4 7 9 6 5 H.323 ιαδίκτυο Internet Gatekeeper Gateway Τηλεφωνικό PSTN ίκτυο Το H.323 είναι ένα σύνολο πρωτοκόλλων για διαδραστικές εφαρµογές πολυµέσων πραγµατικού χρόνου Προδιαγραφές Η.323 Το πρότυπο H.323 περιλαµβάνει προδιαγραφές που ορίζουν: τον τρόπο που τα τερµατικά συστήµατα κάνουν και λαµβάνουν κλήσεις τον τρόπο που τα τερµατικά συστήµατα διαπραγµατεύονται κοινές µεθόδους κωδικοποίησης audo/vdeo τον τρόπο που κοµµάτια audo και vdeo ενθυλακώνονται και µεταδίδονται µέσω του δικτύου τον τρόπο που συγχρονίζονται audo και vdeo (lpsync) τον τρόπο που τα τερµατικά συστήµατα επικοινωνούν µε τους αντίστοιχους gatekeepers τον τρόπο µε τον οποίο επικοινωνούν τηλέφωνα Internet και τηλέφωνα PSTN/ISDN 6-67 6-68 17

Σύγκριση του SIP µε το H.323 Το H.323 είναι ένα πλήρες σύνολο (sute) πρωτοκόλλων για διασκέψεις πολυµέσων: σηµατοδοσία, regstraton, αποδοχή κλήσης, µεταφορά, κωδικοποιητές/ αποκωδικοποιητές Το SIP έχει µία µοναδική συνιστώσα: εγκαθίδρυση και διαχείριση sesson Μπορεί να χρησιµοποιήσει RTP, αλλά δεν επιβάλλει τη χρήση του Μπορεί να συνδυασθεί µε άλλα πρωτόκολλα και υπηρεσίες Το H.323 αναπτύχθηκε από το ITU:έχει την επίδραση της τηλεφωνίας Το SIP αναπτύχθηκε από το IETF: δανείζεται πολλές έννοιες από το HTTP 6-69 Κεφάλαιο 6 6.1 ικτυακές εφαρµογές πολυµέσων 6.2 Εφαρµογές µετάδοσης αποθηκευµένου ήχου και βίντεο µε συνεχή ροή RTSP 6.3 Αξιοποιώντας την υπηρεσία βέλτιστης προσπάθειας: ένα παράδειγµα ιαδικτυακού τηλεφώνου 6.4 Πρωτόκολλα για διαδραστικές εφαρµογές πραγµατικού χρόνου RTP, RTCP SIP 6.5 Πέρα από τα όρια της βέλτιστης προσπάθειας 6.6 Μηχανισµοί χρονοπρογραµµατισµού και αστυνόµευσης 6.7 Ενοποιηµένες 6.8 Πρωτόκολλο RSVP 6.9 ιαφοροποιηµένες 6-70 Βελτίωση QOS σε δίκτυα IP Σήµερα το ιαδίκτυο παρέχει στις εφαρµογές υπηρεσία βέλτιστης προσπάθειας χωρίς εγγυήσεις QoS Στο µέλλον το ιαδίκτυο της επόµενης γενεάς θα παρέχει στις εφαρµογές εγγυήσεις QoS RSVP: πρωτόκολλο σηµατοδοσίας για τη δέσµευση πόρων Intserv (Integrated Servces) Ενοποιηµένες Dffserv (Dfferentated Servces) - ιαφοροποιηµένες Αρχές παροχής εγγυήσεων QOS Παράδειγµα: Εφαρµογή τηλεφώνου IP µε ρυθµό 1Mbpsκαι εφαρµογή FTP µοιράζονται ζεύξη χωρητικότητας 1,5 Mbps µεγάλοι συρµοί από συνεχόµενα πακέτα FTP µπορούν να προκαλέσουν συµφόρηση στο δροµολογητή και απώλειες πακέτων audo θέλουµε να δώσουµε προτεραιότητα στο audo έναντι του FTP Ζεύξη χωρητικότητας 1,5 Μbps Απλό δίκτυο για την µελέτη των αρχών πάνω στις οποίες στηρίζεται η παροχή εγγυήσεων QoS ουρά αναµονής ζεύξης εξερχόµενης από τον R1 6-71 Αρχή 1 απαιτείται µαρκάρισµα των πακέτων ώστε ο δροµολογητής να διακρίνει τις διαφορετικές κλάσεις µεταξύ τους και µία νέα πολιτική εξυπηρέτησης στο δροµολογητή ώστε να χειρίζεται τα πακέτα ανάλογα µε την κλάση τους 6-72 18

Αρχές παροχής εγγυήσεων QOS (συνέχεια) ενδέχεται οι εφαρµογές να παράγουν κίνηση που παρεκκλίνει από τα χαρακτηριστικά που έχουν δηλώσει (π.χ. η εφαρµογή audo µεταδίδει µε ρυθµό µεγαλύτερο από αυτόν που έχει δηλώσει) αστυνόµευση: αναγκάζει την πηγή να συµµορφώνεται µε τα χαρακτηριστικά κίνησης που έχει δηλώσει µαρκάρισµα και αστυνόµευση στα άκρα του δικτύου: παρόµοια µε το ATM UNI (User Network Interface) Αρχές παροχής εγγυήσεων QOS (συνέχεια) Ηεκχώρησησταθερής (αποκλειστικής) χωρητικότητας στις ροές έχει ως αποτέλεσµα την µη αποδοτική χρήση των πόρων του δικτύου όταν οι ροές δεν απαιτούν σταθερή χωρητικότητα όλο το χρόνο µαρκάρισµα πακέτων λογική ζεύξη (1 Mbps) µαρκάρισµα πακέτων και αστυνόµευση λογική ζεύξη (0,5 Mbps) Αρχή 2 προστασία (αποµόνωση) κάθε κλάσης από τις υπόλοιπες 6-73 Αρχή 3 Παράλληλα µε την αποµόνωση των ροών, είναι επιθυµητή η κατά το δυνατόν αποδοτικότερη χρήση των πόρων 6-74 Αρχές παροχής εγγυήσεων QOS (συνέχεια) Ανυπέρβλητος κανόνας: είναι αδύνατο να εξυπηρετηθεί όγκος κίνησης που υπερβαίνει τη χωρητικότητα ζεύξης Αρχές παροχής εγγυήσεων QoS: Σύνοψη QoS για δικτυωµένες εφαρµογές ταξινόµηση πακέτων αποµόνωση: χρονοπρογραµµατισµός και αστυνόµευση υψηλή χρησιµοποίηση πόρων αποδοχή κλήσης Αρχή 4 Αποδοχή Κλήσης: η ροή δηλώνει τις απαιτήσεις της, ενδέχεται όµως να µη γίνει αποδεκτή από το δίκτυο εάν αυτό δεν είναι σε θέση να τις ικανοποιήσει 6-75 Θα εξετάσουµε µηχανισµούς που χρησιµοποιούνται για την παροχή εγγυήσεων QoS 6-76 19