WebRTC. Τηλεδιάσκεψη στο πρόγραμμα περιήγησης. Συνομιλία πολλών χρηστών χρησιμοποιώντας φωνητική συνομιλία WebRTC Webrtc

Προοίμιο. Η συνομιλία μέσω βίντεο P2P είναι ενεργοποιημένη Βάση WebRTCείναι μια εναλλακτική λύση στο Skype και άλλα μέσα επικοινωνίας. Τα κύρια στοιχεία της συνομιλίας μέσω βίντεο p2p που βασίζεται στο WebRTC είναι ένα πρόγραμμα περιήγησης και ένας διακομιστής επαφών. Οι συνομιλίες βίντεο P2P είναι συνομιλίες βίντεο peer-to-peer στις οποίες ο διακομιστής δεν συμμετέχει στη μετάδοση των ροών πληροφοριών. Οι πληροφορίες μεταφέρονται απευθείας μεταξύ των προγραμμάτων περιήγησης (peers) των χρηστών χωρίς κανένα πρόσθετα προγράμματα. Εκτός από τα προγράμματα περιήγησης, οι συνομιλίες βίντεο p2p χρησιμοποιούν διακομιστές επαφών, οι οποίοι έχουν σχεδιαστεί για την εγγραφή χρηστών, την αποθήκευση δεδομένων σχετικά με αυτούς και τη διασφάλιση της εναλλαγής μεταξύ χρηστών. Τα προγράμματα περιήγησης που υποστηρίζουν τις πιο πρόσφατες τεχνολογίες WebRTC και HTML5 παρέχουν άμεσα μηνύματα κειμένου και μετάδοση αρχείων, καθώς και επικοινωνία φωνής και βίντεο μέσω δικτύων IP.

Έτσι, οι συνομιλίες, οι συνομιλίες web, οι συνομιλίες φωνής και βίντεο σε μια διεπαφή ιστού, το IMS, το VoIP είναι υπηρεσίες που παρέχουν διαδικτυακές επικοινωνίες μέσω σύνθετων δικτύων μεταγωγής πακέτων. Κατά κανόνα, οι υπηρεσίες επικοινωνίας απαιτούν είτε την εγκατάσταση εφαρμογών πελάτη σε συσκευές χρήστη (Η/Υ, smartphone κ.λπ.) είτε την εγκατάσταση πρόσθετων και επεκτάσεων σε προγράμματα περιήγησης. Οι υπηρεσίες έχουν τα δικά τους δίκτυα επικοινωνίας, τα περισσότερα από τα οποία είναι χτισμένα σε αρχιτεκτονική πελάτη-διακομιστή.

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

Το πρόβλημα της ενοποίησης υπηρεσιών επικοινωνίας σε πραγματικό χρόνο (chat, τηλεφωνία, τηλεδιάσκεψη), π.χ. Η ενοποίηση καναλιών φωνής, βίντεο, δεδομένων και η πρόσβαση σε αυτά χρησιμοποιώντας μία εφαρμογή (πρόγραμμα περιήγησης) μπορεί να επιλυθεί σε συνομιλίες βίντεο peer-to-peer ή p2p (peer-to-peer, point-to-point) με βάση το πρωτόκολλο WebRTC. Ουσιαστικά, ένα πρόγραμμα περιήγησης που υποστηρίζει το WebRTC γίνεται μια ενιαία διεπαφή για όλες τις συσκευές χρήστη (υπολογιστές, smartphone, iPad, τηλέφωνα IP, κινητά τηλέφωνακ.λπ.) που συνεργάζονται με υπηρεσίες επικοινωνίας.

Είναι το WebRTC που διασφαλίζει την εφαρμογή στο πρόγραμμα περιήγησης όλων των τεχνολογιών που παρέχουν επικοινωνίες σε πραγματικό χρόνο. Η ουσία των συνομιλιών βίντεο p2p είναι ότι τα δεδομένα πολυμέσων και κειμένου μεταφέρονται απευθείας μεταξύ των προγραμμάτων περιήγησης των χρηστών (απομακρυσμένη ανταλλαγή απόψεων) χωρίς τη συμμετοχή διακομιστή ή πρόσθετων προγραμμάτων. Έτσι, τα προγράμματα περιήγησης όχι μόνο παρέχουν πρόσβαση σχεδόν σε όλα πληροφοριακούς πόρουςΔιαδίκτυο, που αποθηκεύονται σε διακομιστές, αλλά γίνονται και μέσο πρόσβασης σε όλες τις υπηρεσίες επικοινωνίας σε πραγματικό χρόνο και τις υπηρεσίες αλληλογραφίας (φωνητικό ταχυδρομείο, ΗΛΕΚΤΡΟΝΙΚΗ ΔΙΕΥΘΥΝΣΗ, SMS κ.λπ.)

Οι διακομιστές (διακομιστές επαφής) των συνομιλιών βίντεο p2p προορίζονται μόνο για την εγγραφή χρηστών, την αποθήκευση δεδομένων σχετικά με τους χρήστες και τη δημιουργία σύνδεσης (εναλλαγή) μεταξύ των προγραμμάτων περιήγησης των χρηστών. Οι πρώτες συνομιλίες βίντεο p2p υλοποιήθηκαν χρησιμοποιώντας τεχνολογίες flash. Οι συνομιλίες βίντεο flash p2p χρησιμοποιούνται, για παράδειγμα, σε στα κοινωνικά δίκτυα. Οι συνομιλίες βίντεο flash p2p δεν παρέχουν υψηλή ποιότηταμετάδοση δεδομένων πολυμέσων. Επιπλέον, για να εξάγετε ροή φωνής και βίντεο από το μικρόφωνο και τη βιντεοκάμερα σε συνομιλίες βίντεο p2p flash, πρέπει να εγκαταστήσετε flash pluginσε ένα πρόγραμμα περιήγησης ιστού.

Ωστόσο, η νέα γενιά τηλεπικοινωνιακών υπηρεσιών περιλαμβάνει επικοινωνίες Ιστού, οι οποίες χρησιμοποιούν μόνο προγράμματα περιήγησης και διακομιστές επαφών που υποστηρίζουν πρωτόκολλα WebRTC και την προδιαγραφή HTML5 για επικοινωνία μέσω Διαδικτύου. Οποιαδήποτε συσκευή χρήστη (PC, iPad, smartphone κ.λπ.) που είναι εξοπλισμένη με τέτοιο πρόγραμμα περιήγησης μπορεί να παρέχει υψηλής ποιότητας φωνητικές κλήσεις και βιντεοκλήσεις, καθώς και τη μεταφορά άμεσων μηνυμάτων κειμένου και αρχείων.

Έτσι, η νέα τεχνολογία για τις διαδικτυακές επικοινωνίες (συνομιλίες p2p, συνομιλίες μέσω βίντεο) είναι το πρωτόκολλο WebRTC. Το WebRTC μαζί με τα HTML5, CSS3 και JavaScript σάς επιτρέπουν να δημιουργείτε διάφορες διαδικτυακές εφαρμογές. Το WebRT έχει σχεδιαστεί για να οργανώνει επικοινωνίες ιστού (δίκτυα peer-to-peer) σε πραγματικό χρόνο χρησιμοποιώντας μια αρχιτεκτονική peer-to-peer. Οι συνομιλίες P2P που βασίζονται στο WebRTC παρέχουν μεταφορά αρχείων, καθώς και επικοινωνία κειμένου, φωνής και βίντεο μεταξύ των χρηστών μέσω Διαδικτύου χρησιμοποιώντας μόνο προγράμματα περιήγησης ιστού χωρίς τη χρήση εξωτερικών πρόσθετων και προσθηκών στο πρόγραμμα περιήγησης.

Στις συνομιλίες p2p, ο διακομιστής χρησιμοποιείται μόνο για τη δημιουργία σύνδεσης p2p μεταξύ δύο προγραμμάτων περιήγησης. Για τη δημιουργία του τμήματος πελάτη μιας συνομιλίας p2p που βασίζεται στο πρωτόκολλο WebRTC, χρησιμοποιούνται HTML5, CSS3 και JavaScript. Η εφαρμογή πελάτη αλληλεπιδρά με προγράμματα περιήγησης μέσω του WebRTC API.

Το WebRTC υλοποιείται από τρία JavaScript API:

• RTCPeerConnection;
• MediaStream(getUserMedia);
• RTCDataChannel.

Τα προγράμματα περιήγησης μεταφέρουν δεδομένα πολυμέσων χρησιμοποιώντας το πρωτόκολλο SRTP, το οποίο εκτελείται πάνω από το UDP. Δεδομένου ότι το NAT δημιουργεί προβλήματα για προγράμματα περιήγησης (πελάτες) πίσω από δρομολογητές NAT που χρησιμοποιούν συνδέσεις p2p μέσω Διαδικτύου, το STUN χρησιμοποιείται για την παράκαμψη των μεταφραστών NAT. Το STUN είναι ένα πρωτόκολλο πελάτη-διακομιστή που τρέχει πάνω από το πρωτόκολλο μεταφοράς UDP. Στις συνομιλίες p2p, κατά κανόνα, χρησιμοποιείται ένας δημόσιος διακομιστής STUN και οι πληροφορίες που λαμβάνονται από αυτόν χρησιμοποιούνται για μια σύνδεση UDP μεταξύ δύο προγραμμάτων περιήγησης, εάν βρίσκονται πίσω από το NAT.

Παραδείγματα υλοποίησης εφαρμογών WebRTC (συνομιλίες p2p, φωνητικές συνομιλίες και συνομιλίες μέσω βίντεο):
1. Η συνομιλία μέσω βίντεο P2P Bistri (συνομιλία βίντεο με ένα κλικ, συνομιλία p2p), που βασίζεται στο WebRTC, μπορεί να ανοίξει στο Bistri. Το Bistri λειτουργεί στο πρόγραμμα περιήγησης χωρίς να εγκαταστήσει πρόσθετα προγράμματα και πρόσθετα. Η ουσία της εργασίας είναι η εξής: ανοίξτε μια συνομιλία βίντεο p2p χρησιμοποιώντας τον καθορισμένο σύνδεσμο, αφού εγγραφείτε στη διεπαφή που ανοίγει, προσκαλέστε συνεργάτες και, στη συνέχεια, από τη λίστα των ομότιμων πελατών επιλέξτε τον συνεργάτη που είναι συνδεδεμένος και κάντε κλικ στην «κλήση βίντεο κουμπί ".

Ως αποτέλεσμα, το MediaStream (getUserMedia) θα καταγράψει το μικρόφωνο + την κάμερα web και ο διακομιστής θα ανταλλάξει μηνύματα σηματοδότησης με τον επιλεγμένο συνεργάτη. Μετά την ανταλλαγή μηνυμάτων σηματοδότησης, το PeerConnection API δημιουργεί κανάλια για τη μετάδοση ροών φωνής και βίντεο. Επιπλέον, το Bistri μεταφέρει άμεσα μηνύματα κειμένου και αρχεία. Στο Σχ. 1 δείχνει ένα στιγμιότυπο οθόνης της διεπαφής συνομιλίας βίντεο Bistri p2p.

Ρύζι. 1. P2P συνομιλία μέσω βίντεο Bistri

2. Twelephone (συνομιλία βίντεο p2p, συνομιλία p2p, SIP Twelephone) - αυτή η εφαρμογή-πελάτης είναι χτισμένη με βάση το HTML5 και το WebRTC, το οποίο σας επιτρέπει να πραγματοποιείτε κλήσεις φωνής και βίντεο, καθώς και να στέλνετε άμεσα μηνύματα κειμένου, π.χ. Το Twelephone περιλαμβάνει δοκιμαστική συνομιλία p2p, συνομιλία μέσω βίντεο και Twelephone SIP. Θα πρέπει να σημειωθεί ότι το Twelephone υποστηρίζει το πρωτόκολλο SIP και τώρα μπορείτε να πραγματοποιείτε και να λαμβάνετε φωνητικές κλήσεις και κλήσεις βίντεο από τηλέφωνα SIP χρησιμοποιώντας τον λογαριασμό σας στο Twitter ως αριθμό τηλεφώνου. Εκτός, γραπτά μηνύματαΜπορείτε να εισάγετε φωνητικά μέσω του μικροφώνου και το πρόγραμμα αναγνώρισης φωνής εισάγει το κείμενο στη γραμμή "Αποστολή μηνύματος".

Το Twelephone είναι μια διαδικτυακή τηλεφωνία που βασίζεται σε πρόγραμμα περιήγησης Google Chrome, ξεκινώντας από την έκδοση 25, χωρίς επιπλέον λογισμικό. Το Twelephone αναπτύχθηκε από τον Chris Matthieu. Το backend Twelephone είναι χτισμένο στο Node.js. Ο διακομιστής (διακομιστής επαφής) χρησιμοποιείται μόνο για τη δημιουργία σύνδεσης p2p μεταξύ δύο προγραμμάτων περιήγησης ή πελατών WebRTC. Η εφαρμογή Twelephone δεν διαθέτει δικά της εργαλεία εξουσιοδότησης, αλλά επικεντρώνεται στη σύνδεση σε έναν λογαριασμό ( λογαριασμός) στο Twitter.

Στο Σχ. 2 δείχνει ένα στιγμιότυπο οθόνης της διεπαφής συνομιλίας μέσω βίντεο Twelephone p2p.

Ρύζι. 2. P2P Twelephone

3. Ομαδική συνομιλία μέσω βίντεο p2p Το Conversat.io είναι χτισμένο στις πιο πρόσφατες τεχνολογίες WebRTC και HTML5. Η συνομιλία μέσω βίντεο Conversat έχει αναπτυχθεί με βάση τη βιβλιοθήκη SimpleWebRTC και προορίζεται για επικοινωνία μεταξύ έως και 6 ομότιμων πελατών σε ένα δωμάτιο (για επικοινωνία, υποδείξτε το όνομα της κοινής αίθουσας για ομότιμους πελάτες στη γραμμή "Ονομάστε τη συνομιλία"). Συνομιλία μέσω βίντεο P2P Το Conversat παρέχει υπηρεσίες επικοινωνίας στους χρήστες χωρίς εγγραφή στον διακομιστή επαφών. Στο Σχ. Το σχήμα 3 δείχνει ένα στιγμιότυπο οθόνης της διεπαφής συνομιλίας μέσω βίντεο Conversat p2p.

Ρύζι. 3. Ομαδική συνομιλία μέσω βίντεο P2P Conversat.io

Για να συμμετάσχουν σε συνομιλίες μέσω βίντεο P2P που βασίζονται στο WebRTC, οι χρήστες πρέπει να έχουν εγκατεστημένο ένα πρόγραμμα περιήγησης που να υποστηρίζει το πρωτόκολλο WebRTC και την προδιαγραφή HTML5. Επί του παρόντος, τα προγράμματα περιήγησης Google Chrome, ξεκινώντας από την έκδοση 25 και Mozilla FirefoxΤο Nightly υποστηρίζει το πρωτόκολλο WebRTC και την προδιαγραφή HTML5. Οι εφαρμογές WebRTC είναι ανώτερες από τις εφαρμογές Flash όσον αφορά την ποιότητα μετάδοσης εικόνας και ήχου.

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

WebRTC Εισαγωγή

Το WebRTC είναι μια τεχνολογία προσανατολισμένη στο πρόγραμμα περιήγησης που σας επιτρέπει να συνδέσετε δύο πελάτες για μεταφορά δεδομένων βίντεο. Τα κύρια χαρακτηριστικά είναι η υποστήριξη εσωτερικού προγράμματος περιήγησης (δεν χρειάζονται τεχνολογίες που εφαρμόζονται από τρίτους, όπως το adobe flash) και η δυνατότητα σύνδεσης πελατών χωρίς τη χρήση πρόσθετων διακομιστών - σύνδεση peer-to-peer (εφεξής, p2p).

Η δημιουργία μιας σύνδεσης p2p είναι μια αρκετά δύσκολη εργασία, καθώς οι υπολογιστές δεν έχουν πάντα δημόσιες διευθύνσεις IP, δηλαδή διευθύνσεις στο Διαδίκτυο. Λόγω του μικρού αριθμού διευθύνσεων IPv4 (και για λόγους ασφαλείας), αναπτύχθηκε ο μηχανισμός NAT, ο οποίος σας επιτρέπει να δημιουργείτε ιδιωτικά δίκτυα, για παράδειγμα, για οικιακή χρήση. Πολλοί οικικοί δρομολογητές υποστηρίζουν πλέον NAT και χάρη σε αυτό, όλες οι οικιακές συσκευές έχουν πρόσβαση στο Διαδίκτυο, αν και οι πάροχοι Διαδικτύου συνήθως παρέχουν μία διεύθυνση IP. Οι δημόσιες διευθύνσεις IP είναι μοναδικές στο Διαδίκτυο, αλλά οι ιδιωτικές δεν είναι. Επομένως, η σύνδεση του p2p είναι δύσκολη.

Για να το κατανοήσετε καλύτερα, εξετάστε τρεις καταστάσεις: και οι δύο κόμβοι βρίσκονται στο ίδιο δίκτυο (Εικόνα 1), και οι δύο κόμβοι βρίσκονται σε διαφορετικά δίκτυα (ένας σε ιδιωτικό, ο άλλος σε δημόσιο) (Εικόνα 2) και οι δύο κόμβοι βρίσκονται σε διαφορετικά ιδιωτικά δίκτυα με τις ίδιες διευθύνσεις IP (Εικόνα 3).

Εικόνα 1: Και οι δύο κόμβοι στο ίδιο δίκτυο

Εικόνα 2: Κόμβοι σε διαφορετικά δίκτυα (ένας σε ιδιωτικό, ένας σε δημόσιο)

Εικόνα 3: Κόμβοι σε διαφορετικά ιδιωτικά δίκτυα, αλλά με αριθμητικά ίσες διευθύνσεις

Στα παραπάνω σχήματα, το πρώτο γράμμα στη σημείωση δύο χαρακτήρων υποδεικνύει τον τύπο κόμβου (p = peer, r = δρομολογητής). Στην πρώτη εικόνα, η κατάσταση είναι ευνοϊκή: οι κόμβοι στο δίκτυό τους αναγνωρίζονται πλήρως από τις διευθύνσεις IP του δικτύου και επομένως μπορούν να συνδεθούν απευθείας μεταξύ τους. Στο δεύτερο σχήμα έχουμε δύο διαφορετικά δίκτυα με παρόμοιους αριθμούς κόμβων. Εδώ εμφανίζονται οι δρομολογητές (routers) που έχουν δύο διεπαφή δικτύου– εντός και εκτός του δικτύου σας. Γι' αυτό έχουν δύο διευθύνσεις IP. Οι κανονικοί κόμβοι έχουν μόνο μία διεπαφή μέσω της οποίας μπορούν να επικοινωνούν μόνο μέσα στο δίκτυό τους. Εάν μεταδίδουν δεδομένα σε κάποιον εκτός του δικτύου τους, τότε χρησιμοποιούν μόνο NAT εντός του δρομολογητή (δρομολογητή) και επομένως είναι ορατά σε άλλους κάτω από τη διεύθυνση IP του δρομολογητή - είναι δική τους εξωτερικόςΔιεύθυνση IP. Άρα ο κόμβος p1 έχει εσωτερικό IP = 192.168.0.200 Και εξωτερικός IP = 10.50.200.5 , και η τελευταία διεύθυνση θα είναι επίσης εξωτερική σε όλους τους άλλους κόμβους του δικτύου της. Η κατάσταση είναι παρόμοια για τον κόμβο p2. Επομένως, η επικοινωνία τους είναι αδύνατη εάν χρησιμοποιούνται μόνο οι εσωτερικές (δικές) διευθύνσεις IP τους. Μπορείτε να χρησιμοποιήσετε εξωτερικές διευθύνσεις, δηλαδή διευθύνσεις δρομολογητή, αλλά επειδή όλοι οι κόμβοι στο ίδιο ιδιωτικό δίκτυο έχουν την ίδια εξωτερική διεύθυνση, αυτό είναι αρκετά δύσκολο. Αυτό το πρόβλημα μπορεί να λυθεί χρησιμοποιώντας τον μηχανισμό NAT

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

Το WebRTC αντιμετωπίζει με επιτυχία τέτοια προβλήματα χρησιμοποιώντας το πρωτόκολλο ICE, το οποίο ωστόσο απαιτεί τη χρήση πρόσθετων διακομιστών (STUN, TURN). Περισσότερα για όλα αυτά παρακάτω.

Δύο φάσεις του WebRTC

Για να συνδέσετε δύο κόμβους μέσω του πρωτοκόλλου WebRTC (ή απλά RTC, εάν επικοινωνούν δύο iPhone), πρέπει να εκτελέσετε ορισμένα προκαταρκτικά βήματα για να δημιουργήσετε τη σύνδεση. Αυτή είναι η πρώτη φάση - η δημιουργία μιας σύνδεσης. Η δεύτερη φάση είναι η μετάδοση δεδομένων βίντεο.

Αξίζει να πούμε αμέσως ότι αν και η τεχνολογία WebRTC χρησιμοποιεί πολλά με διάφορους τρόπουςεπικοινωνιών (TCP και UDP) και έχει ευέλικτη εναλλαγή μεταξύ τους, αυτή η τεχνολογία δεν διαθέτει πρωτόκολλο για τη μετάδοση δεδομένων σύνδεσης. Δεν αποτελεί έκπληξη, καθώς η σύνδεση δύο κόμβων p2p δεν είναι τόσο εύκολη. Επομένως, είναι απαραίτητο να έχουμε μερικά πρόσθετοςμια μέθοδος μετάδοσης δεδομένων που σε καμία περίπτωση δεν σχετίζεται με το WebRTC. Θα μπορούσε να είναι μια μεταφορά πρίζας, πρωτόκολλο HTTP, θα μπορούσε ακόμη και να είναι Πρωτόκολλο SMTPή Russian Post. Αυτός ο μηχανισμός μετάδοσης αρχικόςκαλείται δεδομένα σήμα. Δεν χρειάζεται να μεταδοθούν πολλές πληροφορίες. Όλα τα δεδομένα μεταδίδονται σε μορφή κειμένου και χωρίζονται σε δύο τύπους - SDP και Ice Candidate. Ο πρώτος τύπος χρησιμοποιείται για τη δημιουργία μιας λογικής σύνδεσης και ο δεύτερος για μια φυσική σύνδεση. Περισσότερα για όλα αυτά αργότερα, αλλά προς το παρόν είναι απλώς σημαντικό να θυμόμαστε ότι το WebRTC θα μας δώσει κάποιες πληροφορίες που θα πρέπει να μεταδοθούν σε άλλο κόμβο. Μόλις μεταδώσουμε όλες τις απαραίτητες πληροφορίες, οι κόμβοι θα μπορούν να συνδεθούν και η βοήθειά μας δεν θα χρειάζεται πλέον. Άρα ο μηχανισμός σηματοδότησης που πρέπει να εφαρμόσουμε είναι χωριστά, θα χρησιμοποιηθεί μόνο όταν είναι συνδεδεμένο, αλλά δεν θα χρησιμοποιηθεί κατά τη μετάδοση δεδομένων βίντεο.

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

• Εκκινητής (καλών):
• Προσφορά για έναρξη μεταφοράς δεδομένων βίντεο (createOffer)
• Λήψη του SDP SDP σας)
• Παραλαβή του υποψηφίου Ice Ice )
• Αναμονή κλήσης (callee):
• Λήψη τοπικής (σας) ροής πολυμέσων και ρύθμιση της για μετάδοση (getUserMediaStream)
• Λήψη προσφοράς για έναρξη μεταφοράς δεδομένων βίντεο και δημιουργία απάντησης (createAnswer)
• Λήψη του αντικειμένου SDP και διέλευση του μέσω του μηχανισμού σηματοδότησης (SDP)
• Λήψη των υποψήφιων αντικειμένων πάγου και διοχέτευσή τους μέσω μηχανισμού σηματοδότησης (υποψήφιος πάγος)
• Λήψη μιας απομακρυσμένης (ξένης) ροής πολυμέσων και εμφάνισή της στην οθόνη (onAddStream)

Η μόνη διαφορά είναι στο δεύτερο σημείο.

Παρά τη φαινομενική πολυπλοκότητα των βημάτων, υπάρχουν στην πραγματικότητα τρία από αυτά: αποστολή της δικής σας ροής πολυμέσων (αντικείμενο 1), ρύθμιση παραμέτρων σύνδεσης (στοιχεία 2-4), λήψη της ροής μέσων κάποιου άλλου (αντικείμενο 5). Το πιο δύσκολο βήμα είναι το δεύτερο βήμα, γιατί αποτελείται από δύο μέρη: την καθιέρωση φυσικόςΚαι λογικόςσυνδέσεις. Το πρώτο δείχνει μονοπάτι, κατά μήκος των οποίων πρέπει να ταξιδεύουν τα πακέτα για να μεταβούν από τον έναν κόμβο δικτύου στον άλλο. Το δεύτερο δείχνει παραμέτρους βίντεο/ήχου– τι ποιότητα να χρησιμοποιήσετε, τι κωδικοποιητές να χρησιμοποιήσετε.

Διανοητικά, το στάδιο δημιουργίας προσφοράς ή δημιουργίας απάντησης θα πρέπει να συνδέεται με τα στάδια μετάδοσης υποψήφιων αντικειμένων SDP και Ice.

Βασικές οντότητες Ροές πολυμέσων (MediaStream)

Η κύρια ουσία είναι η ροή πολυμέσων, δηλαδή η ροή δεδομένων βίντεο και ήχου, εικόνας και ήχου. Υπάρχουν δύο τύποι ροών πολυμέσων - τοπικές και απομακρυσμένες. Το τοπικό λαμβάνει δεδομένα από συσκευές εισόδου (κάμερα, μικρόφωνο) και το απομακρυσμένο μέσω του δικτύου. Έτσι, κάθε κόμβος έχει και ένα τοπικό και ένα απομακρυσμένο νήμα. Στο WebRTC, υπάρχει μια διεπαφή MediaStream για ροές και υπάρχει επίσης μια υποδιεπαφή LocalMediaStream ειδικά για μια τοπική ροή. Στο JavaScript μπορείτε να συναντήσετε μόνο το πρώτο, αλλά εάν χρησιμοποιείτε το libjingle μπορείτε επίσης να συναντήσετε το δεύτερο.

Το WebRTC έχει μια μάλλον συγκεχυμένη ιεραρχία μέσα σε ένα νήμα. Κάθε ροή μπορεί να αποτελείται από πολλά κομμάτια πολυμέσων (MediaTrack), τα οποία με τη σειρά τους μπορούν να αποτελούνται από πολλά κανάλια πολυμέσων (MediaChannel). Και μπορεί επίσης να υπάρχουν αρκετές ροές πολυμέσων οι ίδιοι.

Ας τα δούμε όλα με τη σειρά. Για να το κάνουμε αυτό, ας έχουμε υπόψη μας κάποιο παράδειγμα. Ας πούμε ότι θέλουμε να μεταδώσουμε όχι μόνο ένα βίντεο του εαυτού μας, αλλά και ένα βίντεο του τραπεζιού μας, στο οποίο βρίσκεται ένα κομμάτι χαρτί στο οποίο πρόκειται να γράψουμε κάτι. Θα χρειαστούμε δύο βίντεο (εμάς + τραπέζι) και ένα ήχο (εμάς). Είναι σαφές ότι εμείς και ο πίνακας πρέπει να χωρίσουμε σε διαφορετικά νήματα, επειδή αυτά τα δεδομένα είναι πιθανώς ασθενώς εξαρτημένα το ένα από το άλλο. Επομένως, θα έχουμε δύο MediaStream - ένα για εμάς και ένα για το τραπέζι. Το πρώτο θα περιέχει δεδομένα βίντεο και ήχου και το δεύτερο θα περιέχει μόνο βίντεο (Εικόνα 4).

Εικόνα 4: Δύο διαφορετικές ροές πολυμέσων. Ένα για εμάς, ένα για το τραπέζι μας

Είναι αμέσως σαφές ότι μια ροή πολυμέσων τουλάχιστον πρέπει να περιλαμβάνει τη δυνατότητα να περιέχει δεδομένα ΔΙΑΦΟΡΕΤΙΚΟΙ ΤΥΠΟΙ- βίντεο και ήχος. Αυτό λαμβάνεται υπόψη στην τεχνολογία και επομένως κάθε τύπος δεδομένων υλοποιείται μέσω ενός κομματιού πολυμέσων MediaTrack. Το κομμάτι πολυμέσων έχει ένα ειδικό είδος ιδιότητας , το οποίο καθορίζει αν είναι βίντεο ή ήχος (Εικόνα 5)

Εικόνα 5: Οι ροές πολυμέσων αποτελούνται από κομμάτια πολυμέσων

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

Πώς όμως διακρίνουμε τις ροές πολυμέσων στο άλλο άκρο της σύνδεσης; Για να γίνει αυτό, κάθε ροή πολυμέσων έχει μια ιδιότητα ετικέτας - την ετικέτα της ροής, το όνομά της (Εικόνα 6). Τα κομμάτια πολυμέσων έχουν την ίδια ιδιότητα. Αν και με την πρώτη ματιά φαίνεται ότι το βίντεο μπορεί να διακριθεί από τον ήχο με άλλους τρόπους.

Εικόνα 6: Οι ροές και τα κομμάτια πολυμέσων αναγνωρίζονται με ετικέτες

Επομένως, εάν τα κομμάτια πολυμέσων μπορούν να αναγνωριστούν μέσω μιας ετικέτας, τότε γιατί πρέπει να χρησιμοποιήσουμε δύο ροές πολυμέσων για το παράδειγμά μας, αντί για μία; Μετά από όλα, μπορείτε να μεταδώσετε μια ροή πολυμέσων, αλλά να χρησιμοποιήσετε διαφορετικά κομμάτια σε αυτήν. Έχουμε φτάσει σε μια σημαντική ιδιότητα των ροών των μέσων ενημέρωσης - αυτά συγχρονίζωκομμάτια πολυμέσων. Οι διαφορετικές ροές πολυμέσων δεν συγχρονίζονται μεταξύ τους, αλλά μέσα σε κάθε ροή πολυμέσων όλα τα κομμάτια παίζονται ταυτόχρονα.

Έτσι, αν θέλουμε τα λόγια μας, τα συναισθήματα του προσώπου μας και το χαρτί μας να παίζονται ταυτόχρονα, τότε αξίζει να χρησιμοποιήσουμε μια ροή μέσων. Εάν αυτό δεν είναι τόσο σημαντικό, τότε είναι πιο κερδοφόρο να χρησιμοποιείτε διαφορετικές ροές - η εικόνα θα είναι πιο ομαλή.

Εάν κάποιο κομμάτι πρέπει να απενεργοποιηθεί κατά τη μετάδοση, μπορείτε να χρησιμοποιήσετε την ενεργοποιημένη ιδιότητα του κομματιού πολυμέσων.

Τέλος, αξίζει να σκεφτείτε τον στερεοφωνικό ήχο. Όπως γνωρίζετε, ο στερεοφωνικός ήχος είναι δύο διαφορετικοί ήχοι. Και πρέπει επίσης να μεταφερθούν χωριστά. Τα MediaChannels χρησιμοποιούνται για αυτό. Ένα κομμάτι ήχου πολυμέσων μπορεί να έχει πολλά κανάλια (για παράδειγμα, 6 αν χρειάζεστε 5+1 ήχο). Υπάρχουν και κανάλια μέσα στα κομμάτια πολυμέσων, φυσικά. συγχρονισμένη. Για βίντεο, συνήθως χρησιμοποιείται μόνο ένα κανάλι, αλλά πολλά μπορούν να χρησιμοποιηθούν, για παράδειγμα, για επικάλυψη διαφημίσεων.

Να συνοψίσουμε:Χρησιμοποιούμε μια ροή πολυμέσων για τη μετάδοση δεδομένων βίντεο και ήχου. Μέσα σε κάθε ροή πολυμέσων, τα δεδομένα συγχρονίζονται. Μπορούμε να χρησιμοποιήσουμε πολλαπλές ροές πολυμέσων εάν δεν χρειαζόμαστε συγχρονισμό. Μέσα σε κάθε ροή πολυμέσων υπάρχουν δύο τύποι κομματιών πολυμέσων - για βίντεο και για ήχο. Συνήθως δεν υπάρχουν περισσότερα από δύο κομμάτια, αλλά μπορεί να υπάρχουν περισσότερα αν χρειαστεί να μεταδώσετε πολλά διαφορετικά βίντεο (του συνομιλητή και του τραπεζιού του). Κάθε κομμάτι μπορεί να αποτελείται από πολλά κανάλια, τα οποία συνήθως χρησιμοποιούνται μόνο για στερεοφωνικό ήχο.

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

Περιγραφέας συνεδρίας (SDP)

Διαφορετικοί υπολογιστές θα έχουν πάντα διαφορετικές κάμερες, μικρόφωνα, κάρτες βίντεο και άλλο εξοπλισμό. Υπάρχουν πολλές επιλογές που έχουν. Όλα αυτά πρέπει να συντονίζονται για τη μεταφορά δεδομένων μέσων μεταξύ δύο κόμβων δικτύου. Το WebRTC το κάνει αυτόματα και δημιουργεί ειδικό αντικείμενο– Περιγραφέας συνεδρίας SDP. Περάστε αυτό το αντικείμενο σε άλλο κόμβο και τα δεδομένα πολυμέσων μπορούν να μεταφερθούν. Μόνο που δεν υπάρχει ακόμα σύνδεση με άλλο κόμβο.

Για αυτό χρησιμοποιείται οποιοσδήποτε μηχανισμός σηματοδότησης. Το SDP μπορεί να μεταδοθεί είτε μέσω υποδοχών είτε από ένα άτομο (πείτε το σε άλλο κόμβο μέσω τηλεφώνου), είτε από τη Russian Post. Όλα είναι πολύ απλά - θα σας δοθεί ένα έτοιμο SDP και πρέπει να το στείλετε. Και όταν το λάβετε από την άλλη πλευρά, μεταφέρετέ το στο τμήμα WebRTC. Ο περιγραφέας περιόδου λειτουργίας αποθηκεύεται ως κείμενο και μπορεί να αλλάξει στις εφαρμογές σας, αλλά αυτό γενικά δεν είναι απαραίτητο. Για παράδειγμα, όταν συνδέετε επιτραπέζιο τηλέφωνο ↔, μερικές φορές χρειάζεται να επιβάλετε την επιλογή του επιθυμητού κωδικοποιητή ήχου.

Συνήθως, κατά τη δημιουργία μιας σύνδεσης, πρέπει να καθορίσετε κάποιο είδος διεύθυνσης, όπως μια διεύθυνση URL. Αυτό δεν είναι απαραίτητο εδώ, αφού μέσω του μηχανισμού σηματοδότησης εσείς οι ίδιοι θα στείλετε τα δεδομένα στον προορισμό τους. Για να υποδείξουμε στο WebRTC ότι θέλουμε να δημιουργήσουμε μια σύνδεση p2p, πρέπει να καλέσουμε τη συνάρτηση δημιουργίας προσφοράς. Μετά την κλήση αυτής της συνάρτησης και τον καθορισμό μιας ειδικής επανάκλησης 'a, ένα αντικείμενο SDP θα δημιουργηθεί και θα περάσει στην ίδια επανάκληση. Το μόνο που απαιτείται από εσάς είναι να μεταφέρετε αυτό το αντικείμενο μέσω του δικτύου σε έναν άλλο κόμβο (συνομιλητή). Μετά από αυτό, τα δεδομένα θα φτάσουν στο άλλο άκρο μέσω του μηχανισμού σηματοδότησης, δηλαδή αυτό το αντικείμενο SDP. Αυτός ο περιγραφέας συνεδρίας είναι ξένος σε αυτόν τον κόμβο και επομένως φέρει χρήσιμες πληροφορίες. Η λήψη αυτού του αντικειμένου είναι ένα σήμα για την έναρξη της σύνδεσης. Επομένως, πρέπει να συμφωνήσετε με αυτό και να καλέσετε τη συνάρτηση createAnswer. Είναι ένα πλήρες ανάλογο του createOffer. Και πάλι, ο περιγραφέας τοπικής περιόδου λειτουργίας θα μεταβιβαστεί στην επανάκλησή σας και θα πρέπει να επιστραφεί μέσω του μηχανισμού σηματοδότησης.

Αξίζει να σημειωθεί ότι μπορείτε να καλέσετε τη συνάρτηση createAnswer μόνο αφού λάβετε το αντικείμενο SDP κάποιου άλλου. Γιατί; Επειδή το τοπικό αντικείμενο SDP που θα δημιουργηθεί κατά την κλήση του createAnswer πρέπει να βασίζεται στο απομακρυσμένο αντικείμενο SDP. Μόνο σε αυτήν την περίπτωση είναι δυνατό να συντονίσετε τις ρυθμίσεις του βίντεο με τις ρυθμίσεις του συνομιλητή σας. Επίσης, δεν πρέπει να καλέσετε το createAnswer και το createOffer πριν λάβετε τη ροή τοπικών μέσων - δεν θα έχουν τίποτα να γράψουν στο αντικείμενο SDP.

Εφόσον το WebRTC έχει τη δυνατότητα να επεξεργαστεί ένα αντικείμενο SDP, μετά τη λήψη ενός τοπικού περιγραφέα πρέπει να εγκατασταθεί. Μπορεί να φαίνεται λίγο περίεργο ότι πρέπει να μεταφέρουμε στο WebRTC αυτό που μας έδωσε η ίδια, αλλά αυτό είναι το πρωτόκολλο. Όταν λαμβάνεται μια απομακρυσμένη λαβή, πρέπει επίσης να εγκατασταθεί. Επομένως, πρέπει να εγκαταστήσετε δύο περιγραφείς σε έναν κόμβο - δικό σας και κάποιου άλλου (δηλαδή τοπικό και απομακρυσμένο).

Μετά από αυτό χειραψίεςοι κόμβοι γνωρίζουν ο ένας τις επιθυμίες του άλλου. Για παράδειγμα, εάν ο κόμβος 1 υποστηρίζει κωδικοποιητές Α και Β και ο κόμβος 2 υποστηρίζει κωδικοποιητές Β και Γ, τότε, εφόσον κάθε κόμβος γνωρίζει τους δικούς του και τους περιγραφείς του άλλου, και οι δύο κόμβοι θα επιλέξουν τον κωδικοποιητή Β (Εικόνα 7). Η λογική σύνδεσης έχει πλέον καθιερωθεί και οι ροές πολυμέσων μπορούν να μεταδοθούν, αλλά υπάρχει ένα άλλο πρόβλημα - οι κόμβοι εξακολουθούν να συνδέονται μόνο με έναν μηχανισμό σηματοδότησης.

Εικόνα 7: Διαπραγμάτευση κωδικοποιητή

Υποψήφιος πάγος

Η τεχνολογία WebRTC προσπαθεί να μας μπερδέψει με τη νέα της μεθοδολογία. Κατά τη δημιουργία μιας σύνδεσης, η διεύθυνση του κόμβου στον οποίο θέλετε να συνδεθείτε δεν καθορίζεται. Εγκαταστάθηκε πρώτα λογικόςσύνδεση, όχι φυσικός, αν και πάντα γινόταν το αντίθετο. Αυτό όμως δεν θα φανεί παράξενο αν δεν ξεχνάμε ότι χρησιμοποιούμε μηχανισμό σηματοδότησης τρίτων.

Έτσι, η σύνδεση έχει ήδη δημιουργηθεί (λογική σύνδεση), αλλά δεν υπάρχει ακόμη διαδρομή κατά την οποία οι κόμβοι του δικτύου μπορούν να μεταδώσουν δεδομένα. Δεν είναι όλα τόσο απλά, αλλά ας ξεκινήσουμε απλά. Αφήστε τους κόμβους να βρίσκονται στο ίδιο ιδιωτικό δίκτυο. Όπως ήδη γνωρίζουμε, μπορούν εύκολα να συνδεθούν μεταξύ τους χρησιμοποιώντας τις εσωτερικές τους διευθύνσεις IP (ή ίσως κάποιες άλλες, αν δεν χρησιμοποιείται TCP/IP).

Μέσω κάποιας επιστροφής κλήσης και το WebRTC μας ενημερώνει για υποψήφια αντικείμενα Ice. Έρχονται επίσης σε μορφή κειμένου και, όπως οι περιγραφείς συνεδρίας, πρέπει απλώς να αποστέλλονται μέσω ενός μηχανισμού σηματοδότησης. Εάν ο περιγραφέας περιόδου λειτουργίας περιείχε πληροφορίες σχετικά με τις ρυθμίσεις μας σε επίπεδο κάμερας και μικροφώνου, τότε οι υποψήφιοι περιέχουν πληροφορίες σχετικά με την τοποθεσία μας στο δίκτυο. Περάστε τα σε έναν άλλο κόμβο και θα μπορεί να συνδεθεί φυσικά με εμάς, και εφόσον έχει ήδη έναν περιγραφέα περιόδου λειτουργίας, λογικά θα μπορεί να συνδεθεί και τα δεδομένα θα «ρέουν». Αν θυμηθεί να μας στείλει το υποψήφιο αντικείμενο του, δηλαδή πληροφορίες για το πού βρίσκεται ο ίδιος στο δίκτυο, τότε θα μπορέσουμε να συνδεθούμε μαζί του. Ας σημειώσουμε εδώ μια ακόμη διαφορά από την κλασική αλληλεπίδραση πελάτη-διακομιστή. Η επικοινωνία με τον διακομιστή HTTP πραγματοποιείται σύμφωνα με το σχήμα αίτησης-απόκρισης, ο πελάτης στέλνει δεδομένα στον διακομιστή, ο οποίος τα επεξεργάζεται και τα στέλνει μέσω τη διεύθυνση που καθορίζεται στο πακέτο αιτήματος. Στο WebRTC πρέπει να ξέρετε δύο διευθύνσειςκαι συνδέστε τα και από τις δύο πλευρές.

Η διαφορά από τους περιγραφείς συνεδρίας είναι ότι πρέπει να εγκατασταθούν μόνο απομακρυσμένοι υποψήφιοι. Η επεξεργασία εδώ απαγορεύεται και δεν μπορεί να αποφέρει κανένα όφελος. Σε ορισμένες υλοποιήσεις WebRTC, οι υποψήφιοι πρέπει να εγκατασταθούν μόνο αφού έχουν οριστεί περιγραφές συνεδρίας.

Γιατί υπήρχε μόνο ένας περιγραφέας συνεδρίας, αλλά θα μπορούσαν να υπάρχουν πολλοί υποψήφιοι; Επειδή η τοποθεσία στο δίκτυο μπορεί να προσδιοριστεί όχι μόνο από την εσωτερική διεύθυνση IP του, αλλά και από την εξωτερική διεύθυνση του δρομολογητή, και όχι απαραίτητα μόνο από έναν, καθώς και από τις διευθύνσεις των διακομιστών TURN. Το υπόλοιπο της παραγράφου θα αφιερωθεί σε μια λεπτομερή συζήτηση των υποψηφίων και στον τρόπο σύνδεσης κόμβων από διαφορετικά ιδιωτικά δίκτυα.

Έτσι, δύο κόμβοι βρίσκονται στο ίδιο δίκτυο (Εικόνα 8). Πώς να τα αναγνωρίσετε; Χρήση διευθύνσεων IP. Δεν έχει άλλο τρόπο. Είναι αλήθεια ότι μπορείτε ακόμα να χρησιμοποιήσετε διαφορετικές μεταφορές (TCP και UDP) και διαφορετικές θύρες. Αυτές είναι οι πληροφορίες που περιέχονται στο υποψήφιο αντικείμενο - IP, PORT, TRANSPORT και μερικά άλλα. Ας χρησιμοποιήσουμε, για παράδειγμα, τη μεταφορά UDP και τη θύρα 531.

Εικόνα 8: Δύο κόμβοι βρίσκονται στο ίδιο δίκτυο

Τότε, αν βρισκόμαστε στον κόμβο p1, τότε το WebRTC θα μας δώσει ένα τέτοιο υποψήφιο αντικείμενο - . Αυτό δεν είναι μια ακριβής μορφή, απλώς ένα διάγραμμα. Αν βρισκόμαστε στον κόμβο p2, τότε ο υποψήφιος είναι . Μέσω του μηχανισμού σηματοδότησης, το p1 θα λάβει τον υποψήφιο του p2 (δηλαδή τη θέση του κόμβου p2, δηλαδή την IP και τη PORT του). Τότε το p1 μπορεί να συνδεθεί απευθείας με το p2. Πιο σωστά, το p1 θα στείλει δεδομένα στο 10.50.150.3:531 με την ελπίδα ότι θα φτάσει στο p2. Δεν έχει σημασία αν αυτή η διεύθυνση ανήκει στον κόμβο p2 ή σε κάποιο ενδιάμεσο. Το μόνο σημαντικό πράγμα είναι ότι τα δεδομένα θα σταλούν μέσω αυτής της διεύθυνσης και μπορούν να φτάσουν στο p2.

Εφόσον οι κόμβοι βρίσκονται στο ίδιο δίκτυο, όλα είναι απλά και εύκολα - κάθε κόμβος έχει μόνο ένα υποψήφιο αντικείμενο (που σημαίνει πάντα το δικό του, δηλαδή τη θέση του στο δίκτυο). Αλλά θα υπάρχουν πολλοί περισσότεροι υποψήφιοι όταν οι κόμβοι είναι μέσα διαφορετικόςδίκτυα.

Ας περάσουμε σε μια πιο σύνθετη υπόθεση. Ένας κόμβος θα βρίσκεται πίσω από τον δρομολογητή (ακριβέστερα, πίσω από το NAT) και ο δεύτερος κόμβος θα βρίσκεται στο ίδιο δίκτυο με αυτόν τον δρομολογητή (για παράδειγμα, στο Διαδίκτυο) (Εικόνα 9).

Εικόνα 9: Ο ένας κόμβος βρίσκεται πίσω από το NAT, ο άλλος όχι

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

Ας υποθέσουμε ότι ο διακομιστής Ιστού είναι απευθείας συνδεδεμένος στο Διαδίκτυο, δηλαδή έχει μια δημόσια διεύθυνση IP *. Ας είναι αυτός ο κόμβος p2. Ο κόμβος p1 (πελάτης ιστού) στέλνει ένα αίτημα στη διεύθυνση 10.50.200.10. Πρώτον, τα δεδομένα πηγαίνουν στον δρομολογητή r1, ή μάλλον στον δρομολογητή εσωτερικόδιεπαφή 192.168.0.1. Μετά από αυτό, ο δρομολογητής θυμάται τη διεύθυνση πηγής (διεύθυνση p1) και την εισάγει σε έναν ειδικό πίνακα NAT και, στη συνέχεια, αλλάζει τη διεύθυνση πηγής στη δική του (p1 → r1). Επιπλέον, με τον δικό μου τρόπο εξωτερικόςδιεπαφή, ο δρομολογητής στέλνει δεδομένα απευθείας στον διακομιστή web p2. Ο διακομιστής Ιστού επεξεργάζεται τα δεδομένα, δημιουργεί μια απάντηση και τα στέλνει πίσω. Στέλνει το r1 στον δρομολογητή, αφού βρίσκεται στη διεύθυνση επιστροφής (ο δρομολογητής αντικατέστησε τη διεύθυνση με τη δική του). Ο δρομολογητής λαμβάνει τα δεδομένα, κοιτάζει τον πίνακα NAT και προωθεί τα δεδομένα στον κόμβο p1. Ο δρομολογητής λειτουργεί ως ενδιάμεσος εδώ.

Τι γίνεται αν πολλοί κόμβοι από το εσωτερικό δίκτυο έχουν πρόσβαση ταυτόχρονα στο εξωτερικό δίκτυο; Πώς θα καταλάβει ο δρομολογητής σε ποιον να στείλει την απάντηση; Αυτό το πρόβλημα επιλύεται χρησιμοποιώντας λιμάνια. Όταν ένας δρομολογητής αντικαθιστά τη διεύθυνση κεντρικού υπολογιστή με τη δική του, αντικαθιστά επίσης τη θύρα. Εάν δύο κόμβοι έχουν πρόσβαση στο Διαδίκτυο, τότε ο δρομολογητής αντικαθιστά τις θύρες πηγής με διαφορετικός. Στη συνέχεια, όταν το πακέτο από τον διακομιστή ιστού επιστρέψει στο δρομολογητή, ο δρομολογητής θα καταλάβει από τη θύρα σε ποιον έχει εκχωρηθεί το πακέτο. Παράδειγμα παρακάτω.

Ας επιστρέψουμε στην τεχνολογία WebRTC, ή πιο συγκεκριμένα, στο τμήμα της που χρησιμοποιεί το πρωτόκολλο ICE (εξ ου και οι υποψήφιοι Ice). Ο κόμβος p2 έχει έναν υποψήφιο (η θέση του στο δίκτυο είναι 10.50.200.10) και ο κόμβος p1, ο οποίος βρίσκεται πίσω από το δρομολογητή με NAT, θα έχει δύο υποψήφιους - τοπικό (192.168.0.200) και υποψήφιο δρομολογητή (10.50.200.5). Το πρώτο δεν είναι χρήσιμο, αλλά παρ' όλα αυτά δημιουργείται, αφού το WebRTC δεν γνωρίζει ακόμη τίποτα για τον απομακρυσμένο κόμβο - μπορεί να βρίσκεται ή να μην βρίσκεται στο ίδιο δίκτυο. Ο δεύτερος υποψήφιος θα φανεί χρήσιμος και, όπως ήδη γνωρίζουμε, σημαντικό ρόλο θα παίξει το λιμάνι (για να περάσεις από το ΝΑΤ).

Μια καταχώρηση στον πίνακα NAT δημιουργείται μόνο όταν τα δεδομένα εξέρχονται από το εσωτερικό δίκτυο. Επομένως, ο κόμβος p1 πρέπει πρώτα να μεταδώσει τα δεδομένα και μόνο μετά από αυτό τα δεδομένα από τον κόμβο p2 μπορούν να φτάσουν στον κόμβο p1.

Στην πράξη και οι δύο κόμβοιθα είναι πίσω από το ΝΑΤ. Για να δημιουργήσετε μια καταχώρηση στον πίνακα NAT κάθε δρομολογητή, οι κεντρικοί υπολογιστές πρέπει να στείλουν κάτι στον απομακρυσμένο κεντρικό υπολογιστή, αλλά αυτή τη φορά ούτε ο πρώτος μπορεί να φτάσει στον δεύτερο ούτε το αντίστροφο. Αυτό οφείλεται στο γεγονός ότι οι κόμβοι δεν γνωρίζουν τις εξωτερικές διευθύνσεις IP τους και η αποστολή δεδομένων σε εσωτερικές διευθύνσεις είναι άσκοπη.

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

Το πρόβλημα είναι ότι για να μάθετε την εξωτερική σας διεύθυνση IP, χρειάζεστε έναν κόμβο που βρίσκεται μέσα κοινόχρηστο δίκτυο. Για την επίλυση αυτού του προβλήματος, χρησιμοποιούνται πρόσθετοι διακομιστές που είναι απευθείας συνδεδεμένοι στο Διαδίκτυο. Με τη βοήθειά τους, δημιουργούνται επίσης σημαντικές καταχωρήσεις στον πίνακα NAT.

STUN και TURN διακομιστές

Κατά την προετοιμασία του WebRTC, πρέπει να καθορίσετε τους διαθέσιμους διακομιστές STUN και TURN, τους οποίους θα καλούμε στο εξής διακομιστές ICE. Εάν δεν έχουν καθοριστεί διακομιστές, τότε μόνο οι κόμβοι στο ίδιο δίκτυο (που είναι συνδεδεμένοι σε αυτό χωρίς NAT) θα μπορούν να συνδεθούν. Αξίζει άμεσα να σημειωθεί ότι για δίκτυα 3g η χρήση διακομιστών TURN είναι υποχρεωτική.

ΖΑΛΙΖΩ υπηρέτηςείναι απλώς ένας διακομιστής στο Διαδίκτυο που επιστρέφει μια διεύθυνση επιστροφής, δηλαδή τη διεύθυνση του κόμβου του αποστολέα. Ο κεντρικός υπολογιστής πίσω από τον δρομολογητή επικοινωνεί με τον διακομιστή STUN για να διασχίσει το NAT. Το πακέτο που ήρθε στον διακομιστή STUN περιέχει τη διεύθυνση πηγής - τη διεύθυνση του δρομολογητή, δηλαδή την εξωτερική διεύθυνση του κόμβου μας. Αυτή είναι η διεύθυνση STUN που στέλνει ο διακομιστής. Έτσι, ο κόμβος λαμβάνει την εξωτερική του διεύθυνση IP και τη θύρα μέσω της οποίας είναι προσβάσιμος από το δίκτυο. Στη συνέχεια, το WebRTC χρησιμοποιεί αυτήν τη διεύθυνση για να δημιουργήσει έναν επιπλέον υποψήφιο (διεύθυνση και θύρα εξωτερικού δρομολογητή). Τώρα υπάρχει μια καταχώρηση στον πίνακα NAT του δρομολογητή που επιτρέπει στα πακέτα που αποστέλλονται στον δρομολογητή στην απαιτούμενη θύρα να φτάσουν στον κόμβο μας.

Ας δούμε αυτή τη διαδικασία με ένα παράδειγμα.

Παράδειγμα (λειτουργία διακομιστή STUN)

Ο διακομιστής STUN θα συμβολίζεται με το s1. Ο δρομολογητής, όπως και πριν, είναι μέσω του r1 και ο κόμβος είναι μέσω του p1. Θα χρειαστεί επίσης να παρακολουθείτε τον πίνακα NAT - θα τον χαρακτηρίσουμε ως r1_nat. Επιπλέον, αυτός ο πίνακας περιέχει συνήθως πολλές εγγραφές από διαφορετικούς κόμβους του υποδικτύου - δεν δίνονται.

Έτσι, στην αρχή έχουμε έναν κενό πίνακα r1_nat.

Πίνακας 2: Κεφαλίδα πακέτου

Ο κόμβος p1 στέλνει αυτό το πακέτο στον δρομολογητή r1 (ανεξάρτητα από το πώς μπορούν να χρησιμοποιήσουν διαφορετικά υποδίκτυα διαφορετικές τεχνολογίες). Ο δρομολογητής πρέπει να αντικαταστήσει τη διεύθυνση πηγής Src IP, καθώς η διεύθυνση που καθορίζεται στο πακέτο προφανώς δεν είναι κατάλληλη για εξωτερικό υποδίκτυο· επιπλέον, οι διευθύνσεις από ένα τέτοιο εύρος είναι δεσμευμένες και καμία διεύθυνση στο Διαδίκτυο δεν έχει τέτοια διεύθυνση. Ο δρομολογητής κάνει μια αντικατάσταση στο πακέτο και δημιουργεί νέα καταχώρησηστο τραπέζι σας r1_nat. Για να γίνει αυτό, πρέπει να βρει έναν αριθμό θύρας. Θυμηθείτε ότι εφόσον πολλοί κεντρικοί υπολογιστές σε ένα υποδίκτυο μπορούν να έχουν πρόσβαση σε ένα εξωτερικό δίκτυο, ο πίνακας NAT πρέπει να αποθηκεύεται Επιπλέον πληροφορίες, έτσι ώστε ο δρομολογητής να μπορεί να προσδιορίσει ποιος από αυτούς τους πολλούς κόμβους προορίζεται για το πακέτο επιστροφής από τον διακομιστή. Αφήστε το δρομολογητή να βρει τη θύρα 888.

Άλλαξε την κεφαλίδα του πακέτου:

Πίνακας 4: Ο πίνακας NAT έχει ενημερωθεί με νέα καταχώρηση

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

Η πραγματική θύρα στην οποία ο κόμβος p1 δέχεται τη σύνδεση είναι, φυσικά, 35777, αλλά ο διακομιστής στέλνει δεδομένα σε πλασματικόςθύρα 888, η οποία θα αλλάξει από το δρομολογητή στην πραγματική 35777.

Έτσι, ο δρομολογητής αντικατέστησε τη διεύθυνση πηγής και τη θύρα στην κεφαλίδα του πακέτου και πρόσθεσε μια καταχώρηση στον πίνακα NAT. Τώρα το πακέτο αποστέλλεται μέσω του δικτύου στον διακομιστή, δηλαδή στον κόμβο s1. Στην είσοδο, το s1 έχει το ακόλουθο πακέτο:

Src IP Src PORT Προορισμός IP ΘΥΡΑ προορισμού

10.50.200.5	888	12.62.100.200	6000

Πίνακας 5: Το πακέτο έλαβε ο διακομιστής STUN

Συνολικά, ο διακομιστής STUN γνωρίζει ότι έλαβε ένα πακέτο από τη διεύθυνση 10.50.200.5:888. Τώρα ο διακομιστής στέλνει αυτήν τη διεύθυνση πίσω. Αξίζει να σταματήσουμε εδώ και να ρίξουμε άλλη μια ματιά σε αυτό που μόλις εξετάσαμε. Οι παραπάνω πίνακες είναι ένα απόσπασμα από επί κεφαλήςπακέτο, καθόλου από αυτό περιεχόμενο. Δεν μιλήσαμε για το περιεχόμενο, αφού δεν είναι τόσο σημαντικό - κατά κάποιο τρόπο περιγράφεται στο πρωτόκολλο STUN. Τώρα θα εξετάσουμε, εκτός από τον τίτλο, και το περιεχόμενο. Θα είναι απλό και θα περιέχει τη διεύθυνση του δρομολογητή - 10.50.200.5:888, αν και το πήραμε από επί κεφαλήςπακέτο. Αυτό δεν γίνεται συχνά· τα πρωτόκολλα συνήθως δεν ενδιαφέρονται για πληροφορίες σχετικά με τις διευθύνσεις κόμβων· είναι μόνο σημαντικό τα πακέτα να παραδίδονται στον προορισμό τους. Εδώ εξετάζουμε ένα πρωτόκολλο που δημιουργεί μια διαδρομή μεταξύ δύο κόμβων.

Λοιπόν τώρα έχουμε ένα δεύτερο πακέτο που πηγαίνει προς την αντίθετη κατεύθυνση:

Πίνακας 7: Ο διακομιστής STUN στέλνει ένα πακέτο με αυτό το περιεχόμενο

Στη συνέχεια, το πακέτο ταξιδεύει στο δίκτυο μέχρι να φτάσει στην εξωτερική διεπαφή του δρομολογητή r1. Ο δρομολογητής κατανοεί ότι το πακέτο δεν προορίζεται για αυτόν. Πώς το καταλαβαίνει αυτό; Αυτό μπορεί να καθοριστεί μόνο από το λιμάνι. Δεν χρησιμοποιεί τη θύρα 888 για προσωπικούς του σκοπούς, αλλά τη χρησιμοποιεί για τον μηχανισμό NAT. Επομένως, ο δρομολογητής κοιτάζει αυτόν τον πίνακα. Εξετάζει τη στήλη External PORT και αναζητά μια γραμμή που ταιριάζει με το Dest PORT από το εισερχόμενο πακέτο, δηλαδή το 888.

Εσωτερική IP Εσωτερική θύρα Εξωτερική IP Εξωτερική θύρα

192.168.0.200	35777	10.50.200.5	888

Πίνακας 8: Πίνακας NAT

Είμαστε τυχεροί, υπάρχει μια τέτοια γραμμή. Αν ήμασταν άτυχοι, το πακέτο απλώς θα απορρίπτονταν. Τώρα πρέπει να καταλάβετε ποιος κόμβος στο υποδίκτυο πρέπει να στείλει αυτό το πακέτο. Δεν χρειάζεται να βιαστείτε, ας θυμηθούμε ξανά τη σημασία των θυρών σε αυτόν τον μηχανισμό. Ταυτόχρονα, δύο κόμβοι στο υποδίκτυο θα μπορούσαν να στείλουν αιτήματα στο εξωτερικό δίκτυο. Στη συνέχεια, εάν ο δρομολογητής είχε τη θύρα 888 για τον πρώτο κόμβο, τότε για τον δεύτερο θα έβγαινε με τη θύρα 889. Ας υποθέσουμε ότι αυτό συνέβη, δηλαδή, ο πίνακας r1_nat μοιάζει με αυτό:

Πίνακας 10: Ο δρομολογητής αντικαθιστά τη διεύθυνση του δέκτη

Src IP Src PORT Προορισμός IP ΘΥΡΑ προορισμού

12.62.100.200	6000	192.168.0.200	35777

Πίνακας 11: Ο δρομολογητής άλλαξε τη διεύθυνση του δέκτη

Το πακέτο φτάνει με επιτυχία στον κόμβο p1 και, κοιτάζοντας τα περιεχόμενα του πακέτου, ο κόμβος μαθαίνει για την εξωτερική του διεύθυνση IP, δηλαδή τη διεύθυνση του δρομολογητή στο εξωτερικό δίκτυο. Γνωρίζει επίσης τη θύρα που περνά το ρούτερ από το ΝΑΤ.

Τι έπεται? Σε τι χρησιμεύουν όλα αυτά; Ένα όφελος είναι μια καταχώρηση στον πίνακα r1_nat. Εάν τώρα κάποιος στείλει ένα πακέτο με τη θύρα 888 στον δρομολογητή r1, τότε ο δρομολογητής θα προωθήσει αυτό το πακέτο στον κόμβο p1. Αυτό δημιούργησε ένα μικρό στενό πέρασμα στον κρυφό κόμβο p1.

Από το παραπάνω παράδειγμα μπορείτε να πάρετε κάποια ιδέα για το πώς λειτουργεί το NAT και την ουσία ενός διακομιστή STUN. Γενικά, ο μηχανισμός ICE και οι διακομιστές STUN/TURN στοχεύουν ακριβώς στην υπέρβαση των περιορισμών NAT.

Μεταξύ του κόμβου και του διακομιστή δεν μπορεί να υπάρχει ένας δρομολογητής, αλλά πολλοί. Σε αυτήν την περίπτωση, ο κόμβος θα λάβει τη διεύθυνση του δρομολογητή που είναι ο πρώτος που έχει πρόσβαση στο ίδιο δίκτυο με τον διακομιστή. Με άλλα λόγια, θα λάβουμε τη διεύθυνση του δρομολογητή που είναι συνδεδεμένος στον διακομιστή STUN. Για επικοινωνία p2p, αυτό ακριβώς χρειαζόμαστε, αν δεν ξεχνάμε το γεγονός ότι κάθε router θα προσθέτει τη γραμμή που χρειαζόμαστε στον πίνακα NAT. Επομένως, ο δρόμος της επιστροφής θα είναι και πάλι το ίδιο ομαλή.

Ο διακομιστής TURN είναι ένας βελτιωμένος διακομιστής STUN. Από εδώ θα πρέπει να αφαιρέσετε αμέσως ότι οποιοσδήποτε διακομιστής TURN μπορεί επίσης να λειτουργήσει ως διακομιστής STUN. Ωστόσο, υπάρχουν και πλεονεκτήματα. Εάν η επικοινωνία p2p είναι αδύνατη (όπως, για παράδειγμα, σε δίκτυα 3g), τότε ο διακομιστής μεταβαίνει σε λειτουργία αναμετάδοσης, δηλαδή λειτουργεί ως ενδιάμεσος. Φυσικά, δεν μιλάμε για κανένα p2p τότε, αλλά εκτός του μηχανισμού ICE, οι κόμβοι νομίζουν ότι επικοινωνούν απευθείας.

Σε ποιες περιπτώσεις είναι απαραίτητος ένας διακομιστής TURN; Γιατί δεν υπάρχει αρκετός διακομιστής STUN; Το γεγονός είναι ότι υπάρχουν διάφοροι τύποι NAT. Αντικαθιστούν τη διεύθυνση IP και τη θύρα με τον ίδιο τρόπο, αλλά μερικά από αυτά έχουν ενσωματωμένη πρόσθετη προστασία από "παραποίηση". Για παράδειγμα, σε συμμετρικόςΟ πίνακας NAT αποθηκεύει 2 ακόμη παραμέτρους - IP και θύρα του απομακρυσμένου κεντρικού υπολογιστή. Ένα πακέτο από το εξωτερικό δίκτυο περνά μέσω NAT στο εσωτερικό δίκτυο μόνο εάν η διεύθυνση πηγής και η θύρα ταιριάζουν με αυτά που καταγράφονται στον πίνακα. Επομένως, το κόλπο με τον διακομιστή STUN αποτυγχάνει - ο πίνακας NAT αποθηκεύει τη διεύθυνση και τη θύρα του διακομιστή STUN και, όταν ο δρομολογητής λαμβάνει ένα πακέτο από τον συνομιλητή WebRTC, το απορρίπτει επειδή είναι "παραποιημένο". Δεν προήλθε από τον διακομιστή STUN.

Έτσι, απαιτείται διακομιστής TURN στην περίπτωση που και οι δύο συνομιλητές είναι πίσω συμμετρικόςΝΑΤ (ο καθένας στο δικό του).

Σύντομη περίληψη

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

• Ροή πολυμέσων
  • Τα δεδομένα βίντεο και ήχου συσκευάζονται σε ροές πολυμέσων
  • Οι ροές πολυμέσων συγχρονίζουν τα κομμάτια πολυμέσων που αποτελούν
  • Οι διαφορετικές ροές πολυμέσων δεν συγχρονίζονται μεταξύ τους
  • Οι ροές πολυμέσων μπορεί να είναι τοπικές και απομακρυσμένες, η τοπική συνήθως συνδέεται με κάμερα και μικρόφωνο, οι απομακρυσμένες λαμβάνουν δεδομένα από το δίκτυο σε κρυπτογραφημένη μορφή
  • Υπάρχουν δύο τύποι κομματιών πολυμέσων - για βίντεο και για ήχο.
  • Τα κομμάτια πολυμέσων έχουν τη δυνατότητα ενεργοποίησης/απενεργοποίησης
  • Τα κομμάτια πολυμέσων αποτελούνται από κανάλια πολυμέσων
  • Τα κομμάτια πολυμέσων συγχρονίζουν τα κανάλια πολυμέσων που αποτελούν
  • Οι ροές πολυμέσων και τα κομμάτια πολυμέσων έχουν ετικέτες με τις οποίες μπορούν να διακριθούν
• Λαβή συνεδρίας
  • Ο περιγραφέας περιόδου λειτουργίας χρησιμοποιείται για τη λογική σύνδεση δύο κόμβων δικτύου
  • Ο περιγραφέας συνεδρίας αποθηκεύει πληροφορίες σχετικά με διαθέσιμους τρόπουςκωδικοποίηση δεδομένων βίντεο και ήχου
  • Το WebRTC χρησιμοποιεί έναν εξωτερικό μηχανισμό σηματοδότησης - η αποστολή των περιγραφέων συνεδρίας (sdp) εμπίπτει στην εφαρμογή
  • Ο λογικός μηχανισμός σύνδεσης αποτελείται από δύο στάδια - προσφορά (προσφορά) και απάντηση (απάντηση)
  • Η δημιουργία ενός περιγραφέα περιόδου σύνδεσης είναι αδύνατη χωρίς τη χρήση ροής τοπικών μέσων στην περίπτωση μιας προσφοράς και είναι αδύνατη χωρίς τη χρήση ενός περιγραφέα απομακρυσμένης περιόδου σύνδεσης στην περίπτωση μιας απάντησης.
  • Ο περιγραφέας που προκύπτει πρέπει να δοθεί στην υλοποίηση WebRTC και δεν έχει σημασία αν αυτός ο περιγραφέας λαμβάνεται εξ αποστάσεως ή τοπικά από την ίδια υλοποίηση WebRTC
  • Είναι δυνατή η ελαφρά επεξεργασία του περιγραφέα συνεδρίας
• Υποψήφιοι
  • Ο υποψήφιος πάγος είναι η διεύθυνση ενός κόμβου στο δίκτυο
  • Η διεύθυνση του κόμβου μπορεί να είναι δική σας ή μπορεί να είναι η διεύθυνση ενός δρομολογητή ή διακομιστή TURN
  • Οι υποψήφιοι είναι πάντα πολλοί
  • Ο υποψήφιος αποτελείται από διεύθυνση IP, θύρα και τύπο μεταφοράς (TCP ή UDP)
  • Οι υποψήφιοι χρησιμοποιούνται για τη δημιουργία μιας φυσικής σύνδεσης μεταξύ δύο κόμβων σε ένα δίκτυο
  • Οι υποψήφιοι πρέπει επίσης να αποστέλλονται μέσω μηχανισμού σηματοδότησης
  • Οι υποψήφιοι πρέπει επίσης να περάσουν σε εφαρμογές WebRTC, αλλά μόνο σε απομακρυσμένες
  • Σε ορισμένες υλοποιήσεις WebRTC, οι υποψήφιοι μπορούν να μεταδοθούν μόνο αφού έχει οριστεί ένας περιγραφέας περιόδου λειτουργίας
• STUN/TURN/ICE/NAT
  • Το NAT είναι ένας μηχανισμός για την παροχή πρόσβασης σε ένα εξωτερικό δίκτυο
  • Οι οικιακές δρομολογητές υποστηρίζουν έναν ειδικό πίνακα NAT
  • Ο δρομολογητής αντικαθιστά τις διευθύνσεις στα πακέτα - τη διεύθυνση πηγής με τη δική της, εάν το πακέτο πηγαίνει σε εξωτερικό δίκτυο και τη διεύθυνση του παραλήπτη με τη διεύθυνση κεντρικού υπολογιστή στο εσωτερικό δίκτυο, εάν το πακέτο προήλθε από εξωτερικό δίκτυο
  • Για την παροχή πολυκαναλικής πρόσβασης σε εξωτερικό δίκτυο, το NAT χρησιμοποιεί θύρες
  • ICE - NAT Traversal Engine
  • Διακομιστές STUN και TURN – βοηθοί διακομιστές για διέλευση NAT
  • Ο διακομιστής STUN σάς επιτρέπει να δημιουργήσετε τις απαραίτητες καταχωρήσεις στον πίνακα NAT και επίσης επιστρέφει την εξωτερική διεύθυνση του κεντρικού υπολογιστή
  • Ο διακομιστής TURN γενικεύει τον μηχανισμό STUN και τον κάνει να λειτουργεί πάντα
  • Στις χειρότερες περιπτώσεις, ο διακομιστής TURN χρησιμοποιείται ως ενδιάμεσος (ρελέ), δηλαδή το p2p μετατρέπεται σε σύνδεση πελάτη-διακομιστή-πελάτη.

Σήμερα, το WebRTC είναι η «καυτή» τεχνολογία για ροή ήχου και βίντεο σε προγράμματα περιήγησης. Οι συντηρητικές τεχνολογίες, όπως το HTTP Streaming και το Flash, είναι πιο κατάλληλες για τη διανομή εγγεγραμμένου περιεχομένου (video on demand) και είναι σημαντικά κατώτερες από το WebRTC όσον αφορά τις εκπομπές σε πραγματικό χρόνο και τις διαδικτυακές εκπομπές, π.χ. όπου απαιτείται ελάχιστος λανθάνοντας χρόνος βίντεο για να μπορούν οι θεατές να δουν τι συμβαίνει "ζωντανά".

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

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

Ένας άλλος καλός λόγος για να δοκιμάσετε το WebRTC είναι ότι είναι σίγουρα μια τάση. Σήμερα κάθε Android πρόγραμμα περιήγησης Chromeυποστηρίζει αυτήν την τεχνολογία, η οποία εγγυάται εκατομμύρια συσκευές έτοιμες να παρακολουθήσουν την εκπομπή χωρίς να εγκαταστήσουν πρόσθετο λογισμικό ή διαμορφώσεις.

Για να δοκιμάσετε την τεχνολογία WebRTC σε δράση και να εκτελέσετε ένα απλό διαδικτυακή μετάδοση, χρησιμοποιήσαμε το λογισμικό διακομιστή Flashphoner WebRTC Media & Broadcasting Server. Τα χαρακτηριστικά αναφέρουν τη δυνατότητα μετάδοσης ροών WebRTC σε λειτουργία ένα προς πολλά, καθώς και υποστήριξη για κάμερες IP και συστήματα παρακολούθησης βίντεο μέσω του πρωτοκόλλου RTSP. Σε αυτήν την ανασκόπηση θα επικεντρωθούμε στις διαδικτυακές εκπομπές και τις δυνατότητές τους.

Εγκατάσταση WebRTC Media & Broadcasting Server

Επειδή για συστήματα Windowsδεν υπήρχε έκδοση διακομιστή και δεν ήθελα να εγκαταστήσω μια εικονική μηχανή όπως το VMWare+Linux, ώστε να μπορώ να δοκιμάσω διαδικτυακές εκπομπές στο σπίτι Υπολογιστής με WindowsΔεν λειτούργησε. Για να εξοικονομήσουμε χρόνο, αποφασίσαμε να πάρουμε ένα παράδειγμα φιλοξενίας cloud όπως αυτό:

Ήταν το Centos x86_64 έκδοση 6.5 χωρίς προεγκατεστημένο λογισμικό στο κέντρο δεδομένων του Άμστερνταμ. Έτσι, το μόνο που έχουμε στη διάθεσή μας είναι η πρόσβαση διακομιστή και ssh σε αυτόν. Για όσους γνωρίζουν εντολές κονσόλας Linux, η εγκατάσταση ενός διακομιστή WebRTC υπόσχεται να είναι απλή και ανώδυνη. Τι κάναμε λοιπόν:

1. Κατεβάστε το αρχείο:

$wget https://site/download-wcs5-server.tar.gz

2. Αποσυσκευάστε:

$tar -xzf λήψη-wcs5-server.tar.gz

3. Εγκαταστήστε:

$cd FlashphonerWebCallServer

Κατά την εγκατάσταση, εισαγάγετε τη διεύθυνση IP του διακομιστή: XXX.XXX.XXX.XXX

4. Ενεργοποιήστε την άδεια χρήσης:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Εκκίνηση διακομιστή WCS:

$service έναρξη διακομιστή web κλήσης

6. Ελέγξτε το αρχείο καταγραφής:

$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Ελέγξτε ότι υπάρχουν οι δύο διαδικασίες:

$ps aux | grep Flashphoner

Η διαδικασία εγκατάστασης έχει ολοκληρωθεί.

Δοκιμή διαδικτυακών εκπομπών WebRTC

Η δοκιμή των εκπομπών αποδείχθηκε απλή υπόθεση. Εκτός από τον διακομιστή, υπάρχει ένας πελάτης ιστού, ο οποίος αποτελείται από δώδεκα αρχεία Javascript, HTML και CSS και αναπτύχθηκε από εμάς στο φάκελο /var/www/html κατά το στάδιο της εγκατάστασης. Το μόνο πράγμα που έπρεπε να γίνει ήταν να εισαγάγετε τη διεύθυνση IP του διακομιστή στη διαμόρφωση του flashphoner.xml, έτσι ώστε ο πελάτης Ιστού να μπορεί να δημιουργήσει μια σύνδεση με τον διακομιστή μέσω HTML5 Websockets. Ας περιγράψουμε τη διαδικασία της δοκιμής.

1. Ανοίξτε τη δοκιμαστική σελίδα πελάτη index.html στο πρόγραμμα περιήγησης Chrome:

2. Για να ξεκινήσετε τη μετάδοση, πρέπει να κάνετε κλικ στο κουμπί «Έναρξη» στη μέση της οθόνης.
Πριν το κάνετε αυτό, πρέπει να βεβαιωθείτε ότι η κάμερα web είναι συνδεδεμένη και έτοιμη για χρήση. Δεν υπάρχουν ειδικές απαιτήσεις για την κάμερα web, για παράδειγμα, χρησιμοποιήσαμε μια τυπική κάμερα ενσωματωμένη σε φορητό υπολογιστή με ανάλυση 1280x800.

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

3. Η διεπαφή αντιπροσωπεύει μια επιτυχημένη μετάδοση της ροής βίντεο από την κάμερα στον διακομιστή WebRTC. Στην επάνω δεξιά γωνία, μια ένδειξη υποδεικνύει ότι η ροή πηγαίνει στον διακομιστή, ενώ στην κάτω γωνία υπάρχει ένα κουμπί "Διακοπή" για να σταματήσει η αποστολή του βίντεο.

Σημειώστε τον σύνδεσμο στο παρακάτω πλαίσιο. Περιέχει ένα μοναδικό αναγνωριστικό για αυτήν τη ροή, ώστε οποιοσδήποτε να μπορεί να συμμετάσχει στην προβολή. Απλώς ανοίξτε αυτόν τον σύνδεσμο στο πρόγραμμα περιήγησής σας. Για να το αντιγράψετε στο πρόχειρο, κάντε κλικ στο κουμπί «Αντιγραφή».

Σε πραγματικές εφαρμογές όπως διαδικτυακά σεμινάρια, διαλέξεις, διαδικτυακές εκπομπές βίντεο ή διαδραστική τηλεόραση, οι προγραμματιστές θα πρέπει να εφαρμόσουν τη διανομή αυτού του αναγνωριστικού σε ορισμένες ομάδες θεατών, ώστε να μπορούν να συνδεθούν στις επιθυμητές ροές, αλλά αυτή είναι ήδη η λογική της εφαρμογής . Ο διακομιστής WebRTC Media & Broadcasting δεν τον επηρεάζει, αλλά διανέμει μόνο βίντεο.

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

Αποτελέσματα δοκιμής διακομιστή διαδικτυακής μετάδοσης WebRTC

Κατά τη διάρκεια των δοκιμών, η καθυστέρηση φαινόταν τέλεια. Το ping στο κέντρο δεδομένων ήταν περίπου 100 χιλιοστά του δευτερολέπτου και η καθυστέρηση ήταν αόρατη στο μάτι. Από εδώ, μπορούμε να υποθέσουμε ότι η πραγματική καθυστέρηση είναι η ίδια 100 συν ή πλην μερικές δεκάδες χιλιοστά του δευτερολέπτου για τον χρόνο αποθήκευσης. Σε σύγκριση με το βίντεο Flash: σε τέτοιες δοκιμές, το Flash δεν συμπεριφέρεται τόσο καλά όσο το WebRTC. Έτσι, εάν μετακινήσετε το χέρι σας σε ένα παρόμοιο δίκτυο, η κίνηση στην οθόνη μπορεί να φανεί μόνο μετά από ένα ή δύο δευτερόλεπτα.

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

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

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

Βίντεο σχετικά με τη δοκιμαστική μετάδοση από κάμερα web
μέσω διακομιστή WebRTC

Οι τεχνολογίες για την πραγματοποίηση κλήσεων από το πρόγραμμα περιήγησης υπάρχουν εδώ και πολλά χρόνια: Java, ActiveX, Adobe Flash...Τα τελευταία χρόνια έχει γίνει σαφές ότι προσθήκες και έφυγε εικονικές μηχανέςΔεν λάμπουν με άνεση (γιατί να εγκαταστήσω τίποτα;) και, το πιο σημαντικό, με ασφάλεια. Τι να κάνω? Υπάρχει έξοδος!

Μέχρι πρόσφατα, τα δίκτυα IP χρησιμοποιούσαν πολλά πρωτόκολλα για τηλεφωνία IP ή βίντεο: SIP, το πιο κοινό πρωτόκολλο, H.323 και MGCP που έβγαιναν από τη σκηνή, Jabber/Jingle (χρησιμοποιείται στο Gtalk), ημι-ανοιχτό Adobe RTMP* και, φυσικά , έκλεισε το Skype. Το έργο WebRTC, που ξεκίνησε από την Google, προσπαθεί να αλλάξει την κατάσταση στον κόσμο της IP και της διαδικτυακής τηλεφωνίας, κάνοντας όλα τα softphones, συμπεριλαμβανομένου του Skype. Το WebRTC όχι μόνο υλοποιεί όλες τις δυνατότητες επικοινωνίας απευθείας μέσα στο πρόγραμμα περιήγησης, το οποίο είναι πλέον εγκατεστημένο σχεδόν σε κάθε συσκευή, αλλά προσπαθεί επίσης να λύσει ταυτόχρονα ένα γενικότερο πρόβλημα επικοινωνίας μεταξύ των χρηστών του προγράμματος περιήγησης (ανταλλαγή διαφόρων δεδομένων, μετάδοση οθόνης, συνεργασία με έγγραφα και πολύ περισσότερο).

WebRTC από την πλευρά του προγραμματιστή Ιστού

Από την άποψη ενός προγραμματιστή ιστού, το WebRTC αποτελείται από δύο κύρια μέρη:

• έλεγχος ροών πολυμέσων από τοπικούς πόρους (κάμερα, μικρόφωνο ή οθόνη τοπικός υπολογιστής) υλοποιείται από τη μέθοδο navigator.getUserMedia, η οποία επιστρέφει ένα αντικείμενο MediaStream.
• peer-to-peer επικοινωνία μεταξύ συσκευών που δημιουργούν ροές πολυμέσων, συμπεριλαμβανομένου του καθορισμού μεθόδων επικοινωνίας και της απευθείας μετάδοσής τους - Αντικείμενα RTCPeerConnection (για αποστολή και λήψη ροών ήχου και βίντεο) και RTCDataChannel (για αποστολή και λήψη δεδομένων από το πρόγραμμα περιήγησης).

Τι κάνουμε?

Θα καταλάβουμε πώς να οργανώσουμε μια απλή συνομιλία βίντεο πολλών χρηστών μεταξύ προγραμμάτων περιήγησης που βασίζονται στο WebRTC χρησιμοποιώντας υποδοχές Ιστού. Θα αρχίσουμε να πειραματιζόμαστε στο Chrome/Chromium, ως τα πιο προηγμένα προγράμματα περιήγησης όσον αφορά το WebRTC, αν και το Firefox 22, που κυκλοφόρησε στις 24 Ιουνίου, έχει σχεδόν προλάβει. Πρέπει να πούμε ότι το πρότυπο δεν έχει ακόμη υιοθετηθεί και το API μπορεί να αλλάξει από έκδοση σε έκδοση. Όλα τα παραδείγματα δοκιμάστηκαν στο Chromium 28. Για λόγους απλότητας, δεν θα παρακολουθούμε την καθαρότητα του κώδικα και τη συμβατότητα μεταξύ προγραμμάτων περιήγησης.

MediaStream

Το πρώτο και απλούστερο στοιχείο WebRTC είναι το MediaStream. Παρέχει στο πρόγραμμα περιήγησης πρόσβαση σε ροές πολυμέσων από την κάμερα και το μικρόφωνο του τοπικού υπολογιστή. Στο Chrome, για αυτό πρέπει να καλέσετε τη συνάρτηση navigator.webkitGetUserMedia() (καθώς το πρότυπο δεν έχει ακόμη οριστικοποιηθεί, όλες οι συναρτήσεις συνοδεύονται από ένα πρόθεμα και στον Firefox η ίδια συνάρτηση ονομάζεται navigator.mozGetUserMedia()). Όταν το καλέσετε, θα ζητηθεί από τον χρήστη να επιτρέψει την πρόσβαση στην κάμερα και το μικρόφωνο. Θα είναι δυνατή η συνέχιση της κλήσης μόνο αφού ο χρήστης δώσει τη συγκατάθεσή του. Οι παράμετροι της απαιτούμενης ροής πολυμέσων και δύο λειτουργίες επανάκλησης μεταβιβάζονται ως παράμετροι σε αυτήν τη λειτουργία: η πρώτη θα κληθεί εάν επιτευχθεί επιτυχώς η πρόσβαση στην κάμερα/μικρόφωνο, η δεύτερη - σε περίπτωση σφάλματος. Αρχικά, ας δημιουργήσουμε ένα αρχείο HTML rtctest1.html με ένα κουμπί και ένα στοιχείο:

WebRTC - πρώτο βίντεο εισαγωγής ( ύψος: 240 εικονοστοιχεία, πλάτος: 320 εικονοστοιχεία, περίγραμμα: 1 εικονοστοιχείο σταθερό γκρι; ) getUserMedia

Microsoft CU-RTC-Web

Η Microsoft δεν θα ήταν η Microsoft εάν δεν ανταποκρινόταν αμέσως στην πρωτοβουλία της Google κυκλοφορώντας τη δική της ασύμβατη μη τυπική επιλογή που ονομάζεται CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Αν και το μερίδιο του IE, ήδη μικρό, συνεχίζει να μειώνεται, ο αριθμός των χρηστών Skype δίνει στη Microsoft ελπίδα να εκτοπίσει την Google και μπορεί να υποτεθεί ότι αυτό το συγκεκριμένο πρότυπο θα χρησιμοποιηθεί στο πρόγραμμα περιήγησης Εκδόσεις Skype. Το πρότυπο της Google επικεντρώνεται κυρίως στην επικοινωνία μεταξύ των προγραμμάτων περιήγησης. Ταυτόχρονα, το μεγαλύτερο μέρος της φωνητικής κίνησης εξακολουθεί να παραμένει στο κανονικό τηλεφωνικό δίκτυο και χρειάζονται πύλες μεταξύ αυτού και των δικτύων IP όχι μόνο για ευκολία στη χρήση ή ταχύτερη διανομή, αλλά και ως μέσο δημιουργίας εσόδων που θα επιτρέψει σε περισσότερους παίκτες να αναπτύξτε τα. Η εμφάνιση ενός άλλου προτύπου μπορεί όχι μόνο να οδηγήσει στη δυσάρεστη ανάγκη των προγραμματιστών να υποστηρίξουν ταυτόχρονα δύο ασύμβατες τεχνολογίες, αλλά και στο μέλλον να δώσει στον χρήστη μια ευρύτερη επιλογή πιθανών λειτουργιών και διαθέσιμων τεχνικών λύσεων. Περίμενε και θα δεις.

Ενεργοποίηση τοπικής ροής

Μέσα στις ετικέτες του αρχείου HTML μας, ας δηλώσουμε μια καθολική μεταβλητή για τη ροή πολυμέσων:

Var localStream = null;

Η πρώτη παράμετρος στη μέθοδο getUserMedia πρέπει να καθορίζει τις παραμέτρους της ροής πολυμέσων που ζητήθηκε - για παράδειγμα, απλώς ενεργοποιήστε τον ήχο ή το βίντεο:

Var streamConstraints = ("audio": true, "video": true); // Ζητήστε πρόσβαση τόσο σε ήχο όσο και σε βίντεο

Ή καθορίστε πρόσθετες παραμέτρους:

Var streamConstraints = ( "audio": true, "video": ( "υποχρεωτικό": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "προαιρετικό": ) )

Η δεύτερη παράμετρος στη μέθοδο getUserMedia πρέπει να μεταβιβαστεί στη συνάρτηση επανάκλησης, η οποία θα κληθεί εάν είναι επιτυχής:

Λειτουργία getUserMedia_success(stream) ( console.log("getUserMedia_success():", ροή); localVideo1.src = URL.createObjectURL(ροή); // Συνδέστε τη ροή πολυμέσων στο στοιχείο HTML localStream = ροή; // και αποθηκεύστε την σε μια καθολική μεταβλητή για περαιτέρω χρήση )

Η τρίτη παράμετρος είναι μια συνάρτηση επανάκλησης, ένας χειριστής σφαλμάτων που θα καλείται σε περίπτωση σφάλματος

Λειτουργία getUserMedia_error(error) ( console.log("getUserMedia_error():", σφάλμα); )

Η πραγματική κλήση στη μέθοδο getUserMedia είναι ένα αίτημα για πρόσβαση στο μικρόφωνο και την κάμερα όταν πατηθεί το πρώτο κουμπί

Λειτουργία getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

Δεν είναι δυνατή η πρόσβαση σε ροή πολυμέσων από αρχείο που έχει ανοίξει τοπικά. Αν προσπαθήσουμε να το κάνουμε αυτό, θα λάβουμε το σφάλμα:

NavigatorUserMediaError (κωδικός: 1, PERMISSION_DENIED: 1)"

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

Μπορείτε να επιλέξετε τις συσκευές στις οποίες θα έχει πρόσβαση το Chrome στις Ρυθμίσεις, Εμφάνιση συνδέσμου σύνθετων ρυθμίσεων, ενότητα Απόρρητο, Κουμπί περιεχομένου. Στα προγράμματα περιήγησης Firefox και Opera, οι συσκευές επιλέγονται από μια αναπτυσσόμενη λίστα απευθείας όταν επιτρέπεται η πρόσβαση.

Όταν χρησιμοποιείτε το πρωτόκολλο HTTP, θα ζητείται άδεια κάθε φορά που γίνεται πρόσβαση στη ροή πολυμέσων μετά τη φόρτωση της σελίδας. Η μετάβαση σε HTTPS θα σας επιτρέψει να εμφανίσετε το αίτημα μία φορά, μόνο την πρώτη φορά που θα αποκτήσετε πρόσβαση στη ροή πολυμέσων.

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

RTCMediaConnection

Το RTCMediaConnection είναι ένα αντικείμενο που έχει σχεδιαστεί για τη δημιουργία και τη μετάδοση ροών πολυμέσων μέσω του δικτύου μεταξύ των συμμετεχόντων. Επιπλέον, αυτό το αντικείμενο είναι υπεύθυνο για τη δημιουργία μιας περιγραφής συνεδρίας πολυμέσων (SDP), τη λήψη πληροφοριών σχετικά με υποψηφίους ICE για διέλευση NAT ή τείχη προστασίας(τοπικό και με χρήση STUN) και αλληλεπίδραση με τον διακομιστή TURN. Κάθε συμμετέχων πρέπει να έχει ένα RTCMediaConnection ανά σύνδεση. Οι ροές πολυμέσων μεταδίδονται χρησιμοποιώντας το κρυπτογραφημένο πρωτόκολλο SRTP.

TURN διακομιστές

Υπάρχουν τρεις τύποι υποψηφίων ICE: host, srflx και relay. Ο κεντρικός υπολογιστής περιέχει πληροφορίες που λαμβάνονται τοπικά, srflx - πώς φαίνεται ο κόμβος σε έναν εξωτερικό διακομιστή (STUN) και αναμετάδοση - πληροφορίες για την κίνηση μεσολάβησης μέσω του διακομιστή TURN. Εάν ο κόμβος μας βρίσκεται πίσω από το NAT, τότε οι υποψήφιοι κεντρικοί υπολογιστές θα περιέχουν τοπικές διευθύνσειςκαι θα είναι άχρηστο, οι υποψήφιοι srflx θα βοηθήσουν μόνο με ορισμένους τύπους NAT και το ρελέ θα είναι η τελευταία ελπίδα για να περάσει η κυκλοφορία μέσω ενός ενδιάμεσου διακομιστή.

Παράδειγμα υποψηφίου ICE τύπου κεντρικού υπολογιστή, με διεύθυνση 192.168.1.37 και θύρα udp/34022:

A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 τύπος γενιάς κεντρικού υπολογιστή 0

Γενική μορφή για τον καθορισμό διακομιστών STUN/TURN:

Var servers = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn:user@host:port", "credential": "password" ) ]);

Υπάρχουν πολλοί δημόσιοι διακομιστές STUN στο Διαδίκτυο. Υπάρχει μια μεγάλη λίστα, για παράδειγμα. Δυστυχώς, λύνουν ελάχιστα προβλήματα. Δεν υπάρχουν πρακτικά δημόσιοι διακομιστές TURN, σε αντίθεση με το STUN. Αυτό οφείλεται στο γεγονός ότι ο διακομιστής TURN διέρχεται από ροές πολυμέσων, οι οποίες μπορούν να φορτώσουν σημαντικά τόσο το κανάλι δικτύου όσο και τον ίδιο τον διακομιστή. Επομένως, ο ευκολότερος τρόπος σύνδεσης με διακομιστές TURN είναι να το εγκαταστήσετε μόνοι σας (προφανώς, θα χρειαστείτε μια δημόσια IP). Από όλους τους διακομιστές, κατά τη γνώμη μου, ο καλύτερος είναι ο rfc5766-turn-server. Υπάρχει ακόμη και μια έτοιμη εικόνα για το Amazon EC2.

Με το TURN, δεν είναι όλα τόσο καλά όσο θα θέλαμε, αλλά η ενεργή ανάπτυξη βρίσκεται σε εξέλιξη και θα ήθελα να ελπίζω ότι μετά από κάποιο χρονικό διάστημα το WebRTC, αν όχι ίσο με το Skype όσον αφορά την ποιότητα της μετάβασης μέσω μετάφρασης διευθύνσεων (NAT) και τείχη προστασίας , είναι τουλάχιστον αισθητό θα έρθει πιο κοντά.

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

Η επιλογή της μεθόδου μεταφοράς ανήκει στον προγραμματιστή - τουλάχιστον χειροκίνητα. Μόλις πραγματοποιηθεί η ανταλλαγή των απαραίτητων δεδομένων, το RTCMediaConnection θα εγκαταστήσει αυτόματα ροές πολυμέσων (αν είναι δυνατόν, φυσικά).

μοντέλο προσφοράς-απάντησης

Για τη δημιουργία και την αλλαγή των ροών πολυμέσων, χρησιμοποιείται το μοντέλο προσφοράς/απάντησης (που περιγράφεται στο RFC3264) και το SDP (Πρωτόκολλο Περιγραφής Συνεδρίας). Χρησιμοποιούνται επίσης από το πρωτόκολλο SIP. Σε αυτό το μοντέλο, υπάρχουν δύο πράκτορες: Offerer - αυτός που δημιουργεί την περιγραφή SDP της περιόδου σύνδεσης για να δημιουργήσει μια νέα ή τροποποιεί μια υπάρχουσα (Offer SDP) και Answerer - αυτός που λαμβάνει την περιγραφή SDP της περιόδου σύνδεσης από άλλος πράκτορας και απαντά με τη δική του περιγραφή περιόδου σύνδεσης (Απάντηση SDP). Ταυτόχρονα, η προδιαγραφή απαιτεί ένα πρωτόκολλο υψηλότερου επιπέδου (για παράδειγμα, SIP ή το δικό του μέσω web sockets, όπως στην περίπτωσή μας), το οποίο είναι υπεύθυνο για τη μετάδοση SDP μεταξύ των πρακτόρων.

Ποια δεδομένα πρέπει να περάσουν μεταξύ δύο RTCMediaConnections, ώστε να μπορούν να δημιουργήσουν με επιτυχία ροές πολυμέσων:

• Ο πρώτος συμμετέχων που ξεκινά τη σύνδεση σχηματίζει μια Προσφορά στην οποία μεταδίδει μια δομή δεδομένων SDP (το ίδιο πρωτόκολλο χρησιμοποιείται για τον ίδιο σκοπό στο SIP) που περιγράφει τα πιθανά χαρακτηριστικά της ροής πολυμέσων που πρόκειται να αρχίσει να μεταδίδει. Αυτό το μπλοκ δεδομένων πρέπει να μεταφερθεί στον δεύτερο συμμετέχοντα. Ο δεύτερος συμμετέχων σχηματίζει μια Απάντηση, με το SDP του, και τη στέλνει στον πρώτο.
• Τόσο ο πρώτος όσο και ο δεύτερος συμμετέχων εκτελούν τη διαδικασία προσδιορισμού πιθανών υποψηφίων ICE με τη βοήθεια των οποίων ο δεύτερος συμμετέχων μπορεί να μεταδώσει μια ροή πολυμέσων σε αυτούς. Καθώς οι υποψήφιοι ταυτοποιούνται, οι πληροφορίες σχετικά με αυτούς θα πρέπει να διαβιβάζονται σε άλλον συμμετέχοντα.

Προσφορά Σχηματισμού

Για να δημιουργήσουμε μια Προσφορά, χρειαζόμαστε δύο λειτουργίες. Το πρώτο θα κληθεί εάν διαμορφωθεί με επιτυχία. Η δεύτερη παράμετρος της μεθόδου createOffer() είναι μια συνάρτηση επανάκλησης που καλείται σε περίπτωση σφάλματος κατά την εκτέλεσή της (με την προϋπόθεση ότι το τοπικό νήμα είναι ήδη διαθέσιμο).

Επιπλέον, χρειάζονται δύο χειριστές συμβάντων: onicecandidate κατά τον ορισμό ενός νέου υποψηφίου ICE και onaddstream όταν συνδέετε μια ροή πολυμέσων από την μακρινή πλευρά. Ας επιστρέψουμε στο αρχείο μας. Ας προσθέσουμε ένα άλλο στο HTML μετά τις γραμμές με στοιχεία:

Δημιουργία Προσφοράς

Και μετά τη γραμμή με το στοιχείο (για το μέλλον):

Επίσης, στην αρχή του κώδικα JavaScript θα δηλώσουμε μια καθολική μεταβλητή για το RTCPeerConnection:

Var pc1;

Όταν καλείτε τον κατασκευαστή RTCPeerConnection, πρέπει να καθορίσετε διακομιστές STUN/TURN. Για περισσότερες πληροφορίες σχετικά με αυτά, ανατρέξτε στην πλαϊνή γραμμή. Εφόσον όλοι οι συμμετέχοντες βρίσκονται στο ίδιο δίκτυο, δεν απαιτείται.

Var servers = null;

Παράμετροι για την προετοιμασία Προσφοράς SDP

Var offerConstraints = ();

Η πρώτη παράμετρος της μεθόδου createOffer() είναι μια συνάρτηση επανάκλησης που καλείται μετά τον επιτυχή σχηματισμό μιας Προσφοράς

Συνάρτηση pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Ορισμός RTCPeerConnection χρησιμοποιώντας τη μέθοδο setLocalDescription. // Όταν η μακρινή πλευρά στέλνει το SDP της Απάντησής της, θα πρέπει να οριστεί χρησιμοποιώντας τη μέθοδο setRemoteDescription // Μέχρι να εφαρμοστεί η δεύτερη πλευρά, δεν κάνουμε τίποτα // pc2_receivedOffer(desc); )

Η δεύτερη παράμετρος είναι μια συνάρτηση επανάκλησης που θα καλείται σε περίπτωση σφάλματος

Συνάρτηση pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )

Και ας δηλώσουμε μια συνάρτηση επανάκλησης στην οποία θα περάσουν οι υποψήφιοι ICE όπως έχουν καθοριστεί:

Συνάρτηση pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Μέχρι να εφαρμοστεί η δεύτερη πλευρά, δεν κάνουμε τίποτα // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Και επίσης μια λειτουργία επανάκλησης για την προσθήκη ροής πολυμέσων από την μακρινή πλευρά (για το μέλλον, αφού προς το παρόν έχουμε μόνο μία RTCPeerConnection):

Λειτουργία pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

Όταν κάνετε κλικ στο κουμπί "createOffer", θα δημιουργήσουμε μια RTCPeerConnection, θα ορίσουμε τις μεθόδους onicecandidate και onaddstream και θα ζητήσουμε το σχηματισμό ενός Offer SDP καλώντας τη μέθοδο createOffer():

Συνάρτηση createOffer_click() ( console.log("createOffer_click()"); pc1 = νέο webkitRTCPeerConnection(διακομιστές); // Δημιουργία RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Συνάρτηση επιστροφής κλήσης για επεξεργασία pc1.c1. Η λειτουργία επανάκλησης καλείται όταν μια ροή πολυμέσων εμφανίζεται από την μακρινή πλευρά. Δεν υπάρχει ακόμα pc1.addStream(localStream); // Ας μεταδώσουμε τη ροή τοπικών μέσων (υποθέτοντας ότι έχει ήδη ληφθεί) pc1.createOffer(// Και πραγματικά ζητάμε ο σχηματισμός των Προσφορών pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Ας αποθηκεύσουμε το αρχείο ως rtctest2.html, το ανεβάσουμε στον διακομιστή, το ανοίξουμε σε πρόγραμμα περιήγησης και ας δούμε στην κονσόλα τι δεδομένα δημιουργούνται κατά τη λειτουργία του. Το δεύτερο βίντεο δεν θα εμφανιστεί ακόμα, αφού υπάρχει μόνο ένας συμμετέχων. Ας υπενθυμίσουμε ότι το SDP είναι μια περιγραφή των παραμέτρων μιας περιόδου σύνδεσης πολυμέσων, οι διαθέσιμοι κωδικοποιητές, οι ροές πολυμέσων και οι υποψήφιοι ICE είναι πιθανές επιλογές για σύνδεση με έναν δεδομένο συμμετέχοντα.

Σχηματισμός Απάντησης SDP και ανταλλαγή υποψηφίων ICE

Τόσο το Offer SDP όσο και καθένας από τους υποψηφίους ICE πρέπει να μεταφερθούν στην άλλη πλευρά και εκεί, μετά τη λήψη τους, το RTCPeerConnection καλεί τις μεθόδους setRemoteDescription για το Offer SDP και addIceCandidate για κάθε υποψήφιο ICE που λαμβάνεται από την μακρινή πλευρά. ομοίως σε αντιθετη πλευραγια Απάντηση υποψηφίων SDP και απομακρυσμένου ICE. Το ίδιο το Answer SDP σχηματίζεται παρόμοια με την Προσφορά. Η διαφορά είναι ότι δεν καλείται η μέθοδος createOffer, αλλά η μέθοδος createAnswer και πριν από αυτήν η μέθοδος RTCPeerConnection setRemoteDescription μεταβιβάζεται στο SDP προσφοράς που λαμβάνεται από τον καλούντα.

Ας προσθέσουμε ένα άλλο στοιχείο βίντεο στο HTML:

Και μια καθολική μεταβλητή για τη δεύτερη RTCPeerConnection κάτω από τη δήλωση της πρώτης:

Var pc2;

Επεξεργασία Προσφοράς και Απάντηση SDP

Ο σχηματισμός του Answer SDP μοιάζει πολύ με το Offer. Στη συνάρτηση επανάκλησης που καλείται μετά τον επιτυχή σχηματισμό μιας απάντησης, παρόμοια με την Προσφορά, θα δώσουμε μια τοπική περιγραφή και θα διαβιβάσουμε το SDP της απάντησης που λάβαμε στον πρώτο συμμετέχοντα:

Συνάρτηση pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

Η συνάρτηση επανάκλησης, που καλείται σε περίπτωση σφάλματος κατά τη δημιουργία της απάντησης, είναι εντελώς παρόμοια με την Προσφορά:

Συνάρτηση pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", σφάλμα); )

Παράμετροι για το σχηματισμό Απάντησης SDP:

Var answerConstraints = ( "υποχρεωτικό": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

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

Συνάρτηση pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Δημιουργία αντικειμένου RTCPeerConnection για τον δεύτερο συμμετέχοντα με τον ίδιο τρόπο όπως ο πρώτος pc2 = νέο webkitRTCPeerConnection(διακομιστές); pc2.ondidace2onice_onite ; // Ρυθμίστε το πρόγραμμα χειρισμού συμβάντων όταν εμφανίζεται ICE υποψήφιος pc2.onaddstream = pc_onaddstream; // Όταν εμφανιστεί μια ροή, συνδέστε το σε HTML pc2.addStream(localStream); // Μεταφέρετε τη ροή τοπικών μέσων (στο παράδειγμά μας, το δεύτερο ο συμμετέχων έχει το ίδιο με τον πρώτο) // Τώρα, όταν το δεύτερο RTCPeerConnection είναι έτοιμο, θα του περάσουμε το SDP της Προσφοράς που λάβαμε (περάσαμε την τοπική ροή στην πρώτη) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Ζητήστε τη δεύτερη σύνδεση για τη δημιουργία δεδομένων για το μήνυμα απάντησης pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Για να μεταφέρουμε το SDP Προσφοράς από τον πρώτο συμμετέχοντα στον δεύτερο στο παράδειγμά μας, ας το αφαιρέσουμε από το σχόλιο στη συνάρτηση pc1 Δημιουργία Προσφοράςγραμμή κλήσης success():

Pc2_receivedOffer(desc);

Για να εφαρμόσουμε την επεξεργασία των υποψηφίων ICE, ας αφαιρέσουμε το σχολιασμό στον χειριστή εκδηλώσεων ετοιμότητας υποψηφίου ICE του πρώτου συμμετέχοντα pc1_onicecandidate() τη μεταφορά του στον δεύτερο:

Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));

Ο χειριστής εκδηλώσεων ετοιμότητας υποψηφίου ICE του δεύτερου συμμετέχοντα μοιάζει με τον πρώτο:

Συνάρτηση pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Λειτουργία επανάκλησης για την προσθήκη ροής πολυμέσων από τον πρώτο συμμετέχοντα:

Λειτουργία pc2_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

Τερματισμός της σύνδεσης

Ας προσθέσουμε ένα άλλο κουμπί στο HTML

Κλείνω το τηλέφωνο

Και μια λειτουργία για τον τερματισμό της σύνδεσης

Λειτουργία btnHangupClick() ( // Αποσύνδεση τοπικού βίντεο από στοιχεία HTML, διακοπή της ροής τοπικών μέσων, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Για κάθε συμμετέχοντα, απενεργοποιήστε το βίντεο από HTML στοιχεία, κλείστε τη σύνδεση, ορίστε τον δείκτη = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Ας το αποθηκεύσουμε ως rtctest3.html, ας το ανεβάσουμε στον διακομιστή και ας το ανοίξουμε στο πρόγραμμα περιήγησης. Αυτό το παράδειγμα υλοποιεί αμφίδρομη μετάδοση ροών πολυμέσων μεταξύ δύο RTCPeerConnections στην ίδια καρτέλα του προγράμματος περιήγησης. Για να οργανωθεί η ανταλλαγή Προσφοράς και Απάντησης SDP, υποψηφίων ICE μεταξύ συμμετεχόντων και άλλων πληροφοριών μέσω του δικτύου, αντί για απευθείας κλήση διαδικασιών, θα χρειαστεί να υλοποιηθεί η ανταλλαγή μεταξύ των συμμετεχόντων χρησιμοποιώντας κάποιο είδος μεταφοράς, στην περίπτωσή μας - υποδοχές ιστού.

Μετάδοση οθόνης

Η συνάρτηση getUserMedia μπορεί επίσης να καταγράψει την οθόνη και να μεταδώσει ροή ως MediaStream, καθορίζοντας τις ακόλουθες παραμέτρους:

Var mediaStreamConstraints = ( ήχος: ψευδής, βίντεο: ( υποχρεωτικό: ( chromeMediaSource: "οθόνη"), προαιρετικό: ) );

Για την επιτυχή πρόσβαση στην οθόνη, πρέπει να πληρούνται διάφορες προϋποθέσεις:

• ενεργοποιήστε τη σημαία στιγμιότυπου οθόνης στο getUserMedia() στο chrome://flags/,chrome://flags/;
• το αρχείο προέλευσης πρέπει να ληφθεί μέσω HTTPS (προέλευση SSL).
• η ροή ήχου δεν θα πρέπει να ζητηθεί.
• Πολλαπλές αιτήσεις δεν πρέπει να εκτελούνται σε μία καρτέλα του προγράμματος περιήγησης.

Βιβλιοθήκες για WebRTC

Αν και το WebRTC δεν έχει ακόμη ολοκληρωθεί, έχουν ήδη εμφανιστεί αρκετές βιβλιοθήκες που βασίζονται σε αυτό. Το JsSIP έχει σχεδιαστεί για να δημιουργεί λογισμικά τηλέφωνα που βασίζονται σε πρόγραμμα περιήγησης που λειτουργούν με διακόπτες SIP όπως το Asterisk και το Camalio. Το PeerJS θα διευκολύνει τη δημιουργία δικτύων P2P για ανταλλαγή δεδομένων και το Holla θα μειώσει το μέγεθος της ανάπτυξης που απαιτείται για τις επικοινωνίες P2P από προγράμματα περιήγησης.

Node.js και socket.io

Για να οργανώσουμε την ανταλλαγή υποψηφίων SDP και ICE μεταξύ δύο RTCPeerConnections μέσω του δικτύου, χρησιμοποιούμε το Node.js με τη μονάδα socket.io.

Περιγράφεται η εγκατάσταση της πιο πρόσφατης σταθερής έκδοσης του Node.js (για Debian/Ubuntu).

$ sudo apt-get εγκατάσταση python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get ενημέρωση $ sudo apt-get εγκατάσταση nodejs

Εγκατάσταση για άλλους OSπεριγράφεται

Ας ελέγξουμε:

$ echo "sys=require("util"); sys.puts("Μήνυμα δοκιμής");" > nodetest1.js $ nodejs nodetest1.js

Χρησιμοποιώντας το npm (Node Package Manager) θα εγκαταστήσουμε το socket.io και την πρόσθετη μονάδα express:

$ npm εγκατάσταση socket.io express

Ας το δοκιμάσουμε δημιουργώντας ένα αρχείο nodetest2.js για την πλευρά του διακομιστή:

$ nano nodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // Εάν η θύρα 80 είναι δωρεάν app.get("/", λειτουργία (req, res) ( // Κατά την πρόσβαση στη ριζική σελίδα res.sendfile(__dirname + "/nodetest2.html"); // αποστολή του αρχείου HTML ) ) ; io.sockets.on("connection", function (socket) ( // Κατά τη σύνδεση του socket.emit("server event", ( hello: "world" )); // αποστολή μηνύματος socket.on("συμβάν πελάτη" , συνάρτηση (δεδομένα) ( // και δηλώνει ένα πρόγραμμα χειρισμού συμβάντων όταν φθάνει ένα μήνυμα από το client console.log(data); )); ));

Και το nodetest2.html για την πλευρά του πελάτη:

$ nano nodetest2.html var socket = io.connect("/"); // URL διακομιστή Websocket (η ριζική σελίδα του διακομιστή από τον οποίο φορτώθηκε η σελίδα) socket.on("συμβάν διακομιστή", συνάρτηση (δεδομένα) ( console.log(data); socket.emit("συμβάν πελάτη", ( "όνομα": "τιμή" )); ));

Ας ξεκινήσουμε τον διακομιστή:

$ sudo nodejs nodetest2.js

και ανοίξτε τη σελίδα http://localhost:80 (αν εκτελείται τοπικά στη θύρα 80) στο πρόγραμμα περιήγησης. Εάν όλα είναι επιτυχή, στην κονσόλα JavaScript του προγράμματος περιήγησης θα δούμε την ανταλλαγή συμβάντων μεταξύ του προγράμματος περιήγησης και του διακομιστή κατά τη σύνδεση.

Ανταλλαγή πληροφοριών μεταξύ RTCPeerConnection μέσω web sockets Τμήμα πελάτη

Ας αποθηκεύσουμε το κύριο παράδειγμα μας (rtcdemo3.html) με το νέο όνομα rtcdemo4.html. Ας συμπεριλάβουμε τη βιβλιοθήκη socket.io στο στοιχείο:

Και στην αρχή του σεναρίου JavaScript - σύνδεση σε υποδοχές ιστού:

Var socket = io.connect("http://localhost");

Ας αντικαταστήσουμε την άμεση κλήση στις λειτουργίες ενός άλλου συμμετέχοντα στέλνοντάς του ένα μήνυμα μέσω υποδοχών web:

Συνάρτηση createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("προσφορά", desc); ... ) συνάρτηση pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); υποδοχή .emit("απάντηση", desc); ) συνάρτηση pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) συνάρτηση pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ...)

Στη συνάρτηση hangup(), αντί να καλέσουμε απευθείας τις συναρτήσεις του δεύτερου συμμετέχοντα, θα μεταδώσουμε ένα μήνυμα μέσω υποδοχών web:

Συνάρτηση btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

Και προσθέστε χειριστές λήψης μηνυμάτων:

Socket.on("προσφορά", συνάρτηση (δεδομένα) ( console.log("socket.on("προσφορά"):", δεδομένα); pc2_receivedOffer(data); )); socket.on("απάντηση", συνάρτηση (δεδομένα) (е console.log("socket.on("απάντηση"):", δεδομένα); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", συνάρτηση (δεδομένα) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", συνάρτηση (δεδομένα) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("hangup", συνάρτηση (δεδομένα) ( console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) )

Μέρος διακομιστή

Από την πλευρά του διακομιστή, αποθηκεύστε το αρχείο nodetest2 με το νέο όνομα rtctest4.js και μέσα στη συνάρτηση io.sockets.on("connection", function (socket) ( ... ) θα προσθέσουμε τη λήψη και την αποστολή μηνυμάτων πελάτη:

Socket.on("προσφορά", συνάρτηση (δεδομένα) ( // Όταν λάβουμε το μήνυμα "προσφορά", // καθώς υπάρχει μόνο μία σύνδεση πελάτη σε αυτό το παράδειγμα, // θα στείλουμε το μήνυμα πίσω μέσω της ίδιας υποδοχής .emit("προσφορά" , δεδομένα); // Εάν ήταν απαραίτητο να προωθηθεί το μήνυμα σε όλες τις συνδέσεις, // εκτός από τον αποστολέα: // soket.broadcast.emit("προσφορά", δεδομένα); )); socket.on("απάντηση", συνάρτηση (δεδομένα) ( socket.emit("απάντηση", δεδομένα); )); socket.on("ice1", συνάρτηση (δεδομένα) ( socket.emit("ice1", δεδομένα); )); socket.on("ice2", συνάρτηση (δεδομένα) ( socket.emit("ice2", data); )); socket.on("hangup", function (data) ( socket.emit("hangup", data); ));

Επιπλέον, ας αλλάξουμε το όνομα του αρχείου HTML:

// res.sendfile(__dirname + "/nodetest2.html"); // Αποστολή του αρχείου HTML res.sendfile(__dirname + "/rtctest4.html");

Εκκίνηση του διακομιστή:

$ sudo nodejs nodetest2.js

Παρά το γεγονός ότι ο κώδικας και των δύο πελατών εκτελείται μέσα στην ίδια καρτέλα του προγράμματος περιήγησης, όλη η αλληλεπίδραση μεταξύ των συμμετεχόντων στο παράδειγμά μας πραγματοποιείται πλήρως μέσω του δικτύου και ο «διαχωρισμός» των συμμετεχόντων δεν απαιτεί ιδιαίτερες δυσκολίες. Ωστόσο, αυτό που κάναμε ήταν επίσης πολύ απλό - αυτές οι τεχνολογίες είναι καλές επειδή είναι εύχρηστες. Ακόμα κι αν μερικές φορές παραπλανητικό. Συγκεκριμένα, ας μην ξεχνάμε ότι χωρίς διακομιστές STUN/TURN το παράδειγμά μας δεν θα μπορεί να λειτουργήσει παρουσία μετάφρασης διευθύνσεων και τείχη προστασίας.

συμπέρασμα

Το παράδειγμα που προκύπτει είναι πολύ συμβατικό, αλλά αν καθολικοποιήσουμε ελαφρώς τους χειριστές συμβάντων έτσι ώστε να μην διαφέρουν μεταξύ του καλούντος και του καλούντος, αντί για δύο αντικείμενα pc1 και pc2, δημιουργήστε έναν πίνακα RTCPeerConnection και εφαρμόστε δυναμική δημιουργίακαι αφαιρώντας στοιχεία, θα έχετε μια πλήρως χρησιμοποιήσιμη συνομιλία μέσω βίντεο. Δεν υπάρχουν ειδικές λεπτομέρειες που σχετίζονται με το WebRTC και ένα παράδειγμα απλής συνομιλίας μέσω βίντεο για πολλούς συμμετέχοντες (καθώς και τα κείμενα όλων των παραδειγμάτων του άρθρου) βρίσκεται στο δίσκο που συνοδεύει το περιοδικό. Ωστόσο, μπορείτε ήδη να βρείτε αρκετά στο Διαδίκτυο. καλά παραδείγματα. Συγκεκριμένα, χρησιμοποιήθηκαν τα ακόλουθα για την προετοιμασία του άρθρου: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App.

Μπορούμε να υποθέσουμε ότι πολύ σύντομα, χάρη στο WebRTC, θα υπάρξει μια επανάσταση όχι μόνο στην κατανόηση των επικοινωνιών φωνής και βίντεο, αλλά και στον τρόπο με τον οποίο αντιλαμβανόμαστε το Διαδίκτυο στο σύνολό του. Το WebRTC τοποθετείται όχι μόνο ως τεχνολογία για κλήσεις από πρόγραμμα περιήγησης σε πρόγραμμα περιήγησης, αλλά και ως τεχνολογία επικοινωνίας σε πραγματικό χρόνο. Η βιντεοεπικοινωνία που συζητήσαμε είναι μόνο ένα μικρό μέρος πιθανές επιλογέςχρήση του. Υπάρχουν ήδη παραδείγματα προβολής οθόνης και συνεργασίας, ακόμη και ένα δίκτυο παράδοσης περιεχομένου P2P που βασίζεται σε πρόγραμμα περιήγησης που χρησιμοποιεί το RTCDataChannel.