Σε αυτό το τεύχος θα δείξω και θα εξηγήσω μερικές από τις περιπλοκές της ρύθμισης ενός διακομιστή CMS σε λειτουργία συμπλέγματος ανακατεύθυνσης.
ΘεωρίαΓενικά, υπάρχουν τρεις τύποι ανάπτυξης διακομιστή CMS:
- Μονό Συνδυασμένο(Μονό συνδυασμένο), δηλ. αυτός είναι ένας διακομιστής στον οποίο εκτελούνται όλες οι απαραίτητες υπηρεσίες. Στις περισσότερες περιπτώσεις, αυτός ο τύπος ανάπτυξης είναι κατάλληλος μόνο για εσωτερική πρόσβαση πελάτη και σε μικρότερα περιβάλλοντα όπου οι περιορισμοί επεκτασιμότητας και πλεονασμού ενός μεμονωμένου διακομιστή δεν αποτελούν κρίσιμο ζήτημα ή σε περιπτώσεις όπου το CMS εκτελεί μόνο ορισμένες λειτουργίες, όπως ad hoc συνέδρια για το Cisco UCM.
Κατά προσέγγιση σχέδιο εργασίας:
- Single Split(Single Split) επεκτείνει τον προηγούμενο τύπο ανάπτυξης προσθέτοντας έναν ξεχωριστό διακομιστή για εξωτερική πρόσβαση. Στις κληρονομικές αναπτύξεις, αυτό σήμαινε την ανάπτυξη ενός διακομιστή CMS σε ένα αποστρατιωτικοποιημένο τμήμα δικτύου (DMZ) όπου θα μπορούσαν να έχουν πρόσβαση εξωτερικοί πελάτες και ενός διακομιστή CMS στον πυρήνα του δικτύου όπου οι εσωτερικοί πελάτες θα μπορούσαν να έχουν πρόσβαση στο CMS. Το συγκεκριμένο μοντέλο ανάπτυξης αντικαθίσταται πλέον από τον λεγόμενο τύπο Μονή άκρη, που αποτελείται από διακομιστές Cisco Expressway, που είτε έχουν είτε θα έχουν πολλές από τις ίδιες δυνατότητες παράκαμψης τείχους προστασίας, ώστε οι πελάτες να μην χρειάζεται να προσθέσουν έναν αποκλειστικό διακομιστή CMS αιχμής.
Κατά προσέγγιση σχέδιο εργασίας:
- Κλιμακόμενο και ανθεκτικό(Κλιμακόμενο και ανεκτικό σε σφάλματα) Αυτός ο τύπος περιλαμβάνει πλεονασμό για κάθε στοιχείο, επιτρέποντας στο σύστημα να αναπτυχθεί με τις ανάγκες σας στη μέγιστη χωρητικότητά του, ενώ παρέχει πλεονασμό σε περίπτωση αποτυχίας. Χρησιμοποιεί επίσης την έννοια Single Edge για να παρέχει ασφαλή εξωτερική πρόσβαση. Αυτός είναι ο τύπος που θα δούμε σε αυτό το επεισόδιο. Εάν κατανοήσουμε πώς να αναπτύξουμε αυτόν τον τύπο συμπλέγματος, δεν θα κατανοήσουμε μόνο άλλους τύπους αναπτύξεων, αλλά θα μπορέσουμε επίσης να κατανοήσουμε πώς να δημιουργήσουμε συμπλέγματα διακομιστών CMS για να εξυπηρετήσουμε την πιθανή αύξηση της ζήτησης.
Πριν προχωρήσετε στην ανάπτυξη, πρέπει να κατανοήσετε ορισμένα βασικά πράγματα, συγκεκριμένα
Κύρια στοιχεία λογισμικού CMS:
- βάση δεδομένων: Σας επιτρέπει να συνδυάσετε ορισμένες διαμορφώσεις, όπως σχέδιο κλήσης, χώρους χρήστη και τους ίδιους τους χρήστες. Υποστηρίζει ομαδοποίηση για υψηλή διαθεσιμότητα (μονό κύριο) μόνο.
- Call Bridge: υπηρεσία για ηχητική και βιντεοδιάσκεψη που παρέχει πλήρη έλεγχο στη διαχείριση και επεξεργασία των κλήσεων και των διαδικασιών πολυμέσων. Υποστηρίζει ομαδοποίηση για υψηλή διαθεσιμότητα και επεκτασιμότητα.
- Διακομιστής XMPP: υπεύθυνος για την εγγραφή και τον έλεγχο ταυτότητας των πελατών που χρησιμοποιούν την εφαρμογή Cisco Meeting ή/και WebRTC(επικοινωνία σε πραγματικό χρόνο ή απλά στο πρόγραμμα περιήγησης), καθώς και σηματοδότησης μεταξύ συστατικών. Μπορεί να συγκεντρωθεί μόνο για υψηλή διαθεσιμότητα.
- Web Bridge: Παρέχει πρόσβαση πελάτη στο WebRTC.
- Loadbalancer: Παρέχει ένα μόνο σημείο σύνδεσης για εφαρμογές συσκέψεων Cisco σε λειτουργία Single Split. Ακούει την εξωτερική διεπαφή και τη θύρα για εισερχόμενες συνδέσεις. Ομοίως, το πρόγραμμα εξισορρόπησης φορτίου δέχεται εισερχόμενες συνδέσεις TLS από τον διακομιστή XMPP, μέσω του οποίου μπορεί να αλλάξει συνδέσεις TCP από εξωτερικούς πελάτες.
Στο δικό μας σενάριο δεν θα χρειαστεί. - TURN server: Παρέχει τεχνολογία παράκαμψης τείχους προστασίας που επιτρέπει
Τοποθετήστε το CMS μας πίσω από ένα τείχος προστασίας ή NAT για να συνδέσετε εξωτερικούς πελάτες χρησιμοποιώντας την εφαρμογή Cisco Meeting ή συσκευές SIP. Στο δικό μας σενάριο δεν θα χρειαστεί. - Διαχειριστής Ιστού: Διαχειριστική διεπαφή και πρόσβαση API, συμπεριλαμβανομένων των ειδικών συνεδρίων Unified CM.
Λειτουργίες διαμόρφωσης
Σε αντίθεση με τα περισσότερα άλλα προϊόντα της Cisco, ο Cisco Meeting Server υποστηρίζει τρεις μεθόδους διαμόρφωσης για την προσαρμογή οποιουδήποτε τύπου ανάπτυξης.
- Γραμμή εντολών (CLI): Διεπαφή γραμμής εντολών γνωστή ως MMP για εργασίες αρχικής διαμόρφωσης και πιστοποιητικού.
- Διαχειριστής Ιστού: Κυρίως για διαμορφώσεις που σχετίζονται με το CallBridge, ειδικά κατά τη ρύθμιση ενός μεμονωμένου διακομιστή χωρίς συμπλέγματα.
- REST API: Χρησιμοποιείται για τις πιο σύνθετες εργασίες διαμόρφωσης και εργασίες που σχετίζονται με συμπλέγματα βάσης δεδομένων.
Εκτός από τα παραπάνω, χρησιμοποιείται το πρωτόκολλο SFTP για να μεταφέρετε αρχεία —συνήθως άδειες, πιστοποιητικά ή αρχεία καταγραφής— προς και από τον διακομιστή CMS.
Στους οδηγούς ανάπτυξης της Cisco είναι γραμμένο σε λευκό και αγγλικό ότι το σύμπλεγμα πρέπει να αναπτυχθεί τουλάχιστον τρεις διακομιστές (κόμβοι) στο πλαίσιο βάσεων δεδομένων. Επειδή Μόνο με μονό αριθμό κόμβων θα λειτουργήσει ο μηχανισμός για την επιλογή ενός νέου Database Master και γενικά το Database Master έχει σύνδεση με το μεγαλύτερο μέρος της βάσης δεδομένων διακομιστή CMS.
Και όπως δείχνει η πρακτική, δύο διακομιστές (κόμβοι) δεν είναι πραγματικά αρκετά. Ο μηχανισμός επιλογής λειτουργεί κατά την επανεκκίνηση του Master, ο διακομιστής Slave γίνεται κύριος μόνο αφού εμφανιστεί ο διακομιστής που έχει επανεκκινηθεί. Ωστόσο, εάν σε ένα σύμπλεγμα δύο διακομιστών ο κύριος διακομιστής σβήσει ξαφνικά, τότε ο διακομιστής Slave δεν θα γίνει ο κύριος και εάν ο Slave σβήσει, τότε ο υπόλοιπος κύριος διακομιστής θα γίνει Slave.
Αλλά στο πλαίσιο του XMPP, θα ήταν πραγματικά απαραίτητο να συγκεντρωθεί ένα σύμπλεγμα τριών διακομιστών, επειδή εάν, για παράδειγμα, απενεργοποιήσετε την υπηρεσία XMPP σε έναν από τους διακομιστές στους οποίους το XMMP βρίσκεται σε κατάσταση Leader, τότε στον υπόλοιπο διακομιστή το XMPP θα παραμείνει σε κατάσταση ακόλουθου και οι συνδέσεις CallBridge στο XMPP θα πέσουν, επειδή Το CallBridge συνδέεται αποκλειστικά με XMPP με κατάσταση Leader. Και αυτό είναι κρίσιμο, γιατί... δεν θα περάσει ούτε μια κλήση.
Επίσης στους ίδιους οδηγούς ανάπτυξης παρουσιάζεται ένα σύμπλεγμα με έναν διακομιστή XMPP.
Και λαμβάνοντας υπόψη τα παραπάνω, γίνεται σαφές γιατί: λειτουργεί επειδή είναι σε λειτουργία failover.
Στην περίπτωσή μας, ο διακομιστής XMPP θα υπάρχει και στους τρεις κόμβους.
Υποτίθεται ότι και οι τρεις διακομιστές μας είναι ανοιχτοί.
Εγγραφές DNS
Πριν ξεκινήσετε τη ρύθμιση διακομιστών, πρέπει να δημιουργήσετε εγγραφές DNS А и SRV τύποι:
Λάβετε υπόψη ότι στις εγγραφές μας DNS υπάρχουν δύο τομείς example.com και conf.example.com. Το Example.com είναι ένας τομέας που μπορούν να χρησιμοποιήσουν όλοι οι συνδρομητές του Cisco Unified Communication Manager για τα URI τους, ο οποίος πιθανότατα υπάρχει στην υποδομή σας ή είναι πιθανό να υπάρχει. Ή το example.com αντιστοιχεί στον ίδιο τομέα που χρησιμοποιούν οι χρήστες για τις διευθύνσεις ηλεκτρονικού ταχυδρομείου τους. Ή το πρόγραμμα-πελάτη Jabber στον φορητό υπολογιστή σας μπορεί να έχει URI [προστασία μέσω email]. Τομέα confΤο .example.com είναι ο τομέας που θα διαμορφωθεί για τους χρήστες του Cisco Meeting Server. Ο τομέας του Cisco Meeting Server θα είναι conf.example.com, επομένως για τον ίδιο χρήστη Jabber, το user@ URI θα πρέπει να χρησιμοποιηθεί για να συνδεθείτε στο Cisco Meeting Serverconf.example.com.
Βασική διαμόρφωση
Όλες οι ρυθμίσεις που περιγράφονται παρακάτω εμφανίζονται σε έναν διακομιστή, αλλά πρέπει να γίνουν σε κάθε διακομιστή του συμπλέγματος.
QoS
Δεδομένου ότι το CMS δημιουργεί σε πραγματικό χρόνο κίνηση ευαίσθητη σε καθυστερήσεις και απώλεια πακέτων, στις περισσότερες περιπτώσεις συνιστάται η διαμόρφωση της ποιότητας υπηρεσίας (QoS). Για να επιτευχθεί αυτό, το CMS υποστηρίζει την προσθήκη ετικετών σε πακέτα με τους Κώδικες Διαφοροποιημένων Υπηρεσιών (DSCP) που δημιουργεί. Αν και η ιεράρχηση κυκλοφορίας βάσει DSCP εξαρτάται από τον τρόπο επεξεργασίας της κίνησης από τα στοιχεία δικτύου της υποδομής σας, στην περίπτωσή μας θα διαμορφώσουμε το CMS μας με τυπική ιεράρχηση DSCP με βάση τις βέλτιστες πρακτικές QoS.
Σε κάθε διακομιστή θα εισάγουμε αυτές τις εντολές
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AΈτσι, όλη η κίνηση βίντεο είχε την σήμανση AF41 (DSCP 0x22), όλη η φωνητική κίνηση έφερε την σήμανση EF (DSCP 0x2E), άλλοι τύποι κυκλοφορίας με χαμηλή καθυστέρηση, όπως το SIP και το XMPP, χρησιμοποιούν AF31 (DSCP 0x1A).
Ελέγχουμε:
NTP
Το Πρωτόκολλο Ώρας Δικτύου (NTP) είναι σημαντικό όχι μόνο για την παροχή ακριβών χρονικών σφραγίδων κλήσεων και συνεδρίων, αλλά και για την επαλήθευση πιστοποιητικών.
Προσθέστε διακομιστές NTP στην υποδομή σας με μια εντολή όπως
ntp server add <server>
Στην περίπτωσή μας, υπάρχουν δύο τέτοιοι διακομιστές, άρα θα υπάρχουν δύο ομάδες.
Ελέγχουμε:
Και ορίστε τη ζώνη ώρας για τον διακομιστή μας
DNS
Προσθέτουμε διακομιστές DNS στο CMS με μια εντολή όπως:
dns add forwardzone <domain-name> <server ip>
Στην περίπτωσή μας, υπάρχουν δύο τέτοιοι διακομιστές, άρα θα υπάρχουν δύο ομάδες.
Ελέγχουμε:
Διαμόρφωση διεπαφής δικτύου
Διαμορφώνουμε τη διεπαφή με μια εντολή όπως:
ipv4 <interface> add <address>/<prefix length> <gateway>
Ελέγχουμε:
Όνομα διακομιστή (Όνομα κεντρικού υπολογιστή)
Ορίζουμε το όνομα διακομιστή με μια εντολή όπως:
hostname <name>
Και κάνουμε επανεκκίνηση.
Αυτό ολοκληρώνει τη βασική διαμόρφωση.
Πιστοποιητικά
ΘεωρίαΟ Cisco Meeting Server απαιτεί κρυπτογραφημένη επικοινωνία μεταξύ διαφόρων στοιχείων, και ως εκ τούτου, απαιτούνται πιστοποιητικά X.509 για όλες τις αναπτύξεις CMS. Βοηθούν να διασφαλιστεί ότι οι υπηρεσίες/διακομιστής είναι αξιόπιστοι από άλλους διακομιστές/υπηρεσίες.
Κάθε υπηρεσία απαιτεί πιστοποιητικό, αλλά η δημιουργία ξεχωριστών πιστοποιητικών για κάθε υπηρεσία μπορεί να οδηγήσει σε σύγχυση και περιττή πολυπλοκότητα. Ευτυχώς, μπορούμε να δημιουργήσουμε το ζεύγος δημόσιου-ιδιωτικού κλειδιού ενός πιστοποιητικού και στη συνέχεια να το χρησιμοποιήσουμε ξανά σε πολλές υπηρεσίες. Στην περίπτωσή μας, το ίδιο πιστοποιητικό θα χρησιμοποιηθεί για Call Bridge, XMPP Server, Web Bridge και Web Admin. Επομένως, πρέπει να δημιουργήσετε ένα ζεύγος δημόσιων και ιδιωτικών κλειδιών πιστοποιητικού για κάθε διακομιστή στο σύμπλεγμα.
Η ομαδοποίηση βάσεων δεδομένων, ωστόσο, έχει ορισμένες ειδικές απαιτήσεις πιστοποιητικού και ως εκ τούτου απαιτεί δικά της πιστοποιητικά που είναι διαφορετικά από εκείνα των άλλων υπηρεσιών. Το CMS χρησιμοποιεί ένα πιστοποιητικό διακομιστή, το οποίο είναι παρόμοιο με τα πιστοποιητικά που χρησιμοποιούνται από άλλους διακομιστές, αλλά υπάρχει επίσης ένα πιστοποιητικό πελάτη που χρησιμοποιείται για συνδέσεις βάσης δεδομένων. Τα πιστοποιητικά βάσης δεδομένων χρησιμοποιούνται τόσο για έλεγχο ταυτότητας όσο και για κρυπτογράφηση. Αντί να παρέχει ένα όνομα χρήστη και κωδικό πρόσβασης για τη σύνδεση του πελάτη στη βάση δεδομένων, παρουσιάζει ένα πιστοποιητικό πελάτη που είναι αξιόπιστο από τον διακομιστή. Κάθε διακομιστής στο σύμπλεγμα βάσης δεδομένων θα χρησιμοποιεί το ίδιο ζεύγος δημόσιου και ιδιωτικού κλειδιού. Αυτό επιτρέπει σε όλους τους διακομιστές του συμπλέγματος να κρυπτογραφούν δεδομένα με τέτοιο τρόπο ώστε να μπορούν να αποκρυπτογραφηθούν μόνο από άλλους διακομιστές που μοιράζονται επίσης το ίδιο ζεύγος κλειδιών.
Για να λειτουργήσει ο πλεονασμός, τα συμπλέγματα βάσεων δεδομένων πρέπει να αποτελούνται από τουλάχιστον 3 διακομιστές, αλλά όχι περισσότερους από 5, με μέγιστο χρόνο μετ' επιστροφής 200 ms μεταξύ οποιωνδήποτε μελών του συμπλέγματος. Αυτό το όριο είναι πιο περιοριστικό από ό,τι για τη ομαδοποίηση της γέφυρας κλήσεων, επομένως είναι συχνά ο περιοριστικός παράγοντας στις γεωγραφικά κατανεμημένες αναπτύξεις.
Ο ρόλος της βάσης δεδομένων για ένα CMS έχει μια σειρά από μοναδικές απαιτήσεις. Σε αντίθεση με άλλους ρόλους, απαιτεί πιστοποιητικό πελάτη και διακομιστή, όπου το πιστοποιητικό πελάτη έχει ένα συγκεκριμένο πεδίο CN που παρουσιάζεται στον διακομιστή.
Το CMS χρησιμοποιεί μια βάση δεδομένων postgres με ένα κύριο και πολλά πανομοιότυπα αντίγραφα. Υπάρχει μόνο μία κύρια βάση δεδομένων κάθε φορά (ο «διακομιστής βάσης δεδομένων»). Τα υπόλοιπα μέλη του συμπλέγματος είναι αντίγραφα ή "πελάτες βάσης δεδομένων".
Ένα σύμπλεγμα βάσης δεδομένων απαιτεί ένα αποκλειστικό πιστοποιητικό διακομιστή και ένα πιστοποιητικό πελάτη. Πρέπει να υπογράφονται από πιστοποιητικά, συνήθως μια εσωτερική ιδιωτική αρχή έκδοσης πιστοποιητικών. Επειδή οποιοδήποτε μέλος του συμπλέγματος βάσης δεδομένων μπορεί να γίνει το κύριο, τα ζεύγη πιστοποιητικού διακομιστή βάσης δεδομένων και πελάτη (που περιέχουν τα δημόσια και ιδιωτικά κλειδιά) πρέπει να αντιγραφούν σε όλους τους διακομιστές, ώστε να μπορούν να λάβουν την ταυτότητα του πελάτη ή του διακομιστή βάσης δεδομένων. Επιπλέον, το πιστοποιητικό ρίζας CA πρέπει να φορτωθεί για να διασφαλιστεί ότι τα πιστοποιητικά πελάτη και διακομιστή μπορούν να επαληθευτούν.
Έτσι, δημιουργούμε ένα αίτημα για ένα πιστοποιητικό που θα χρησιμοποιείται από όλες τις υπηρεσίες διακομιστή εκτός από τη βάση δεδομένων (θα υπάρχει ξεχωριστό αίτημα για αυτό) με μια εντολή όπως:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Στο CN γράφουμε το γενικό όνομα των διακομιστών μας. Για παράδειγμα, εάν τα ονόματα κεντρικών υπολογιστών των διακομιστών μας server01, server02, server03, τότε η ΣΟ θα είναι server.example.com
Κάνουμε το ίδιο και στους υπόλοιπους δύο διακομιστές με τη διαφορά ότι οι εντολές θα περιέχουν τα αντίστοιχα “hostnames”
Δημιουργούμε δύο αιτήματα για πιστοποιητικά που θα χρησιμοποιηθούν από την υπηρεσία βάσης δεδομένων με εντολές όπως:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresόπου διακομιστής dbcluster и dbclusterclient ονόματα των αιτημάτων μας και μελλοντικά πιστοποιητικά, όνομα κεντρικού υπολογιστή1(2)(3) ονόματα των αντίστοιχων διακομιστών.
Εκτελούμε αυτή τη διαδικασία μόνο σε έναν διακομιστή (!) και θα ανεβάσουμε τα πιστοποιητικά και τα αντίστοιχα αρχεία .key σε άλλους διακομιστές.
Ενεργοποίηση λειτουργίας πιστοποιητικού πελάτη στο AD CS
Πρέπει επίσης να συγχωνεύσετε τα πιστοποιητικά για κάθε διακομιστή σε ένα αρχείο.Στο *NIX:
cat server01.cer server02.cer server03.cer > server.cerΣε Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
Και ανεβάστε σε κάθε διακομιστή:
1. "Ατομικό" πιστοποιητικό διακομιστή.
2. Πιστοποιητικό ρίζας (μαζί με ενδιάμεσα, εάν υπάρχουν).
3. Πιστοποιητικά για τη βάση δεδομένων («διακομιστής» και «πελάτης») και αρχεία με επέκταση .key, τα οποία δημιουργήθηκαν κατά τη δημιουργία αιτήματος για τα πιστοποιητικά βάσης δεδομένων «διακομιστής» και «πελάτης». Αυτά τα αρχεία πρέπει να είναι ίδια σε όλους τους διακομιστές.
4. Αρχείο και των τριών «ατομικών» πιστοποιητικών.
Ως αποτέλεσμα, θα πρέπει να λάβετε κάτι σαν αυτήν την εικόνα αρχείου σε κάθε διακομιστή.
Σύμπλεγμα βάσεων δεδομένων
Τώρα που έχετε μεταφορτώσει όλα τα πιστοποιητικά στους διακομιστές CMS, μπορείτε να διαμορφώσετε και να ενεργοποιήσετε την ομαδοποίηση βάσεων δεδομένων μεταξύ των τριών κόμβων. Το πρώτο βήμα είναι να επιλέξετε έναν διακομιστή ως κύριο κόμβο του συμπλέγματος βάσης δεδομένων και να τον ρυθμίσετε πλήρως.
Κύρια βάση δεδομένων
Το πρώτο βήμα για τη ρύθμιση της αναπαραγωγής της βάσης δεδομένων είναι να καθορίσετε τα πιστοποιητικά που θα χρησιμοποιηθούν για τη βάση δεδομένων. Αυτό γίνεται χρησιμοποιώντας μια εντολή όπως:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Τώρα ας πούμε στο CMS ποια διεπαφή να χρησιμοποιήσει για ομαδοποίηση βάσεων δεδομένων με την εντολή:
database cluster localnode aΣτη συνέχεια αρχικοποιούμε τη βάση δεδομένων συμπλέγματος στον κύριο διακομιστή με την εντολή:
database cluster initialize
Κόμβοι βάσης δεδομένων πελάτη
Κάνουμε την ίδια διαδικασία, μόνο αντί για την εντολή αρχικοποίηση συμπλέγματος βάσης δεδομένων εισάγετε μια εντολή όπως:
database cluster join <ip address existing master>όπου διεύθυνση ip υπάρχουσα κύρια διεύθυνση ip του διακομιστή CMS στον οποίο προετοιμάστηκε το σύμπλεγμα, απλά Master.
Ελέγχουμε πώς λειτουργεί το σύμπλεγμα βάσεων δεδομένων μας σε όλους τους διακομιστές με την εντολή:
database cluster status
Κάνουμε το ίδιο στον τρίτο διακομιστή που απομένει.
Ως αποτέλεσμα, αποδεικνύεται ότι ο πρώτος μας διακομιστής είναι ο Master, οι υπόλοιποι είναι Slaves.
Υπηρεσία Διαχειριστή Ιστού
Ενεργοποιήστε την υπηρεσία διαχειριστή ιστού:
webadmin listen a 445Η θύρα 445 επιλέχθηκε επειδή η θύρα 443 χρησιμοποιείται για την πρόσβαση χρήστη στο πρόγραμμα-πελάτη Ιστού
Διαμορφώνουμε την υπηρεσία Web Admin με αρχεία πιστοποιητικών με μια εντολή όπως:
webadmin certs <keyfile> <certificatefile> <ca bundle>Και ενεργοποιήστε το Web Admin με την εντολή:
webadmin enable
Εάν όλα πάνε καλά, θα λάβουμε γραμμές SUCCESS που υποδεικνύουν ότι ο Διαχειριστής Ιστού έχει ρυθμιστεί σωστά για το δίκτυο και το πιστοποιητικό. Ελέγχουμε τη λειτουργικότητα της υπηρεσίας χρησιμοποιώντας ένα πρόγραμμα περιήγησης ιστού και εισάγουμε τη διεύθυνση του διαχειριστή Ιστού, για παράδειγμα: : 445
Cluster γέφυρας κλήσεων
Το Call Bridge είναι η μόνη υπηρεσία που υπάρχει σε κάθε ανάπτυξη CMS. Το Call Bridge είναι ο κύριος μηχανισμός συνδιάσκεψης. Παρέχει επίσης μια διεπαφή SIP ώστε οι κλήσεις να μπορούν να δρομολογούνται προς ή από αυτήν, για παράδειγμα, από ένα Cisco Unified CM.
Οι εντολές που περιγράφονται παρακάτω πρέπει να εκτελούνται σε κάθε διακομιστή με τα κατάλληλα πιστοποιητικά.
Έτσι:
Συσχετίζουμε τα πιστοποιητικά με την υπηρεσία Call Bridge με μια εντολή όπως:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Συνδέουμε τις υπηρεσίες CallBridge στη διεπαφή που χρειαζόμαστε με την εντολή:
callbridge listen aΚαι επανεκκινήστε την υπηρεσία με την εντολή:
callbridge restart
Τώρα που έχουμε διαμορφώσει τις γέφυρες κλήσεων, μπορούμε να διαμορφώσουμε την ομαδοποίηση της γέφυρας κλήσεων. Η ομαδοποίηση Call Bridge είναι διαφορετική από τη ομαδοποίηση βάσεων δεδομένων ή XMPP. Το Call Bridge Cluster μπορεί να υποστηρίξει από 2 έως 8 κόμβους χωρίς κανέναν περιορισμό. Παρέχει όχι μόνο πλεονασμό, αλλά και εξισορρόπηση φορτίου, έτσι ώστε οι διασκέψεις να μπορούν να διανέμονται ενεργά σε διακομιστές Call Bridge χρησιμοποιώντας έξυπνη διανομή κλήσεων. Το CMS έχει πρόσθετες δυνατότητες, ομάδες Call Bridge και σχετικές λειτουργίες που μπορούν να χρησιμοποιηθούν για περαιτέρω διαχείριση.
Η ομαδοποίηση γέφυρας κλήσεων διαμορφώνεται κυρίως μέσω της διεπαφής διαχειριστή ιστού
Η διαδικασία που περιγράφεται παρακάτω πρέπει να εκτελείται σε κάθε διακομιστή του συμπλέγματος.
Ετσι,
1. Μεταβείτε στον ιστό στην επιλογή Configuration > Cluster.
2. Στο Call Bridge ταυτότητα Ως μοναδικό όνομα, πληκτρολογήστε callbridge[01,02,03] που αντιστοιχεί στο όνομα διακομιστή. Αυτά τα ονόματα είναι αυθαίρετα, αλλά πρέπει να είναι μοναδικά για αυτό το σύμπλεγμα. Έχουν περιγραφικό χαρακτήρα επειδή υποδεικνύουν ότι είναι αναγνωριστικά διακομιστή [01,02,03].
3.Β Γέφυρες ομαδοποιημένων κλήσεων εισάγετε τις διευθύνσεις URL διαχειριστή ιστού των διακομιστών μας στο σύμπλεγμα, [01,02,03].example.com:445, στο πεδίο Διεύθυνση. Φροντίστε να καθορίσετε τη θύρα. Μπορείτε να αφήσετε κενό τον τομέα SIP συνδέσμου Peer.
4. Προσθέστε ένα πιστοποιητικό στο CallBridge trust κάθε διακομιστή, το αρχείο του οποίου περιέχει όλα τα πιστοποιητικά των διακομιστών μας, τα οποία συγχωνεύσαμε σε αυτό το αρχείο στην αρχή, με μια εντολή όπως:
callbridge trust cluster <trusted cluster certificate bundle>Και επανεκκινήστε την υπηρεσία με την εντολή:
callbridge restart
Ως αποτέλεσμα, σε κάθε διακομιστή θα πρέπει να λάβετε αυτήν την εικόνα:
Σύμπλεγμα XMPP
Η υπηρεσία XMPP στο CMS χρησιμοποιείται για τη διαχείριση όλων των εγγραφών και ελέγχου ταυτότητας για τις εφαρμογές συσκέψεων Cisco (CMA), συμπεριλαμβανομένου του προγράμματος-πελάτη ιστού CMA WebRTC. Το ίδιο το Call Bridge λειτουργεί επίσης ως πελάτης XMPP για σκοπούς ελέγχου ταυτότητας και επομένως πρέπει να ρυθμιστεί όπως άλλοι πελάτες. Η ανοχή σφαλμάτων XMPP είναι μια δυνατότητα που υποστηρίζεται σε περιβάλλοντα παραγωγής από την έκδοση 2.1
Οι εντολές που περιγράφονται παρακάτω πρέπει να εκτελούνται σε κάθε διακομιστή με τα κατάλληλα πιστοποιητικά.
Έτσι:
Συσχετίζουμε τα πιστοποιητικά με την υπηρεσία XMPP με μια εντολή όπως:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Στη συνέχεια, ορίστε τη διεπαφή ακρόασης με την εντολή:
xmpp listen aΗ υπηρεσία XMPP απαιτεί έναν μοναδικό τομέα. Αυτό είναι το login για τους χρήστες. Με άλλα λόγια, όταν ένας χρήστης προσπαθεί να συνδεθεί χρησιμοποιώντας την εφαρμογή CMA (ή μέσω του προγράμματος-πελάτη WebRTC), εισάγει userID@logindomain. Στην περίπτωσή μας θα είναι userid@conf.example.com. Γιατί δεν είναι μόνο το example.com; Στη συγκεκριμένη ανάπτυξή μας, επιλέξαμε τον Ενοποιημένο τομέα CM που θα χρησιμοποιούν οι χρήστες Jabber στο Ενοποιημένο CM ως example.com, επομένως χρειαζόμασταν έναν διαφορετικό τομέα για τους χρήστες CMS για τη δρομολόγηση κλήσεων από και προς το CMS μέσω τομέων SIP.
Ρυθμίστε έναν τομέα XMPP χρησιμοποιώντας μια εντολή όπως:
xmpp domain <domain>Και ενεργοποιήστε την υπηρεσία XMPP με την εντολή:
xmpp enableΣτην υπηρεσία XMPP, πρέπει να δημιουργήσετε διαπιστευτήρια για κάθε Γέφυρα κλήσεων που θα χρησιμοποιηθούν κατά την εγγραφή στην υπηρεσία XMPP. Αυτά τα ονόματα είναι αυθαίρετα (και δεν σχετίζονται με τα μοναδικά ονόματα που ρυθμίσατε για ομαδοποίηση γέφυρας κλήσεων). Πρέπει να προσθέσετε τρεις γέφυρες κλήσεων σε έναν διακομιστή XMPP και, στη συνέχεια, να εισαγάγετε αυτά τα διαπιστευτήρια σε άλλους διακομιστές XMPP στο σύμπλεγμα, επειδή αυτή η ρύθμιση παραμέτρων δεν ταιριάζει στη βάση δεδομένων του συμπλέγματος. Αργότερα θα διαμορφώσουμε κάθε Γέφυρα Κλήσης ώστε να χρησιμοποιεί αυτό το όνομα και το μυστικό για εγγραφή στην υπηρεσία XMPP.
Τώρα πρέπει να διαμορφώσουμε την υπηρεσία XMPP στον πρώτο διακομιστή με τρεις γέφυρες κλήσης callbridge01, callbridge02 και callbridge03. Σε κάθε λογαριασμό θα εκχωρηθούν τυχαίοι κωδικοί πρόσβασης. Αργότερα θα εισαχθούν σε άλλους διακομιστές Call Bridge για να συνδεθείτε σε αυτόν τον διακομιστή XMPP. Εισαγάγετε τις ακόλουθες εντολές:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Ως αποτέλεσμα, ελέγχουμε τι συνέβη με την εντολή:
xmpp callbridge list
Ακριβώς η ίδια εικόνα θα πρέπει να εμφανίζεται στους υπόλοιπους διακομιστές μετά τα βήματα που περιγράφονται παρακάτω.
Στη συνέχεια, προσθέτουμε ακριβώς τις ίδιες ρυθμίσεις στους υπόλοιπους δύο διακομιστές, μόνο με τις εντολές
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Προσθέτουμε το Secret πολύ προσεκτικά ώστε, για παράδειγμα, να μην υπάρχουν επιπλέον κενά σε αυτό.
Ως αποτέλεσμα, κάθε διακομιστής θα πρέπει να έχει την ίδια εικόνα:
Στη συνέχεια, σε όλους τους διακομιστές του συμπλέγματος, καθορίζουμε αξιόπιστα το αρχείο που περιέχει και τα τρία πιστοποιητικά, που δημιουργήθηκαν νωρίτερα με μια εντολή όπως αυτή:
xmpp cluster trust <trust bundle>Ενεργοποιούμε τη λειτουργία συμπλέγματος xmpp σε όλους τους διακομιστές συμπλέγματος με την εντολή:
xmpp cluster enableΣτον πρώτο διακομιστή του συμπλέγματος, ξεκινάμε τη δημιουργία ενός συμπλέγματος xmpp με την εντολή:
xmpp cluster initializeΣε άλλους διακομιστές, προσθέστε ένα σύμπλεγμα στο xmpp με μια εντολή όπως:
xmpp cluster join <ip address head xmpp server>Ελέγχουμε σε κάθε διακομιστή την επιτυχία της δημιουργίας ενός συμπλέγματος XMPP σε κάθε διακομιστή με τις εντολές:
xmpp status
xmpp cluster statusΠρώτος διακομιστής:
Δεύτερος διακομιστής:
Τρίτος διακομιστής:
Σύνδεση Call Bridge σε XMPP
Τώρα που εκτελείται το σύμπλεγμα XMPP, πρέπει να διαμορφώσετε τις υπηρεσίες Call Bridge για σύνδεση στο σύμπλεγμα XMPP. Αυτή η ρύθμιση παραμέτρων γίνεται μέσω του διαχειριστή ιστού.
Σε κάθε διακομιστή, μεταβείτε στο Configuration > General και στο πεδίο Μοναδικό όνομα Call Bridge γράψτε μοναδικά ονόματα που αντιστοιχούν στον διακομιστή Call Bridge callbridge[01,02,03]Το В поле Domain conf.example.ru και τους αντίστοιχους κωδικούς πρόσβασης, μπορείτε να τους κατασκοπεύσετε
σε οποιονδήποτε διακομιστή του συμπλέγματος με την εντολή:
xmpp callbridge list
Αφήστε κενό το πεδίο «Διακομιστής». Κάλμπριτζ θα εκτελέσει μια αναζήτηση DNS SRV για _xmpp-component._tcp.conf.example.comγια να βρείτε έναν διαθέσιμο διακομιστή XMPP. Οι διευθύνσεις IP για τη σύνδεση γεφυρών κλήσης σε XMPP μπορεί να διαφέρουν σε κάθε διακομιστή, εξαρτάται από τις τιμές που επιστρέφονται στο αίτημα εγγραφής _xmpp-component._tcp.conf.example.com callbridge, το οποίο με τη σειρά του εξαρτάται από τις ρυθμίσεις προτεραιότητας για μια δεδομένη εγγραφή DNS.
Στη συνέχεια, μεταβείτε στην επιλογή Κατάσταση > Γενικά για να επαληθεύσετε εάν η υπηρεσία Call Bride έχει συνδεθεί με επιτυχία στην υπηρεσία XMPP.
Web Bridge
Σε κάθε διακομιστή του συμπλέγματος, ενεργοποιήστε την υπηρεσία Web Bridge με την εντολή:
webbridge listen a:443Διαμορφώνουμε την υπηρεσία Web Bridge με αρχεία πιστοποιητικών με μια εντολή όπως:
webbridge certs <keyfile> <certificatefile> <ca bundle>Το Web Bridge υποστηρίζει HTTPS. Θα ανακατευθύνει το HTTP στο HTTPS εάν έχει ρυθμιστεί να χρησιμοποιεί "http-redirect".
Για να ενεργοποιήσετε την ανακατεύθυνση HTTP, χρησιμοποιήστε την ακόλουθη εντολή:
webbridge http-redirect enableΓια να ενημερώσετε το Call Bridge ότι το Web Bridge μπορεί να εμπιστευτεί τις συνδέσεις από το Call Bridge, χρησιμοποιήστε την εντολή:
webbridge trust <certfile>όπου αυτό είναι ένα αρχείο που περιέχει και τα τρία πιστοποιητικά από κάθε διακομιστή στο σύμπλεγμα.
Αυτή η εικόνα πρέπει να βρίσκεται σε κάθε διακομιστή του συμπλέγματος.
Τώρα πρέπει να δημιουργήσουμε έναν χρήστη με τον ρόλο "appadmin", τον χρειαζόμαστε για να μπορούμε να διαμορφώσουμε το σύμπλεγμα μας(!), και όχι κάθε διακομιστής στο σύμπλεγμα ξεχωριστά, με αυτόν τον τρόπο οι ρυθμίσεις θα εφαρμοστούν εξίσου σε κάθε διακομιστή παρά το γεγονός ότι θα γίνουν μια φορά.
Για περαιτέρω ρύθμιση θα χρησιμοποιήσουμε .
Για εξουσιοδότηση, επιλέξτε Βασικό στην ενότητα Εξουσιοδότηση
Για να στείλετε σωστά εντολές στον διακομιστή CMS, πρέπει να ορίσετε την απαιτούμενη κωδικοποίηση
Καθορίζουμε Webbridge με την εντολή ΜΕΤΑ με παράμετρο url και νόημα
Στο ίδιο το webbridge, υποδεικνύουμε τις απαιτούμενες παραμέτρους: πρόσβαση επισκέπτη, προστατευμένη πρόσβαση κ.λπ.
Καλέστε τις ομάδες Bridge
Από προεπιλογή, το CMS δεν κάνει πάντα την πιο αποτελεσματική χρήση των πόρων διάσκεψης που διαθέτει.
Για παράδειγμα, για μια συνάντηση με τρεις συμμετέχοντες, κάθε συμμετέχων μπορεί να καταλήξει σε τρεις διαφορετικές γέφυρες κλήσης. Προκειμένου αυτοί οι τρεις συμμετέχοντες να επικοινωνούν μεταξύ τους, το Call Bridges θα δημιουργήσει αυτόματα συνδέσεις μεταξύ όλων των διακομιστών και των πελατών στον ίδιο χώρο, έτσι ώστε όλα να φαίνονται σαν όλοι οι πελάτες να βρίσκονται στον ίδιο διακομιστή. Δυστυχώς, το μειονέκτημα αυτού είναι ότι μια διάσκεψη 3 ατόμων θα καταναλώνει πλέον 9 θύρες πολυμέσων. Πρόκειται προφανώς για αναποτελεσματική χρήση των πόρων. Επιπλέον, όταν μια Γέφυρα Κλήσεων είναι πραγματικά υπερφορτωμένη, ο προεπιλεγμένος μηχανισμός είναι να συνεχίσετε να δέχεστε κλήσεις και να παρέχετε υπηρεσίες μειωμένης ποιότητας σε όλους τους συνδρομητές αυτής της Γέφυρας Κλήσεων.
Αυτά τα προβλήματα επιλύονται χρησιμοποιώντας τη δυνατότητα Call Bridge Group. Αυτή η δυνατότητα εισήχθη στην έκδοση 2.1 του λογισμικού Cisco Meeting Server και έχει επεκταθεί για να υποστηρίζει την εξισορρόπηση φορτίου τόσο για εισερχόμενες όσο και για εξερχόμενες κλήσεις εφαρμογής Cisco Meeting (CMA), συμπεριλαμβανομένων των συμμετεχόντων στο WebRTC.
Για την επίλυση του προβλήματος της επανασύνδεσης, έχουν εισαχθεί τρία διαμορφώσιμα όρια φορτίου για κάθε Γέφυρα Κλήσης:
LoadLimit — αυτό είναι το μέγιστο αριθμητικό φορτίο για μια συγκεκριμένη Γέφυρα Κλήσης. Κάθε πλατφόρμα έχει ένα προτεινόμενο όριο φόρτωσης, όπως 96000 για το CMS1000 και 1.25 GHz ανά vCPU για την εικονική μηχανή. Οι διαφορετικές κλήσεις καταναλώνουν ένα συγκεκριμένο ποσό πόρων ανάλογα με την ανάλυση και το ρυθμό καρέ του συμμετέχοντος.
NewConferenceLoadLimitBasisPoints (προεπιλογή 50% loadLimit) - ορίζει το όριο φόρτωσης διακομιστή, μετά το οποίο απορρίπτονται νέες συνεδριάσεις.
ExistingConferenceLoadLimitBasisPoints (προεπιλογή 80% του loadLimit) - η τιμή φόρτωσης διακομιστή μετά την οποία οι συμμετέχοντες που συμμετέχουν σε μια υπάρχουσα διάσκεψη θα απορριφθούν.
Ενώ αυτή η δυνατότητα σχεδιάστηκε για διανομή κλήσεων και εξισορρόπηση φορτίου, άλλες ομάδες όπως TURN Servers, Web Bridge Servers και Recorders μπορούν επίσης να αντιστοιχιστούν σε Call Bridge Groups, ώστε να μπορούν επίσης να ομαδοποιηθούν σωστά για βέλτιστη χρήση. Εάν κάποιο από αυτά τα αντικείμενα δεν έχει εκχωρηθεί σε μια ομάδα κλήσεων, θεωρείται ότι είναι διαθέσιμα σε όλους τους διακομιστές χωρίς ιδιαίτερη προτεραιότητα.
Αυτές οι παράμετροι διαμορφώνονται εδώ: :445/api/v1/system/configuration/cluster
Στη συνέχεια, υποδεικνύουμε σε κάθε callbridge σε ποια ομάδα callbridge ανήκει:
Πρώτη γέφυρα κλήσης
Δεύτερη γέφυρα κλήσης
Τρίτη γέφυρα κλήσης
Έτσι, διαμορφώσαμε την ομάδα Call Brdige ώστε να χρησιμοποιεί πιο αποτελεσματικά τους πόρους του συμπλέγματος διακομιστών συσκέψεων Cisco.
Εισαγωγή χρηστών από την υπηρεσία καταλόγου Active Directory
Η υπηρεσία Web Admin έχει μια ενότητα διαμόρφωσης LDAP, αλλά δεν παρέχει σύνθετες επιλογές διαμόρφωσης και οι πληροφορίες δεν αποθηκεύονται στη βάση δεδομένων του συμπλέγματος, επομένως η διαμόρφωση θα πρέπει να γίνει είτε χειροκίνητα σε κάθε διακομιστή μέσω της διεπαφής Ιστού είτε μέσω το API, και έτσι ώστε να "τρεις φορές "Don't up up" θα συνεχίσουμε να ορίζουμε τα δεδομένα μέσω του API.
Χρήση διεύθυνσης URL για πρόσβαση :445/api/v1/ldapServers δημιουργούν ένα αντικείμενο διακομιστή LDAP, καθορίζοντας παραμέτρους όπως:
- IP διακομιστή
- αριθμός θύρας
- имя пользователя
- пароль
- προστατευμένο περιβάλλον
Ασφαλές - επιλέξτε true ή false ανάλογα με τη θύρα, 389 - μη ασφαλές, 636 - προστατευμένο.
Αντιστοίχιση παραμέτρων πηγής LDAP σε χαρακτηριστικά στον διακομιστή συσκέψεων Cisco.
Η αντιστοίχιση LDAP αντιστοιχίζει τα χαρακτηριστικά στον κατάλογο LDAP με τα χαρακτηριστικά του CMS. Τα πραγματικά χαρακτηριστικά:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Περιγραφή των χαρακτηριστικώνJID αντιπροσωπεύει το αναγνωριστικό σύνδεσης του χρήστη στο CMS. Δεδομένου ότι πρόκειται για διακομιστή LDAP της Microsoft Active Directory, το CMS JID αντιστοιχίζεται στο sAMAccountName στο LDAP, το οποίο είναι ουσιαστικά το αναγνωριστικό σύνδεσης της υπηρεσίας καταλόγου Active Directory του χρήστη. Σημειώστε επίσης ότι παίρνετε το sAMAccountName και προσθέτετε τον τομέα conf.pod6.cms.lab στο τέλος του, επειδή αυτό είναι το στοιχείο σύνδεσης που θα χρησιμοποιήσουν οι χρήστες σας για να συνδεθούν στο CMS.
nameMapping αντιστοιχίζει αυτό που περιέχεται στο πεδίο DisplayName της υπηρεσίας καταλόγου Active Directory με το πεδίο ονόματος CMS του χρήστη.
coSpaceNameMapping δημιουργεί ένα όνομα χώρου CMS με βάση το πεδίο displayName. Αυτό το χαρακτηριστικό, μαζί με το χαρακτηριστικό coSpaceUriMapping, είναι αυτό που απαιτείται για τη δημιουργία ενός χώρου για κάθε χρήστη.
coSpaceUriMapping ορίζει το τμήμα χρήστη του URI που σχετίζεται με τον προσωπικό χώρο του χρήστη. Μερικοί τομείς μπορούν να ρυθμιστούν ώστε να καλούνται στο διάστημα. Εάν το τμήμα χρήστη αντιστοιχεί σε αυτό το πεδίο για έναν από αυτούς τους τομείς, η κλήση θα κατευθυνθεί στο χώρο αυτού του χρήστη.
coSpaceSecondaryUriMapping ορίζει ένα δεύτερο URI για να φτάσει στο διάστημα. Αυτό μπορεί να χρησιμοποιηθεί για να προσθέσετε ένα αριθμητικό ψευδώνυμο για τη δρομολόγηση κλήσεων στο χώρο του εισαγόμενου χρήστη ως εναλλακτική λύση στο αλφαριθμητικό URI που ορίζεται στην παράμετρο coSpaceUriMapping.
Ο διακομιστής LDAP και η αντιστοίχιση LDAP έχουν διαμορφωθεί. Τώρα πρέπει να τα συνδέσετε δημιουργώντας μια πηγή LDAP.
Χρήση διεύθυνσης URL για πρόσβαση :445/api/v1/ldapSource δημιουργήστε ένα αντικείμενο LDAP Source, καθορίζοντας παραμέτρους όπως:
- διακομιστής
- χαρτης
- βάσηDn
- φιλτράρισμα
Τώρα που έχει ολοκληρωθεί η διαμόρφωση LDAP, μπορείτε να εκτελέσετε τη λειτουργία μη αυτόματου συγχρονισμού.
Αυτό το κάνουμε είτε στη διεπαφή Ιστού κάθε διακομιστή κάνοντας κλικ Συγχρονίστε τώρα τμήμα Active Directory
ή μέσω του API με την εντολή ΜΕΤΑ χρησιμοποιώντας τη διεύθυνση URL για πρόσβαση :445/api/v1/ldapSyncs
Ad-Hoc συνέδρια
Τι είναι αυτό;Στην παραδοσιακή έννοια, μια διάσκεψη είναι όταν δύο συμμετέχοντες μιλούν μεταξύ τους και ένας από τους συμμετέχοντες (χρησιμοποιώντας μια συσκευή καταχωρισμένη στο Unified CM) πατά το κουμπί "Conference", καλεί το άλλο άτομο και αφού μιλήσει με αυτό το τρίτο μέρος , πατά ξανά το κουμπί "Διάσκεψη" για να συμμετάσχετε όλοι οι συμμετέχοντες στο τριμερές συνέδριο.
Αυτό που διακρίνει μια διάσκεψη Ad-Hoc από μια προγραμματισμένη διάσκεψη σε ένα CMS είναι ότι μια διάσκεψη Ad-Hoc δεν είναι απλώς μια κλήση SIP σε ένα CMS. Όταν ο εκκινητής της διάσκεψης κάνει δεύτερη φορά κλικ στο κουμπί Διάσκεψη για να προσκαλέσει όλους στην ίδια σύσκεψη, το Unified CM πρέπει να πραγματοποιήσει μια κλήση API στο CMS για να δημιουργήσει μια συνδιάσκεψη on-the-fly στην οποία στη συνέχεια μεταφέρονται όλες οι κλήσεις. Όλα αυτά γίνονται απαρατήρητα από τους συμμετέχοντες.
Αυτό σημαίνει ότι το Unified CM πρέπει να διαμορφώσει τα διαπιστευτήρια API και τη διεύθυνση/θύρα WebAdmin της υπηρεσίας καθώς και τον κορμό SIP απευθείας στον διακομιστή CMS για να συνεχίσει την κλήση.
Εάν είναι απαραίτητο, το CUCM μπορεί να δημιουργήσει δυναμικά ένα διάστημα στο CMS, έτσι ώστε κάθε κλήση να μπορεί να φτάσει στο CMS και να ταιριάζει με τον κανόνα εισερχόμενης κλήσης που προορίζεται για κενά.
Ενοποίηση με το CUCM έχει ρυθμιστεί με τον ίδιο τρόπο όπως περιγράφεται στο άρθρο εκτός από το ότι στο Cisco UCM πρέπει να δημιουργήσετε τρεις κορμούς για το CMS, τρεις γέφυρες συνδιάσκεψης, στο προφίλ ασφαλείας SIP καθορίστε τρία ονόματα θεμάτων, ομάδες διαδρομής, λίστες διαδρομών, ομάδες πόρων μέσων και λίστες ομάδων πόρων πολυμέσων και προσθέστε μερικούς κανόνες δρομολόγησης στο Cisco Meeting Server.
Προφίλ ασφαλείας SIP:
Κοντό πανταλόνι αθλητών:
Κάθε κορμός μοιάζει με τον ίδιο:
Γέφυρα Συνεδρίου
Κάθε γέφυρα συνεδρίου μοιάζει με το ίδιο:
Ομάδα Διαδρομών
Λίστα διαδρομών
Ομάδα πόρων μέσων
Λίστα ομάδων πόρων μέσων
Κανόνες κλήσης
Σε αντίθεση με τα πιο προηγμένα συστήματα διαχείρισης κλήσεων, όπως το Unified CM ή το Expressway, το CMS αναζητά τον τομέα μόνο στο πεδίο SIP Request-URI για νέες κλήσεις. Έτσι, αν το SIP INVITE είναι για γουλιά: [προστασία μέσω email]Το CMS ενδιαφέρεται μόνο για το domain.com. Το CMS ακολουθεί αυτούς τους κανόνες για να καθορίσει πού θα δρομολογήσει μια κλήση:
1. Το CMS προσπαθεί πρώτα να αντιστοιχίσει τον τομέα SIP με τους τομείς που έχουν ρυθμιστεί στους κανόνες εισερχόμενων κλήσεων. Αυτές οι κλήσεις μπορούν στη συνέχεια να δρομολογηθούν σε («στοχευμένους») χώρους ή συγκεκριμένους χρήστες, εσωτερικά IVR ή απευθείας ενσωματωμένους προορισμούς Microsoft Lync/Skype για επιχειρήσεις (S4B).
2. Εάν δεν υπάρχει αντιστοίχιση στους κανόνες εισερχόμενων κλήσεων, το CMS θα προσπαθήσει να αντιστοιχίσει τον τομέα που έχει διαμορφωθεί στον πίνακα προώθησης κλήσεων. Εάν γίνει αντιστοίχιση, ο κανόνας μπορεί να απορρίψει ρητά την κλήση ή να την προωθήσει. Αυτή τη στιγμή, το CMS μπορεί να ξαναγράψει τον τομέα, κάτι που μερικές φορές είναι χρήσιμο για την κλήση τομέων Lync. Μπορείτε επίσης να επιλέξετε να περάσετε τη ρίψη, πράγμα που σημαίνει ότι κανένα από τα πεδία δεν θα τροποποιηθεί περαιτέρω ή να χρησιμοποιήσετε ένα εσωτερικό σχέδιο κλήσης CMS. Εάν δεν υπάρχει αντιστοιχία στους κανόνες προώθησης κλήσεων, η προεπιλογή είναι να απορρίψετε την κλήση. Λάβετε υπόψη ότι στο CMS, αν και η κλήση "προωθείται", το μέσο εξακολουθεί να είναι συνδεδεμένο με το CMS, πράγμα που σημαίνει ότι θα βρίσκεται στη διαδρομή σηματοδότησης και κυκλοφορίας μέσων.
Τότε μόνο οι προωθημένες κλήσεις υπόκεινται στους κανόνες εξερχόμενων κλήσεων. Αυτές οι ρυθμίσεις καθορίζουν τους προορισμούς στους οποίους αποστέλλονται οι κλήσεις, τον τύπο κορμού (είτε πρόκειται για νέα κλήση Lync είτε για τυπική κλήση SIP) και τυχόν μετατροπές που μπορούν να πραγματοποιηθούν εάν η μεταφορά δεν έχει επιλεγεί στον κανόνα προώθησης κλήσεων.
Εδώ είναι το πραγματικό αρχείο καταγραφής του τι συμβαίνει κατά τη διάρκεια μιας Ad-Hoc διάσκεψης
Το στιγμιότυπο οθόνης το δείχνει άσχημα (δεν ξέρω πώς να το βελτιώσω), οπότε θα γράψω το αρχείο καταγραφής ως εξής:
Info 127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info call create failed to find coSpace -- attempting to retrieve from database
Info API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G
Info 127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba
Info call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"
Info call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"
Info call 7: setting up UDT RTP session for DTLS (combined media and control)
Info conference "001036270012": unencrypted call legs now present
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"
Info call 8: setting up UDT RTP session for DTLS (combined media and control)
Info call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"
Info call 9: setting up UDT RTP session for DTLS (combined media and control)
Info call 8: compensating for far end not matching payload types
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 7: compensating for far end not matching payload types
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: follow-up single codec offer received
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: sending response to single-codec additional offer
Info call 9: compensating for far end not matching payload types
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 9: BFCP (client role) now active
Info call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info call 9: BFCP (client role) now active
Info call 7: ending; remote SIP teardown - connected for 0:13
Info call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e
Info participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info call 9: on hold
Info call 9: non matching payload types mode 1/0
Info call 9: answering offer in non matching payload types mode
Info call 8: on hold
Info call 8: follow-up single codec offer received
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: sending response to single-codec additional offer
Info call 9: ending; remote SIP teardown - connected for 0:12Το ίδιο το Ad-Hoc συνέδριο:
Κανόνες εισερχόμενων κλήσεων
Η διαμόρφωση των παραμέτρων των εισερχόμενων κλήσεων είναι απαραίτητη για να μπορείτε να λαμβάνετε μια κλήση στο CMS. Όπως είδατε στη ρύθμιση LDAP, όλοι οι χρήστες εισήχθησαν με τον τομέα conf.pod6.cms.lab. Επομένως, τουλάχιστον, θέλετε οι κλήσεις σε αυτόν τον τομέα να στοχεύουν χώρους. Θα χρειαστεί επίσης να ορίσετε κανόνες για όλα όσα προορίζονται για το πλήρως πιστοποιημένο όνομα τομέα (και ίσως ακόμη και τη διεύθυνση IP) καθενός από τους διακομιστές CMS. Ο εξωτερικός μας έλεγχος κλήσεων, το Unified CM, θα διαμορφώσει τους κορμούς SIP που είναι αφιερωμένοι σε καθέναν από τους διακομιστές CMS ξεχωριστά. Ανάλογα με το αν ο προορισμός αυτών των κορμών SIP είναι μια διεύθυνση IP ή το FQDN του διακομιστή θα καθορίσει εάν το CMS πρέπει να ρυθμιστεί ώστε να δέχεται κλήσεις που κατευθύνονται στη διεύθυνση IP ή στο FQDN του.
Ο τομέας που έχει τον κανόνα εισερχομένων υψηλότερης προτεραιότητας χρησιμοποιείται ως τομέας για τυχόν χώρους χρήστη. Όταν οι χρήστες συγχρονίζονται μέσω LDAP, το CMS δημιουργεί αυτόματα κενά, αλλά μόνο το τμήμα χρήστη του URI (coSpaceUriMapping), για παράδειγμα, user.space. Μέρος Το πλήρες URI δημιουργείται με βάση αυτόν τον κανόνα. Στην πραγματικότητα, εάν επρόκειτο να συνδεθείτε στο Web Bridge σε αυτό το σημείο, θα βλέπατε ότι το Space URI δεν έχει τομέα. Ορίζοντας αυτόν τον κανόνα ως την υψηλότερη προτεραιότητα, ορίζετε τον τομέα για τους χώρους που δημιουργούνται συνδ.example.com.
Κανόνες εξερχόμενων κλήσεων
Για να επιτρέψετε στους χρήστες να πραγματοποιούν εξερχόμενες κλήσεις στο σύμπλεγμα Unified CM, πρέπει να διαμορφώσετε εξερχόμενους κανόνες. Ο τομέας των τελικών σημείων που έχουν καταχωριστεί με το Unified CM, όπως το Jabber, είναι το example.com. Οι κλήσεις σε αυτόν τον τομέα θα πρέπει να δρομολογούνται ως τυπικές κλήσεις SIP σε ενοποιημένους κόμβους επεξεργασίας κλήσεων CM. Ο κύριος διακομιστής είναι ο cucm-01.example.com και ο πρόσθετος διακομιστής είναι ο cucm-02.example.com.
Ο πρώτος κανόνας περιγράφει την απλούστερη δρομολόγηση κλήσεων μεταξύ διακομιστών συμπλέγματος.
Πεδίο Τοπικό από τον τομέα είναι υπεύθυνος για το τι θα εμφανίζεται στο SIP-URI του καλούντος για το άτομο που καλείται μετά το σύμβολο «@». Αν το αφήσουμε κενό, τότε μετά το σύμβολο «@» θα υπάρχει η διεύθυνση IP του CUCM από την οποία περνά αυτή η κλήση. Εάν καθορίσουμε έναν τομέα, τότε μετά το σύμβολο "@" θα υπάρχει πραγματικά ένας τομέας. Αυτό είναι απαραίτητο για να μπορείτε να καλέσετε, διαφορετικά δεν θα είναι δυνατή η επιστροφή μέσω SIP-URI name@ip-address.
Καλέστε όταν υποδεικνύεται Τοπικό από τον τομέα
Καλέστε πότε ΔΕΝ υποδεικνύεται Τοπικό από τον τομέα
Βεβαιωθείτε ότι έχετε καθορίσει ρητά Κρυπτογραφημένο ή Μη κρυπτογραφημένο για εξερχόμενες κλήσεις, επειδή τίποτα δεν λειτουργεί με την παράμετρο Auto.
Εγγραφή
Οι βιντεοδιασκέψεις καταγράφονται από το διακομιστή εγγραφής. Το Recorder είναι ακριβώς το ίδιο με το Cisco Meeting Server. Η συσκευή εγγραφής δεν απαιτεί εγκατάσταση οποιωνδήποτε αδειών. Απαιτούνται άδειες εγγραφής για διακομιστές που εκτελούν υπηρεσίες CallBridge, π.χ. απαιτείται άδεια εγγραφής και πρέπει να εφαρμόζεται στο στοιχείο CallBridge και όχι στον διακομιστή που εκτελεί το Recorder. Το Recorder συμπεριφέρεται ως πρόγραμμα-πελάτης Extensible Messaging and Presence Protocol (XMPP), επομένως ο διακομιστής XMPP πρέπει να είναι ενεργοποιημένος στον διακομιστή που φιλοξενεί το CallBridge.
Επειδή Έχουμε ένα σύμπλεγμα και η άδεια χρήσης πρέπει να «απλωθεί» και στους τρεις διακομιστές του συμπλέγματος. Στη συνέχεια, απλά στον προσωπικό σας λογαριασμό στις άδειες χρήσης που συσχετίζουμε (προσθέτουμε) τις διευθύνσεις MAC των a-interfaces όλων των διακομιστών CMS που περιλαμβάνονται στο σύμπλεγμα.
Και αυτή είναι η εικόνα που πρέπει να υπάρχει σε κάθε διακομιστή του συμπλέγματος
Γενικά, υπάρχουν πολλά σενάρια για την τοποθέτηση του Recorder, αλλά θα παραμείνουμε σε αυτό:
Προτού ρυθμίσετε το Recorder, πρέπει να προετοιμάσετε ένα μέρος όπου θα πραγματοποιηθούν πραγματικά η εγγραφή των βιντεοδιασκέψεων. Στην πραγματικότητα εδώ , πώς να ρυθμίσετε όλη την εγγραφή. Επικεντρώνομαι σε σημαντικά σημεία και λεπτομέρειες:
1. Είναι καλύτερα να αφαιρέσετε το πιστοποιητικό από τον πρώτο διακομιστή του συμπλέγματος.
2. Ενδέχεται να προκύψει το σφάλμα "Recorder unavailable" επειδή έχει καθοριστεί λάθος πιστοποιητικό στο Recorder Trust.
3. Η εγγραφή ενδέχεται να μην λειτουργεί εάν ο κατάλογος NFS που έχει καθοριστεί για εγγραφή δεν είναι ο ριζικός κατάλογος.
Μερικές φορές υπάρχει ανάγκη αυτόματης εγγραφής μιας διάσκεψης ενός συγκεκριμένου χρήστη ή χώρου.
Για αυτό, δημιουργούνται δύο Προφίλ κλήσεων:
Με την εγγραφή απενεργοποιημένη
Και με λειτουργία αυτόματης εγγραφής
Στη συνέχεια, «συνδέουμε» ένα CallProfile με λειτουργία αυτόματης εγγραφής στον απαιτούμενο χώρο.
Στο CMS είναι έτσι καθιερωμένο ότι εάν ένα CallProfile συνδέεται ρητά σε οποιοδήποτε χώρο ή χώρο, τότε αυτό το CallProfile λειτουργεί μόνο σε σχέση με αυτούς τους συγκεκριμένους χώρους. Και αν το CallProfile δεν είναι δεσμευμένο σε κανένα κενό, τότε από προεπιλογή εφαρμόζεται σε εκείνους τους χώρους στους οποίους κανένα CallProfile δεν είναι ρητά δεσμευμένο.
Την επόμενη φορά θα προσπαθήσω να περιγράψω πώς γίνεται η πρόσβαση στο CMS εκτός του εσωτερικού δικτύου του οργανισμού.
Πηγές:
Πηγή: www.habr.com