Cisco Meeting Server 2.5.2. אשכול במצב מדרגי ועמיד עם פונקציית הקלטת ועידת וידאו

בגיליון זה אראה ואסביר כמה מהמורכבויות של הגדרת שרת CMS במצב אשכול כשל.


Теорияבאופן כללי, ישנם שלושה סוגים של פריסת שרת CMS:

• סינגל משולב(משולב יחיד), כלומר. זהו שרת אחד שבו פועלים כל השירותים הדרושים. ברוב המקרים, פריסה מסוג זה מתאימה רק לגישה פנימית של לקוח ובסביבות קטנות יותר שבהן מגבלות המדרגיות והיתירות של שרת בודד אינן בעיה קריטית, או במצבים שבהם ה-CMS מבצע רק פונקציות מסוימות, כמו אד-הוק. כנסים על Cisco UCM.

  תכנית עבודה משוערת:
  

• פיצול יחיד(פיצול יחיד) מרחיב את סוג הפריסה הקודם על ידי הוספת שרת נפרד לגישה חיצונית. בפריסות מדור קודם, פירוש הדבר היה פריסת שרת CMS בקטע רשת מפורז (DMZ) שבו לקוחות חיצוניים יכולים לגשת אליו, ושרת CMS אחד בליבת הרשת שבו לקוחות פנימיים יכולים לגשת ל-CMS. מודל הפריסה המסוים הזה מוחלף כעת על ידי מה שנקרא סוג אדג 'בודד, המורכב משרתים כביש מהיר של סיסקו, שיש להם או יהיו להם הרבה מאותן יכולות עקיפת חומת אש, כך שלקוחות לא יצטרכו להוסיף שרת קצה CMS ייעודי.

  תכנית עבודה משוערת:
  

• ניתן להרחבה ועמיד(ניתן להרחבה וסובלנות לתקלות) סוג זה כולל יתירות עבור כל רכיב, מה שמאפשר למערכת לצמוח עם הצרכים שלך לקיבולת המרבית שלה תוך מתן יתירות במקרה של כשל. הוא גם משתמש בקונספט Single Edge כדי לספק גישה חיצונית מאובטחת. זה הסוג שנסתכל עליו בפרק הזה. אם נבין כיצד לפרוס אשכולות מסוג זה, לא רק נבין סוגים אחרים של פריסות, אלא נוכל גם להבין כיצד ליצור אשכולות של שרתי CMS כדי להתאים לגידול פוטנציאלי בביקוש.

לפני שתמשיך לפריסה, אתה צריך להבין כמה דברים בסיסיים, כלומר

רכיבי תוכנת CMS עיקריים:

• מסד נתונים: מאפשר לך לשלב כמה תצורות, כגון תוכנית חיוג, חללי משתמש ומשתמשים עצמם. תומך באשכולות לזמינות גבוהה (מאסטר יחיד) בלבד.
• התקשר לגשר: שירות לשיחות ועידה באודיו ווידאו המעניק שליטה מלאה על ניהול ועיבוד שיחות ותהליכי מולטימדיה. תומך באשכולות עבור זמינות גבוהה ומדרגיות.
• שרת XMPP: אחראי על רישום ואימות של לקוחות באמצעות יישום Cisco Meeting ו/או WebRTC(תקשורת בזמן אמת, או פשוט בדפדפן), כמו גם איתות בין רכיבים. ניתן לאסוף עבור זמינות גבוהה בלבד.
• גשר אינטרנט: מספק גישת לקוח ל-WebRTC.
• מאזן עומסים: מספק נקודת חיבור אחת עבור Cisco Meeting Apps במצב פיצול יחיד. מאזין לממשק החיצוני וליציאה לחיבורים נכנסים. באותה מידה, מאזן העומס מקבל חיבורי TLS נכנסים משרת XMPP, שדרכו הוא יכול להחליף חיבורי TCP מלקוחות חיצוניים.
  בתרחיש שלנו לא יהיה צורך בכך.
• שרת TURN: מספק טכנולוגיית עקיפת חומת אש המאפשרת
  מקם את ה-CMS שלנו מאחורי חומת אש או NAT כדי לחבר לקוחות חיצוניים באמצעות Cisco Meeting App או התקני SIP. בתרחיש שלנו לא יהיה צורך בכך.
• מנהל אינטרנט: ממשק ניהול וגישה ל-API, כולל עבור ועידות Unified CM מיוחדות.

מצבי תצורה

בניגוד לרוב מוצרי Cisco האחרים, Cisco Meeting Server תומך בשלוש שיטות תצורה כדי להתאים לכל סוג של פריסה.

• שורת פקודה (CLI): ממשק שורת הפקודה המכונה MMP עבור משימות תצורה ראשוניות ומשימות אישור.
• מנהל אינטרנט: בעיקר עבור תצורות הקשורות ל-CallBridge, במיוחד בעת הגדרת שרת יחיד שאינו מקובץ.
• REST API: משמש למשימות התצורה המורכבות ביותר ולמשימות הקשורות למסד נתונים מקובצים.

בנוסף לאמור לעיל, נעשה שימוש בפרוטוקול SFTP כדי להעביר קבצים - בדרך כלל רישיונות, אישורים או יומנים - לשרת CMS וממנו.

במדריכי פריסה מבית Cisco כתוב בלבן ובאנגלית שצריך לפרוס את האשכול לפחות שלושה שרתים (צמתים) בהקשר של מסדי נתונים. כי רק עם מספר אי זוגי של צמתים יעבוד המנגנון לבחירת Database Master חדש, ובאופן כללי ל- Database Master יש חיבור עם רוב מסד הנתונים של שרת CMS.

וכפי שמראה בפועל, שני שרתים (צמתים) ממש לא מספיקים. מנגנון הבחירה פועל כאשר ה-Master מופעל מחדש, שרת ה-Slave הופך ל-Master רק לאחר העלאת השרת המחודש. עם זאת, אם באשכול של שני שרתים שרת המאסטר יוצא לפתע, אז שרת העבדים לא יהפוך למאסטר, ואם העבד ייצא, אז שרת המאסטר הנותר יהפוך ל-slave.

אבל בהקשר של XMPP, באמת יהיה צורך להרכיב אשכול של שלושה שרתים, מכיוון אם, למשל, תשבית את שירות XMPP באחד השרתים שבהם XMMP נמצא בסטטוס Leader, אז בשרת שנותר XMPP יישאר בסטטוס Follower וחיבורי CallBridge ל-XMPP יתנתקו, מכיוון CallBridge מתחבר באופן בלעדי ל-XMPP עם סטטוס מנהיג. וזה קריטי, כי... אף שיחה אחת לא תעבור.

כמו כן, באותם מדריכי פריסה מודגם אשכול עם שרת XMPP אחד.

ובהתחשב באמור לעיל, מתברר מדוע: זה עובד כי הוא נמצא במצב failover.

במקרה שלנו, שרת XMPP יהיה קיים בכל שלושת הצמתים.

ההנחה היא שכל שלושת השרתים שלנו פועלים.

רשומות DNS

לפני שתתחיל להגדיר שרתים, עליך ליצור רשומות DNS А и SRV סוגים:

שים לב שברשומות ה-DNS שלנו יש שני דומיינים example.com ו conf.example.com. Example.com הוא דומיין שכל מנויי Cisco Unified Communication Manager יכולים להשתמש בו עבור ה-URI שלהם, שככל הנראה קיים בתשתית שלך או סביר להניח שהוא נוכח. לחלופין, example.com מתאים לאותו דומיין שבו משתמשים משתמשים עבור כתובות האימייל שלהם. לחלופין, ייתכן שללקוח Jabber במחשב הנייד שלך יש URI [מוגן בדוא"ל]. תְחוּם conf.example.com הוא הדומיין שיוגדר עבור משתמשי Cisco Meeting Server. הדומיין של Cisco Meeting Server יהיה conf.example.com, אז עבור אותו משתמש Jabber, יהיה צורך להשתמש ב-user@ URI כדי להיכנס ל-Cisco Meeting Serverconf.example.com.

תצורה בסיסית

כל ההגדרות המתוארות להלן מוצגות בשרת אחד, אך יש לבצע אותן בכל שרת באשכול.

QoS

מאז ה-CMS יוצר זמן אמת תעבורה רגישה לעיכובים ואובדן מנות, ברוב המקרים מומלץ להגדיר את איכות השירות (QoS). כדי להשיג זאת, ה-CMS תומך בתיוג מנות עם קודי השירותים המבדילים (DSCPs) שהוא יוצר. למרות שתעדוף תעבורה מבוסס 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 אלפיות השנייה בין כל חברי האשכול. מגבלה זו מגבילה יותר מאשר עבור אשכולות Call Bridge, ולכן היא לרוב הגורם המגביל בפריסות מבוזרות גיאוגרפית.

לתפקיד מסד הנתונים עבור 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 אנו כותבים את השם הכללי של השרתים שלנו. לדוגמה, אם שמות המארחים של השרתים שלנו שרת 01, שרת 02, שרת 03, אז CN יהיה server.example.com

אנו עושים את אותו הדבר בשני השרתים הנותרים, עם ההבדל שהפקודות יכללו את "שמות המארחים" המתאימים.

אנו מייצרים שתי בקשות לאישורים שישמשו את שירות מסד הנתונים עם פקודות כמו:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

איפה dbclusterserver и 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 שעליו אתחול האשכול, פשוט מאסטר.

אנו בודקים כיצד אשכול מסד הנתונים שלנו עובד בכל השרתים עם הפקודה:

database cluster status

אנחנו עושים את אותו הדבר בשרת השלישי שנותר.

כתוצאה מכך, מתברר שהשרת הראשון שלנו הוא המאסטר, השאר הם עבדים.

שירות ניהול אינטרנט

הפעל את שירות מנהל האינטרנט:

webadmin listen a 445

יציאה 445 נבחרה מכיוון שיציאה 443 משמשת לגישת משתמש ללקוח האינטרנט

אנו מגדירים את שירות ניהול האינטרנט עם קבצי אישורים עם פקודה כמו:

webadmin certs <keyfile> <certificatefile> <ca bundle>

והפעל את Web Admin עם הפקודה:

webadmin enable

אם הכל בסדר, נקבל שורות SUCCESS המציינות ש-Web Admin מוגדר כהלכה עבור הרשת והאישור. אנו בודקים את הפונקציונליות של השירות באמצעות דפדפן אינטרנט ומזינים את הכתובת של מנהל האינטרנט, לדוגמה: cms.example.com: 445

התקשר לגשר אשכול

Call Bridge הוא השירות היחיד הקיים בכל פריסת CMS. Call Bridge הוא מנגנון שיחות הועידה העיקרי. הוא גם מספק ממשק SIP כך שניתן לנתב שיחות אליו או ממנו על ידי, למשל, Cisco Unified CM.

יש לבצע את הפקודות המתוארות להלן בכל שרת עם האישורים המתאימים.
אז:

אנו מקשרים אישורים לשירות Call Bridge עם פקודה כמו:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

אנו קושרים את שירותי CallBridge לממשק שאנו צריכים באמצעות הפקודה:

callbridge listen a

והפעל מחדש את השירות עם הפקודה:

callbridge restart

כעת, לאחר שהגדרנו את גשרי השיחות שלנו, אנו יכולים להגדיר אשכול גשר שיחות. אשכול גשר שיחות שונה מאשכול מסד נתונים או XMPP. Call Bridge Cluster יכול לתמוך בין 2 ל-8 צמתים ללא כל הגבלה. הוא מספק לא רק יתירות, אלא גם איזון עומסים כך שניתן להפיץ ועידות באופן פעיל על פני שרתי Call Bridge באמצעות הפצת שיחות חכמה. ל-CMS יש תכונות נוספות, קבוצות Call Bridge ותכונות קשורות שניתן להשתמש בהן להמשך ניהול.

אשכול גשר שיחות מוגדר בעיקר דרך ממשק ניהול האינטרנט
ההליך המתואר להלן חייב להתבצע בכל שרת באשכול.
לפיכך,

1. עבור דרך האינטרנט אל תצורה > אשכול.
2. בתוך Call Bridge Identity כשם ייחודי, הזן callbridge[01,02,03] המתאים לשם השרת. שמות אלו הם שרירותיים, אך חייבים להיות ייחודיים עבור אשכול זה. הם תיאוריים בטבעם מכיוון שהם מציינים שהם מזהי שרת [01,02,03].
3.ב גשרי שיחות מקובצים הזן את כתובות ה-URL של מנהלי האינטרנט של השרתים שלנו באשכול, CMS[01,02,03].example.com:445, בשדה כתובת. הקפד לציין את היציאה. אתה יכול להשאיר את דומיין SIP של קישור עמית ריק.
4. הוסף אישור ל-CallBridge trust של כל שרת, שהקובץ שלו מכיל את כל האישורים של השרתים שלנו, שאותם מיזגנו לקובץ הזה כבר בהתחלה, בפקודה כמו:

callbridge trust cluster <trusted cluster certificate bundle>

והפעל מחדש את השירות עם הפקודה:

callbridge restart

כתוצאה מכך, בכל שרת אתה אמור לקבל את התמונה הזו:

אשכול XMPP

שירות XMPP ב-CMS משמש לטיפול בכל הרישום והאימות עבור Cisco Meeting Apps (CMA), כולל לקוח האינטרנט CMA WebRTC. ה-Call Bridge עצמו פועל גם כלקוח XMPP למטרות אימות ולכן יש להגדיר אותו כמו לקוחות אחרים. עמידות לתקלות XMPP היא תכונה שנתמכת בסביבות ייצור מאז גרסה 2.1

יש לבצע את הפקודות המתוארות להלן בכל שרת עם האישורים המתאימים.
אז:

אנו מקשרים אישורים לשירות XMPP עם פקודה כמו:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

לאחר מכן הגדר את ממשק ההאזנה עם הפקודה:

xmpp listen a

שירות XMPP דורש דומיין ייחודי. זוהי הכניסה למשתמשים. במילים אחרות, כאשר משתמש מנסה להיכנס באמצעות אפליקציית CMA (או דרך לקוח WebRTC), הוא מזין userID@logindomin. במקרה שלנו זה יהיה userid@conf.example.com. למה זה לא רק example.com? בפריסה הספציפית שלנו, בחרנו את תחום ה-Unified CM שלנו שמשתמשי Jabber ישתמשו בו ב-Unified CM כ-example.com, כך שהיינו צריכים דומיין אחר עבור משתמשי CMS כדי לנתב שיחות אל ה-CMS וממנו דרך דומיינים של SIP.

הגדר תחום XMPP באמצעות פקודה כמו:

xmpp domain <domain>

והפעל את שירות XMPP עם הפקודה:

xmpp enable

בשירות XMPP, עליך ליצור אישורים עבור כל Call Bridge שישמש בעת ההרשמה לשירות XMPP. שמות אלו הם שרירותיים (ואינם קשורים לשמות הייחודיים שהגדרת עבור אשכול גשר שיחות). עליך להוסיף שלושה גשרי שיחות בשרת XMPP אחד ולאחר מכן להזין את האישורים האלה בשרתי XMPP אחרים באשכול מכיוון שתצורה זו אינה מתאימה למסד הנתונים של האשכול. מאוחר יותר נגדיר כל Call Bridge להשתמש בשם ובסוד זה כדי להירשם לשירות 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 בזהירות רבה, כך, למשל, לא יהיו בו רווחים נוספים.


כתוצאה מכך, לכל שרת צריכה להיות אותה תמונה:

לאחר מכן, בכל השרתים באשכול, אנו מציינים ב-trust את הקובץ המכיל את כל שלושת האישורים, שנוצרו קודם לכן בפקודה כזו:

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

שרת ראשון:

שרת שני:

שרת שלישי:

חיבור גשר שיחות ל-XMPP

כעת כשאשכול ה-XMPP פועל, עליך להגדיר את שירותי ה-Call Bridge להתחבר לאשכול ה-XMPP. תצורה זו מתבצעת דרך מנהל האינטרנט.

בכל שרת, עבור אל תצורה > כללי ובשדה שם ייחודי של גשר שיחות לכתוב שמות ייחודיים המתאימים לשרת Call Bridge callbridge[01,02,03]... בשטח תְחוּם 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 באמצעות הפקודה:

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 עם הפקודה POST עם פרמטר כתובת אתר ומשמעות cms.example.com



ב-webbridge עצמו אנו מציינים את הפרמטרים הנדרשים: גישת אורח, גישה מוגנת וכו'.

התקשר ל-Bridge Groups

כברירת מחדל, ה-CMS לא תמיד עושה את השימוש היעיל ביותר במשאבי הוועידה העומדים לרשותו.

לדוגמה, עבור פגישה עם שלושה משתתפים, כל משתתף עשוי להגיע לשלושה גשרי שיחות שונים. על מנת ששלושת המשתתפים הללו יתקשרו זה עם זה, Call Bridges ייצור חיבורים אוטומטית בין כל השרתים והלקוחות באותו שטח, כך שהכל ייראה כאילו כל הלקוחות נמצאים באותו שרת. לרוע המזל, החיסרון בכך הוא שכנס בודד של 3 אנשים יצרוך כעת 9 יציאות מדיה. ברור שזה שימוש לא יעיל במשאבים. בנוסף, כאשר גשר שיחות באמת עמוס יתר על המידה, מנגנון ברירת המחדל הוא להמשיך לקבל שיחות ולספק שירות איכותי מופחת לכל המנויים של אותו גשר שיחות.

בעיות אלו נפתרות באמצעות התכונה Call Bridge Group. תכונה זו הוצגה בגרסה 2.1 של תוכנת Cisco Meeting Server והיא הורחבה לתמיכה באיזון עומסים עבור שיחות נכנסות ויוצאות של Cisco Meeting App (CMA), כולל משתתפי WebRTC.

כדי לפתור את בעיית החיבור מחדש, הוכנסו שלוש מגבלות עומס הניתנות להגדרה עבור כל גשר שיחות:

מגבלת עומס - זהו העומס המספרי המרבי עבור גשר שיחות מסוים. לכל פלטפורמה יש מגבלת עומס מומלצת, כגון 96000 עבור ה-CMS1000 ו-1.25 GHz לכל vCPU עבור המכונה הוירטואלית. שיחות שונות צורכות כמות מסוימת של משאבים בהתאם לרזולוציה וקצב הפריימים של המשתתף.
NewConferenceLoadLimitBasisPoints (ברירת מחדל 50% loadLimit) - מגדיר את מגבלת העומס של השרת, ולאחר מכן ועידות חדשות נדחות.
ExistingConferenceLoadLimitBasisPoints (ברירת מחדל 80% מ-loadLimit) - ערך טעינת השרת שאחריו משתתפים המצטרפים לוועידה קיימת יידחו.

אמנם תכונה זו תוכננה להפצת שיחות ואיזון עומסים, אך ניתן להקצות קבוצות אחרות כגון TURN Servers, Web Bridge Servers ומקליטים ל-Call Bridge Groups כך שניתן גם לקבץ אותם כראוי לשימוש מיטבי. אם כל אחד מהאובייקטים הללו אינו מוקצה לקבוצת שיחות, ההנחה היא שהם זמינים לכל השרתים ללא כל עדיפות מסוימת.

פרמטרים אלה מוגדרים כאן: cms.example.com:445/api/v1/system/configuration/cluster

לאחר מכן, אנו מציינים לכל callbridge לאיזו קבוצת callbridge הוא שייך:

Callbridge הראשון

Callbridge שני

גשר שיחות שלישי


לפיכך, הגדרנו את קבוצת Call Brdige לשימוש יעיל יותר במשאבים של אשכול ה-Cisco Meeting Server.

ייבוא ​​משתמשים מ- Active Directory

לשירות Web Admin יש סעיף תצורת LDAP, אך הוא אינו מספק אפשרויות תצורה מורכבות, והמידע אינו מאוחסן במסד הנתונים של האשכול, כך שתצטרך לבצע את התצורה, או ידנית בכל שרת דרך ממשק האינטרנט, או באמצעות ה-API, וכדי ש"שלוש פעמים "אל תקום" עדיין נגדיר את הנתונים דרך ה-API.

שימוש ב-URL לגישה cms01.example.com:445/api/v1/ldapServers יוצרים אובייקט LDAP Server, תוך ציון פרמטרים כגון:

• כתובת ה- IP של השרת
• מספר יציאה
• имя пользователя
• סיסמא
• לבטח

מאובטח - בחר נכון או שקר בהתאם ליציאה, 389 - לא מאובטח, 636 - מוגן.


מיפוי פרמטרי מקור LDAP לתכונות ב-Cisco Meeting Server.
מיפוי LDAP ממפה את התכונות בספריית LDAP לתכונות ב-CMS. התכונות בפועל:

• jidMapping
• מיפוי שמות
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

תיאור התכונותJID מייצג את מזהה הכניסה של המשתמש ב-CMS. מכיוון שזהו שרת Microsoft Active Directory LDAP, ה-CMS JID ממפה ל-sAMAccountName ב-LDAP, שהוא בעצם מזהה ההתחברות של ה-Active Directory של המשתמש. כמו כן, שים לב שאתה לוקח את sAMAccountName ומוסיף את הדומיין conf.pod6.cms.lab לקצה שלו מכיוון שזוהי ההתחברות שהמשתמשים שלך ישתמשו בו כדי להיכנס ל-CMS.

מיפוי שמות מתאים את הכלול בשדה Active Directory displayName לשדה שם ה-CMS של המשתמש.

coSpaceNameMapping יוצר שם מרחב CMS ​​המבוסס על השדה displayName. תכונה זו, יחד עם התכונה coSpaceUriMapping, היא מה שנדרש ליצירת מרחב עבור כל משתמש.

coSpaceUriMapping מגדיר את חלק המשתמש ב-URI המשויך למרחב האישי של המשתמש. ניתן להגדיר כמה דומיינים לחיוג לחלל. אם חלק המשתמש מתאים לשדה זה עבור אחד מהדומיינים הללו, השיחה תופנה למרחב של אותו משתמש.

coSpaceSecondaryUriMapping מגדיר URI שני להגיע לחלל. זה יכול לשמש כדי להוסיף כינוי מספרי לניתוב שיחות למרחב המשתמש המיובא כחלופה ל-URI האלפאנומרי המוגדר בפרמטר coSpaceUriMapping.

שרת LDAP ומיפוי LDAP מוגדרים. כעת עליך לקשר אותם יחד על ידי יצירת מקור LDAP.

שימוש ב-URL לגישה cms01.example.com:445/api/v1/ldapSource צור אובייקט מקור LDAP, תוך ציון פרמטרים כגון:

• שרת
• מיפוי
• baseDn
• לסנן

כעת, לאחר שתצורת ה-LDAP הושלמה, תוכל לבצע את פעולת הסנכרון הידנית.

אנו עושים זאת בממשק האינטרנט של כל שרת על ידי לחיצה סנכרן כעת סעיף של Active Directory


או דרך ה-API עם הפקודה POST באמצעות כתובת URL כדי לגשת cms01.example.com:445/api/v1/ldapSyncs

כנסים אד-הוק

מה זה?בתפיסה המסורתית, ועידה היא כאשר שני משתתפים משוחחים זה עם זה, ואחד המשתתפים (באמצעות מכשיר הרשום ב-Unified CM) לוחץ על כפתור "ועידה", מתקשר לאדם השני ולאחר דיבור עם אותו צד שלישי , לוחץ שוב על כפתור "ועידה" כדי להצטרף לכל המשתתפים בוועידה המשולשת.

מה שמבדיל בין ועידה אד-הוק לוועידה מתוכננת ב-CMS הוא שועידה אד-הוק היא לא רק שיחת SIP ל-CMS. כאשר יוזם הוועידה לוחץ על כפתור הוועידה בפעם השנייה כדי להזמין את כולם לאותה פגישה, Unified CM חייב לבצע קריאת API ל-CMS כדי ליצור ועידה תוך כדי תנועה שאליה כל השיחות מועברות. כל זה קורה מבלי שהמשתתפים יבחינו בו.

המשמעות היא ש-Unified CM חייב להגדיר את אישורי ה-API וכתובת/יציאת ה-WebAdmin של השירות, כמו גם את ה-SIP Trunk ישירות לשרת ה-CMS כדי להמשיך את השיחה.

במידת הצורך, CUCM יכולה ליצור באופן דינמי רווח ב-CMS כך שכל שיחה תוכל להגיע ל-CMS ולהתאים לכלל השיחה הנכנסת המיועד לרווחים.

אינטגרציה עם CUCM מוגדר באותו אופן כפי שמתואר במאמר מוקדם יותר אלא שב-Cisco UCM אתה צריך ליצור שלושה טראנקים עבור ה-CMS, שלושה גשרי ועידה, בפרופיל אבטחת SIP לציין שלושה שמות נושאים, קבוצות מסלולים, רשימות מסלולים, קבוצות משאבי מדיה ורשימות קבוצות משאבי מדיה, ולהוסיף כמה כללי ניתוב ל-Cisco Meeting Server.

פרופיל אבטחת SIP:


מִכנְסֵי שְׂחִיָה:


כל תא מטען נראה אותו הדבר:




גשר הכנסים


כל גשר ועידות נראה אותו הדבר:


קבוצת מסלול


רשימת מסלולים


קבוצת משאבי מדיה


רשימת קבוצות משאבי מדיה

כללי שיחות

בניגוד למערכות מתקדמות יותר לניהול שיחות כמו Unified CM או Expressway, CMS מחפשת את הדומיין רק בשדה SIP Request-URI עבור שיחות חדשות. אז אם SIP INVITE מיועד ללגימה: [מוגן בדוא"ל]ל-CMS אכפת רק מ-domain.com. CMS פועלת לפי הכללים הבאים כדי לקבוע לאן לנתב שיחה:

1. ה-CMS מנסה תחילה להתאים את תחום ה-SIP עם התחומים המוגדרים בכללי השיחה הנכנסת. לאחר מכן ניתן לנתב שיחות אלו למרחבים ("ממוקדים") או למשתמשים ספציפיים, למכשירי IVR פנימיים או ליעדים משולבים ישירות של Microsoft Lync/Skype for Business (S4B).
2. אם אין התאמה בכללי השיחה הנכנסת, CMS ינסה להתאים לתחום שהוגדר בטבלת העברת השיחות. אם מתבצעת התאמה, הכלל יכול לדחות את השיחה במפורש או להעביר את השיחה. בשלב זה, ה-CMS עשוי לשכתב את הדומיין, מה שלעתים שימושי לקריאה לדומיינים של Lync. אתה יכול גם לבחור לעבור זריקה, מה שאומר שאף אחד מהשדות לא ישונה יותר, או להשתמש בתוכנית חיוג פנימית של CMS. אם אין התאמה בכללי העברת השיחות, ברירת המחדל היא דחיית השיחה. זכור כי ב-CMS, למרות שהשיחה "מועברת", המדיה עדיין קשורה ל-CMS, מה שאומר שהיא תהיה בנתיב האיתות ותעבורת המדיה.
אז רק שיחות מועברות כפופות לכללי השיחה היוצאת. הגדרות אלו קובעות את היעדים שאליהם נשלחות שיחות, סוג הטראנק (בין אם זו שיחת Lync חדשה או שיחת SIP רגילה), וכל ההמרות שניתן לבצע אם העברה לא נבחרה בכלל העברת השיחות.

הנה היומן האמיתי של מה שקורה במהלך ועידה אד-הוק

צילום המסך מציג את זה בצורה גרועה (אני לא יודע איך לשפר את זה), אז אני אכתוב את היומן כך:

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

כנס האד-הוק עצמו:


כללי שיחות נכנסות
הגדרת הפרמטרים של שיחות נכנסות נחוצה כדי להיות מסוגל לקבל שיחה ב-CMS. כפי שראית בהגדרת LDAP, כל המשתמשים יובאו עם הדומיין conf.pod6.cms.lab. אז לכל הפחות, אתה רוצה שיחות לדומיין הזה כדי למקד למרחבים. תצטרך גם להגדיר כללים לכל מה שמיועד לשם התחום המלא (ואולי אפילו כתובת ה-IP) של כל אחד משרתי ה-CMS. בקרת השיחות החיצונית שלנו, Unified CM, תגדיר את תצורת SIP trunks המוקדשים לכל אחד משרתי CMS בנפרד. תלוי אם היעד של טראנקי SIP אלה הוא כתובת IP או ה-FQDN של השרת יקבע אם יש להגדיר את ה-CMS לקבל שיחות המכוונות לכתובת ה-IP שלו או ל-FQDN.

הדומיין שיש לו את הכלל הנכנס בעדיפות הגבוהה ביותר משמש כדומיין עבור כל חללי המשתמש. כאשר משתמשים מסתנכרנים באמצעות LDAP, ה-CMS יוצר רווחים באופן אוטומטי, אך רק את חלק המשתמש של ה-URI (coSpaceUriMapping), לדוגמה, user.space. חֵלֶק תחום ה-URI המלא נוצר על סמך כלל זה. למעשה, אם הייתם נכנסים ל-Web Bridge בשלב זה, הייתם רואים של- Space URI אין תחום. על ידי הגדרת כלל זה כעדיפות הגבוהה ביותר, אתה מגדיר את הדומיין עבור הרווחים שנוצרו conf.example.com.


כללי שיחות יוצאות

כדי לאפשר למשתמשים לבצע שיחות יוצאות לאשכול Unified CM, עליך להגדיר כללים יוצאים. הדומיין של נקודות הקצה הרשומות ב-Unified CM, כגון Jabber, הוא example.com. שיחות לתחום זה צריכות להיות מנותבות כשיחות SIP סטנדרטיות לצמתי עיבוד שיחות Unified CM. השרת הראשי הוא cucm-01.example.com, והשרת הנוסף הוא cucm-02.example.com.

הכלל הראשון מתאר את הניתוב הפשוט ביותר של שיחות בין שרתי אשכולות.

שדה מקומי מהדומיין אחראי למה שיוצג ב-SIP-URI של המתקשר עבור האדם שנקרא אחרי הסמל "@". אם נשאיר אותו ריק, אז אחרי הסמל "@" תהיה כתובת ה-IP של ה-CUCM שדרכה עוברת השיחה הזו. אם נציין דומיין, אז אחרי הסמל "@" יהיה למעשה דומיין. זה הכרחי על מנת שניתן יהיה להתקשר בחזרה, אחרת לא ניתן יהיה להתקשר חזרה דרך SIP-URI name@ip-address.

התקשר כשמצוין מקומי מהדומיין


תתקשר מתי לא צוין מקומי מהדומיין


הקפד לציין במפורש מוצפן או לא מוצפן עבור שיחות יוצאות, כי שום דבר לא עובד עם הפרמטר Auto.

הקלטה

ועידות וידאו מוקלטות על ידי שרת ההקלטה. מקליט זהה לחלוטין ל-Cisco Meeting Server. מקליט אינו דורש התקנה של רישיונות כלשהם. רישיונות הקלטה נדרשים עבור שרתים המריצים שירותי CallBridge, כלומר. נדרש רישיון הקלטה ויש להחיל אותו על רכיב CallBridge, ולא על השרת שבו פועל מקליט. מקליט מתנהג כלקוח Extensible Messaging and Presence Protocol (XMPP), כך ששרת XMPP חייב להיות מופעל בשרת המארח את CallBridge.

כי יש לנו אשכול והרישיון צריך להיות "למתוח" על פני כל שלושת השרתים באשכול. ואז פשוט בחשבון האישי שלך ברישיונות שאנו משייכים (מוסיפים) את כתובות ה-MAC של ממשקי ה-a של כל שרתי ה-CMS הכלולים באשכול.

וזו התמונה שאמורה להיות בכל שרת באשכול

באופן כללי, ישנם מספר תרחישים להצבת מקליט, אך אנו נצמד לזה:


לפני הגדרת מקליט, עליך להכין מקום בו יוקלטו בפועל ועידות הווידאו. בעצם כאן קשר, כיצד להגדיר את כל ההקלטות. אני מתמקד בנקודות ובפרטים חשובים:

1. עדיף להחליק את האישור מהשרת הראשון באשכול.
2. השגיאה "הרשמקול אינו זמין" עלולה להתרחש מכיוון שהאישור השגוי צוין ב-Recorder Trust.
3. ייתכן שהכתיבה לא תעבוד אם ספריית ה-NFS שצוינה להקלטה אינה ספריית הבסיס.

לפעמים יש צורך להקליט אוטומטית ועידה של משתמש או מרחב ספציפי אחד.

לשם כך נוצרים שני CallProfiles:
כשההקלטה מושבתת


ועם פונקציית הקלטה אוטומטית


לאחר מכן, אנו "מצמידים" CallProfile עם פונקציית הקלטה אוטומטית למרחב הרצוי.


ב-CMS זה כל כך מבוסס שאם CallProfile קשור במפורש למרחב או מרחב כלשהו, ​​אז CallProfile זה עובד רק ביחס למרחבים הספציפיים הללו. ואם ה-CallProfile אינו קשור לרווח כלשהו, ​​אז כברירת מחדל הוא מוחל על אותם רווחים ששום CallProfile אינו קשור אליהם במפורש.

בפעם הבאה אנסה לתאר כיצד ניתן לגשת ל-CMS מחוץ לרשת הפנימית של הארגון.

מקורות:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. pdf

מקור: www.habr.com