מדריך פריסת העברה

מבוא

לפני שתתחיל

מדריך זה מיועד לצוותים או אנשים עם ניסיון בתצורה וניהול של Cisco Unified Communications Manager (Unified CM) ונקודות קצה של סיסקו, כולל טלפונים לשולחן IP, התקני וידאו ולקוחות רכים של Jabber. לאורך מסמך זה, ישנם קישורים לתיעוד מוצר ותמיכה שיסייעו.

מסמך זה מתמקד במעברים Webex Calling מרו Unified CM בי דיירים בלבד. המונח Webex Callingבמסמך זה מתייחס תמיד לדיירים Webex Calling מרובים.

לפני תחילת ההגירה מ Unified CM - אלWebex Calling, חובה לקבל הבנה מקיפה של הפ Webex Calling תרון ומרכיביו בהתאמה. העברה מוצלחת דורשת היכרות עם הא Webex Calling רכיטקטורה, דגמי השירות, אפשרויות הפריסה והתכונות הנלוות כדי למפות כראוי Unified CM עומסי עבודה קיימים ולעצב תוכנית מעבר יעילה.

הבנה מעמיקה של Webex Calling המרכיבים הבאים חיונית כדי ליידע אסטרטגיית מעבר יעילה ונכונות תפעול ית.

רכזת בקרה
הקצאת ספריות ומשתמשים
Webex Callingפלטפורמה
נקודות קצה מתקשרות נתמכות
אפשרויות קישוריות PSTN
Webex Callingתוכנית חיוג וניהול מספרים
תכונות אבטחה ותאימות.

לקבלת מידע נוסף, ראה א רכיטקטורה מועדפת של סיסקו עבורWebex Calling.

מדריך זה ידגיש כלים ותהליכים לשימוש לאורך מחזור החיים של המעבר. עם זאת, מעבר משיחות מקומיותUnified CM, לפלטפורמת שיחות ענן חדשה,Webex Calling, יכול להיות מאמץ משמעותי עם אתגרים עסקיים, טכניים ומורכבים פוטנציאליים. כדי לעזור להתגבר על אתגרים אלה, לסיסקו יש כמה אפשרויות שונות זמינות שיסייעו לך במסע שלך. חשוב לעיין במידע ב- Enterprise Cloud Calling - העברת שיחות ול הבין כל אפשרות וכיצד כל אחת מהן יכולה לעזור לך בהעברה שלך.

כלי העברה של Webex: שירות עצמי, כלים חינמיים המובנים ב- Control Hub כדי לייעל את המעבר שלך ל Webex Calling
ספקי העברה מוסמכים: ספקי תוכנה וכלים מאומתים של סיסקו ש פיתחו פתרונות העברה כדי לסייע לשותפים ולקוחות Webex בהעברות מורכבות וגדולות. פתרונות אלה יכולים לעזור לפשט, לנהל ולהאיץ את המעבר Webex Calling
Webex Setup Assist: שירות העברה בהנחיית Cisco שמנחה לקוחות ו שותפים דרך Webex Calling הפריסה והתצורה, הדרושים כדי להעביר בהצלחה Unified CM משתמשים ושירותים אל. Webex Calling

סקירה כללית

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

מטרת מסמך זה היא לספק הנחיות פריסה ללקוחות המע וניינים במיוחד לעבור מהמק Unified CM ומי Webex Calling לענן. מדריך פריסה זה מניח שלקורא יש הבנה בסיסית של מעבר השיחות בין Unified CM לביןWebex Calling, כולל אילו שינויים בעת ביצוע המעבר הזה ומה ההבדלים בעת העברת עומס העבודה של השיחות מהמקומי לענן. לפני שתמשיך, ודא ש בדקת ומכיר את המידע הזמין במ פת המעבר. מסמך מפת מעבר זה מספק מידע על השינויים וההבדלים במעבר זה.

כפי שמוצג באיור ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות ו גישה מרחוק, פריסה מקומית טיפוסית כוללת רכיבי תשתית שיתוף פעולה שונים ברשת, פלטפורמת בקרת שיחות, פלטפורמת קצה, נקודות קצה של חומרה ותוכנה, ובמקרים מסוימים אפילו פלטפורמות ועידה ותזמון. בא רכיטקטורת סיסקו זה יכלול Unified CM בקרת שיחות, Expressway לגישה מרחוק ושירותי קצה בין עסקים לעסק (B2B), שרת ישיבות סיסקו/ניהול פגישות של סי סקו לוועידה מקומית, חיבור Unity להעברת הודעות קוליות וחומרה הפונה למשתמש (טלפונים IP של סיסקו, מערכות וידיאו של Cisco Desk and Room) ותוכנה () נקודות קצה מבוססות IP. Cisco Jabber רכיבים אלה עשויים להשתנות מעט בסביבות מסוימות, אך זוהי נקודת המוצא למעבר המתואר בשאר מסמך זה.

On-Premises Collaboration Architecture: Call Control and Remote Access — ***ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות וגישה מרחוק***

הארכיטקטורה המוצגת באיור ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות וגישה מרחוק מבוס סת על הארכיטקטורה המועדפת (PA) עבור פריסות מקומיות ארגוניות של Cisco Collaboration. לקבלת מידע נוסף על הארגון המקומי, ראה א רכיטקטורות מועדפות לשיתוף פעולה של סיסקו.

לפני: טבלת רכיבי תשתית להתקש רות מקומית מפרטת את רכיבי המפתח של הארכיטקטורה המקומית לפני המעבר לענןWebex Calling.

טבלה 1. לפני: רכיבי תשתית להתקשרות מקומית
מוצר	תיאור
Unified CM	בקרת שיחות מקומית המספקת שירותי רישום מכשירים וניתוב שיחות
Cisco Expressway-C/E	תשתית קצה המספקת פונקציונליות ניידת ו- Remote Access (MRA) ועסק לעסק (B2B) המאפשרת לנקודות קצה מרוחקות להתחבר בצורה מאובטחת מחוץ לארגון. הכביש המהיר נפרס בזוגות כדי לספק מעבר חומת אש לנ קודות קצה חיצוניות.
שרת פגישות של סיסקו (CMS), ניהול פגישות של סיסקו (CMM) וחבילת ניהול טל נוכחות של סיסקו (TMS)	תשתית ועידה קולית, וידאו ואינטרנט מקומית המספקת יכולות של פגישות מרובות נקודות, ניהול פגישות ותזמון. [אופציונלי]
Cisco Unity Connection	פלטפורמת העברת הודעות קוליות מקומית המספקת יכולות דואר קולי והודעות מאוחדות. [אופציונלי]
שולחן סיסקו, חדר סיסקו, לוח סיסקו, טלפוני IP של סיסקו ו Cisco Jabber	התקנים מבוססי IP הרשומים Unified CM ומספקים יכולות שיחות קוליות ווידאו

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

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

דגמי טלפון שאינם נתמכים על ידי Webex Calling
שילובים מורכבים או רבים עם מערכות או פתרונות מקומיים אחרים, במיוחד כאשר שכפול אינטגרציות אלה עם זה Webex Calling קשה או שאין פתרונות חלופיים שווים זמינים
תוכנית חיוג מורכבת, מחלקות שירות מפורטות ביותר או שניהם
גישה לאינטרנט מגבילה, מוגבלת או לא אמינה
מדיניות מחמירה בנושא פרטיות נתונים ובעלות
דרישת תאימות להקלטה ואחסון מדיה מקומית או בארץ
שילובים של צד שלישי ללא אינטגרציה חלו Webex Calling פית בת קיימא
שילובי מוקדי קשר שבהם מרכז הקשר אינטר עדיין לא עובר לע נן.

Transition Decision: On-Premises Calling to Webex Calling — ***החלטת מעבר: קריאה מקומית ל Webex Calling***

לקוחות המעוניינים להתחיל למנף שירותי שיחות בענן צריכים לשקולWebex Calling. שירות שיחות ענן זה מאפשר ללקוח למנף את הארכיטקטורה העולמית של Webex לצורך קנה מידה וקישוריות. משתתפים ברשת הארגונית ומשתתפים מרו חקים מחוץ לרשת הארגונית יכולים לתקשר באמצעות נקודות קצה חומרה מבוססות IP ו/או יישומי לקוח רך לשולחן העבודה או הנייד.

מסמך זה מתמקד בלקוחות עם פריסות בקרת Unified CM שיחות שרוצים להבין את השלבים הכלליים, השיקולים והד רישות להפעלת Webex Calling פריסה כמתואר בסעיף הבא.

רכיבי ליבה

ארכיטקטורת היעד להעברה זו כוללת מספר רכיבים חדשים. זה כולל את Webex Calling השירות לשיחות מבוססות ענן, אפליקציית Webex, מחבר ספריות של Cisco לשילוב זהויות ושער מקומי (LGW) ל גישה ל- PSTN, כמו גם שילוב מקומי לשיחות בענן. תוכניות שיחות של סיסקו או PSTN מחובר לענן (CCP) המופעלות על ידי Cloud Connect עבור שו Webex Calling תף הן אפשרויות נוספות לגישה ל- PSTN.

כפי שמוצג באיור לאחר: א Webex Calling רכיטקטורה, הרכיבים החד Webex Calling שים (מחבר ספרייה, שער מקומי ושער שרידות) מתווספים לפריסה המקומית הקי ימת.

After: Webex Calling Architecture — ***אחרי: Webex Calling אדריכלות***

אחרי: טבלת רכיבי תשתית להתקשרות בענן מפרטת את האלמנטים החדשים של הא רכיטקטורה לאחר המעבר ל- Webex.

טבלה 2. אחרי: רכיבי תשתית לשיחות ענן
מוצר	תיאור
Webex Calling	שירות שיחות מבוסס ענן המועבר מפלטפורמת Webex ומספק רישום נקודות קצה וניתוב שיחות
מחבר ספריית סיסקו	יישום Windows הפועל במחשב תחום של Windows המספק ס נכרון זהות בין הארגון המקומי Active Directory לבין מאגר הזהו יות של ארגון Webex. עבור לקוחות העוברים ממזהה מקומי Active Directory ל- Entra ID, שילוב הזהות עם Webex במקום Cisco Directory Connector משתמש ביישום אשף זיהוי Entra.
שער מקומי	שער מקומי משמש כגשר בין רשת התקשורת המאוחדת המקומית של הלקוח לבין הע Webex Calling נן. ניתן לפרוס אותו במקום או לארח אותו על ידי שותף, ולספק גישת PSTN לנקודות קצה הרשומות בענן, כמו גם שילוב שיחות בין Unified CM נקודות קצה רשומות ונקודות קצה רשומות בענן. Cisco IOSנתב שירותים משולבים XE (סדרת ISR 1100 ו- 4000), סדרת Cisco Catalyst 8200/8300, תו כנת קצה של Cisco Catalyst 8000V ובקרי גבול הפעלה שונים של צד שלישי מוסמכים (SBC) יכולים לשמש כ- LGW לגישת הגירה בשלבים.
שער שרידות	שער שרידות (SGW) הוא שער מבוסס IOS-XE ברשת מקומית המספק שירותי שיחות חזרה לנ קודות קצה באתר Webex Calling במהלך הפסקות רשת.
תוכנית שיחות של סיסקו, חיבור לענן עבור Webex Calling	תוכנית השיחות של Cisco ו- Cloud Connect for Webex Calling הן אפשרויות מבוססות ענן לגישה PSTN לנקודות קצה. Webex Calling גישה ל- PSTN מקלה על ידי ספק PSTN בענן ואינה דורשת ציוד מקומי.
אפליקציית Webex	יישום לקוח פועל במערכת הפעלה שולחנית (Windows, Mac) או מערכת הפעלה ניידת (Android, iOS) ונרשם ישירות לפ Webex Calling לטפורמה לפונקציונליות שיחות.

סקירת תהליך PPDIO

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

תיאור כללי של PPDIO

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

שימוש ב- PPDIO עבור פרויקטים Unified CM של Webex Calling הגירה

בעת המעבר מ- Unified CMWebex Calling, תהליך PPDIO מספק מפת דרכים ברורה להבטחת מעבר חלק ויעיל:

הכן

להעריך את Unified CM הסביבה הקיימת ואת מוכנות ההגירה
איסוף נתונים מפורטים על משתמשים, מכשירים, רשת ותלות
אסוף פרטי מיקום כולל כתובת תגובת חירום, מספר משתמשים, גישה לאינטרנט, גישה ל- PSTN
זהה סיכונים והגדר את היקף הפרויקט כדי ליישר את כל בעלי העניין.

תוכנית

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

עיצוב

מיפוי Unified CM תצורות נוכחיות, תוכניות חיוג ופרופילי משתמשים למק Webex Calling בילים
תכנן את Webex Calling הסביבה, כולל אסטרטגיית PSTN (ביניים וסופית), מיקומים, תפקידי משתמש ונקודות אינטגרציה כמו שער מקומי (CUBE) וסנכרון ספריות
תכנן תרחישי דו קיום שבו Unified CM ות Webex Calling פעלו בו זמנית במהלך ההגירה.

ליישם

השתמש בכלי העברת Control Hub לצד כלים של צד שלישי כדי לבצע שינויים במצב קושחה של המכשיר, תצורת תכונות והעברות משתמשים
השתמש בפעולות ובהקצאה בכמות גדולה באמצעות ממשקי API של Webex כדי לייעל העברות ותצורות בקנה מידה גדול
ביצוע הקצאת רישיונות, רישום מכשירים ועדכוני תצורה
אימות הצלחת ההעברה באמצעות בדיקות ו אימות תפעולי.

אופטימיזציה

מעקב רציף Webex Calling אחר הביצועים וחוויית המשתמש
חידוד תצורות וזרימות עבודה בהתבסס על נתונים תפעוליים ומשוב
מינוף יכולות אוטומציה ואינטגרציה לשיפור היעילות והמדר גיות
ביטול Unified CM רכיבים מדור קודם בהתאם לצורך ולספק תמיכה מתמשכת לפעולות יום 2.

גישת PPDIO משופרת זו מבטיחה העברה מבוקרת, שקופה ויעילה מ- אל, תוך מינוף Unified CM הכליםWebex Calling, ממשקי ה- API והמערכת האקולוגית של השותפים של סיסקו כדי לשמור על המשכיות עסקית ולש פר את יכולות שיתוף הפעולה.

לולאות משוב PPDIO

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

Iterations while executing PPDIO — ***איטרציות בעת ביצוע PPDIO***

במהלך ביצוע תהליך ה- PPDIO, מקובל שממצאים בשלבים המאוחרים יחייבו בדיקה מחודשת ואולי תיקון החלטות שהתקבלו בשלבים מוקדמים יותר. לדוגמה, בעיות שנתקלו בשלב היישום, כגון זיהוי עמימות עי צובית או פרטים חסרים, עשויות לחשוף כי היבטים מסוימים לא טופלו במלו אם בשלב התכנון. במקרים כאלה, יש צורך לחזור לשלב הקודם הר לוונטי כדי לפתור בעיות אלה לפני שתמשיך. מנגנון משוב איטרטיבי זה, כפי שמודגם בתהליך PPDI Unified CM O בסיוע איור מבטיח שהפ תרון מאומת ומעודן ביסודיות, ובסופו של דבר תורם לפריסה חזקה וי עילה יותר.

Unified CM assisted PPDIO process — ***Unified CMתהליך PPDIO בסיוע***

כאשר מבצעים מעבר מ- Unified CM לWebex Calling, כל שלב בתהליך PPDIO יכול להפיק תועלת משמעותית ממידע שנאסף מ Unified CM הסביבה הקיימת. לדוגמה, ניתן לחלץ מלאי מקיף של משתמשים, מספרי טלפון, תכונות שיחות ורכיבי תוכנית חיוג מהת Unified CM צורה הנוכחית. נתונים אלה משלימים מידע המסופק ישירות על ידי בעלי העניין ומ סייעים לייעל פעילויות תכנון ועיצוב. מינוף כלים מתאימים לאוטומציה של חילוץ וניתוח נתונים לא רק משפר את הדיוק אלא גם מאיץ את התהליך הכולל. על ידי ניצול תובנות מהפריסה הקיימת, Webex Calling ניתן לבצע את המעבר בצורה יעילה יותר מאשר יישום גרינפילד מסורתי, תוך שמירה על מתודולוגיית PPDIO המובנית. תהליך זה מודגם בתהליך PPDIO Unified CM בסיוע איור.

גישת הגירה

כשאתה מתכנן את המעבר שלך מהמק Unified CM ומי ל-Webex Calling, עליך לקבוע כיצד תתקרב למסע זה. ראשית תצטרך להחליט אם ה העברה תהיה חיתוך פלאש (הכל בבת אחת) או גישה שלבית (העברת קבוצות של משת משים/מכשירים לאורך תקופה ממושכת).

ביצוע העברה מסוג flash-cut מזי ז את כל המשתמשים והמכשירים שלך בצורה המהירה ביותר. בשיטה זו, תעביר את כל המשתמשים והמכשירים מק Unified CM ומי Webex Calling לאותו זמן. בעיקרו של דבר, זהו חלון העברה יחיד עבור כל המשתמשים והמכשירים. לאחר השלמת ההעברה, כל המשתמשים והמכשירים שלך יהיו בפ Webex Calling לטפורמה וניתן להשבית את כל הת Unified CM שתית שלך. עם זאת, ארגונים רבים אינם יכולים להשתמש בגישה זו בשל היקף וגודל פריסת השיחות שלהם.

הגישה השנייה היא הגירה בשלבים. רוב הארגונים ישתמשו בגישה זו מכיוון שהיא מספקת שליטה, ניהול וגודל טובים יותר עם ההעברה. כמו כן, הוא מתאים יותר לפריסות ו/או פריסות UC גדולות יותר באזורים מרובים. לכן, מסמך זה מתמקד בגישה השל בית עם שני שלבים במעבר.

כפי שמוצג להלן איור מעבר שיחות בשלבים: היברידי וענן, שלב המעבר הראשון (שלב 1) מביא לפריסת קיום דו-קיום עם סביבות שיחות כפולות. בשלב זה, חלק מהמשתמשים, המכשירים והלקוחות הרכים עוברים אליהם Webex Calling בעוד שאחרים עדיין נמצאים בבקרת השיחות המקומיתUnified CM. שלב המעבר הסופי (שלב 2) מביא לסביבת שיחות ענן טהורה שבה כל המשתמשים, המכשירים והלקוחות הרכים הועברו במלואם לפ Webex Calling לטפורמה.

משך הזמן שלוקח לארגון לעבור לחלוטין לשיחות ענן ישתנה בהתאם לפריסה הנוכחית שלו. במקרים מסוימים, ארגון עשוי לבצע את המעבר הראשוני ולהי שאר בשלב בקרת השיחות הכפולות הדו-קיום (שלב 1) לתקופה ממושכת (חודשים ואף שנים), ואילו במקרים אחרים, ארגון עשוי לעבור באופן מלא ל Webex Calling (שלב 2) בפרק זמן קצר מאוד (שבועות או חודשים). מסמך זה נועד לכסות את שני השלבים (שלב 1 - דו קיום ושלב 2 - מעבר מלא).

Phased Calling Transition: Hybrid and Cloud — ***מעבר שיחות בשלבים: היברידי וענן***

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

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

Recommended 3-Phase Transition — ***מעבר תלת פאזי מומלץ***

טרום העברה: שלב זה מתמקד בהכנת Webex והסבי Unified CM בות להגירה. זה לא קשור להתקשרות לתכנון או תצורות ספציפיות ומתמקד בהשלמת פעילויות שניתן לבצע כעת ולפני תחילת פרויקט Webex Calling העברה כלשהו. המטרה היא לבנות את הבסיס לשתי הסביבות להת כונן להגירה.

הכנה להגירה: שלב זה הוא המקום בו המאמץ מתחיל להתכונן להגירה אל Webex Calling. כאן יש לבחון ולעדכן את הדרישות העסקיות והטכניות. אל תעשה רק הע לאה והעברה של מה שנפרס איתו Unified CM כרגע, אלא הגדר מחדש את הדרישות העסקיות והטכניות שהחברה שלך זקוקה להם היום ובעתיד על ידי מינוף הכוח של. Webex Calling בנוסף, זהו השלב בו תשלים את העיצוב, תכנון התצורה ותכנונ/לוח הזמנים של ההעברה.

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

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

איור פעילויות טרום הגירה להלן מדגיש חמש קטגוריות ספציפיות של פעילויות הקשורות להגי Webex Calling רה.

Pre-Migration Activities — ***פעילויות לפני הגירה***

הכן

דרישות עסקיות וטכניות

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

מדוע איסוף דרישות חשוב:

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

דרישות עסקיות

דרישות עסקיות אופייניות כוללות:

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

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

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

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

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

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

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

הדרכת משתמשים וצרכי תמיכה הם מרכיבים חיוניים במהלך ההעברה מ- אל כדי להבטיח מעבר חלק ואימוץ משתמשים. שיקולים מרכזיים כוללים:

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

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

דרישות טכניות

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

מוכנות רשת ויכולת רוחב פס

הערכת רשת מקיפה היא קריטית כדי להבטיח שהתשתית הקיימת שלך יכולה לתמוך Webex Calling בסביבה החדשה. זה כולל:
- ניתוח רוחב פס: הערכת השימוש ברוחב הפס הנוכחי והמוקרן לטיפול בתעבורת קול, וידאו ונתונים ללא עומס.
- איכות השירות (QoS): יישום מדיניות QoS לתעדף תעבורה קולית ולמזעור חביון, ריצוד ואובדן מנות.
- קישוריות WAN ואינטרנט: אימות שקישורי WAN ו חיבורי אינטרנט עומדים בדרישות לשיחות מבוססות ענן, כולל יכולות יתירות ומעבר לכי שלון.
- תצורת חומת אש ו- NAT: הבטחה שהגדרות חומת האש וה-NAT מאפש רות איתות ותעבורת מדיה נדרשים עבור.
אינטגרציה עם המערכת הקיימת

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

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

אבטחה היא בעלת חשיבות עליונה בתקשורת ענן:
- הצפנה: אכי פת הצפנה מקצה לקצה לזרמי איתות ומדיה, בהתאם לשיטות האבטחה המומלצות של סיסקו.
- אימות ובקרת גישה: הטמעת מנגנוני אימות מאובטחים (כגון SSO, אימות רב-גורמי) ובקרות גישה גרעיניות למשתמשים.
- תאימות: הב טחת הפתרון עומד בתקני הרגולציה והת אימות לתעשייה הרלוונטיים (לדוגמה, GDPR, HIPAA).
- ניטור אבטחה: שילוב עם כלי SIEM והגדרת התראה על אירועי אבטחה פוטנציאליים.

טבלה 1. הערכת דוגמה
דרישה	שיקולים מרכזיים
מוכנות רשת ורוחב פס	רוחב פס, QoS, WAN/אינטרנט, חומת האש/NAT
אינטגרציה עם מערכות קיימות	מדריך, CRM, מרכזייה, דוא"ל/לוח שנה
תאימות והקצאה של נקודות קצה	תמיכה במכשירים, הקצאה, עדכוני קושחה
תצורות אבטחה והצפנה	הצפנה, אימות, תאימות, ניטור אבטחה
הדרכת משתמשים וניהול שינויים	תוכניות הדרכה, תיעוד, שינוי תקשורת
ניידות מספרים ותכנית חיוג	העברה/העברת מספרים, תרגום תוכנית חיוג
שילובים של צד שלישי	חיפוש, מרכז קשר, פקס, התקנים אנלוגיים

מוכנות רשת ודרישות

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

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

ללקוחות ולשותפים יש גישה לאפשרויות קישוריות מעבר לאינטרנט Over-the-Top (OTT) שיכולות לייעל את החיבור לכלול Webex Edge את Connect. לקבלת מידע נוסף על פרטי עיצוב Webex Edge Connect, ראה א רכיטקטורה מועדפת של Cisco עבור Webex Edge Connect עבורWebex Meetings, התקשרות למספר דיירים ומופע ייעודי .

לקוחות יכולים להשתמש ב- cScan להערכת רשת המספקת מידע על איכות הרשת של הלקוח, כמה שיחות ניתן ליצור, חביון וכן הלאה. לקבלת מידע נוסף על הכלי cScan, ראה שימוש ב- cScan לבדיקת איכות Webex Calling הרשת.

כדי להבטיח שהרשת מוכנה להעברה אל, שקול את רשימת הבדיקה הבאה:

תכנון רוחב פס

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

ט Webex Calling בלת חי שובי רוחב הפס של סוג השיחה מציגה את סוגי השיחות הזמינים עם פריסה יחד עם ה- codec ורוחב הפס המ רבי הנדרש עבור כל סוג שיחה. כפי שמוצג בטבלת חי Webex Callingשובי רוחב הפס של סוג השיחה ניתן לחשב את רוחב הפס הנדרש לשיחת שמע עבור כל סוג שיחה באמצעות הנוסחה הכללית הבאה:

מספר שיחות במקביל צפויות * רוחב פס לשיחה בהת בסס על codec = תפוקת רשת נדרשת.

טבלה 2. Webex Callingחישובי רוחב פס מסוג שי חה
סוגי שיחות	קודק - רוחב פס	חישובי רוחב פס
/טלפון שולחני ->	אופוס - 70 קילו-ביט לשנייה	מספר שיחות במקביל * 70 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> טלפון שולחני	אופוס - 70 קילו-ביט לשנייה	מספר שיחות במקביל * 70 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> PSTN באמצעות LGW	G.711 - 80 קילו-ביט לשנייה	מספר שיחות במקביל * 80 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> PSTN באמצעות PSTN בענן (למשל תוכנית שיחות של סיסקו)	G.711 - 80 קילו-ביט לשנייה	מספר שיחות במקביל * 80 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> ארגוני באמצעות LGW	G.722 - 80 קילו-ביט לשנייה	מספר שיחות במקביל * 80 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> דואר קולי	אופוס - 70 קילו-ביט לשנייה	מספר שיחות במקביל * 70 kbps = תפוקת רשת נדרשת

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

כל רגלי השיחה מעוגנות תמיד על SBC הגישה. כדי לקבוע את רוחב הפס הנדרש לאינטרנט עבור כל מיקום נתון, לא רק יש לקחת בחשבון את השיחות בין המיקומים, אלא גם שיחות תוך מיקום ושיחות לשער מקומי וממנו באותו מיקום. לדוגמה, שיחה בתוך האתר בין שני טלפונים MPP תצטרך עד 2 x 70 kbps דופלקס מלא בגישה לאינטרנט של המיקום.

ט Webex Callingבלת הדוגמאות לחישוב רוחב הפס מציגה דוגמה לת רגיל חישוב רוחב פס מלא, בהנחה שכל המכשירים נמצאים באותו אתר.

טבלה 3. Webex Calling דוגמאות לחישוב רוחב פס
סוגי שיחות	מספר שיחות במקביל	רוחב פס כולל
אפליקציית Webex/טלפון שולחני → אפליקציית Webex	15	2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → טלפון שולחני	15	2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → PSTN באמצעות LGW	50	2* 50* 80 קילו-ביט לשנייה = 8,000 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → PSTN באמצעות חיבור ענן עבור Webex Calling	0	0* 80 קילו-סיביות לשנייה
אפליקציית Webex/טלפון שולחני → ארגוני באמצעות LGW	15	2* 15* 80 קילו-ביט לשנייה = 2,400 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → דואר קולי Webex Calling	5	5* 70 קילו-ביט לשנייה = 350 קילו-ביט לשנייה
סה"כ שיחות/רוחב פס	100 שיחות	14,950 קילו-ביט לשנייה/14.95 מגהביט לשנייה

כל ערכי רוחב הפס בטבלאות לעיל מתי יחסים לרוחב פס IP. רוחב הפס של הקישור גבוה יותר בהתאם לאנקפסולציות WAN.
רוחב הפס בטבלאות לעיל מיועד לשי חות שמע. עבור רוחב פס של שיחות וידאו, Webex App וטלפונים MPP 8845/65 תומכים בוידאו H.264 ברזולוציה מקסימלית של 720p ברוחב פס מרבי של 1,500 kbps לשיחה. עם זאת, כמות רוחב הפס הנצרכת בכל נקודה במהלך השיחה תשתנה בהתבסס על קצב סיביות משתנה הטמון בתקשורת וידאו.

איכות השירות (QoS)

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

הספים הבאים מומלצים לאי כות קול מיטבית כאשר שיחות עוברות מעבר לכל היותר (OTT) וברחבי האינטרנט :
- חביון - פחות מ 100ms בכיוון אחד
- ריצוד - פחות מ -10 אלפיות השנייה
- אובדן מנות - 0.5% או פחות.
חומת אש ו- NAT

ודא שחומת האש מוגדרת כך שתאפשר תנועה כמפורט במאמר הזמין ב מידע הפניה ליציאה עבור Webex Calling. בנוסף, אפשר גישה לת חומים ולטווחי IP המפורטים באותו מדריך והימנע מ- SIP ALG מכיוון שהוא מפריע לאיתות SIP. יש להימנע מת עבורת מדיה באמצעות פרוקסי.
DNS ו- NTP

ודא רזולוציית DNS נכונה של דומיינים ושרתי NTP אמינים כדי לסנכרן שעוני מכשירים לאימות ורישום אישור TLS.
תכנון גיבוי כשל

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

שרידות האתר מבטיחה שהעסק שלך יהיה נגיש תמיד, גם אם חיבור הרשת שלך נשבר. Site Survibility משתמשת בשער ברשת המקומית שלך כדי לספק שירות שיחות חזרה לנ קודות קצה באתר במצבים שבהם חיבור הרשת נשבר. שקול את שרידות האתר באמצעות שער שרידות מקומי (SGW) אם דרישות עסקיות דורשות שיחה רציפה במקרה של הפסקת רשת. ל מידע נוסף על בדיקת שרידות האתר, ראה שרידות האתר עבור. Webex Calling

הגדרת UC המחובר לענן

Cloud Connected UC (CCUC) הוא פתרון ניהול וניתוח מבוסס ענן שנועד לספק נראות, ניהול ותובנות מרכזיות לפריסות מקומיות (כגון) ובענן (Unified CM). הוא משמש כגשר בין סביבות מקומיות מסורתיות לבין שירותי הענן של סיסקו, ותומך בארגונים לאורך מסע ההעברה מ- אל.

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

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

הערכת הסביבה הנוכחית

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

חשוב לבחון את ההיבטים הבאים כחלק מהמאמץ הזה.

רישוי

הבנת מבנה הרישוי הנוכחי של הפריסה הקיימת היא המפתח בעת ההכנה להעברה אל. בצע הערכת רישיון של האזורים הבאים ב פתרון המקומי הקיים של Cisco.

פלטפורמה

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

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

אם Cisco Unified Border Element (CUBE) נדרש לגישה PSTN למע בר זה, יש לשקול גם רישוי CUBE. שיקולי רישוי CUBE מכוסים בהמשך מסמך זה.

מיקומות/אתרים

יש לקחת בחשבון את מספר וסוגי האתרים (מרכזי גדול, אזורי, סניף וכן הלאה) בפ ריסה הקיימת שלך בעת תכנון המעבר הזה. הבנה מלאה של אתרי הפריסה הקיימים תסייע בתכנון אסטרטגי למע בר מוצלח במיוחד כשמדובר בקביעת אילו אתרים להעביר ובאיזה סדר. הבנה מפורטת של דרישות תוכנית חיוג (מספור, הרגלי חיוג, סוגי הגבלה וכן הלאה), קישוריות רשת האתר ורוחב הפס (אינטרנט, WAN, LAN) וגישה ל- PSTN (מקומית או מרכזית, IP או TDM) עבור כל אתר תהיה קריטית בעת קבלת החלטות הגירה. לקבלת מידע נוסף על מודלים נפוצים של פריסה ושיקולים מרכזיים, עיין במידע על מודלים של פריסת שיתוף פעולה הזמין ב- SRND של שיתוף פעולה.

שיקול פריסה חשוב נוסף בעת המעבר אליו הוא זמינות המיקום. יש יכולות, מנויים והתקנים שונים הזמינים בהתאם למיקום הפריסה שלך. לקבלת מידע נוסף על זמינות גיאוגרפית, ראה היכן Webex זמין? .

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

מלאי התקנים/לקוחות קיימים

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

טלפונים שולחניים

לטלפונים שולחניים אודיו ווידאו נתמכים רק בטלפונים השולחניים מסדרת 6800, 7800, 8800 ו- 9800. זוהי תת-קבוצה של טלפוני ה- IP של סיסקו הנתמכים איתם. ישנם כמה דגמים וגרסאות של הטלפונים 6800, 7800 ו- 8800 שלא ניתן להשתמש בהם. לקבלת מידע נוסף על אילו דגמים וגרסאות חומרה נתמכות, ראה התקנים נתמכים עבור Webex Calling.

לא ניתן לשדרג את טלפוני ה- IP מסדרת Cisco 6800 מקושחה ארגונית לקושחה מרו בת פלטפורמות (MPP), הנדרשת עבור. לכן כל 6800 טלפונים הרשומים לקושחה ארגונית פועלת חייבים להיות מוחלפים בדגם 6800 MPP או בדגם טלפון נתמך אחר.

יש לשדרג את טלפוני ה- IP מסדרת Cisco 7800 ו- 8800 לקושחת טלפון רב-פלטפורמה (MPP) לפני המעבר ורישוםם. כדי לקבוע אילו דגמים וגרסאות חומרה של 7800 ו- 8800 תומכים בקושחת MPP, ראה המרת טלפונים IP מסדרת Cisco 7800 ו- 8800 בין קושחת ארגונית ו- MPP.

8845, 8865 ו- 8865NR הגיעו לסוף המכירה ולא מומלץ להעביר אליהם.

גרסאות ישנות יותר של הטלפונים מסדרת 8800 (8811, 8841, 8851, 8851NR, 8861) אינן מומלצות לשימוש. Webex Calling טלפונים עם גרסאות חומרה VID 14 ומעלה יירשמו אך עשויים להיתקל בבעיות ביצועים מסוימות עקב החומרה.

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

יהיה צורך להחליף את כל טלפוני ה- IP האחרים בטלפונים מסדרת 6800, 7800, 8800 או 9800 הנתמכים על ידי. Webex Calling לקבלת מידע נוסף על מכשירי IP וטלפונים שולח ניים נתמכים עם, עיין במאמר ב התקנים נתמכים עבור Webex Calling.

נקודות קצה של וידאו

נקודות קצה של וידאו אישיות וחדרים, כולל סדרת Cisco Board, סדרת Room ו סדרת Desk, יכולות להירשם ל- SIP באופן מקורי. כל אחת מנקודות הקצה האלה שצריכות לבצע שיחות שמע ו/או PSTN דורשת רישיון שיחה:

התקנים משותפים בחדרי ישיבות, חללי הצטופפות וכו' דורשים רישיון Professional Workspace או Workspace.

המכשיר האישי של משתמש קצה דורש רישיון מקצועי או סטנדרטי.

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

כאשר התקני וידאו מועברים מרישום אל, ה- URI של נקודות קצה אלה ישתנה מכיוון שהם רשומים כעת בענן.

דגמי הטלפון 8845, 8865 ו- 8875 הם טלפונים וידאו אישיים הנתמכים עם.

לקוחות רכים

זהו הלקוח הרך היחיד הנתמך על ידי, בניגוד לתומך Unified CM הן באפליקציית Webex והן ב- Jabber, והוא הלקוח הרך החדש המוגדר כ ברירת מחדל עבור משתמשי קצה.

בהתאם למצבי הפריסה המיושמים עבור Jabber (מצבי IM בלבד, טלפון בלבד ו/או UC מלאים), ייתכן שיהיה עליך לשקול גם את המעבר של עומסי העבודה של הודעות ו/או פגישות מ- Jabber ל-. ניתן לפרוס אותו במצב טלפון בלבד אם הוא ישמש כלקוח מתקשר בלבד או שניתן לפרוס אותו כ מלא Webex Suite אם עומסי עבודה אחרים, למשל. Webex Messagingו/אוWebex Meetings, עוברים לאפליקציה עם שיחות.

זה משפר את חוויית משתמש הקצה על ידי מתן תכונות AI כמו מודיעין אודיו/וידאו, תמלול שיחות ואחרים. לקבלת מידע נוסף, ראה https://www.webex.com/all-new-webex.

לפני העברת משתמשים אל תצטרכו להעביר את לקוחות Jabber שלהם ל-. יש לך שתי אפשרויות להשלמת המעבר הזה.

לפני שתעביר אותם ל

כאשר אתה מעביר אותם ל.

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

למידע נוסף, אודות שתי האפשרויות הללו ראה מסע הגירה - שלב אחד או שניים? .

לקבלת רשימה מלאה של ההתקנים הנתמכים עבור, ראה התקנים נתמכים עבור Webex Calling.

בדוק את זכאות המכשיר

כאמור, תומך בתת-קבוצה של טלפוני ה- IP של סיסקו ודורש סוג קושחה שונה עבור הטלפונים מסדרת 7800 ו- 8800. Unified CMטלפונים מפעילים את הקושחה הארגונית ואילו טלפונים מפעילים את הקושחה של טלפון רב פלטפורמה (MPP). מומלץ לוודא אילו טלפונים רשומים זכאים לשדרג לקושחת MPP במהלך שלב ההכנה. זה נותן לך זמן להחליף טלפונים שאינם מתאימים באחד מדגמי הטלפון הנתמכים או לזהות תוכנית חלופית, כמו העברת משתמש לאפליקציית Webex בלבד.

כדי לסייע בקביעת הזכאות של הטלפונים, לרכזת Control יש כלי מובנה בשם Migrate Your Phone to Webex Calling. בעת שימוש בכלי זה לבדיקת זכאות המכשיר, בחר באפשרות העברה צור רישיון מכשיר בלבד.

אפשרות הכלי Control Hub לאימות זכאות הט Unified CM לפונים ל Webex Calling

אפשרות זו מאפשרת לך להעלות קובץ CSV המכיל את הטלפונים כדי שתוכל לבדוק את הזכאות של כל טלפון. על ידי בחירת אפשרות העברה זו, היא לא מוסיפה את הטלפונים מכיוון שאתה עדיין בשלב ההכנה ועדיין לא מוכן לעשות זאת. לקבלת מידע נוסף, ראה העברת הטלפון אל Webex Calling.

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

בדוק ידנית כל טלפון וודא את הדגם ואת גרסת החומרה (PID VID)

תווית טלפון 7800/8800 עם מידע על דגם וגרסת חומרה

השתמש בכלי המוכנות לטלפון IP של סיסקו

הורד את הכלי מ - https://github.com/joemar2/mpp_readiness_check.

כלי זה אינו כלי רשמי של סיסקו וגם אינו נתמך ב- TAC. יש לו תמיכה במאמץ הטוב ביותר אך הוא חופשי לשימוש.

יש להפעיל את הכלי הזה במחשב מקומי ויכול לגשת לשרתים ולטלפוני ה- IP. יש לו אפשרות לאפשר גישה לאינטרנט בטלפוני ה- IP, המומלצת ונחוצה כדי להשיג את התוצאות הטובות ביותר. לכן, יש להשתמש בו בשעות החופש כדי למנוע הפרעה למשתמשי הקצה. הפלט של הכלי מספק דוח המפרט אילו מהטלפונים מסדרת 7800 ו- 8800 זכאים לשדרג לקושחת MPP. מכיוון שהוא ני גש ישירות לטלפון הוא יכול לאמת את המכשירים הלא ידו עים שדווח ו מכלי Control Hub.

דוח כלי מוכנות לטלפון IP של סיסקו

משתמשים

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

פריסת עם שיחות

פריסת ה- with

קביעת תצורה של שירותים עבור משתמש

כדי להפוך את המשתמשים לחיפוש בספרייה (לחץ כדי להתקשר, פרטי קשר למשתמש, חיפוש בספריית טלפונים).

מומלץ לספק את כל המשתמשים לפני או בתחילת הפרויקט שלך. זה כולל משתמשים שעדיין משתמשים Unified CM בפלטפורמת השיחות שלהם אינה תלויה במכשיר השיחה שלהם (טלפון IP, Jabber,). כאשר משתמשים מועברים אל (ו/או ל), תעדכן את הרישיונות שלהם כדי לאפשר את השירותים הדרושים להם. על-ידי הקצאת כל המשתמשים המתקשרים בארגון לפני תחילת המעבר, היא מאפשרת למשתמש שעבר אל או לחפש בספרייה משתמש מתקשר ארגוני שעדיין נמצא ב- Jabber ו/או מופעל. זה מבטיח שמשתמשים שעברו מעבר יוכלו למצוא את פרטי הקשר של כל משתמש אחר ול התקשר אליהם באמצעות חיפוש הספריות.

חיפוש ספ ריית הדמויות מציג דוגמה למשתמש שמחפש משתמש אחר. תוצאות החיפוש מציגות את פרטי הקשר של המשתמש וי כולות להיות עבור משתמש שעדיין נמצא ב- Jabber או עבור משתמש שעבר ל- ו/או.

חיפוש ספריית אפליקציות Webex

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

לדוגמה, אם המשתמשים בפריסה מחולקים לשלושה אתרים עיקריים, ניו יורק (ניו יורק), סן פרנסיסקו (SFC) ו-Research Triangle Park (RTP), תוכנית מעבר משתמשים עשויה להיראות כמו התוכנית המתוארת ב תוכנית מעבר משתמשים לפי טבלת אתר.
טבלה 4. תוכנית מעבר משתמשים לפי אתר
אתר משתמש/מיקום מידע טרום המעבר והדרכות תקופת מעבר תמיכה לאחר המעבר
ניו יורק (1,525 משתמשים) שבוע של אפריל 1 אפריל 15 - אפריל 27 שבוע של 29 באפריל
SFO (1,600 משתמשים) שבוע של 6 במאי 20 במאי - 31 במאי שבוע של 3 ביוני
RTP (1,275 משתמשים) שבוע של 3 ביוני 17 ביוני - 28 ביוני שבוע של יולי 1

גורם חשוב נוסף הוא העברת משתמשים יחד שיש להם תלות זה בזה . זה יכול לכלול, בין היתר, את הדברים הבאים:

ניטור BLF

אותו טייס/קבוצה של ציד

שתף שורות

חלק מאותה קבוצת איסוף שיחות

שימוש באותם מספרי חניון שיחות

אינטרקום

מנהל/מנהל

באפשרותך לעיין בתצורה (ממשק משתמש או ייצוא) או להשתמש בכלי Migration Insights כדי לסייע בזיהוי קבוצות המשתמשים עם ת לות אלה.

טבלה 4. תוכנית מעבר משתמשים לפי אתר
אתר משתמש/מיקום	מידע טרום המעבר והדרכות	תקופת מעבר	תמיכה לאחר המעבר
ניו יורק (1,525 משתמשים)	שבוע של אפריל 1	אפריל 15 - אפריל 27	שבוע של 29 באפריל
SFO (1,600 משתמשים)	שבוע של 6 במאי	20 במאי - 31 במאי	שבוע של 3 ביוני
RTP (1,275 משתמשים)	שבוע של 3 ביוני	17 ביוני - 28 ביוני	שבוע של יולי 1

קישוריות PSTN

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

PSTN מקומי עם שער מקומי (LGW) הוא מרכיב חיוני באסטרטגיית המעבר. הוא מספק קישוריות בין הפריסה המקומית ו/או PSTN לפלטפורמה. תומך הן בסיסקו והן בבקרי גבול הפעלה של צד שלישי (SBC) שיכולים לשמש כשער מקומי. לקבלת הרשימה העדכנית ביותר של SBC נתמכים, ראה רשימת SBC נתמכים.

תומך בעד 250 שיחות במקביל משער מקומי יחיד המבוסס על רישום וביותר מ-250 שיחות במקביל משער מקומי יחיד המבוסס על אישורים. שערים מקומיים מבוססי אישורים יכולים לתמוך בעד 6500 שיחות במקביל, אך הדבר מבוסס על סוג הקישוריות שיש לשער המקומי (Over-the-Top לעומת צילומי חיבור) ודגם ה- SBC שעליו פרוס השער המקומי. מגבלות אלה הן במהותה מגבלת ספירת ברירת המחדל הן עבור שיחות PSTN מקומיות מבוססות שער והן לשיחות בין אתרים בין נקודות קצה. לקבלת מידע נוסף, ראה התחלת העבודה עם השער המקומי.

כל שיחות החורגות ממגבלה זו נדחות עם 403 אסור. ניתן להפעיל את הפקודה הקולית הפעילה של הצג שיחה בשער המקומי בכל מופע כדי לקבוע את המספר הכולל של שיחות פעילות.

תנאי רשת ירודים בין שער מקומי לגישה SBC יכולים להגביל את ביצועי חיבור האיתות, מה שמוביל למגבלת שיחות במקביל נמוכה עוד יותר. חביון חד כיווני בין השער המקומי למרכז הנתונים לא יעלה על 100 אלפיות השנייה והריצוד צריך להיות פחות מ -10 אלפיות השנייה ואילו אובדן המ נות הוא פחות מ -0.5%.

תכונות ושימוש בתכונות

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

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

סקור את התצורה בממשק המשתמש של מנהל המערכת

ייצוא תצורה - ייצוא בכמות גדולה או AXL

כלי תובנות הגירה (מומלץ)

כלי שותפים של צד שלישי של סיסקו (מומלץ).

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

סקירה של רשומות CDR גולמיות

סקירת Unified CM נתוני RTMT

כלי תובנות הגירה באמצעות נתוני CDR

סקירה של ניתוח UC המחובר לענן ב

עוצמת השיחה

נקודות קצה רשומות

(CAC) מיקומים

ניצול תא המטען.

כלי שותפים של צד שלישי של סיסקו.

סיסקו ממליצה להתחיל עם הכלי 'תובנות ההעברה' של Webex Control Hub לצורך ניתוח זה. תוכל לייבא את קובץ הייצוא שלך. TAR ואת קבצי Unified CM CDR (אופציונלי, אך נדרש לניתוח ניצו ל תכונות) לכלי. הכלי יפיק את הדוחות הבאים מבוססי CSV שניתן להשתמש בהם כדי להתחיל את הניתוח:

טבלה 5. דוחות שנוצרו מקוב Unified CM ץ.tar
שם הדוח
תיאור דוח
ImportedDataBulk.csv
כל המשתמשים והמכשירים מנ Unified CM תונים
DeviceEligibility.csv
מזהה מכשירים הזכאים להעברה Webex Calling אליהם (טלפונים IP, התקני מערכת הפעלה בחדר, ATAs וצד שלישי)
DevicePoolNumbers.txt
רשימת כל המספרים במא גר מכשירים מסוים
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
פרטים על מכשירים ומשתמשים שיש להעביר יחד בהתבסס על קווים משותפים, פיילוט ציד, תור שיחות, חניית שיחות ותצורת קבוצת איסוף שיחות
HuntGroupMigrationInsight.csv
מידע מפורט על קווי ציד שהוקצו, קבוצות קווים וסוכנים משויכים
SharedlineGroupMigrationReport.csv
סקירה כללית של האופן שבו מספרי טלפון (מספרי ספריות) משותפים בין משתמשים

טבלה 6. דוחות שנוצרו מקב Unified CM צי.tar ו- CDR gzip
שם הדוח
תיאור דוח
FeatureUsageBasedDeviceEligibilityReport.csv
מידע על זכא ות להעברת מכשירים בהתבסס על השימוש בתכונה
FeatureUsageWithLastUsageDateReport.csv
ספירת שימוש למספר הפעמים שהתקשרו טייסי ציד ותור שיחות יחד עם תאריך השימוש האחרון
UserWorkspaceLastUsage.csv
תאריך שימוש אחרון עבור משתמשים וסביבות עבודה עבור לקוחות רכים וטלפונים קשיחים כאחד
DIDUsageReport.csv
שימוש DID הן עבור DID שהוקצו והן לא מוקצים

לקבלת פרטים נוספים אודות דוחות תובנות ההעברה, ראה תובנות העברה.

אם אתה זקוק למידע נוסף אודות התכונות והשימוש לאחר סקירת המידע בדוחות Migration Insights, Cisco ממליצה לשקול את אחד מכלי ההעברה של שותפי צד שלישי של Cisco ו/או לבדוק את הת צורות ב- GUI או בנתוני הייצוא של התצורה.

טבלה 5. דוחות שנוצרו מקוב Unified CM ץ.tar
שם הדוח תיאור דוח
ImportedDataBulk.csv כל המשתמשים והמכשירים מנ Unified CM תונים
DeviceEligibility.csv מזהה מכשירים הזכאים להעברה Webex Calling אליהם (טלפונים IP, התקני מערכת הפעלה בחדר, ATAs וצד שלישי)
DevicePoolNumbers.txt רשימת כל המספרים במא גר מכשירים מסוים
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv פרטים על מכשירים ומשתמשים שיש להעביר יחד בהתבסס על קווים משותפים, פיילוט ציד, תור שיחות, חניית שיחות ותצורת קבוצת איסוף שיחות
HuntGroupMigrationInsight.csv מידע מפורט על קווי ציד שהוקצו, קבוצות קווים וסוכנים משויכים
SharedlineGroupMigrationReport.csv סקירה כללית של האופן שבו מספרי טלפון (מספרי ספריות) משותפים בין משתמשים

טבלה 6. דוחות שנוצרו מקב Unified CM צי.tar ו- CDR gzip
שם הדוח תיאור דוח
FeatureUsageBasedDeviceEligibilityReport.csv מידע על זכא ות להעברת מכשירים בהתבסס על השימוש בתכונה
FeatureUsageWithLastUsageDateReport.csv ספירת שימוש למספר הפעמים שהתקשרו טייסי ציד ותור שיחות יחד עם תאריך השימוש האחרון
UserWorkspaceLastUsage.csv תאריך שימוש אחרון עבור משתמשים וסביבות עבודה עבור לקוחות רכים וטלפונים קשיחים כאחד
DIDUsageReport.csv שימוש DID הן עבור DID שהוקצו והן לא מוקצים

שילובים של סיסקו: חיבור יוניטי UCCX UCCE

דואר קולי הוא חלק בלתי נפרד מההצעה ומובנה באופן מקורי בפתרון. אינו יכול להשתלב עם פתרון דואר קולי מבוסס מקום כגון Unity Connection או Unity Connection Express. יתר על כן, אין דרך מקורית להעביר הודעות דואר קולי או ברכות קיי מות לחיבור Unity לשירות הדואר הקולי המקורי הזמין עם. לחלק מכלי ההעברה של שותף צד שלישי של סיסקו יש יכולות להעביר חלק מהנתונים הללו. לקבלת מידע נוסף על דואר קולי עבור, ראה קביעת תצורה וניהול של הגדרות דואר קולי עבור משתמש. Webex Calling

תומך גם בתיבות דואר קולי ופקס משותפות. לקבלת מידע נוסף, ראה ניהול דואר קולי משותף ותיבת פקס נכנסת עבור. Webex Calling

יש תכונה מובנית של שיחה אוטומטית הכלולה כחלק מפלטפורמת הליבה. תכונה זו מאפשרת מעבר של מטפלי השיחות של חיבור Unity שלך ופונקציונליות מלווה אוטומטית. הכלי רכזת הבקרה, הע בר תכונות מ-Unified CM, תומך ב העברת תצורות חיבור Unity למשיבים אוטומטיים. לקבלת מידע נוסף אודות השימוש בכלי זה, ראה העברת התקנים ות כונות מ- Unified CM אלWebex Calling.

הקלטת שיחות

כולל שתי אפשרויות להקלטת שיחות ללא עלות נוספת.

הקלטת שיחות Webex

הקלטת Dubber Go (הצעת שותפים) - שילוב בין דובר שבו כל המדיה המוקלטת נשמרת בצורה מאובטחת בענן.

טבלת אפשרויות ההקלטה הכל ולה מדגישה כמה תכונות עיקריות של שתי אפשרויות הק לטת השיחות הזמינות ללא עלות נוספת.

טבלה 7. אפשרויות הקלטה כלולות
Webex דאבר גו

זמין לכל המשתמשים זמין לכל המשתמשים

הקלטות ללא הגבלה הקלטות ללא הגבלה

תקופת שמירה של שנה* תקופת שמירה של 30 יום

אחסון בנפח של 100 ג'יגה-בתים לכל ארגון -

קציני ציות יכולים לגשת להקלטות שיחות ולנהל אותן -

ממשקי API לניהול הקלטות -

מנהלי מערכת יכולים להגדיר ולנהל את הגישה של המשתמשים להקלטות השיחות שלהם
משתמשים יכולים לנהל את ההקלטות שלהם באמצעות רכזת משתמשים ו/או אפליקציית Webex.
רק משתמשים יכולים לגשת ולנהל את ההקלטות שלהם
מפורטל הדובר שלהם.

אם הארגון שלך דורש יכולות הקלטה נוספות כגון הקלטת שיחות תאימות, תקופות שמירה ארוכות יותר, אחסון רב יותר, ניתוח AI ו/או גישה למנהל מערכת, קיימות הצעות בת שלום או תוספות הן של Cisco והן מספקי הקלטות של צדדים שלישיים. לקבלת מידע נוסף על ספקי הקלטה, תצורות ושירותי שותפים נוספים, ראה ניהול הק לטת שיחות עבור Webex Calling.

טבלה 7. אפשרויות הקלטה כלולות
Webex	דאבר גו
זמין לכל המשתמשים	זמין לכל המשתמשים
הקלטות ללא הגבלה	הקלטות ללא הגבלה
תקופת שמירה של שנה*	תקופת שמירה של 30 יום
אחסון בנפח של 100 ג'יגה-בתים לכל ארגון	-
קציני ציות יכולים לגשת להקלטות שיחות ולנהל אותן	-
ממשקי API לניהול הקלטות	-
מנהלי מערכת יכולים להגדיר ולנהל את הגישה של המשתמשים להקלטות השיחות שלהם משתמשים יכולים לנהל את ההקלטות שלהם באמצעות רכזת משתמשים ו/או אפליקציית Webex.	רק משתמשים יכולים לגשת ולנהל את ההקלטות שלהם מפורטל הדובר שלהם.

שילובים של צד שלישי

תומך במגוון שילובים של צד ^שלישי כולל אך לא רק SBCs עבור שערים מקומיים, טלפוני IP, טלפונים אינטרקום, רמקולים/זיגרים, ATA וכו'. בנוסף למכשירי צד שלישי ^אלה, Webex Calling תומך ב פתרונות שונים של ^צד שלישי לתמיכת לקוחות, ניתוח, הקלטה, חיוב וכו'. לקבלת מידע נוסף על פתרונות ^צד שלישי, ראה Webex App Hub.

תכנית

תוכנית פרויקט ברמה גבוהה

מסע הגירה - צעד אחד או שניים?

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

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

שלב 1

שלב 2

תוכנית פרויקט ברמה גבוהה

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

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

הגדרת היקף ההעברה (לדוגמה, אילו משתמשים, מכשירים ותכונות יע ברו)

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

תיאום הערכות מוכנות לרשת, ו

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

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

מסע הגירה - צעד אחד או שניים?

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

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

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

שירותי שיחות עברו מ-

מספרי טלפון ותוספים הועברו מ-

לקוח רך עבר מג'אבר ל- - יירשם ל

רישום הטלפון עבר מ-.

שירות השיחות של המשתמש, הלקוח הרך והטלפון עוברים בו זמנית

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

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

הגישה השנייה היא הגירה דו-שלבית. בשלב 1, משתמשים עוברים לשירותי השיחות אך נשארים פעילים. ואז בשלב 2, המשתמשים מועברים מ Unified CM -. אפשרות זו מומלצת ללקוחות גדולים יותר לניהול השינויים של משתמשי הקצה ורוצים לה פריד בין שינוי הלקוח הרך של המשתמש לבין השינוי בשירות השיחה. האיור הבא הע בר לקוח רך; ולאחר מכן העבר שירות שיחות, לקוח רך וטלפון Webex Calling למטה מדגיש סוג זה של העברה.

שלב 1

לקוח רך עבר מ- - יירשם ל.

שלב 2

שירותי שיחות עברו מ-.

מספרי טלפון ותוספים עברו מ-.

ההרשמה עברה מ-.

רישום הטלפון עבר מ-.

העבר לקוח רך; ואז העבר שירות שיחות, לקוח רך וטלפון אל Webex Calling

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

האפשרות שתבחר תלויה באופן שבו ברצונך לנהל את המעבר של המשתמשים שלך ל- and. ההמלצה היא לקחת את זה בשלבים (אפשרות 2). זה מאפשר לך למזער את השינויים של משתמש הקצה בבת אחת ולחלק את המאמץ לחלקים שונים של הפרויקט. עם זאת, אם אתה מעדיף שמשתמשים יושפעו רק פעם אחת, השימוש באפשרות 1 תקף גם הוא.

כאשר מסתכלים על המסע המומלץ (אפשרות 1), איור מפ ת המעבר ברמה גבוהה של Jabber ל-Webex App להלן מציג את המעבר ברמה גבוהה עבור שלב 1.

מפת מעבר ברמה גבוהה של ג'אבר לאפליקציית Webex

בשלב זה משתמשים עוברים מ- Jabber ל- עבור כל שירותי השיחות שלהם. עם זאת, פלטפורמת השיחות עדיין Unified CM והיא תרשום את שירותי השיחות שלה אליה. כפי שניתן לראות במ פת המעבר ברמה גבוהה של Jabber ל-Webex App, הת שתית המקומית אינה משתנה, והיא פועלת באותו אופן שבו Jabber עושה זאת. השינוי היחיד הוא הדורש חיבור אל.

לקבלת מידע נוסף אודות מעבר זה, ראה מדריך מפת מעבר ו פריסה של Jabber ל-Webex תחת הקטע לקוח בדף מעבר לשיתוף פעולה.

Unified CMלדמות Webex Calling מפת מעבר ברמה גבוהה הוא המעבר ברמה גבוהה מ- ל-. זהו שלב 2 של המסע המומלץ.

Unified CMלמ Webex Calling פת מעבר ברמה גבוהה

אם תחליט להשתמש בגישה של שלב יחיד, זה חל גם כן.

בשלב זה משתמשים עוברים לקבוצות. בשלב זה המשתמשים מתחילים להשתמש בשירותי השיחות שלהם, רישום שיחות ורישום טלפון IP.

מכיוון שמשתמשים עוברים בקבוצות, משתמשי Enterprise יפוצלו בין שתי פלטפורמות השיחות במהלך המעבר. שלב 1 באיור Unified CMמפ Webex Calling ת מעבר ברמה גבוהה מתאר מצב זה. בשלב זה נדרש תכנון כיצד לנהל שיחות בין משתמשים בשתי הפלטפורמות וכיצד ינותבו שיחות PSTN. בכל פעם שעוברת מעבר לקבוצת משתמשים, יידרשו תוכניות חיוג ועדכוני ניתוב שיחות בשער (ים) המקומיים.

לאחר שכל המשתמשים, הלקוחות הרכים והמכשירים הועברו אל (שלב 2), ניתן להסיר ולהשבית את כל תשתית ה- UC המקומית.

עיצוב

בחירת אזור

מיקומים

PSTN

תוכנית חיוג

תוכנית חיוג מקומית ב

תוכנית חיוג

הקלטה

1. בחירת ספק הקלטת שיחות

2. בחירת אזור

שיחת חירום

רישוי

הקצאה ידנית דרך

תבניות הקצאת רישיון אוטומטיות

הקצאה בכמות גדולה באמצעות תבנית CSV

הקצאה מבוססת API

דרישות רישיון

הקצאת משתמשים

קבוצות משתמשים

גישה מומלצת בעת מעבר מ-

עיצוב קבוצות משתמשים

כניסה יחידה (SSO)

תמיכה מרובה של IdP

1. מיזוגים ורכישות

2. מחלקות IT עצמאיות מרו בות

3. קבוצות משתמשים או דומיינים שונים

4. תמיכה בפרוטוקולי אימות שונים

5. אבטחה ותאימות משופרים

6. חווית משתמש פשוטה

שני MFA עם SSO עבור

תכונות

מלווה אוטומטי

התקשר לפארק

איסוף שיחות

תור שיחה

קבוצת האנט

מצבי הפעלה

קבוצת פיג'ינג

הקלטות

טווח הגעה למספר יחיד

קבוצת דואר קולי

בחירת אזור

זמין ברחבי העולם ומועבר ממרכזי נתונים מיותרים במספר אזורים: ארה"ב (דאלאס, שיקגו), קנדה (ונקובר, טורונטו), אירופה (פרנקפורט, אמסטרדם), בריטניה (לונדון, מנצ'סטר), אוסטרליה (מלבורן, סידני), יפן (טוקיו, אוסקה), ערב הסעודית (ריאד, ג' דה) והודו (מומבאי, צ'נאי). ה- POP המדיה מספקים שירותי מדיה כדי לייעל את זמני התקשורת הלו ך ושוב. מרכז הנתונים של סינגפור למשל משמש לייעל את זמני הנסיעה הלוך ושוב לתקשורת עבור לקוחות במדינות אסיה שבהן זמני הלוך ושוב לאזור אוסטרליה או יפן עשויים להיות לא אופטימליים. מרכזי הנתונים מחוברים זה לזה על ידי עמוד שדרה רב-ג'יגה-ביט ומ יותר לחלוטין. האיור של מרכזי נתונים המופצים ברחבי העולם מציג סקירה כללית של כל מרכזי הנתונים. לקבלת הרשימה העדכנית ביותר של מרכזי נתונים זמינים, ראה מי קומי מרכז נתונים עבור Webex Calling.

מרכזי נתונים מבוזרים ברחבי העולם

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

לקבלת זמינות במדינה, ראה היכן Webex זמין? .

מיקומים

כדי להתכונן להקצאת מיקומים יש לאסוף את המידע הנדרש עבור כל מיקומי יעד ההעברה. המידע הדרוש לכל מיקום מסוכם ב מידע ללכידה עבור כל מיקום.
טבלה 1. מידע ללכידה עבור כל מיקום
מידע הערה
טווח (ים) הרחבה לכל מיקום יכולים להיות הרחבות המתחילות בספרות שונות. יש לחסוך ספרה אחת לספרת ההיגוי החיוג הבין-אתרים (לדוגמה 8) וספרה אחת לספרת ההיגוי של PSTN (לדוגמה 9). שום טווח הרחבה לא יכול להתחיל עם אחת מש תי הספרות הללו.
כל טווחי ההרחבה של כל המיקומים חייבים להיות בא ורך שווה.
טווח (ים) DID -
ספרת היגוי PSTN -
קוד האתר כל קודי האתר של כל המיקומים צריכים להיות ייחודיים ובעלי אורך זהה.
מספר ראשי בעת יצירת מיקום יש לספק שני DIDs. אחד כמספר ראשי (לדוגמה שיוקצה לשירות מלווה אוטומטי) ואחד עבור פורטל הדואר הקולי.
הקצאת DID אחד למספר הדואר הקולי.
מספר דואר קולי
מספר הרישיונות רישיונות נדרשים לפי סוג כולל סטנדרטי, מקצועי, סביבת עבודה, רשימת מסלולים, תוכנית שיחות יוצאות.
שיחות במקביל בשעות העמוסות סכום השיחות במקביל בין התקנים ובין התקנים לשער המקומי (PSTN ושיחות למכשירים). נדרש כדי לקבוע את רוחב הפס הנדרש לגישה לאינטרנט.
ארץ -
אזור זמן -
שפה -
איש קשר (שם, טלפון, דוא"ל) -
כתובת (כתובת רחוב, עיר, מדינה, מיקוד) -
מיקום פיזי הניתן לשליחה של שירותי חירום לנקודות קצה מיקום הניתן למשלוח של המכשיר המשמש לשיחות חירום כולל בדרך כלל את הדברים הבאים: כתובת בניין, כתובת בנין+מספר קומה, כתובת בנין+מספר סוויטה, או כתובת בניין + מספר קומה + מספר משרד/קובי.
לכל מכשיר מיקום רשת פיזי ייחודי לשירותי חירום מיקום רשת פיזית לשיחות חירום כולל בדרך כלל את הדברים הבאים: מתג/יציאת מתג להתקנים קוויים, מזהי ערכת שירות בסיסיים (BSSID) של נקודת גישה אלחוטית (BSSID) עבור התקנים מחוברים אלחוטיים ו/או רשתות משנה IP מקומיות עבור התקני נקודת קצה.

PSTN

בעת תכנון פריסה, ללקוחות יש שלוש אפשרויות קישוריות PSTN עיקריות: תוכניות שיחות של Cisco (שירות PSTN המועבר בענן המנוהל על ידי Cisco), ספקי PSTN המחוברים לענן (CCPP, שבהם ספקים מספקים שירות PSTN דרך הענן) ו- PSTN מקומי (שבו שערים מקומיים מחברים את הרשת הארגונית ל- PSTN). עם הצגת גזע PSTN לפריסות היברידיות (למידע נוסף, ראה גזע PSTN עבור פריסות היברידיות ב- PSTN trunking), ארגונים Webex Calling מקבלים גמישות נוספת בגישת ה העברה שלהם. תכונה זו מאפשרת ללקוחות להעביר את ה- PSTN שלהם ל- CCPP בתחילת מסע המעבר ולהתחיל לעבור ל- PSTN בענן עבור משתמשים, תוך מינוף CCPP כדי לשמור על שירות PSTN עבור משתמשים שנשארים בסיסקו במהלך העברה בשלבים.

גישה היברידית זו מאפשרת לארגונים להעביר תחילה קבוצות משתמשים נבחרות לענן, מבלי לשנות באופן מיידי את כל סביבת הטלפוניה שלהם. עם זאת, הוא מציג מורכבות וסיכון נוספים, במיוחד סביב התאמת לוגי קת ניתוב שיחות קיימת לתמיכה בארכיטקטורה החדשה. יכולת פעולה הד דית עם יישומים מדור קודם, כגון שרתי פקס, מרכזי קשר או מערכות עימוד, דורשת גם שיקול זהיר. האתגרים הטכניים העיקריים עשויים לכלול הבטחת משא ומתן חלק מקצה לקצה על codec ואיתות DTMF (Dual-Tone Multi-Frequency) בסביבה המעורבת, כמו גם אימות תאימות עם תכונות טלפוניה מיוחדות. תכנון ובדיקה נכונים חיוניים כדי למזער את ההפרעות ולשמור על שירותי קול אמינים לאורך כל תהליך ההעברה. בנוסף, שיקולים מסחריים חשובים, שכן מטעף היברידי דורש רישיון שימוש המבוסס על מספר השיחות במקביל בין הסביבה המקומית לבין ספק ה - PSTN המחובר לענן (CCPP).

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

העברה ל- CCCP בהתחלה לעומת שמירה על PSTN מקומי

האיור מעבר ל- CCCP בהתחלה לעומת שמירה על PSTN מקומי מציג את שתי אפשרויות ההעברה של PSTN שהוס ברו לעיל. האיור משמאל מציג את התרחיש שבו כל המשתמשים והיישומים המקומיים צורכים שירותי PSTN המחוברים לענן באמצעות תא מטען מקומי ושער מקומי המחבר את המקומי אליו ואילו האיור בצד ימין מציג את התרחיש שבו ה- PSTN המקומי הקי ים נשאר במקומו ומשתמשים משתמשים משתמשים ב- PSTN מקומי דרך חיבור השער המקומי בין Webex Calling המק ומי ו. במהלך המעבר ניתן לעבור למיקומים באמצעות PSTN מחובר לענן.

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

תוכנית חיוג

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

תוכנית חיוג מקומית ב

במהלך המעבר כדי לאפשר דו קיום של מכשירים הר Unified CM שומים על ועל גבי תוכנית החיוג הארגונית יש לשנות כך שניתן יהיה לעמוד לפחות בדרישות הבאות:

+E.164 חיוג מ- אל

חיוג תוסף מ- אל (בתוך האתר אך גם בין אתרים אם טווחי ההרחבה ייחודיים)

חיוג בין אתרים מקוצר מ-

חיוג מאולץ ברשת מ- ל

התקשרות חוזרת מספריית שיחות שלא נענו ליעדים

שיחות PSTN מ- PSTN אם במהלך המעבר נעשה שימוש ב- PSTN מקומי עבור

שיחות PSTN מ- ל- if במהלך המעבר נעשה שימוש בחיתוך PSTN לפריסות היברידיות כדי לספק גישה ל- PSTN למשתמשים מקומיים באמצעות Cloud Connect עבור

מאולץ ברשת מ- ל

חיוג תוסף מ- (בין אתרים).

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

תוכנית החיוג של שיטות עבודה מומלצות של איור מציגה את גישת תוכנית החיוג המומלצת כמתו אר בא רכיטקטורה מועדפת עבור פריסות מקומיות ארגוניות של Cisco Collabor ation 12.x, CVD. המאפיינים העיקריים של גישה זו כוללים:

מחיצה יחידה עבור מספרי ספריות +E.164

ניתוב ליבה המבוסס על דפוסי מסלול +E.164

נורמליזציה של כל הרגלי החיוג ל- +E.164 באמצעות דפוסי תרגום

שימוש בתבנית תרגום הקוראת ירושת מרחב חיפוש (אפשרות השתמש במרחב החיפוש של המ קור המוגדר על דפוסי תרגום).

תוכנית חיוג לשיטות מומלצות

לדוגמה, חיוג PSTN (9+1+10D) ממכשיר ב- SJC המסופק עם מ רחב חיפוש שיחות קו SJCInternational יתאים תחילה לתבנית התרגום 9.1 [2-9] XX [2-9] XXXXXX שמנרמל את מספר הצד המתקשר ל- +E.164. לאחר מכן, החיפוש המשני משתמש שוב באותו מרחב חיפוש קריאה SJCInternational (קורא לי רושה של שטח חיפוש) והמחרוזת +E.164 ספרות תתאים למספר ספריית +E.164 במחיצת DN או לאחד מדפוסי המסלול של PSTN במחיצה USPSTNNational או SJCpStnLocal. הרגלי חיוג מקוצרים בתוך האתר ובין אתרים מיו שמים על ידי התרגומים במחיצת ESN ו- SJCTO E 164. בעוד מחיצת ESN היא מחיצה גלובלית (נגישה לטלפונים בכל המיקומים) מחיצת SJCTOE164 נגישה רק למשתמשים במיקום SJC. זה בהנחה של טווח י הרחבה חופפים.

הצעד הראשון לאפשר שיחות מ- אל הוא לוודא כי יעדי +E.164 מנותבים בהתאם. ניתן להשיג זאת על ידי הוספת מחיצה לתוכנית החיוג, הוספת דפוסי מסלול +E.164 עבור כל היעדים למחיצה זו, ולבסוף הוספת המחיצה לכל מרחבי החיפוש המתקשרים המייצגים מחלקות שירות שאליהן צריך להיות מסוגל להגיע. יצירת מחיצה ייעודית נדרשת כדי לאפשר יצירת סוג שירות מובחן לשיחות שמ קורן. כדי להימנע מלולאות שיחה, שטח החיפוש של השיחות הנכנסות בתא המטען מהשער המקומי לא א מורה להיות בעלת גישה למחיצה.

+E.164 ניתוב אל Webex Calling

כפי שמוצג באיור +E.164 ניתוב אלWebex Calling, כדי לאפשר ניתוב מ- אל למיקום עם טווח +E.164 DID +1 221 555 2XXX וקוד אתר 121, יש להוסיף למחיצה ד פוס מסלול דחוף התואם לטווח +E.164 זה.

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

כדי לאפשר חיוג מקוצר בין אתרים לאתר, תבנית המסלול הנדרשת 8121.2XXX מתווספת למחיצה. עבור אתרים שיועברו לדפוס נורמליזציה של חיוג 8121.2XXX שמנרמל את חיוג ESN ל-+E. 164, ייתכן שכבר קיימים במחיצת ESN. במקרה זה נראה כי 8121.2XXX מיותר, אך ברגע שכל ה- DNs של המיקום המתאים הועברו לדפוס התרגום לנורמליזציה של חיוג 8121.2XXX ניתן להסיר ואז תבנית המסלול 8121.2XXX מאפשרת חיוג ESN אפילו למשתמשים בהרחבה בלבד בטווח זה.

באמצעות שינויי תוכנית חיוג אלה ניתן לבצע שיחות למיקום לא רק על ידי חיוג מקוצר בין אתרים ו- +E.164. כמו כן, חיוג PSTN בינלאומי וללאומי אפשרי מכיוון שהרגלי חיוג אלה מנורמלים תחילה ל-+E.164 באמצעות דפוסי התרגום הקיימים לנורמליזציה של חיוג ולאחר מכן מנותבים אליו על ידי התאמת דפוס המסלול +E.164 במחיצה.

ניתן לספק את התאמת תבנית המסלול +E.164 בטווח ה- DID של המיקום בזמן שכל ה- DID עדיין מתארחים. אלגוריתם ההתאמה הטוב ביותר של דפוסי ההתאמה מוודא שכאשר מחויגים מספר המתארח בו, מספר הספרייה +E.164 המוגדר בו הוא התאמה טובה יותר מתבנית הנתיב +E.164 המוגדרת בתווים כלליים המצביעה עליה כך שהשיחות יורחבו לקו מופעל ולא נשלחו אליו.

תוכנית חיוג

לכל משתמש מסופק סיומת ו/או מספר טלפון +E.164. אורך ההרחבה הוא הגדרה גלובלית קבועה: לכל התוספים בפריסה יש אורך זהה. ניתן להשתמש בחיוג הרחבה בין משתמשים הן במיקום והן בין מיקומים. חיוג תוסף בין אתרים מקו צר (המקרה האחרון) פועל רק אם התוסף שחויג הוא ייחודי.

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

אורך התוסף, התנהגות החיוג בין מיקומים, אורך הקידומת לחיוג בין מיקומים וספרת ההיגוי בקידומת הניתוב לחיוג בין מיקומים מוגדרים בהגדרות שירות השיחות ב:

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

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

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

אפשר חיוג סיומת בין מיקומים: החלף כדי להפעיל/להשבית חיוג סיומות בין מיקומים. אפשרות זו צריכה להיות מופעלת רק אם כל התוספים בא רגון הם ייחודיים. אם האפשרות מושבתת, יש לחייג מספרים משמעותיים ארגוניים (קוד היגוי, קוד אתר, סיומת) או מספרי טלפון בין מי קומים.

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

דוגמה למס פור ארגוני בטבלה מצי גה דוגמה לשלושה מיקומים שבהם טווחי ה הרחבה של שני מיקומים, NYC ו- RTP, זהים. הקמת ערכת מס פור ארגונית עם ספרת היגוי בין אתרים 8, ואחריה קוד אתר בן שלוש ספרות, וההרחבה בת ארבע הספרות יוצרת הרגל חיוג בין אתרים מקוצר שאינו חופף.

טבלה 2. דוגמה למספור ארגוני
אתר טווח הרחבה קוד האתר טווח ארגוני

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

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

הטבלה טו וחי הארכה באורך קבוע מציגה דוגמה לשלושה מיקומים וטווחי הארכה בא ורך קבוע. מכיוון שיש להימנע מהרגלי חיוג חופפים, חשוב לוודא כי עבור כל טווח הרחבה הספרה הראשונה של הטווח אינה תואמת את ספרת ההיגוי לחיוג בין אתרים מקוצר. אם לדוגמה 8 נבחרה כספרת ההיגוי לחיוג בין אתרים, אזי אין טווח הרחבה באתר כלשהו יכול להתחיל ב- 8. בדרך כלל, התוספים במיקום נתון תואמים את הספרות האחרונות של ה- DID שהוקצו למיקום זה. כדי למנוע התנגשויות ניתן לשנות את הספרה הראשונה של התוסף. אם, לדוגמה, נעשה שימוש ב- DID בטווח +1 408 555 8XXX במיקום, במקום להשתמש ב- 8XXX כטווח הרחבה ניתן להשתמש ב- 7XXX עבור התוספים באתר זה

טבלה 3. טווחי הארכה באורך קבוע
אתר טווח הרחבה הרחבות קוד האתר טווח ארגוני

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

מחרוזות חיוג שבע ספרות שחייגו במכשיר באמצעות תוכנית החיוג האמריקאית חופפות לתבנית בת שבע ספרות לחיוג מקומי בתוכנית החיוג האמריקאית הטעונה מראש. כדי למנוע חפיפות בין הרגלי חיוג ברשת ומחוץ לרשת (PSTN), ניתן להשתמש בקוד גישה חיצוני חובה במיקום זה. אם סכימת המספור הארג ונית הקיימת והחיוג המקוצר המקביל בין אתרים חופפים לדפוסים בחיוגה הלאומית, אז במהלך המעבר לסכימת המספור כדי למנוע חפיפות ניתן לשנות גם לצורה ארוכה או קצרה יותר. הדרך הקלה ביותר להשיג זאת היא להוסיף ספרת ריפוד נוספת לסכימת המספור. סכימת החיוג החדשה הארוכה יותר בין אתרים צריכה להיות מאומצת רק על ידי משתמשים שכבר עברו אליה. משתמשים עדיין יכולים להמשיך לחייג שבע ספרות. תוכנית החיוג הארגונית המופעלת במקרה זה צריכה לוודא שהחיוג המקוצר בן שבע ספרות מ- ל- ל- י Unified CM הפוך ל-+E.164 או לפורמט החיוג המקוצר שנפרס עליו. זה צריך להיעשות לפני שליחת השיחה לשער המקומי.

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

טבלה 4. מעבר חיוג בן שבע ספרות

אתר הרחבות קוד האתר טווח ארגוני אודה לאתר אנטרפרייז

NYC 2XXX 22 8 22 2XXX 822 8 822 2XXX

SFO 8XXX 23 8 23 7XXX 823 8 823 7XXX

RTP 1XXX 24 8 24 11XX 824 8 824 11XX

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

הקלטה

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

1. בחירת ספק הקלטת שיחות

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

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

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

דרישות עסקיות: בחירת הספק צריכה להיות מונעת על ידי הערכה של גורמים עסקיים כגון ציות לתקנות (דוגמה - MiFID II, HIPAA), א בטחת איכות, יישוב סכסוכים או צרכי הכשרה

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

2. בחירת אזור

קביעת האזור שבו מאוחסנות ומעובדות הקלטות שיחות היא קריטית לתאימות ולביצועים:

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

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

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

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

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

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

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

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

תחזיות צמיחה: שקול צמיחה צפויה בהיקפי השיחות או הרחבת היקף ה הקלטה, שעשויה לנבוע מהגדלת קנה מידה עסקי, דרישות רגולטוריות חדשות או הצטרפות של משתמשים או מיקומים נוספים.

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

שיחת חירום

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

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

כל הלקוחות צריכים לפרוס, לכל הפחות, את תצורת שיחות החירום הבסיסית. שיחת חירום בסיסית דורשת להקצות לפחות מספר+E.164 אחד בבעלות לקוח לכל מיקום שהוגדר ב-. עבור שיחות חירום בסיסיות, כל מיקום יוגדר על ידי כתובת רחוב שאליה נשלחים שירותי משטרה, כיבוי אש או אמבולנס במקרה חירום. ברוב המקרים, המספר הראשי של המיקום הוא הבחירה הטובה ביותר לייצג את המיקום הפיזי של החירום. בדרך כלל, הקצאת הכתובת למספר +E.164 מתואמת עם ספק PSTN. התמונות שלהלן מציגות את הקצאת המספר הראשי שישמש כמספר השיחה לחירום למיקום ריצ'רדסון.

מיקום תצורת ECBN

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

תצורת ECBN של משתמש

עבור פריסות טלפוניה מבוססות ארה"ב שחייבות לספק פתרונות שיפור לשיחות חירום, משתמש ב- Horizon Mobility של RedSky המשולב בניתוב שיחות חירום. בעת שימוש ב- RedSky לניתוב שיחות, מנהל מערכת חייב להירשם לחשבון דרך סיסקו ולהגדיר את המידע המתאים ב הגדרות שיחה -> שירות כדי להפעיל תכונה זו. לאחר הפעלת שירות RedSky ברמת המערכת, מנהל מערכת יאפשר את שירות RedSky בכל רמת מיקום. הפעלת שיחות חירום משופרות במיקום תפעיל את השירות עבור כל המכשירים שהוקצו למיקום זה. התקנים התומכים בשיחות חירום משופרות הם טלפונים MPP של סיסקו, טלפונים של Cisco PhoneOS ושל סיסקו.

ישנן שתי הגדרות להפעלת שיחות חירום משופרות במיקום. יש להשתמש באפש רות אפשר ל- RedSky לקבל מידע על קישוריות רשת ושיחות בדיקה כדי לוודא שתצורת RedSky עבור מיפוי התקנים ותשתיות נכונה. הגדרה זו מאפשרת גם לבצע שיחות בדיקה ל- 933 כדי לבצע אימות מיקום באמצעות מערכת IVR של RedSky כדי לקרוא את מיקום המתקשר. למרות שמסמך זה לא יכסה את תצורת RedSky למעקב אחר מיקום, מנהל מערכת צריך לבדוק תמיד את גילוי המיקום שלו לפני הפעלת שיחות חירום לנתיב ל- RedSky. לאחר השלמת הבדיקה ואומת כמדויקת, מנהל המערכת ינתב שיחות ל- RedSky על ידי החלפת שיחות החירום במסלול ל- RedSky. מתג זה יפנה את כל שיחות החירום למיקום ל- RedSky למ סירה למרכז המשיבון עבור המיקום.

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

רישוי

ישנן מספר אפשרויות להקצאת רישיונות למשתמשים.

הקצאה ידנית דרך

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

מנהלי מערכת יכולים לערוך רישיונות שירות עבור משתמשים בודדים ולהקצות רישיונות שיחות ישירות.

תבניות הקצאת רישיונות אוטומטיות

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

ניתן לבצע רישוי אוטומטי באמצעות סנכרון ספריות או עדכונים ידניים למשתמש, אך ל משתמשים חייב להיות מספר טלפון תקף בפורמט +E.164 ומספרי הטלפון חייבים להתקיים במי קום לפני הקצאת המשתמש. אם התנאים אינם מתקיימים (למשל פורמט מספר טלפון לא חוקי), רישיונות לא יוקצו.

הקצאה בכמות גדולה באמצעות תבנית CSV

העלה קובץ CSV עם פרטי משתמש והקצאות רישיון כדי להוסיף או לשנות מספר משתמשים בו זמנית.

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

הקצאה מבוססת API

השתמש בממשקי API כדי להקצות רישיונות ולנהל משתמשים באופן תכנותי.

תומך בפעולות API לניהול משתמשים ורישיונות (אנשים, SCIM 2.0 ו- API של רישיונות), שניתן למנף לאוטומציה של הקצאת רישיונות. ממשק ה- API של הרישיונות מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ותוספים.
טבלה 5. אפשרויות הקצאת משתמשים - סיכום
שיטת הקצאה יתרונות חסרונות
דרך ידנית פשוט למעט משתמשים.
מאפשר שליטה מדויקת ומפורטת על הקצ את רישיון.
לא ניתן להרחבה, גוזל זמן
נוטה לטעות אנושית במהלך כניסה ידנית.

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

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

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

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

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

לקבלת מידע נוסף, ראה הגדרת הקצאות רי שיונות אוטומטיות ב- Control Hub והגד רת תבניות הקצאת רישיונות אוטומטיות ל Webex Calling משתמשים.

דרישות רישיון

סעיף זה מכסה רק רישיונות קשורים. סוגי רישיונות אחרים (דוגמה - רישום מכשיר Webex, העברת הודעות, פ גישות) אינם מכוסים. כחלק מתהליך התכנון יש לקבוע את דרישות הרי שיון. יש לחשב את ספירת הרישיונות עבור סוגי הרישיונות הבאים:

סטנדרטי: מספר משתמשים בודדים הדורשים תכונות טלפוניה סטנדרטיות.

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

סביבת עבודה לאזור משות ף: מספר מיקומי שימוש משותף או אזורים משותפים הדורשים יכולות שיחות סטנדרטיות.

סיוע ללקוח: מספר הסוכנים והמפקחים הזקוקים לתכונות סיוע ללקוח. הסיוע ללקוח כולל את הרישיון המקצועי.

שיחות רשימת מסלולים: מספר שיחות PSTN המחוברות לענן הנדרשות בין משתמשים מקומיים ו/או יישומי צד שלישי מיוחדים מקומיים.

מסוף מלווה: מספר המשתמשים הזקוקים לגישה ללקוח המסוף הנלווה.

תוכנית שיחות של סיסקו (תוכנית שיחות יוצאות): מספר המשתמשים הזקוקים למספר PSTN ו/או גישה לשיחות PSTN יוצאות עבור שירות PSTN של Cisco.

אין סוג רישיון ייעודי עבור סביבות עבודה מקצועיות. סביבות עבודה מקצועיות צורכות רישיון מקצועי.

סביבות עבודה מסוג Hotdesk בלבד מציעות שירות מארח הדלפק חם ושיחות חירום ממארח הדלפק חם ו אינן דורשות רישיון כלשהו. לקבלת מידע נוסף, ראה הוספ ה וניהול של התקני Hot Desk בלבד.

כדי לקבוע את סוג הרישיון הנדרש עבור כל משתמש וסביבת עבודה בהתבסס על התכונות הדרושות, ראה תכונות זמינות לפי סוג רישיון עבור Webex Calling.

כדי להבדיל בין הפונקציונליות המוצעת על ידי תורי שיחות בשילוב עם הרישיון המקצועי בניגוד לסיוע ללקוח, ראה תור Webex Calling שיחות והשוואת תכונות סיוע ללקוח.

הקצאת משתמשים

בעת הקצאת משתמשים ב- Webex, קיימות מספר אפשרויות זמינות, שכל אחת מהן מתאימה לצרכים ול סביבות ארגוניות שונות:

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

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

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

אפליקציית אשף Entra ID (Azure AD): שיטה זו מיועדת לארגונים המשתמשים ב- Microsoft Entra ID (Azure AD), ומספקת סנכרון אוטומטי כמעט בזמן אמת של חשבונות משתמש ותכונות ישירות מ- Entra ID אל. הוא מנוהל באופן מלא בפנים ודורש התקנה מינימלית.

יישומי SCIM 2.0: עבור סביבות שאינן של Microsoft או ספקי זהות אחרים כמו Okta או Duo, אפליקציות סנכרון מבוססות SCIM מאפשרות הקצאה אוטומטית של משתמשים וביטול הקצאה באמצעות מיפוי תכונות וסנכרון קבו צתי.

Unified CMסנכרון משתמש: אפשרות זו מאפשרת ליצור חשבונות משתמש המבוססים על משתמשי קצה קיימים על ידי סנכרון מ- אל. פעולה זו מחייבת הפעלה של UC מחובר לענן (CCUC) באשכולות המקומיים. עם זאת, בדרך כלל מומלץ לסנכרן משתמשים מספריית ענן מרכזית כמו Entra ID ולא ישירות מ.

הקצאת API: ניתן להשתמש בממשקי API ציבוריים (אנשים, SCIM 2.0) כדי לספק משתמשים. היתרון העיקרי בשימוש בממשקי API הוא האפשרות לשלב את הקצאת המשתמש במערכות ארגוניות אחרות.
טבלה 6. אפשרויות הקצאת משתמשים עבור
שיטת הקצאה תיאור יתרונות חסרונות
ידני יצירה/ניהול משתמשים בנפרד ב פשוט למעט משתמשים; אין צורך בתשתית לא ניתן להרחבה; גוזל זמן עבור משתמשים רבים
בכמות גדולה (קובץ CSV) ייבוא/עדכן משתמשים בכמות גדולה באמצעות CSV ב יעיל לקבוצות; אין צורך בקידוד הכנה ידנית ל- CSV; פחות דינמי
ממשק API של אנשים ו- SCIM 2.0 ניהול משתמשים תכנותי באמצעות ממשקי API של Webex גמיש; תומך באוטומציה ואינטגרציה דורש פיתוח ותשתיות
סנכרון ספריות סנכרון אוטומטי מ- AD, Entra ID, אפליקציות SCIM, Unified CM אוטומציה של מחזור חיים; תומך בסינון ומיפוי מורכבות התקנה: לחלק מהאפשרויות יש תכונות מוגבלות או דורשות ת שתית
סקירה כללית וטבלה אלה משקפים את אפשרויות הקצאת המשתמשים העיקריות, היתרונות והמגבלות שלהן כדי לעזור לך לבחור את הגישה הטובה ביותר לצרכי הארגון שלך.

קבוצות משתמשים

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

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

ניהול פשוט: ניהול רישיונות, הגדרות ומד יניות עבור מספר משתמשים בו זמנית.

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

מדרגיות: תומך עד 250,000 חברים לקבוצה.

אינטגר ציה: סנכרן קבוצות מ- Microsoft Entra ID (Azure AD) או Active Directory לניהול משתמשים וקבוצות אוטומטי.

גמישות: צור קבוצות מקומיות או סנכרן קבוצות אבטחה; נהל חברות בקבוצה באופן ידני או באמצעות קבצי CSV.

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

מקרי השימוש העיקריים עבור קבוצות משתמשים בעת הקצאה הם:

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

תבניות הגדרות: החל אוספים של הגדרות שירות (למשל, העברת הודעות, פגישה, שיחות) על קבוצות לחוויית משתמש עקבית.

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

אוטומציה ואינטגר ציה: השתמש בממשקי API או בסנכרון ספריות לניהול מחזור חיים אוטומטי של משתמשים וקבוצות.

הטבלה הבאה מסכמת את האפשרויות השונות לניהול קבוצות משתמשים וני הול קבוצות ב-.
טבלה 7. אפשרויות לניהול קבוצות וחברות קבוצתיות
אופציה תיאור יתרונות חסרונות

הקצאה קבוצתית (קבוצות) צור ונהל קבוצות ישירות. הוספה/הסרה של חברים באופן ידני או באמצעות CSV. שליטה מלאה על חברות בקבוצה
יישום מיידי של רישיונות ות בניות
קל ליצור ולערוך קבוצות נדרשים עדכונים ידניים
סיכון לשגיאות בהעלאות CSV ידניות
אין סנכ רון אוטומטי עם ספריות חיצוניות

קבוצות מסונכרנות ממזהה Entra (Azure AD) או Active Directory סנכרן אוטומטית קבוצות אבטחה וחברות מ שירותי ספריות חיצוניים. סנכרון אוטומטי מפחית עבודה ידנית
מבטיח עקביות עם המדריך הארגוני
תומך בארגונים גדולים
לא ניתן לערוך חברות בקבוצה ב-
עיכוב סנכרון עד 12 שעות
קבוצות מקוננות דורשות בחירה ידנית

קבוצות ו- SCIM 2.0 API (קבוצות) השתמש בקבוצות או ב- SCIM 2.0 API לניהול קבוצות וחברות פרוגרמטי אוטומציה ואינטגרציה עם מערכות אחרות
ניתן להרחבה לסביבות גדולות או מורכ בות
דורש מאמץ פיתוח
המורכבות תלויה בשימוש ב- API

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

גישה מקיפה זו לניהול קבוצות משתמשים מאפשרת לארגונים לנהל ביעילות רישיונות משתמשים, הגדרות ומדיניות, ומבטיחה חוויות שיתוף פעולה עקביות וניתנות להרחבה.

גישה מומלצת בעת מעבר מ-

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

סיסקו ממליצה להשתמש בספריית ענן מרכזית כגון Microsoft Entra ID (Azure AD) כ מקור האמת היחיד לזהויות משתמשים. סנכרון משתמשים מ- Entra ID כדי להבטיח עקביות, מפשט את הניהול ותומך ביכולות כניסה יחידה (SSO).

כדי להבטיח שכל המשתמשים נמצאים גם ב- Entra ID, ארגונים צריכים לוודא שחשבונות המשתמש ב- תואמים לחשבונות ב- Entra ID. ניתן לעשות זאת על ידי ייצוא רשימות משתמשים והשוואתן עם רשימות משתמשים של Entra ID.

לסיכום, שיטת ההקצאה המומלצת היא לסנכרן משתמשים מ- Microsoft Entra ID (Azure AD) ל- Webex באמצעות אשף Azure AD או יישומי SCIM. הקצאה בכמות גדולה ידנית ו- CSV זמינות כשיטות משלימות אך הן פחות ניתנות להרחבה ונוטות יותר לשגיאות עבור ארגונים גדולים. הבטחה ש-Entra ID הוא המקור הסמכותי וכי כל המשתמשים קיימים ב- Entra ID היא קריטית להעברה מוצלחת וחוויית משתמש עקבית ברחבי סביבות.

המעבר משירות ספריות מקומי, למשלActive Directory, לשירות ספריות ענן, כמו Entra ID (מזהה Azure), אינו תלוי במעבר השיחה. סיסקו ממליצה לסיים את המעבר לשירות ספריות ענן לפני תחילת מעבר השיחות.

עיצוב קבוצות משתמשים

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

שם קבוצה: שם ייחודי של הקבוצה.

רישיונות: רישיונות שיוקצו לקבוצה זו (אם קיימים) והיקף (יש להקצות רישיונות למשתמשים קיימים או רק למשתמשים חדשים)

תבניות הגדרות: תבניות שיחות של אפליקציות Webex ו- משתמשים.

סנכרון ספריות: האם קבוצה זו תסונכרן מהספרייה הארגונית או שמא מדובר בקבוצת Webex מקומית המסופקת ב- Control Hub או באמצעות ממשק API.

תיאור: כיצד תשמש קבוצה זו ואילו משתמשים צריכים להיות חברים בקבוצה זו

פרטים אלה ישמשו בהמשך שלב היישום ליצירת קבוצות או קבוצות מקומיות בספריית הארגון ולנהל חברות בקבוצה של משתמשים.

כניסה יחידה (SSO)

סיסקו ממליצה להשתמש ב- SSO לאימות משתמשים. לשימוש ב- SSO יש כמה יתרונות משכנעים, כולל:

אימות משתמש פשוט יותר: משתמשים יכולים להיכנס פעם אחת באמצעות האישורים הארגוניים שלהם (למשל מ- Azure ID) כדי לגשת ליישומים משולבים אחרים, מה שמבטל את הצורך בסיסמאות מרובות ול הפחית את הנחיות הכניסה. זה משפר את האבטחה על ידי הבטחת סיסמאות ארגוניות לעולם לא מאוחסנות או מועברות לאחר האימות.

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

אבטחה משופרת: SSO מפחית את עייפות הסיסמאות ואת הסיכון להפרות הקשורות לסיסמה על ידי ריכוז האי מות באמצעות ספקי זהות מהימנים (IDP).

שילוב קל של אימות רב-גורמי (MFA): ניתן לתמוך בקלות ב - MFA באמצעות פתרון ניהול גישה לזהויות כמו Cisco Duo או באמצעות תמיכה ב- M FA של ה- IdP.

ישנן מספר אפשרויות ליישם SSO עבור שירותים:

SSO מבוסס SAML 2.0: הפרו טוקול הראשי הנתמך לשילוב SSO, המאפשר החלפה מאובטחת של מידע אימות בין Id P לבין ספק השירות.

חיבור OpenID (OIDC): נתמך כפרוטוקול אימות מודרני חלופי לשילוב SSO.

זהות Webex: נתמכת גם כאפשרות של ספק זהות.

SSO מוגדר ומנוהל באופן מרכזי באמצעות, ודורש החלפת מטא נתונים בין ה- IdP שנבחר.

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

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

סיסקו דואו

אוקטה

Microsoft Active Directoryשירותי פדרציה (ADFS)

מיקרוסופט Azure

פינגפדרט

אופנאם

F5 BIG-IP.

IDP אלה תואמים לתקני SAML 2.0 או OpenID Connect ואומתו לתאימות לפתרונות שיתוף פעולה של סיסקו.

תמיכה מרובה של IdP

מאפשר לארגונים להגדיר SSO עם מספר IDPs כדי להתאים לסבי בות IT מורכבות כגון מיזוגים, רכישות או מחלקות IT מבוזרות שבהן קבוצות שונות משתמשות ב-IDP שונים. ניתן ליישם תמיכה מרובה של IdP באמצעות תכונת IdP מרובה בתוך מערכת IAM ארגונית כמו Cisco Duo או באמצעות שילוב של מערכת IAM ארגונית.

התמיכה המרובה של ספק הזהות (IdP) מטפלת במספר מקרי שימוש מרכזיים שבהם ארגונים דורשים אימות גמיש ומאובטח בסביבות IT מגוונות:

1. מיזוגים ורכישות

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

2. מחלקות IT עצמאיות מרובות

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

3. קבוצות משתמשים או דומיינים שונים

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

4. תמיכה בפרוטוקולי אימות שונים

תומך ב- IDP של SAML ו- OpenID Connect (OIDC), ומאפשר לארגונים לשלב סוגים שונים של ספקי זהות בהתאם לתשתית הקיימת שלהם ולדרישות האבטחה שלהם.

5. אבטחה ותאימות משופרים

על ידי הפעלת IDP מרובים, ארגונים יכולים ליישם מנגנוני אימות חזקים יותר, כולל אימות רב-גורמי (MFA) באמצעות שילובים כמו Duo, ולאכוף מדיניות אבטחה עקבית על פני בסיסי משתמשים מגוונים.

6. חווית משתמש פשוטה

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

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

שני MFA עם SSO עבור

Duo Access Gateway (DAG) יכול לאמת משתמשים באמצעות ספריות קיימות מקומיות או מבוססות ענן, כגון Active Directory (AD) ו- OpenLDAP. הוא תומך גם באינטגרציה עם ספקי זהות אחרים כמו מיקרוסופט ADFS, מיקרוסופט Azure, אוקטה, OneLogin, CAS ו- Shibboleth. גמישות זו מאפשרת לארגונים להשתמש בת שתית הספריות הנוכחית שלהם עבור Webex SSO עם Duo MFA.

Duo פועל כשכבת אימות חזקה על גבי אימות הספרייה הראשית. הוא מת פקד כספק זהות (IdP) המשתמש ב- SAML 2.0 כדי לאכוף אימות דו-גורמי (2FA) לפני מתן גישה ל. Duo מעריך את הקשר של משתמשים, מכשירים ורשת מול מדיניות הניתנת להגדרה כדי לאפשר או לדחות גישה, ומשפר את האבטחה מעבר לשם משתמש וסיסמה בלבד. Duo מספק גם בקרות מדיניות גמישות, כגון דרישת MFA בכל כניסה עבור יישומים מסוימים ותדירות נמוכה יותר עבור אחרים.

היתרונות של Cisco Duo כוללים:

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

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

שילוב עם ספריות קיימות: תומך ב - AD מקומי, OpenLDAP, ספריות ענן וספקי SSO שונים, תוך צמצום שינויי תשתית.

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

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

הרשמה לשירות עצמי: הר שמה מובנית והנחת צמד משפרות את חווית המשתמש במהלך הגדרת MFA.

Duo MFA עם SSO למנף ספריות קיימות כמו ו Active Directory - OpenLDAP, או ספ קי זהות ענן, לאימות משתמשים. תפקידו של Duo הוא לספק גורם אימות שני חזק ומונע מדיניות המשולב באמצעות SAML 2.0, שיפור האבטחה תוך שמירה על נוחות המשתמש באמצעות SSO. היתרונות כוללים תנוחת אבטחה משופרת, אכיפת מדיניות גמישה, אינטגרציה חלקה וחווית משתמש טובה יותר.

סיסקו ממליצה ליישם SSO למשתמשים. לקבלת אבטחה משופרת שילוב עם Cisco Duo מומלץ.

יש לפרוס את אסטרטגיית ה- IAM ו- SSO הארגונית לפני תחילת המעבר מ -.

תכונות

יש השלמה מלאה של תכונות ליבה הכלולות בשירות. זה כולל תכונות שיחות רבות ברמה ארגונית שהיו זמינות במשך שנים רבות. ייתכן שלא תראה שוויון של 100% בין תכונות לתכונות, אולם כפי שאתה יכול לראות באיור שלהלן, תכונות השיחות העיקריות זמינות ב.

Webex Callingתכונות ברמה ארגונית

מלבד תכונות המשתמש הרבות, יש תכונות מערכת ליבה הכלולות בפלטפורמה. אלה כוללים תכונות כמו דיי לים אוטומטיים, תורי שיחות, פארק שיחות וכו '. אתה יכול לראות את כל תכונות מערכת הליבה הזמינות תחת שירות → שיחות → תכונות כפי שמתואר בת כונות Webex Calling הליבה של איור.

Webex Callingתכונות ליבה

מלווה אוטומטי

השיחה האוטומטית מאפשרת אוטומציה 24/7 של טיפול בשיחות נכנסות, המאפשר טיפול יעיל בשיחות ללא צורך באדם לענות לכל שיחה.

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

השיחה האוטומטית תומכת בתכונות העיקריות הבאות:

לוחות זמנים עסקיים ואחרי שעות העבודה

לוח זמנים לחג

אפשרות תפריט חיוג כדי לכוון את הלקוחות שלך לאן שהם צריכים ללכת

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

אפשרות חיוג לפי שם

אפשרויות העברת שיחות

ניתוח ודוחות של רכזת בקרה.

לקבלת מידע נוסף, ראה ניהול שיחות טלפון אוטומ טיות.

התקשר לפארק

Call park נותן למשתמשים את היכולת בקלות לשים שיחה ב המתנה כדי שמשתמש אחר יוכל לאחזר בקלות כאשר הם זמינים לקחת אותה. זה גם משחרר את המשתמש שענה לשיחה המק ורית לבצע או לקבל שיחות אחרות בזמן שהשיחה חונה.

ישנם שני סוגים של פארקי שיחות זמינים ב:

Call park direct - מאפשר לכל משתמש להחנות שיחה לתוסף של משתמש אחר או לתוסף פארק שיחות, כפי שהוגדר על ידי מנהל המערכת

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

בהתבסס על התצורה וסוג הפארק, משתמשים יכולים לאחזר שיחות על ידי חיוג *88+><extension of parked call>, לחיצה על מקש הקו המשויך לתו סף פארק השיחות או באמצעות מקש רך בטלפון ה- IP שלהם.

אפשרות החזרה זמינה לזיכרון שיחה חונה לאחר תקופה מוגדרת למשתמש שהחנה את השיחה או למשתמש חלופי.

לקבלת מידע נוסף, ראה ניהול חניית שיחות במרכז הבקרה.

איסוף שיחות

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

המשתמשים בקבוצה חייבים להיות באותו מיקום.

משתמשים יכולים להשתמש בטלפון השולחני או בטלפון השולחני שלהם כדי לאסוף שיחה.

:

תומך בהתראות חזותיות ושמע

הודעת שיחה נכנסת

איסוף שיחות טוסט מבוסס FACK (חיוג *98) או הודעה

התראות לאיסוף שיחות עבור רב-שורות.

טלפונים שולחניים:

הודעת שיחה נכנסת

פעמוני שמע והתראה חזותית דרך נורית המכשיר. ה- 6821 תומך רק בפעוני שמע

כאשר סוג ההודעה נבחר ב- אינו ללא

הודעות איסוף שיחות רק עבור קווים ראשיים בלבד.

לקבלת מידע נוסף, ראה קביעת תצורה של קבוצת איסוף שיחות.

תור שיחה

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

הקריאה של סיסקו לשילוב Microsoft Teams מאפשרת לסוכנים לגשת לשיחות ותכונות תור שיחות ישירות מלקוח Microsoft Teams שלהם.

תורי שיחות תומכים בתכונות העיקריות הבאות:

ברכות והודעות (קבלת פנים, נחמה, לחישה וכו ')

החזק מוזיקה

התקשרות חוזרת

מדיניות ניתוב תור (שירות לילה, חגים, העברה)

כניסה/יציאה בתור סוכן

ניהול סטטוס תור סוכן

או תמיכה טלפונית בשולחן העבודה

סוכן מפקח מתקשר לפקח, מאמן, דוברה או משתלט באמצעות קודי גישה לתכונות (FACS)

(גישה למנהל) עבור:

ניהול תור

ניתוח ודיווח של סוכנים ותור

ניהול תור, סוכן ומפקח.

לקבלת מידע נוסף, ראה קביעת תצורה של תור שיחות.

כולל תכונת תוספת לסיוע לקוח המספקת יכולות תור שיחות נוספות ומע ניקה לסוכנים ולמפקחים חווית משתמש טובה יותר בתוך. להשוואה בין התכונות של תור השיחות ותכונות סיוע ללקוח, ראה Webex Callingהשוואת תכונות תור שיחות וסיוע ללקוח.

קבוצת האנט

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

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

לקבלת מידע נוסף, ראה ניהול קבוצות ציד במרכז הבקרה.

מצבי הפעלה

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

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

משתמש מורשה יכול לעבור בין תרחישים שונים אלה (מצבים) להעברת שיחות אם הוא צריך לשנות היכן מנותבות שיחות נכנסות לתקופה מסוימת. משתמשים אלה יכולים לנהל את המצבים באמצעות טלפונים 6800/7800/8800 MPP שלהם, טלפונים 9800 או במרכז המשתמשים במצבים ניהול.

לקבלת מידע נוסף, ראה ניתוב שיחות בהתבסס על מצבי הפעלה ב- Webex Calling.

קבוצת פיג'ינג

קבוצות הדפינג מאפשרות למשתמשים לבצע שיחה בכיוון אחד כדי לשלוח הודעת שמע לקבוצת משתמשים. כל קבוצה יכולה להכיל עד 75 משתמשי יעד ו/או סביבות עבודה שאליהם מגיעים באמצעות חיוג למספר או סיומת מוגדרת מראש.

כאשר משתמש מתקשר לקבוצת עימוד, מתבצעת שיחה בו זמנית לכל היעדים שהוקצו בקבו צה, ובשלב זה המתקשר יכול לדבר את ההודעות שלו ולנתק לאחר סיום ההודעות.

לקבלת מידע נוסף, ראה קביעת תצורה של קבוצת עימוד ב- Control Hub.

הקלטות

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

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

לקבלת מידע נוסף אודות תכונה זו ורשימה של הקלטות של צד שלישי, ראה ניהול הק לטת שיחות עבור Webex Calling.

טווח הגעה למספר יחיד

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

לקבלת מידע נוסף אודות תכונה זו ועל האופן שבו מנהל מערכת מגדיר אותה, ראה קביעת תצורה של טווח הגעה למספר יחיד (Office Anywhere).

לקבלת מידע נוסף על האופן שבו משתמש יכול לנהל ולהגדיר תכונה זו עבור עצמו ב - Webex User Hub (פורטל), ראה קביעת תצורה של טווח הגעה למספר יחיד (משרד בכל מקום).

קבוצת דואר קולי

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

דואר קולי למטרות כלליות עבור מחלקה או קבוצת עבודה

הוספת אפשרות של דואר קולי למלווה אוטומטי או לקבוצת ציד

כדי לשלוח שיחות הצפה מתור שיחות

משתמשים הזקוקים רק לתיבת דואר קולי.

לקבלת מידע נוסף, ראה ניהול דואר קולי משותף ותיבת פקס נכנסת עבור. Webex Calling

מסוף הנלווה מופיע בדף תכונות שיחות ב- Webex, אולם זוהי תכונה תוספת הדורשת רכישת רישיון המסוף הנלווה לשימוש.

לקבלת מידע נוסף, ראה התחלת העבודה עם מסוף הנלווה.

לקבלת מידע על כל התכונות, כולל תכונות תוספות מסוימות, ראה תכונות זמינות לפי סוג רישיון עבור Webex Calling.

טבלה 1. מידע ללכידה עבור כל מיקום
מידע	הערה
טווח (ים) הרחבה	לכל מיקום יכולים להיות הרחבות המתחילות בספרות שונות. יש לחסוך ספרה אחת לספרת ההיגוי החיוג הבין-אתרים (לדוגמה 8) וספרה אחת לספרת ההיגוי של PSTN (לדוגמה 9). שום טווח הרחבה לא יכול להתחיל עם אחת מש תי הספרות הללו. כל טווחי ההרחבה של כל המיקומים חייבים להיות בא ורך שווה.
טווח (ים) DID	-
ספרת היגוי PSTN	-
קוד האתר	כל קודי האתר של כל המיקומים צריכים להיות ייחודיים ובעלי אורך זהה.
מספר ראשי	בעת יצירת מיקום יש לספק שני DIDs. אחד כמספר ראשי (לדוגמה שיוקצה לשירות מלווה אוטומטי) ואחד עבור פורטל הדואר הקולי. הקצאת DID אחד למספר הדואר הקולי.
מספר דואר קולי
מספר הרישיונות	רישיונות נדרשים לפי סוג כולל סטנדרטי, מקצועי, סביבת עבודה, רשימת מסלולים, תוכנית שיחות יוצאות.
שיחות במקביל בשעות העמוסות	סכום השיחות במקביל בין התקנים ובין התקנים לשער המקומי (PSTN ושיחות למכשירים). נדרש כדי לקבוע את רוחב הפס הנדרש לגישה לאינטרנט.
ארץ	-
אזור זמן	-
שפה	-
איש קשר (שם, טלפון, דוא"ל)	-
כתובת (כתובת רחוב, עיר, מדינה, מיקוד)	-
מיקום פיזי הניתן לשליחה של שירותי חירום לנקודות קצה	מיקום הניתן למשלוח של המכשיר המשמש לשיחות חירום כולל בדרך כלל את הדברים הבאים: כתובת בניין, כתובת בנין+מספר קומה, כתובת בנין+מספר סוויטה, או כתובת בניין + מספר קומה + מספר משרד/קובי.
לכל מכשיר מיקום רשת פיזי ייחודי לשירותי חירום	מיקום רשת פיזית לשיחות חירום כולל בדרך כלל את הדברים הבאים: מתג/יציאת מתג להתקנים קוויים, מזהי ערכת שירות בסיסיים (BSSID) של נקודת גישה אלחוטית (BSSID) עבור התקנים מחוברים אלחוטיים ו/או רשתות משנה IP מקומיות עבור התקני נקודת קצה.

טבלה 2. דוגמה למספור ארגוני
אתר	טווח הרחבה	קוד האתר	טווח ארגוני
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

טבלה 3. טווחי הארכה באורך קבוע
אתר	טווח הרחבה	הרחבות	קוד האתר	טווח ארגוני
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

טבלה 4. מעבר חיוג בן שבע ספרות

אתר	הרחבות	קוד האתר	טווח ארגוני	אודה לאתר	אנטרפרייז
NYC	2XXX	22	8 22 2XXX	822	8 822 2XXX
SFO	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

טבלה 5. אפשרויות הקצאת משתמשים - סיכום
שיטת הקצאה	יתרונות	חסרונות
דרך ידנית	פשוט למעט משתמשים. מאפשר שליטה מדויקת ומפורטת על הקצ את רישיון.	לא ניתן להרחבה, גוזל זמן נוטה לטעות אנושית במהלך כניסה ידנית.
תבניות רישיון אוטומטיות	ניתן להרחבה מפחית שגיאות ידניות ניתן להחיל על משתמשים חדשים ו קיימים.	דורש מספרי טלפון ומיקומים חוקיים. מורכב יותר לה גדרה כמו כן דורש קבוצות משתמשים לכל קבוצת משתמשים עם דרישות רישוי שוות ערך.
העלאה בכמות גדולה של CSV	יעיל עבור קבוצות משתמשים גדולות מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ותוספים.	דורש עיצוב CSV זהיר פוטנציאל לשגיאות אם מספרי טלפון או סיומות חסרים או שגויים.
הקצאה מבוססת API	אוטומטי, גמיש. מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ותוספים.	דורש פיתוח וידע API.

טבלה 6. אפשרויות הקצאת משתמשים עבור
שיטת הקצאה	תיאור	יתרונות	חסרונות
ידני	יצירה/ניהול משתמשים בנפרד ב	פשוט למעט משתמשים; אין צורך בתשתית	לא ניתן להרחבה; גוזל זמן עבור משתמשים רבים
בכמות גדולה (קובץ CSV)	ייבוא/עדכן משתמשים בכמות גדולה באמצעות CSV ב	יעיל לקבוצות; אין צורך בקידוד	הכנה ידנית ל- CSV; פחות דינמי
ממשק API של אנשים ו- SCIM 2.0	ניהול משתמשים תכנותי באמצעות ממשקי API של Webex	גמיש; תומך באוטומציה ואינטגרציה	דורש פיתוח ותשתיות
סנכרון ספריות	סנכרון אוטומטי מ- AD, Entra ID, אפליקציות SCIM, Unified CM	אוטומציה של מחזור חיים; תומך בסינון ומיפוי	מורכבות התקנה: לחלק מהאפשרויות יש תכונות מוגבלות או דורשות ת שתית

טבלה 7. אפשרויות לניהול קבוצות וחברות קבוצתיות
אופציה	תיאור	יתרונות	חסרונות
הקצאה קבוצתית (קבוצות)	צור ונהל קבוצות ישירות. הוספה/הסרה של חברים באופן ידני או באמצעות CSV.	שליטה מלאה על חברות בקבוצה יישום מיידי של רישיונות ות בניות קל ליצור ולערוך קבוצות	נדרשים עדכונים ידניים סיכון לשגיאות בהעלאות CSV ידניות אין סנכ רון אוטומטי עם ספריות חיצוניות
קבוצות מסונכרנות ממזהה Entra (Azure AD) או Active Directory	סנכרן אוטומטית קבוצות אבטחה וחברות מ שירותי ספריות חיצוניים.	סנכרון אוטומטי מפחית עבודה ידנית מבטיח עקביות עם המדריך הארגוני תומך בארגונים גדולים	לא ניתן לערוך חברות בקבוצה ב- עיכוב סנכרון עד 12 שעות קבוצות מקוננות דורשות בחירה ידנית
קבוצות ו- SCIM 2.0 API (קבוצות)	השתמש בקבוצות או ב- SCIM 2.0 API לניהול קבוצות וחברות פרוגרמטי	אוטומציה ואינטגרציה עם מערכות אחרות ניתן להרחבה לסביבות גדולות או מורכ בות	דורש מאמץ פיתוח המורכבות תלויה בשימוש ב- API

ליישם

מוכנות לרשת

הגדרה ראשונית

אימות תחום

תביעה (המרה) של משתמשים קיימים

קביעת תצורה ובדיקה של סנכרון ספריות

הגדרה ובדיקה של כניסה יחידה (SSO)

לרכוש, לספק ולאמת רישיונות

Webex Callingהגדרות שירות

הגירת פיילוט

רכישת PSTN

הגדר מיקומים

אינטגרציה עם בקרת שיחות מקומית

העברת משתמשים בקבוצות

סביבות עבודה

התקני אספקה

קביעת תצורה של תכונות

בדיקת קבלה

מוכנות רשת

השלב הראשון במעבר הוא להבטיח קישוריות אינטרנט אמינה ומאובטחת בין הרשת המקומית לענן.

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

מנהלי רשת ואבטחה חייבים להבין את הזרימות הללו במונחים של:

כיוון (נכנס לעומת יוצא)

פרוטוקולים (דוגמה - SIP TLS, SRTP, HTTPS)

טו@@ וחי כתובות IP המשמשים שירותים

מספרי יצי אה שיש לפתוח או לאפשר.

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

לקבלת מידע על הזרימות הנדרשות כולל כתובת IP, יציאות ופרוטוקולים, ראה מידע הפניה ליציאה עבור Webex Calling. השתמש ב מידע זה כדי להגדיר את חומת האש, פרוקסי ותשתיות רשת אחרות בפריסה הקיימת כדי לאפשר זרימות רשת.

פריצת אינטרנט מבוזרת מכל סניף או אתר היא הגישה המומלצת לשירותי שיתוף פעולה בע נן כגון. על ידי מתן אפשרות לתנועה לצאת באופן מקומי, מודל זה:

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

מתרחב ביעילות ככל שיותר משתמשים ואתרים עוברים

עובד בצורה חלקה עם SD-WAN, שיכול לנתב באופן דינמי הפעלות לנקודת הכניסה הקרובה לענן לקבלת ביצועים מיטביים

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

בנוסף, על ארגונים להבטיח רוחב פס אינטרנט נאות בכל אתר. רוחב הפ ס צריך להיות בגודל בהתבסס על המספר הצפוי של שיחות במקביל, ה- codec שנבחר (למשל, Opus או G.711), בתוספת תקורה לאיתות, שידורים חוזרים וצמיחה. זה מתיישב עם שלב ה הכנה של מחזור החיים של PPDIO ומבסס בסיס איתן להגירה.

הגדרה ראשונית

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

אימות תחום

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

ודא שכל הדומיינים המשויכים לכתובות הדוא"ל של המשתמשים שלך מאומתים. אימות תחום אינו בלעדי; ניתן לאמת את אותו תחום בארגונים מרובים.

לקבלת מידע נוסף על ניהול תחומים, ראה ניהול התחומים שלך.

תביעה (המרה) של משתמשים קיימים

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

לקבלת מידע נוסף על תביעות משתמשים, ראה ת ביעת משתמשים למשתמשי הארגון שלך (המרה).

הגדר ובדיקה של סנכרון ספריות

כדי לאפשר ניהול משתמשים וקבוצות חלק, באפשרותך לסנכרן משתמשים וקבוצות מה ספרייה הארגונית שלך או Microsoft Entra ID (לשעבר Azure AD) או Microsoft Active Directory (AD) אל. תהליך זה מבטיח כי זהויות משתמשים וחברות קבוצתיות נשמרות באופן עקבי ברחבי הסביבה שלך.

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

השיטה היעילה ביותר לסינון המשתמשים המסונכרנים היא למנף חברות בקבוצת ספריות:

1
יצירת קבוצת סנכרון ייעודית: בספרייה הארג ונית שלך (Microsoft Entra ID או AD), צור קבוצת אבטחה ספציפית לסנכרון (לדוגמה, קבוצת סנכרון).

2
אכלס את הקבוצה עם משתמשי יעד: הוסף לקבוצה זו רק את המשתמשים שברצונך לסנכרן (כגון קבוצת בדיקה בשלב הפיילוט). זה מאפשר לך לשלוט בחוזקה מי נכלל בתהליך הסנכרון.

3
קביעת תצורה של הסכם הסנכרון באמצעות סינון מבוסס קבוצה: בעת הגדרת הסכם הס נכרון בהקצאת Directory Connector או Entra ID, הגדר את התחום כך שיכלול רק משתמשים שהם חברים בקבוצה המיועדת.

עבור מזהה Microsoft Entra, באפשרותך להשתמש בהקצאות מבוססות קבוצה בהגדרות הקצאה

עבור AD, באפשרותך להגדיר מסנן LDAP שיכלול רק משתמשים השייכים לקבוצה ש צוינה.

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

שלבי יישום לדוגמה:

בספרייה פעילה:

צור קבוצת אבטחה בשם קבוצת סנכרון.

הוסף את משתמשי הפיילוט הרצויים לקבוצה זו.

הגדר מחבר ספריות עם מסנן LDAP כגון: (MemberOf=CN= קבוצת סנכרון WebEx, OU = קבוצות, DC=התחום שלך, DC=COM).

במיקרוסופט הזן מזהה:

יצירת קבוצה בשם קבוצת סנכרון

הקצאת הקבוצה להגדרות הקצאה של מזהה Entra

רק משתמשים בקבוצה זו יוקצו ל.

בדוק תמיד סנכרון מבוסס קבוצה בסביבה שאינה ייצור לפני הגשת בקשה לארגון כולו

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

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

הפניות:

סנכרן משתמשי זיהוי כניסה לרכזת הבקרה

הגדר את אפליקציית אשף ה- Entra ID במרכז הבקרה

מחבר ספרייה

הגדרה ובדיקה של כניסה יחידה (SSO)

כניסה יחידה (SSO) משפרת את האבטחה ומפשטת את גישת המשתמשים בכך שהיא מאפשרת למשתמשים לאמת פעם אחת עם האישורים הארגוניים שלהם ולקבל גישה חלקה אל. תומך בשילוב SSO עם מכשירי IDP תואמים ל- SAML 2.0, כולל Microsoft Entra ID (לשעבר Azure AD), פתרונות מאוחדים Active Directory (AD) ומדידים שונים של צד שלישי.

בשלב זה יש ליישם ולבדוק את הגדרת SSO המתוכננת.

הפניות:

שילוב כניסה יחידה ברכזת הבקרה

קביעת תצורה של כניסה יחידה לניהול webex

הגדר כניסה יחידה באמצעות מזהה Microsoft Entra

SSO עם מספר IDP

ניהול SSO באינטגרציה ברכזת הבקרה

לרכוש, לספק ולאמת רישיונות

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

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

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

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

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

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

Webex Callingהגדרות שירות

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

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

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

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

הגירת פיילוט

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

העברת הפיילוט צריכה למנף את אותו שילוב של כלים המסופקים ב- Cisco ושירותי העברה של צד שלישי המתו כננים לפריסה הארגונית הרחבה יותר, ולהבטיח שהת הליכים, זרימות העבודה של האוטומציה ונקודות האינטגרציה מאומתים ביסודיות בתנאים מייצגים.

המטרות העיקריות של פריסת פיילוט זו הן כפולות: ראשית, לאמת ולשכלל את תהליכי המעבר מקצה לקצה כולל זרימות עבודה להקצאת משתמשים, נהלי העברת נתונים ותצורות נקודות קצה; ושנית, לאמת באופן מקיף את הפונקציונליות של שירותים שהועברו בתנאים תפעוליים בעולם האמיתי.

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

התובנות שנצברו בשלב הפיילוט הזה מסייעות ב אופטימיזציה של גלי ההגירה הבאים ולהבטחת מעבר חלק ומפחית סיכונים עבור הארגון כולו.

רכישת PSTN

כדי לרכוש שירותי PSTN עבור, בחר תחילה אפשרות קישוריות PSTN ב-.

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

אם מעבר מלא (שלב 2) לענן הוא המטרה הסופית כולל PSTN, אז תידרש תוכנית שיחות של סיסקו או אפשרות Cloud Connect עבור PSTN.

עבוד עם הספק שבחרת כדי להזמין ולהעביר מספרי טלפון לפני שתגדיר אותם. הזמנת מספרי טלפון או הפעלת הזמנות יציאות נדרש/אפשרית רק עבור PSTN מקומי ו- Cloud Connect עבור. עבור תוכניות שיחות של סיסקו, ההזמנה וההעברה יוזמות מתוך Control Hub ברגע שנוצר המיקום, ובמדינות שבהן תוכנית השיחות של סיסקו זמינה. לקבלת מידע נוסף על תוכניות שיחות של Cisco, ראה תחילת העבודה עם תוכניות Cisco.

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

הגדר מיקומים

לפני הוספת משתמשים ומכשירים, עליך לספק מיקומי שיחות. עבור כל מיקום, יש להכניס כתובת רחוב חוקית. בארה"ב ובקנדה, כתובת זו מאומתת ומשמשת את הפלטפורמה ל שליחת מידע על מיקום PIDF-LO לשיחות חירום.

בעת קביעת תצורה של מיקומים המשתמשים ב- PSTN מקומי, עליך להגדיר את השערים המקומיים בהתאם. בתוך, יש ליצור תא מטען וקבוצת מסלולים עבור כל שער מקומי, ולאחר מכן קבוצת המסלול מוקצה כבחירת PSTN עבור המיקום. סיסקו ממליצה בחום לבחור תמיד קבוצת מסלולים כבחירת PSTN, מכיוון שגישה זו מאפשרת להוסיף בקלות גזעים נוספים בעתיד, התומכים הן במדרגיות והן ביתירות. סיסקו ממליצה גם לאפשר תמיכה בזהות כפולה ותמיכה ב- P-Charge-Info בכל תא מטען PSTN, מכיוון שהדבר מפשט את זיהוי הצד הניתן לחיוב עבור שיחות יוצאות ישירות או מופנות. אם ספק ה- PSTN שלך משתמש בכותרת אחרת לחיוב, באפשרותך להעתיק את המידע מהכותרת P-Charge-Info בשער המקומי לכותרת החיוב הנדרשת.

עבור מיקומים המשתמשים ב- Cloud Connect עבור או בתוכנית השיחות של Cisco כאפשרות PSTN שלהם, פשוט בחר את בחירת ה- PSTN המתאימה למי קום במהלך ההתקנה. אם המיקום משתמש ב- Cloud Connect עבור PSTN מקומי או ב- PSTN מקומי, יהיה עליך להוסיף את מספרי הטלפון שהוזמנו בשלב הקו דם. ניתן להוסיף מספרים כלא פעילים אם אינך מעוניין שיכללו אותם בני תוב שיחות מיד; באפשרותך להפעיל מספרים אלה מאוחר יותר כאשר הם מוקצים למשתמשים או לתכונות.

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

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

שילוב עם בקרת שיחות מקומית

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

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

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

העברת משתמשים בקבוצות

כאשר אתה מעביר משתמשים מ- אל, ייתכן שלא תוכל להעביר את כל המשתמשים בו זמנית. זה יכול לנבוע מסיבות מרובות, לרבות אך לא רק מספר האתרים או המשתמשים, כמה זמן לוקח לעבור לאתר ו /או קבוצת משתמשים בו זמנית, משאבי IT או אתר מוגבלים לתמיכה בחלון השינוי, משך חלון השינוי, מורכבות השינוי וכו'.

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

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

מעקב אחר משתמשים אחרים המשתמשים ב- BLFs

באותו טייס ציד, תור שיחה וכו '

קווים משותפים

שימוש באיסוף שיחות

שימוש באותם מספרי חניון שיחות

אינטרקום

מנהל/מנהל.

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

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

השתמש בפלט מהכלי Migration Insights או מכלי צד שלישי שבו השתמשת בשלב ההכנה כדי לקבוע אילו משתמשים ותכונות יש לקבץ יחד. פלט זה היה אמור לשמש לפיתוח תוכנית ההעברה שלך ויספק לך תובנות לגבי האופן שבו תקבץ משתמשים ותכונות שצריכים לעבור יחד.

השלבים העיקריים בעת מעבר קבוצת משתמשים הם:

זיהוי משתמשים להעברה משותפת

ודא שכל המשתמשים נמצאים

ודא שכל ה- TN עבור המשתמשים קיימים ב

ודא פורמט מספר טלפון נכון בספרייה

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

אימות או קביעת תצורה של כל שירותי השיחות והתכונות עבור קבוצת המשתמשים (לפני המעבר או במהלך המעבר בהתאם)

בספרייה הארגונית הוסף משתמשים לקבוצת המשתמשים המותאמים לשי חות

כלי מינוף - כלי העברת משתמשים ותכונות ו/או כלים של צד שלישי

השבת/מחק מספר ספריית משתמש/מכשיר ותכונות/שירותים להתקשר לאחר המעבר.

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

סביבות עבודה

ב-, סביבת עבודה מתייחסת למיקום משותף (כמו חדר ישיבות, חלל הצטופפות או שולחן עבודה חם) שניתן להקצות למכשירים, הרחבות ומשתמשים. שלא כמו טלפונים מסורתיים של Unifed CM, סביבות עבודה הן:

ממוקד מיקום: קשור למרחבים פיזיים.

גמיש למכשיר: יכול להכיל מכשיר אחד או יותר (טלפונים שולחניים, לוחות וכו ').

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

לקבלת מידע נוסף על סביבות עבודה ב-, ראה סביבות עבודה.

התקני אספקה

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

כל הטלפונים הנתמכים שעליך לעבור מהם יצטרכו להיות מוגדרים כמשתמש או כסביבת עבודה ויש להגדיר מחדש את הטלפון הפיזי כדי להירשם אליו. בנוסף, הטלפונים מסדרת 7800 ו- 8800 זקוקים לשדרוג הקושחה שלהם מקושחה ארגונית לקו שחה מרובת פלטפורמות (MPP). תהליך זה כולל טעינת קושחת מעבר לפני טעינת קושחת MPP הנדרשת לרישום. זה גם דורש רישיון ההגירה המתאים. סיסקו שיפ רה את התהליך הזה במהלך השנים האחרונות כדי להקל עליך לשדרג את טלפוני הקושחה הארגוניים שלך לקושחת MPP. לקבלת מידע נוסף על השלבים להשלמת שדרוג הקושחה, ראה המרת טלפונים IP מסדרת Cisco 7800 ו- 8800 בין קושחת ארגונית ו- MP P.

בנוסף לשלבים המפורטים במאמר זה, יש לו כלי מובנה, העבר את הטלפון שלך אל, שבו תוכל להשתמש כדי Webex Calling לסייע בהעברת הטלפונים 7800 ו- 8800 שלך מקושחה ארגונית ל- MPP. כלי זה גם מאפשר לך להוסיף את הטלפונים ולהקצות אותם למשתמשים או סביבות העבודה המתאימות. לקבלת מידע נוסף על השימוש בכלים, ראה העברת הטלפון שלך.

עבור כל טלפונים מסדרת 9800 הרשומים עם דרישת העברת הקושחה לעיל אינה חלה. טלפונים אלה מריצים את PhoneOS, הנת מך על ידי שניהם וגם. כדי להעביר טלפונים אלה אליהם תצטרך להוסיף אותםWebex Calling, להקצות אותם למשתמש או לסביבת עבודה ולאחר מכן לאפס את הטלפונים להגדרות היצרן. רצף האתחול של Phon eOS לרישום איור להלן מציג את רצף האתחול של PhoneOS וכיצד הטלפון יירשם לאחר הוספתו, גם אם הטלפון עדיין מסופק ו/או אפשרויות DHCP (דוגמה - 150) נמצאות בשימוש.

רצף אתחול PhoneOS לרישום

תומך באיפוס להגדרות היצרן של מכשירי PhoneOS כדי לאפשר כניסה ל- Zero-Touch. מנהלים יכולים לאפס מרחוק את הטלפונים 9800 ו- 8875 דרך ד פי הניהול של CUCM, מה שמבטל את הצורך בגישה פיזית לטלפונים כדי להרכיב את הטלפונים אליהם. תכונה זו נתמכת בחבילות המכשירים החל מה- 9 בספטמבר 2025:

CUCM v15 - מנהל תקשורת מאוחד גרסה 15

CUCM v14 - מנהל תקשורת מאוחד גרסה 14.

למידע נוסף על תהליך ההרשמה לסדרת 9800, ראה תהליך ההרשמה.

בנוסף לטלפוני ה- IP של סיסקו, ייתכן שיהיה צורך בהקצאת התקנים אחרים כגון מתאמי טלפון אנלוגיים (ATA), טלפונים אלחוטיים (Wifi, DECT), התקני וידאו, שערים קוליים ו התק ^נים וטלפונים של צד שלישי. לרבים מהמכשירים הללו אין נתיב שדרוג קושחה כמו טלפוני ה- IP כדי להעביר אותם מקושחה ארגונית לקושחת ענ ן. לכן, תספק כל אחד מהמכשירים הללו ב- Control Hub. לא ניתן להעביר לחלק מאלה והמודל המקביל יצטרך להחליף אותו (למשל ATA 191/192) ואחרים ידרשו תצורה ידנית מחדש ו/או שינויים בתוכנה.

שערים קוליים - כדי להעביר את השער המקומי, ראה העברת ש ער מקומי.
לקבלת מידע נוסף להגדרת תצורת השער הקולי VG400, VG410 או VG420 ברכזת הבקרה, ראה שער מקומי

מתאם טלפון אנלוגי (ATA) - כדי להתחיל עם סיסקו ATA 191 ו- 192, עיין בסי סקו ATA.

טלפון אלחוטי Wifi - לשילוב טלפון אלחוטי 840 ו- 860, ראה שילוב טלפון אלחוטי Webex.

טלפונים אלחוטיים DECT - כדי להתחיל עם סדרת ה- IP DECT 6800 החדשה של סיסקו, ראה סיסקו IP DECT.

כדי לבנות ולנהל רשת DECT דיגיטלית ב- Control Hub, ראה ניהול רשת DEC T

לקבלת מידע נוסף על סיסקו IP DECT 6800, ראה מדריך פריסה

התק ^{נים וט} לפונים של צד שלישי - עבוד עם ספקים ^של צד שלישי בדרישות המכשיר/טלפון ותהליך העברתם או החלפתם לתמיכה.

הגדר תכונות

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

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

מנהלי שיחות אוטומטיות - לניהול שיחות אוטומטיות, ראה שיחות אוטומטיות

פארק שיחות - לניהול פארק שיחות, ראה פארק שיחות

איסוף שיחות - כדי להגדיר קבוצת איסוף שיחות, ראה אי סוף שיחות

תורי שיחות - כדי להגדיר תור שיחות, ראה תור שיחות

קבוצות ציד - לניהול קבוצות ציד, ראה ניהול קבוצת ציד

מצבי הפעלה - לניתוב שיחות בהתבסס על מצבי הפעלה, ראה ניתוב שיחות בהתבסס על מצבי הפעלה

קבוצות דיוור - לקביעת תצורה של קבוצת עימוד, ראה קביעת תצורה של קבוצת הדפינג

הקלטות - לניהול הקלטת שיחות עבור, ראה ניהול הקלטות

טווח הגעה למספר יחיד - כדי להגדיר טווח הגעה למספר יחיד (במשרד בכל מקום), ראה קביעת תצורה של מספר יחיד

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

בדיקת קבלה

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

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

הקצאת משתמשים והקצאת מספרים

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

אימות הקצאת מספרים כולל אישור שלכל משתמש מוקצה התוסף והמספר החיצוני הנכונים, וכי מספרים אלה מנותבים כהלכה הן בזרימות שיחות פנימיות (ברשת) והן בזרימות שיחות חיצוניות (PSTN) . חשוב לבדוק אם יש חפיפות, הקצאות חסרות או תצורות שגויות שעלולות להוביל לשגיאות ניתוב שיחות או הפרעות בשירות.

זרימות שיחות PSTN והצגת מזהה המתקשר

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

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

זרימות שיחות ברשת

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

טיפול בשיחות משתמש ואימות תכונות

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

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

תורי שיחות: ניסיון סוכן ומפקח

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

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

קבוצות ציד: חלוקת שיחות

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

משיבים אוטומטיים: הודעות ופעולות תפריט

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

פעולת דואר קולי

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

אופטימיזציה

העברת PSTN ל- Cloud Connect עבור

בצע אופטימיזציה של התשתית המקומית

השתמש בניתוח ופתרון בעיות

העברת PSTN ל- Cloud Connect עבור

לאחר שכל נקודות הקצה והמשתמשים מועברים לשיחות ענן המטרה היחידה של Unified CM היא לפעול כמעבר בין שערי PSTN ודרך שער מקומי. להסרת שערי PSTN ושער מקומי מהתמונה באמצעות Cloud Connect כגישה ל- PSTN לכל Webex Calling המשתמשים יש מספר יתרונות, כולל הפחתת עלויות ושיפור האמינות. כדי להעביר את הגישה המקומית ל-PSTN ל-Cloud Connect עבור , בצע את השלבים הבאים:

Cloud Connect לבחירת שותפים.

עיין ברשימת Cloud Connect עבור שותפים ובחר מבין השותפים הזמינים עבור המיקום של הארגון שלך.

חיבור ענן לאימות.

לפני החלפת גישת PSTN עבור מיקומים ל- Cloud Connect, יש לאמת ולאמת את הקישוריות ל- PSTN באמצעות שותף Cloud Connect שנבחר. לשם כך, יש לספק מיקום בדיקה עם חלק מ משתמשי הבדיקה המסופקים במיקום הבדיקה הזה. גישת PSTN עבור מיקום בדיקה זה מוגדרת לאחר מכן לשותף Cloud Connect לפני אימות קישוריות PSTN באמצעות טלפוני הבדיקה. לאחר אימות מוצלח, ניתן לבטל את הקצאת מיקום הבדי קה.

העברת מספרים.

כדי להתכונן לקיצוץ ל- Cloud Connect יש לבצע הזמנת יציאה עבור כל המספרים שהו קצו כעת לתא המטען של PSTN המסתיים בו. יש להעביר את כל המספרים לשותף Cloud Connect. כדי לשמור על יכולת הגעה בין מיקומים, יש להעביר את כל המספרים של כל המיקומים בו זמנית.

עבור לשותף Cloud Connect.

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

כפי שנדון בסעיף PSTN של פרק העיצוב, לקוחות יכולים גם לבחור להעביר את גישת ה- PSTN שלהם ל- Cloud Connect בתחילת המעבר באמצעות גזע PSTN לפריסות היברידיות. לקבלת מידע נוסף, ראה מטעף PSTN לפריסות היברידיות. Webex Calling במקרה זה במהלך המעבר הגישה ל- PSTN היא דרך השער המקומי ולאחר העברת כל המשתמשים אליו אין שלב העברה נוסף הקשור ל- PSTN מלבד ביטול ההפעלה והשערים המקומיים.

בצע אופטימיזציה של התשתית המקומית

לאחר שכל המשתמשים עברו וכל נקודות הקצה עברו לרישום ענן (או הוצאו משימוש), עדכן את הת שתית המקומית המתאימה כעת כאשר שיחות ענן נמצאות בשימוש. עדכוני התשתית כוללים:

הסר רשומות בקרת שיחות והודעות מקומ DNS SRV יות משרתי ה- DNS המקומיים כולל cisco_uds. _tcp. <domain>, כניס ה_כוס. _tcp. <domain>. רשומות SRV אלה אינן נדרשות עוד לגילוי שירות לקוחות.

הסר רש DNS SRV ומות הקשורות לקצה ממערכת ה- DNS הציבורית כולל collab_edge. _tls. <domain>. רשומות SRV אלה אינן נדרשות עוד לגילוי שירות לקוחות של שירותי קצה לשיתוף פעולה.

עדכן את כל היקפי DHCP הרלוונטיים כדי להסיר את האפשרות 66 ואת כתובות שרת TFTP/אתחול אפשרות 150. היקפים אלה אינם נדרשים עוד לגילוי וה ורדה של תצורת בקרת שיחות נקודות קצה.

עדכן/הסר עמיתים חיוגים מתאימים בשער מקומי/קובייה שמנתבים שיחות אל וממנה. Unified CM עמיתים בחיוג אלה אינם נדרשים עוד לניתוב שיחות מקומיות.

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

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

ניקוי: לאחר העברת גישת PSTN ל- PSTN המחובר לענן, ניתן לבטל גזעי PSTN, שערי PSTN ושער מקומי.

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

DNs השייכים למשתמשים שהועברו צריכים להיות ממוקמים במ חיצה נסתרת כדי למנוע כשלים בניתוב שיחות וכדי להבטיח שלכל ה- CSS יש גישה עדיפה לנתיב הענן של אותם DNs.

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

החלפת מתג רשת

החלפת נקודת גישה אלחוטית

שינויים בהיקף DHCP

שינויים פיזיים בתוך הבניין (אם נפתרים לקובית/משרד)

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

השתמש בניתוח ופתרון בעיות

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

ניתוח איכות מדיה

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

פתרון בעיות באיכות המדיה

פתרון בעיות יכול להשתלב גם עם מוצרים אחרים של סיסקו כמו מתגי ThousandEyes ו- Meraki כדי לספק חוויה משולבת עשירה עוד יותר ב- Control Hub. לקבלת מידע נוסף על שימוש בניתוח Webex Callingופתרון בעיות, ראה פתרון בעיות בשי Webex Calling חות ב- Control Hub.

מבוא

לפני שתתחיל

סקירה כללית

רכיבי ליבה

סקירת תהליך PPDIO

תיאור כללי של PPDIO

שימוש ב- PPDIO עבור פרויקטים Unified CM של Webex Calling הגירה

הכן

תוכנית

עיצוב

ליישם

אופטימיזציה

לולאות משוב PPDIO

גישת הגירה

לפני שתתחיל

מדריך זה מיועד לצוותים או אנשים עם ניסיון בתצורה וניהול של Cisco Unified Communications Manager (Unified CM) ונקודות קצה של סיסקו, כולל טלפונים לשולחן IP, התקני וידאו ולקוחות רכים של Jabber. לאורך מסמך זה, ישנם קישורים לתיעוד מוצר ותמיכה שיסייעו.

מסמך זה מתמקד במעברים Webex Calling מרו Unified CM בי דיירים בלבד. המונח Webex Callingבמסמך זה מתייחס תמיד לדיירים Webex Calling מרובים.

לפני תחילת ההגירה מ Unified CM - אלWebex Calling, חובה לקבל הבנה מקיפה של הפ Webex Calling תרון ומרכיביו בהתאמה. העברה מוצלחת דורשת היכרות עם הא Webex Calling רכיטקטורה, דגמי השירות, אפשרויות הפריסה והתכונות הנלוות כדי למפות כראוי Unified CM עומסי עבודה קיימים ולעצב תוכנית מעבר יעילה.

הבנה מעמיקה של Webex Calling המרכיבים הבאים חיונית כדי ליידע אסטרטגיית מעבר יעילה ונכונות תפעול ית.

רכזת בקרה

הקצאת ספריות ומשתמשים

Webex Callingפלטפורמה

נקודות קצה מתקשרות נתמכות

אפשרויות קישוריות PSTN

Webex Callingתוכנית חיוג וניהול מספרים

תכונות אבטחה ותאימות.

לקבלת מידע נוסף, ראה א רכיטקטורה מועדפת של סיסקו עבורWebex Calling.

מדריך זה ידגיש כלים ותהליכים לשימוש לאורך מחזור החיים של המעבר. עם זאת, מעבר משיחות מקומיותUnified CM, לפלטפורמת שיחות ענן חדשה,Webex Calling, יכול להיות מאמץ משמעותי עם אתגרים עסקיים, טכניים ומורכבים פוטנציאליים. כדי לעזור להתגבר על אתגרים אלה, לסיסקו יש כמה אפשרויות שונות זמינות שיסייעו לך במסע שלך. חשוב לעיין במידע ב- Enterprise Cloud Calling - העברת שיחות ול הבין כל אפשרות וכיצד כל אחת מהן יכולה לעזור לך בהעברה שלך.

כלי העברה של Webex: שירות עצמי, כלים חינמיים המובנים ב- Control Hub כדי לייעל את המעבר שלך ל Webex Calling

ספקי העברה מוסמכים: ספקי תוכנה וכלים מאומתים של סיסקו ש פיתחו פתרונות העברה כדי לסייע לשותפים ולקוחות Webex בהעברות מורכבות וגדולות. פתרונות אלה יכולים לעזור לפשט, לנהל ולהאיץ את המעבר Webex Calling

Webex Setup Assist: שירות העברה בהנחיית Cisco שמנחה לקוחות ו שותפים דרך Webex Calling הפריסה והתצורה, הדרושים כדי להעביר בהצלחה Unified CM משתמשים ושירותים אל. Webex Calling

סקירה כללית

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

מטרת מסמך זה היא לספק הנחיות פריסה ללקוחות המע וניינים במיוחד לעבור מהמק Unified CM ומי Webex Calling לענן. מדריך פריסה זה מניח שלקורא יש הבנה בסיסית של מעבר השיחות בין Unified CM לביןWebex Calling, כולל אילו שינויים בעת ביצוע המעבר הזה ומה ההבדלים בעת העברת עומס העבודה של השיחות מהמקומי לענן. לפני שתמשיך, ודא ש בדקת ומכיר את המידע הזמין במ פת המעבר. מסמך מפת מעבר זה מספק מידע על השינויים וההבדלים במעבר זה.

כפי שמוצג באיור ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות ו גישה מרחוק, פריסה מקומית טיפוסית כוללת רכיבי תשתית שיתוף פעולה שונים ברשת, פלטפורמת בקרת שיחות, פלטפורמת קצה, נקודות קצה של חומרה ותוכנה, ובמקרים מסוימים אפילו פלטפורמות ועידה ותזמון. בא רכיטקטורת סיסקו זה יכלול Unified CM בקרת שיחות, Expressway לגישה מרחוק ושירותי קצה בין עסקים לעסק (B2B), שרת ישיבות סיסקו/ניהול פגישות של סי סקו לוועידה מקומית, חיבור Unity להעברת הודעות קוליות וחומרה הפונה למשתמש (טלפונים IP של סיסקו, מערכות וידיאו של Cisco Desk and Room) ותוכנה () נקודות קצה מבוססות IP. Cisco Jabber רכיבים אלה עשויים להשתנות מעט בסביבות מסוימות, אך זוהי נקודת המוצא למעבר המתואר בשאר מסמך זה.

ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות וגישה מרחוק

הארכיטקטורה המוצגת באיור ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות וגישה מרחוק מבוס סת על הארכיטקטורה המועדפת (PA) עבור פריסות מקומיות ארגוניות של Cisco Collaboration. לקבלת מידע נוסף על הארגון המקומי, ראה א רכיטקטורות מועדפות לשיתוף פעולה של סיסקו.

לפני: טבלת רכיבי תשתית להתקש רות מקומית מפרטת את רכיבי המפתח של הארכיטקטורה המקומית לפני המעבר לענןWebex Calling.

טבלה 1. לפני: רכיבי תשתית להתקשרות מקומית
מוצר תיאור

Unified CM בקרת שיחות מקומית המספקת שירותי רישום מכשירים וניתוב שיחות

Cisco Expressway-C/E תשתית קצה המספקת פונקציונליות ניידת ו- Remote Access (MRA) ועסק לעסק (B2B) המאפשרת לנקודות קצה מרוחקות להתחבר בצורה מאובטחת מחוץ לארגון. הכביש המהיר נפרס בזוגות כדי לספק מעבר חומת אש לנ קודות קצה חיצוניות.

שרת פגישות של סיסקו (CMS), ניהול פגישות של סיסקו (CMM) וחבילת ניהול טל נוכחות של סיסקו (TMS) תשתית ועידה קולית, וידאו ואינטרנט מקומית המספקת יכולות של פגישות מרובות נקודות, ניהול פגישות ותזמון. [אופציונלי]

Cisco Unity Connection פלטפורמת העברת הודעות קוליות מקומית המספקת יכולות דואר קולי והודעות מאוחדות. [אופציונלי]

שולחן סיסקו, חדר סיסקו, לוח סיסקו, טלפוני IP של סיסקו ו Cisco Jabber התקנים מבוססי IP הרשומים Unified CM ומספקים יכולות שיחות קוליות ווידאו

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

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

דגמי טלפון שאינם נתמכים על ידי Webex Calling

שילובים מורכבים או רבים עם מערכות או פתרונות מקומיים אחרים, במיוחד כאשר שכפול אינטגרציות אלה עם זה Webex Calling קשה או שאין פתרונות חלופיים שווים זמינים

תוכנית חיוג מורכבת, מחלקות שירות מפורטות ביותר או שניהם

גישה לאינטרנט מגבילה, מוגבלת או לא אמינה

מדיניות מחמירה בנושא פרטיות נתונים ובעלות

דרישת תאימות להקלטה ואחסון מדיה מקומית או בארץ

שילובים של צד שלישי ללא אינטגרציה חלו Webex Calling פית בת קיימא

שילובי מוקדי קשר שבהם מרכז הקשר אינטר עדיין לא עובר לע נן.

החלטת מעבר: קריאה מקומית ל Webex Calling
לקוחות המעוניינים להתחיל למנף שירותי שיחות בענן צריכים לשקולWebex Calling. שירות שיחות ענן זה מאפשר ללקוח למנף את הארכיטקטורה העולמית של Webex לצורך קנה מידה וקישוריות. משתתפים ברשת הארגונית ומשתתפים מרו חקים מחוץ לרשת הארגונית יכולים לתקשר באמצעות נקודות קצה חומרה מבוססות IP ו/או יישומי לקוח רך לשולחן העבודה או הנייד.

מסמך זה מתמקד בלקוחות עם פריסות בקרת Unified CM שיחות שרוצים להבין את השלבים הכלליים, השיקולים והד רישות להפעלת Webex Calling פריסה כמתואר בסעיף הבא.

רכיבי ליבה

ארכיטקטורת היעד להעברה זו כוללת מספר רכיבים חדשים. זה כולל את Webex Calling השירות לשיחות מבוססות ענן, אפליקציית Webex, מחבר ספריות של Cisco לשילוב זהויות ושער מקומי (LGW) ל גישה ל- PSTN, כמו גם שילוב מקומי לשיחות בענן. תוכניות שיחות של סיסקו או PSTN מחובר לענן (CCP) המופעלות על ידי Cloud Connect עבור שו Webex Calling תף הן אפשרויות נוספות לגישה ל- PSTN.

כפי שמוצג באיור לאחר: א Webex Calling רכיטקטורה, הרכיבים החד Webex Calling שים (מחבר ספרייה, שער מקומי ושער שרידות) מתווספים לפריסה המקומית הקי ימת.

אחרי: Webex Calling אדריכלות

אחרי: טבלת רכיבי תשתית להתקשרות בענן מפרטת את האלמנטים החדשים של הא רכיטקטורה לאחר המעבר ל- Webex.

טבלה 2. אחרי: רכיבי תשתית לשיחות ענן
מוצר תיאור

Webex Calling שירות שיחות מבוסס ענן המועבר מפלטפורמת Webex ומספק רישום נקודות קצה וניתוב שיחות

מחבר ספריית סיסקו יישום Windows הפועל במחשב תחום של Windows המספק ס נכרון זהות בין הארגון המקומי Active Directory לבין מאגר הזהו יות של ארגון Webex.
עבור לקוחות העוברים ממזהה מקומי Active Directory ל- Entra ID, שילוב הזהות עם Webex במקום Cisco Directory Connector משתמש ביישום אשף זיהוי Entra.

שער מקומי שער מקומי משמש כגשר בין רשת התקשורת המאוחדת המקומית של הלקוח לבין הע Webex Calling נן. ניתן לפרוס אותו במקום או לארח אותו על ידי שותף, ולספק גישת PSTN לנקודות קצה הרשומות בענן, כמו גם שילוב שיחות בין Unified CM נקודות קצה רשומות ונקודות קצה רשומות בענן. Cisco IOSנתב שירותים משולבים XE (סדרת ISR 1100 ו- 4000), סדרת Cisco Catalyst 8200/8300, תו כנת קצה של Cisco Catalyst 8000V ובקרי גבול הפעלה שונים של צד שלישי מוסמכים (SBC) יכולים לשמש כ- LGW לגישת הגירה בשלבים.

שער שרידות שער שרידות (SGW) הוא שער מבוסס IOS-XE ברשת מקומית המספק שירותי שיחות חזרה לנ קודות קצה באתר Webex Calling במהלך הפסקות רשת.

תוכנית שיחות של סיסקו, חיבור לענן עבור Webex Calling תוכנית השיחות של Cisco ו- Cloud Connect for Webex Calling הן אפשרויות מבוססות ענן לגישה PSTN לנקודות קצה. Webex Calling גישה ל- PSTN מקלה על ידי ספק PSTN בענן ואינה דורשת ציוד מקומי.

אפליקציית Webex יישום לקוח פועל במערכת הפעלה שולחנית (Windows, Mac) או מערכת הפעלה ניידת (Android, iOS) ונרשם ישירות לפ Webex Calling לטפורמה לפונקציונליות שיחות.

סקירת תהליך PPDIO

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

תהליך PPDIO

תיאור כללי של PPDIO

הכן: הערך את הסביבה הנוכחית, אסוף דרישות ויישר בעלי עניין כדי ליצור בסיס איתן.

תכנית: פיתוח תוכניות פרויקטים מפורטות הכוללות לוחות זמנים, משאבים ואסטרטגיות להפחתת סיכונים.

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

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

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

שימוש ב- PPDIO עבור פרויקטים Unified CM של Webex Calling הגירה

בעת המעבר מ- Unified CMWebex Calling, תהליך PPDIO מספק מפת דרכים ברורה להבטחת מעבר חלק ויעיל:

הכן

להעריך את Unified CM הסביבה הקיימת ואת מוכנות ההגירה

איסוף נתונים מפורטים על משתמשים, מכשירים, רשת ותלות

אסוף פרטי מיקום כולל כתובת תגובת חירום, מספר משתמשים, גישה לאינטרנט, גישה ל- PSTN

זהה סיכונים והגדר את היקף הפרויקט כדי ליישר את כל בעלי העניין.

תוכנית

יצירת תוכנית העברה מקיפה עם לוחות זמנים של אצווה, הקצאות משאבים ולוחות זמנים

הגדרת משימות כגון שדרוגי קושחת מכשירים, הקצאת רישיונות והקלטת משתמשים

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

עיצוב

מיפוי Unified CM תצורות נוכחיות, תוכניות חיוג ופרופילי משתמשים למק Webex Calling בילים

תכנן את Webex Calling הסביבה, כולל אסטרטגיית PSTN (ביניים וסופית), מיקומים, תפקידי משתמש ונקודות אינטגרציה כמו שער מקומי (CUBE) וסנכרון ספריות

תכנן תרחישי דו קיום שבו Unified CM ות Webex Calling פעלו בו זמנית במהלך ההגירה.

ליישם

השתמש בכלי העברת Control Hub לצד כלים של צד שלישי כדי לבצע שינויים במצב קושחה של המכשיר, תצורת תכונות והעברות משתמשים

השתמש בפעולות ובהקצאה בכמות גדולה באמצעות ממשקי API של Webex כדי לייעל העברות ותצורות בקנה מידה גדול

ביצוע הקצאת רישיונות, רישום מכשירים ועדכוני תצורה

אימות הצלחת ההעברה באמצעות בדיקות ו אימות תפעולי.

אופטימיזציה

מעקב רציף Webex Calling אחר הביצועים וחוויית המשתמש

חידוד תצורות וזרימות עבודה בהתבסס על נתונים תפעוליים ומשוב

מינוף יכולות אוטומציה ואינטגרציה לשיפור היעילות והמדר גיות

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

גישת PPDIO משופרת זו מבטיחה העברה מבוקרת, שקופה ויעילה מ- אל, תוך מינוף Unified CM הכליםWebex Calling, ממשקי ה- API והמערכת האקולוגית של השותפים של סיסקו כדי לשמור על המשכיות עסקית ולש פר את יכולות שיתוף הפעולה.

לולאות משוב PPDIO

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

איטרציות בעת ביצוע PPDIO

במהלך ביצוע תהליך ה- PPDIO, מקובל שממצאים בשלבים המאוחרים יחייבו בדיקה מחודשת ואולי תיקון החלטות שהתקבלו בשלבים מוקדמים יותר. לדוגמה, בעיות שנתקלו בשלב היישום, כגון זיהוי עמימות עי צובית או פרטים חסרים, עשויות לחשוף כי היבטים מסוימים לא טופלו במלו אם בשלב התכנון. במקרים כאלה, יש צורך לחזור לשלב הקודם הר לוונטי כדי לפתור בעיות אלה לפני שתמשיך. מנגנון משוב איטרטיבי זה, כפי שמודגם בתהליך PPDI Unified CM O בסיוע איור מבטיח שהפ תרון מאומת ומעודן ביסודיות, ובסופו של דבר תורם לפריסה חזקה וי עילה יותר.

Unified CMתהליך PPDIO בסיוע

כאשר מבצעים מעבר מ- Unified CM לWebex Calling, כל שלב בתהליך PPDIO יכול להפיק תועלת משמעותית ממידע שנאסף מ Unified CM הסביבה הקיימת. לדוגמה, ניתן לחלץ מלאי מקיף של משתמשים, מספרי טלפון, תכונות שיחות ורכיבי תוכנית חיוג מהת Unified CM צורה הנוכחית. נתונים אלה משלימים מידע המסופק ישירות על ידי בעלי העניין ומ סייעים לייעל פעילויות תכנון ועיצוב. מינוף כלים מתאימים לאוטומציה של חילוץ וניתוח נתונים לא רק משפר את הדיוק אלא גם מאיץ את התהליך הכולל. על ידי ניצול תובנות מהפריסה הקיימת, Webex Calling ניתן לבצע את המעבר בצורה יעילה יותר מאשר יישום גרינפילד מסורתי, תוך שמירה על מתודולוגיית PPDIO המובנית. תהליך זה מודגם בתהליך PPDIO Unified CM בסיוע איור.

גישת הגירה

כשאתה מתכנן את המעבר שלך מהמק Unified CM ומי ל-Webex Calling, עליך לקבוע כיצד תתקרב למסע זה. ראשית תצטרך להחליט אם ה העברה תהיה חיתוך פלאש (הכל בבת אחת) או גישה שלבית (העברת קבוצות של משת משים/מכשירים לאורך תקופה ממושכת).

ביצוע העברה מסוג flash-cut מזי ז את כל המשתמשים והמכשירים שלך בצורה המהירה ביותר. בשיטה זו, תעביר את כל המשתמשים והמכשירים מק Unified CM ומי Webex Calling לאותו זמן. בעיקרו של דבר, זהו חלון העברה יחיד עבור כל המשתמשים והמכשירים. לאחר השלמת ההעברה, כל המשתמשים והמכשירים שלך יהיו בפ Webex Calling לטפורמה וניתן להשבית את כל הת Unified CM שתית שלך. עם זאת, ארגונים רבים אינם יכולים להשתמש בגישה זו בשל היקף וגודל פריסת השיחות שלהם.

הגישה השנייה היא הגירה בשלבים. רוב הארגונים ישתמשו בגישה זו מכיוון שהיא מספקת שליטה, ניהול וגודל טובים יותר עם ההעברה. כמו כן, הוא מתאים יותר לפריסות ו/או פריסות UC גדולות יותר באזורים מרובים. לכן, מסמך זה מתמקד בגישה השל בית עם שני שלבים במעבר.

כפי שמוצג להלן איור מעבר שיחות בשלבים: היברידי וענן, שלב המעבר הראשון (שלב 1) מביא לפריסת קיום דו-קיום עם סביבות שיחות כפולות. בשלב זה, חלק מהמשתמשים, המכשירים והלקוחות הרכים עוברים אליהם Webex Calling בעוד שאחרים עדיין נמצאים בבקרת השיחות המקומיתUnified CM. שלב המעבר הסופי (שלב 2) מביא לסביבת שיחות ענן טהורה שבה כל המשתמשים, המכשירים והלקוחות הרכים הועברו במלואם לפ Webex Calling לטפורמה.

משך הזמן שלוקח לארגון לעבור לחלוטין לשיחות ענן ישתנה בהתאם לפריסה הנוכחית שלו. במקרים מסוימים, ארגון עשוי לבצע את המעבר הראשוני ולהי שאר בשלב בקרת השיחות הכפולות הדו-קיום (שלב 1) לתקופה ממושכת (חודשים ואף שנים), ואילו במקרים אחרים, ארגון עשוי לעבור באופן מלא ל Webex Calling (שלב 2) בפרק זמן קצר מאוד (שבועות או חודשים). מסמך זה נועד לכסות את שני השלבים (שלב 1 - דו קיום ושלב 2 - מעבר מלא).

מעבר שיחות בשלבים: היברידי וענן

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

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

מעבר תלת פאזי מומלץ

טרום העברה: שלב זה מתמקד בהכנת Webex והסבי Unified CM בות להגירה. זה לא קשור להתקשרות לתכנון או תצורות ספציפיות ומתמקד בהשלמת פעילויות שניתן לבצע כעת ולפני תחילת פרויקט Webex Calling העברה כלשהו. המטרה היא לבנות את הבסיס לשתי הסביבות להת כונן להגירה.

הכנה להגירה: שלב זה הוא המקום בו המאמץ מתחיל להתכונן להגירה אל Webex Calling. כאן יש לבחון ולעדכן את הדרישות העסקיות והטכניות. אל תעשה רק הע לאה והעברה של מה שנפרס איתו Unified CM כרגע, אלא הגדר מחדש את הדרישות העסקיות והטכניות שהחברה שלך זקוקה להם היום ובעתיד על ידי מינוף הכוח של. Webex Calling בנוסף, זהו השלב בו תשלים את העיצוב, תכנון התצורה ותכנונ/לוח הזמנים של ההעברה.

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

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

איור פעילויות טרום הגירה להלן מדגיש חמש קטגוריות ספציפיות של פעילויות הקשורות להגי Webex Calling רה.

פעילויות לפני הגירה

הכן

דרישות עסקיות וטכניות

מדוע איסוף דרישות חשוב:

דרישות עסקיות

דרישות טכניות

מוכנות רשת ודרישות

הגדרת UC המחובר לענן

הערכת הסביבה הנוכחית

רישוי

מיקומות/אתרים

מלאי התקנים/לקוחות קיימים

בדוק את זכאות המכשיר

משתמשים

קישוריות PSTN

תכונות ושימוש בתכונות

שילובים של סיסקו: חיבור יוניטי UCCX UCCE

הקלטת שיחות

שילובים של צד שלישי

דרישות עסקיות וטכניות

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

מדוע איסוף דרישות חשוב:

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

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

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

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

דרישות עסקיות

דרישות עסקיות אופייניות כוללות:

מספר המשתמשים והמיקומים שיש להעביר

תכונות ושירותים רצויים (לדוגמה, ניתוב שיחות, דואר קולי, ועידה, דיילים אוטומטיים, תורי שיחות)

מדיניות תאימות ואבטחה

אילוצי תקציב וציפיות עלות

הדרכת משתמשים וצרכי תמיכה

ציר זמן הגירה ושיקולי המשכיות עסקית.

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

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

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

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

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

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

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

ביקורת ומעקב: יישום יכולות רישום וניטור למעקב אחר גישה ושימוש לביקורות תאימות וחקירות אירועי אבטחה.

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

אבטחת אבטחת ספק: הערכת אישורי האבטחה ואישורי התאימות של סיסקו כדי להבטיח אמינות.

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

הדרכת משתמשים וצרכי תמיכה הם מרכיבים חיוניים במהלך ההעברה מ- אל כדי להבטיח מעבר חלק ואימוץ משתמשים. שיקולים מרכזיים כוללים:

תוכניות הדרכה: פיתוח הדרכות מותאמות לקבוצות משתמשים שונות (משתמשי קצה, מנהלי מערכת, צוות דלפק העזרה) כדי להכיר להם תכונות, ממשקי משתמש וזרימות עבודה חדשות.

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

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

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

חינוך שוטף: תכנן עדכוני הדרכה רציפים כאשר תכונות או עדכונים חדשים י פורסמו ב.

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

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

דרישות טכניות

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

מוכנות רשת ויכולת רוחב פס

הערכת רשת מקיפה היא קריטית כדי להבטיח שהתשתית הקיימת שלך יכולה לתמוך Webex Calling בסביבה החדשה. זה כולל:

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

איכות השירות (QoS): יישום מדיניות QoS לתעדף תעבורה קולית ולמזעור חביון, ריצוד ואובדן מנות.

קישוריות WAN ואינטרנט: אימות שקישורי WAN ו חיבורי אינטרנט עומדים בדרישות לשיחות מבוססות ענן, כולל יכולות יתירות ומעבר לכי שלון.

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

אינטגרציה עם המערכת הקיימת

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

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

CRM ויישומים עסקיים: זיהוי נקודות אינטגרציה עם מערכות ניהול קשרי לקוחות ויישומים קריטיים אחרים לעסקים.

עבודה משותפת של מרכזייה מדור קודם: תכנון לדו-קיום או אסטרטגיות העברה בשלבים אם יישארו מערכות טלפוניה מדור קודם במהלך המעבר.

תאימות והקצאה של נקודות קצה

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

תמיכה במכשירים: אישור כי טלפונים והתקני IP קיימים נתמכים על ידי החלפות נדרשות או מזהים אותם.

תהליכי הקצאה: הק מת שיטות הקצאה אוטומטיות או יעילות לצורך כניסה יעילה של נקודות קצה.

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

תצורות אבטחה ותקני הצפנה

אבטחה היא בעלת חשיבות עליונה בתקשורת ענן:

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

אימות ובקרת גישה: הטמעת מנגנוני אימות מאובטחים (כגון SSO, אימות רב-גורמי) ובקרות גישה גרעיניות למשתמשים.

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

ניטור אבטחה: שילוב עם כלי SIEM והגדרת התראה על אירועי אבטחה פוטנציאליים.

טבלה 1. הערכת דוגמה
דרישה שיקולים מרכזיים

מוכנות רשת ורוחב פס רוחב פס, QoS, WAN/אינטרנט, חומת האש/NAT

אינטגרציה עם מערכות קיימות מדריך, CRM, מרכזייה, דוא"ל/לוח שנה

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

תצורות אבטחה והצפנה הצפנה, אימות, תאימות, ניטור אבטחה

הדרכת משתמשים וניהול שינויים תוכניות הדרכה, תיעוד, שינוי תקשורת

ניידות מספרים ותכנית חיוג העברה/העברת מספרים, תרגום תוכנית חיוג

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

מוכנות רשת ודרישות

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

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

ללקוחות ולשותפים יש גישה לאפשרויות קישוריות מעבר לאינטרנט Over-the-Top (OTT) שיכולות לייעל את החיבור לכלול Webex Edge את Connect. לקבלת מידע נוסף על פרטי עיצוב Webex Edge Connect, ראה א רכיטקטורה מועדפת של Cisco עבור Webex Edge Connect עבורWebex Meetings, התקשרות למספר דיירים ומופע ייעודי .

לקוחות יכולים להשתמש ב- cScan להערכת רשת המספקת מידע על איכות הרשת של הלקוח, כמה שיחות ניתן ליצור, חביון וכן הלאה. לקבלת מידע נוסף על הכלי cScan, ראה שימוש ב- cScan לבדיקת איכות Webex Calling הרשת.

כדי להבטיח שהרשת מוכנה להעברה אל, שקול את רשימת הבדיקה הבאה:

תכנון רוחב פס

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

ט Webex Calling בלת חי שובי רוחב הפס של סוג השיחה מציגה את סוגי השיחות הזמינים עם פריסה יחד עם ה- codec ורוחב הפס המ רבי הנדרש עבור כל סוג שיחה. כפי שמוצג בטבלת חי Webex Callingשובי רוחב הפס של סוג השיחה ניתן לחשב את רוחב הפס הנדרש לשיחת שמע עבור כל סוג שיחה באמצעות הנוסחה הכללית הבאה:

מספר שיחות במקביל צפויות * רוחב פס לשיחה בהת בסס על codec = תפוקת רשת נדרשת.
טבלה 2. Webex Callingחישובי רוחב פס מסוג שי חה
סוגי שיחות קודק - רוחב פס חישובי רוחב פס
/טלפון שולחני -> אופוס - 70 קילו-ביט לשנייה מספר שיחות במקביל * 70 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> טלפון שולחני אופוס - 70 קילו-ביט לשנייה מספר שיחות במקביל * 70 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> PSTN באמצעות LGW G.711 - 80 קילו-ביט לשנייה מספר שיחות במקביל * 80 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> PSTN באמצעות PSTN בענן (למשל תוכנית שיחות של סיסקו) G.711 - 80 קילו-ביט לשנייה מספר שיחות במקביל * 80 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> ארגוני באמצעות LGW G.722 - 80 קילו-ביט לשנייה מספר שיחות במקביל * 80 kbps = תפוקת רשת נדרשת
/טלפון שולחני -> דואר קולי אופוס - 70 קילו-ביט לשנייה מספר שיחות במקביל * 70 kbps = תפוקת רשת נדרשת

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

כל רגלי השיחה מעוגנות תמיד על SBC הגישה. כדי לקבוע את רוחב הפס הנדרש לאינטרנט עבור כל מיקום נתון, לא רק יש לקחת בחשבון את השיחות בין המיקומים, אלא גם שיחות תוך מיקום ושיחות לשער מקומי וממנו באותו מיקום. לדוגמה, שיחה בתוך האתר בין שני טלפונים MPP תצטרך עד 2 x 70 kbps דופלקס מלא בגישה לאינטרנט של המיקום.

ט Webex Callingבלת הדוגמאות לחישוב רוחב הפס מציגה דוגמה לת רגיל חישוב רוחב פס מלא, בהנחה שכל המכשירים נמצאים באותו אתר.
טבלה 3. Webex Calling דוגמאות לחישוב רוחב פס
סוגי שיחות מספר שיחות במקביל רוחב פס כולל
אפליקציית Webex/טלפון שולחני → אפליקציית Webex 15 2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → טלפון שולחני 15 2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → PSTN באמצעות LGW 50 2* 50* 80 קילו-ביט לשנייה = 8,000 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → PSTN באמצעות חיבור ענן עבור Webex Calling 0 0* 80 קילו-סיביות לשנייה
אפליקציית Webex/טלפון שולחני → ארגוני באמצעות LGW 15 2* 15* 80 קילו-ביט לשנייה = 2,400 קילו-ביט לשנייה
אפליקציית Webex/טלפון שולחני → דואר קולי Webex Calling 5 5* 70 קילו-ביט לשנייה = 350 קילו-ביט לשנייה
סה"כ שיחות/רוחב פס 100 שיחות 14,950 קילו-ביט לשנייה/14.95 מגהביט לשנייה

כל ערכי רוחב הפס בטבלאות לעיל מתי יחסים לרוחב פס IP. רוחב הפס של הקישור גבוה יותר בהתאם לאנקפסולציות WAN.

רוחב הפס בטבלאות לעיל מיועד לשי חות שמע. עבור רוחב פס של שיחות וידאו, Webex App וטלפונים MPP 8845/65 תומכים בוידאו H.264 ברזולוציה מקסימלית של 720p ברוחב פס מרבי של 1,500 kbps לשיחה. עם זאת, כמות רוחב הפס הנצרכת בכל נקודה במהלך השיחה תשתנה בהתבסס על קצב סיביות משתנה הטמון בתקשורת וידאו.

איכות השירות (QoS)

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

יעדי חביון, ריצוד ואובדן מנות

הספים הבאים מומלצים לאי כות קול מיטבית כאשר שיחות עוברות מעבר לכל היותר (OTT) וברחבי האינטרנט :

חביון - פחות מ 100ms בכיוון אחד

ריצוד - פחות מ -10 אלפיות השנייה

אובדן מנות - 0.5% או פחות.

חומת אש ו- NAT

ודא שחומת האש מוגדרת כך שתאפשר תנועה כמפורט במאמר הזמין ב מידע הפניה ליציאה עבור Webex Calling. בנוסף, אפשר גישה לת חומים ולטווחי IP המפורטים באותו מדריך והימנע מ- SIP ALG מכיוון שהוא מפריע לאיתות SIP. יש להימנע מת עבורת מדיה באמצעות פרוקסי.

DNS ו- NTP

ודא רזולוציית DNS נכונה של דומיינים ושרתי NTP אמינים כדי לסנכרן שעוני מכשירים לאימות ורישום אישור TLS.

תכנון גיבוי כשל

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

שרידות האתר

שרידות האתר מבטיחה שהעסק שלך יהיה נגיש תמיד, גם אם חיבור הרשת שלך נשבר. Site Survibility משתמשת בשער ברשת המקומית שלך כדי לספק שירות שיחות חזרה לנ קודות קצה באתר במצבים שבהם חיבור הרשת נשבר. שקול את שרידות האתר באמצעות שער שרידות מקומי (SGW) אם דרישות עסקיות דורשות שיחה רציפה במקרה של הפסקת רשת. ל מידע נוסף על בדיקת שרידות האתר, ראה שרידות האתר עבור. Webex Calling

הגדרת UC המחובר לענן

Cloud Connected UC (CCUC) הוא פתרון ניהול וניתוח מבוסס ענן שנועד לספק נראות, ניהול ותובנות מרכזיות לפריסות מקומיות (כגון) ובענן (Unified CM). הוא משמש כגשר בין סביבות מקומיות מסורתיות לבין שירותי הענן של סיסקו, ותומך בארגונים לאורך מסע ההעברה מ- אל.

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

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

הערכת הסביבה הנוכחית

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

חשוב לבחון את ההיבטים הבאים כחלק מהמאמץ הזה.

רישוי

הבנת מבנה הרישוי הנוכחי של הפריסה הקיימת היא המפתח בעת ההכנה להעברה אל. בצע הערכת רישיון של האזורים הבאים ב פתרון המקומי הקיים של Cisco.

פלטפורמה

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

משתמשים ומכשירים

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

שער מקומי

אם Cisco Unified Border Element (CUBE) נדרש לגישה PSTN למע בר זה, יש לשקול גם רישוי CUBE. שיקולי רישוי CUBE מכוסים בהמשך מסמך זה.

מיקומות/אתרים

יש לקחת בחשבון את מספר וסוגי האתרים (מרכזי גדול, אזורי, סניף וכן הלאה) בפ ריסה הקיימת שלך בעת תכנון המעבר הזה. הבנה מלאה של אתרי הפריסה הקיימים תסייע בתכנון אסטרטגי למע בר מוצלח במיוחד כשמדובר בקביעת אילו אתרים להעביר ובאיזה סדר. הבנה מפורטת של דרישות תוכנית חיוג (מספור, הרגלי חיוג, סוגי הגבלה וכן הלאה), קישוריות רשת האתר ורוחב הפס (אינטרנט, WAN, LAN) וגישה ל- PSTN (מקומית או מרכזית, IP או TDM) עבור כל אתר תהיה קריטית בעת קבלת החלטות הגירה. לקבלת מידע נוסף על מודלים נפוצים של פריסה ושיקולים מרכזיים, עיין במידע על מודלים של פריסת שיתוף פעולה הזמין ב- SRND של שיתוף פעולה.

שיקול פריסה חשוב נוסף בעת המעבר אליו הוא זמינות המיקום. יש יכולות, מנויים והתקנים שונים הזמינים בהתאם למיקום הפריסה שלך. לקבלת מידע נוסף על זמינות גיאוגרפית, ראה היכן Webex זמין? .

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

מלאי התקנים/לקוחות קיימים

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

טלפונים שולחניים

לטלפונים שולחניים אודיו ווידאו נתמכים רק בטלפונים השולחניים מסדרת 6800, 7800, 8800 ו- 9800. זוהי תת-קבוצה של טלפוני ה- IP של סיסקו הנתמכים איתם. ישנם כמה דגמים וגרסאות של הטלפונים 6800, 7800 ו- 8800 שלא ניתן להשתמש בהם. לקבלת מידע נוסף על אילו דגמים וגרסאות חומרה נתמכות, ראה התקנים נתמכים עבור Webex Calling.

לא ניתן לשדרג את טלפוני ה- IP מסדרת Cisco 6800 מקושחה ארגונית לקושחה מרו בת פלטפורמות (MPP), הנדרשת עבור. לכן כל 6800 טלפונים הרשומים לקושחה ארגונית פועלת חייבים להיות מוחלפים בדגם 6800 MPP או בדגם טלפון נתמך אחר.

יש לשדרג את טלפוני ה- IP מסדרת Cisco 7800 ו- 8800 לקושחת טלפון רב-פלטפורמה (MPP) לפני המעבר ורישוםם. כדי לקבוע אילו דגמים וגרסאות חומרה של 7800 ו- 8800 תומכים בקושחת MPP, ראה המרת טלפונים IP מסדרת Cisco 7800 ו- 8800 בין קושחת ארגונית ו- MPP.

8845, 8865 ו- 8865NR הגיעו לסוף המכירה ולא מומלץ להעביר אליהם.

גרסאות ישנות יותר של הטלפונים מסדרת 8800 (8811, 8841, 8851, 8851NR, 8861) אינן מומלצות לשימוש. Webex Calling טלפונים עם גרסאות חומרה VID 14 ומעלה יירשמו אך עשויים להיתקל בבעיות ביצועים מסוימות עקב החומרה.

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

יהיה צורך להחליף את כל טלפוני ה- IP האחרים בטלפונים מסדרת 6800, 7800, 8800 או 9800 הנתמכים על ידי. Webex Calling לקבלת מידע נוסף על מכשירי IP וטלפונים שולח ניים נתמכים עם, עיין במאמר ב התקנים נתמכים עבור Webex Calling.

נקודות קצה של וידאו

נקודות קצה של וידאו אישיות וחדרים, כולל סדרת Cisco Board, סדרת Room ו סדרת Desk, יכולות להירשם ל- SIP באופן מקורי. כל אחת מנקודות הקצה האלה שצריכות לבצע שיחות שמע ו/או PSTN דורשת רישיון שיחה:

התקנים משותפים בחדרי ישיבות, חללי הצטופפות וכו' דורשים רישיון Professional Workspace או Workspace.

המכשיר האישי של משתמש קצה דורש רישיון מקצועי או סטנדרטי.

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

כאשר התקני וידאו מועברים מרישום אל, ה- URI של נקודות קצה אלה ישתנה מכיוון שהם רשומים כעת בענן.

דגמי הטלפון 8845, 8865 ו- 8875 הם טלפונים וידאו אישיים הנתמכים עם.

לקוחות רכים

זהו הלקוח הרך היחיד הנתמך על ידי, בניגוד לתומך Unified CM הן באפליקציית Webex והן ב- Jabber, והוא הלקוח הרך החדש המוגדר כ ברירת מחדל עבור משתמשי קצה.

בהתאם למצבי הפריסה המיושמים עבור Jabber (מצבי IM בלבד, טלפון בלבד ו/או UC מלאים), ייתכן שיהיה עליך לשקול גם את המעבר של עומסי העבודה של הודעות ו/או פגישות מ- Jabber ל-. ניתן לפרוס אותו במצב טלפון בלבד אם הוא ישמש כלקוח מתקשר בלבד או שניתן לפרוס אותו כ מלא Webex Suite אם עומסי עבודה אחרים, למשל. Webex Messagingו/אוWebex Meetings, עוברים לאפליקציה עם שיחות.

זה משפר את חוויית משתמש הקצה על ידי מתן תכונות AI כמו מודיעין אודיו/וידאו, תמלול שיחות ואחרים. לקבלת מידע נוסף, ראה https://www.webex.com/all-new-webex.

לפני העברת משתמשים אל תצטרכו להעביר את לקוחות Jabber שלהם ל-. יש לך שתי אפשרויות להשלמת המעבר הזה.

לפני שתעביר אותם ל

כאשר אתה מעביר אותם ל.

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

למידע נוסף, אודות שתי האפשרויות הללו ראה מסע הגירה - שלב אחד או שניים? .

לקבלת רשימה מלאה של ההתקנים הנתמכים עבור, ראה התקנים נתמכים עבור Webex Calling.

בדוק את זכאות המכשיר

כאמור, תומך בתת-קבוצה של טלפוני ה- IP של סיסקו ודורש סוג קושחה שונה עבור הטלפונים מסדרת 7800 ו- 8800. Unified CMטלפונים מפעילים את הקושחה הארגונית ואילו טלפונים מפעילים את הקושחה של טלפון רב פלטפורמה (MPP). מומלץ לוודא אילו טלפונים רשומים זכאים לשדרג לקושחת MPP במהלך שלב ההכנה. זה נותן לך זמן להחליף טלפונים שאינם מתאימים באחד מדגמי הטלפון הנתמכים או לזהות תוכנית חלופית, כמו העברת משתמש לאפליקציית Webex בלבד.

כדי לסייע בקביעת הזכאות של הטלפונים, לרכזת Control יש כלי מובנה בשם Migrate Your Phone to Webex Calling. בעת שימוש בכלי זה לבדיקת זכאות המכשיר, בחר באפשרות העברה צור רישיון מכשיר בלבד.

אפשרות הכלי Control Hub לאימות זכאות הט Unified CM לפונים ל Webex Calling

אפשרות זו מאפשרת לך להעלות קובץ CSV המכיל את הטלפונים כדי שתוכל לבדוק את הזכאות של כל טלפון. על ידי בחירת אפשרות העברה זו, היא לא מוסיפה את הטלפונים מכיוון שאתה עדיין בשלב ההכנה ועדיין לא מוכן לעשות זאת. לקבלת מידע נוסף, ראה העברת הטלפון אל Webex Calling.

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

בדוק ידנית כל טלפון וודא את הדגם ואת גרסת החומרה (PID VID)

תווית טלפון 7800/8800 עם מידע על דגם וגרסת חומרה

השתמש בכלי המוכנות לטלפון IP של סיסקו

הורד את הכלי מ - https://github.com/joemar2/mpp_readiness_check.

כלי זה אינו כלי רשמי של סיסקו וגם אינו נתמך ב- TAC. יש לו תמיכה במאמץ הטוב ביותר אך הוא חופשי לשימוש.

יש להפעיל את הכלי הזה במחשב מקומי ויכול לגשת לשרתים ולטלפוני ה- IP. יש לו אפשרות לאפשר גישה לאינטרנט בטלפוני ה- IP, המומלצת ונחוצה כדי להשיג את התוצאות הטובות ביותר. לכן, יש להשתמש בו בשעות החופש כדי למנוע הפרעה למשתמשי הקצה. הפלט של הכלי מספק דוח המפרט אילו מהטלפונים מסדרת 7800 ו- 8800 זכאים לשדרג לקושחת MPP. מכיוון שהוא ני גש ישירות לטלפון הוא יכול לאמת את המכשירים הלא ידו עים שדווח ו מכלי Control Hub.

דוח כלי מוכנות לטלפון IP של סיסקו

משתמשים

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

פריסת עם שיחות

פריסת ה- with

קביעת תצורה של שירותים עבור משתמש

כדי להפוך את המשתמשים לחיפוש בספרייה (לחץ כדי להתקשר, פרטי קשר למשתמש, חיפוש בספריית טלפונים).

מומלץ לספק את כל המשתמשים לפני או בתחילת הפרויקט שלך. זה כולל משתמשים שעדיין משתמשים Unified CM בפלטפורמת השיחות שלהם אינה תלויה במכשיר השיחה שלהם (טלפון IP, Jabber,). כאשר משתמשים מועברים אל (ו/או ל), תעדכן את הרישיונות שלהם כדי לאפשר את השירותים הדרושים להם. על-ידי הקצאת כל המשתמשים המתקשרים בארגון לפני תחילת המעבר, היא מאפשרת למשתמש שעבר אל או לחפש בספרייה משתמש מתקשר ארגוני שעדיין נמצא ב- Jabber ו/או מופעל. זה מבטיח שמשתמשים שעברו מעבר יוכלו למצוא את פרטי הקשר של כל משתמש אחר ול התקשר אליהם באמצעות חיפוש הספריות.

חיפוש ספ ריית הדמויות מציג דוגמה למשתמש שמחפש משתמש אחר. תוצאות החיפוש מציגות את פרטי הקשר של המשתמש וי כולות להיות עבור משתמש שעדיין נמצא ב- Jabber או עבור משתמש שעבר ל- ו/או.

חיפוש ספריית אפליקציות Webex

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

לדוגמה, אם המשתמשים בפריסה מחולקים לשלושה אתרים עיקריים, ניו יורק (ניו יורק), סן פרנסיסקו (SFC) ו-Research Triangle Park (RTP), תוכנית מעבר משתמשים עשויה להיראות כמו התוכנית המתוארת ב תוכנית מעבר משתמשים לפי טבלת אתר.
טבלה 4. תוכנית מעבר משתמשים לפי אתר
אתר משתמש/מיקום מידע טרום המעבר והדרכות תקופת מעבר תמיכה לאחר המעבר
ניו יורק (1,525 משתמשים) שבוע של אפריל 1 אפריל 15 - אפריל 27 שבוע של 29 באפריל
SFO (1,600 משתמשים) שבוע של 6 במאי 20 במאי - 31 במאי שבוע של 3 ביוני
RTP (1,275 משתמשים) שבוע של 3 ביוני 17 ביוני - 28 ביוני שבוע של יולי 1

גורם חשוב נוסף הוא העברת משתמשים יחד שיש להם תלות זה בזה . זה יכול לכלול, בין היתר, את הדברים הבאים:

ניטור BLF

אותו טייס/קבוצה של ציד

שתף שורות

חלק מאותה קבוצת איסוף שיחות

שימוש באותם מספרי חניון שיחות

אינטרקום

מנהל/מנהל

באפשרותך לעיין בתצורה (ממשק משתמש או ייצוא) או להשתמש בכלי Migration Insights כדי לסייע בזיהוי קבוצות המשתמשים עם ת לות אלה.

קישוריות PSTN

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

PSTN מקומי עם שער מקומי (LGW) הוא מרכיב חיוני באסטרטגיית המעבר. הוא מספק קישוריות בין הפריסה המקומית ו/או PSTN לפלטפורמה. תומך הן בסיסקו והן בבקרי גבול הפעלה של צד שלישי (SBC) שיכולים לשמש כשער מקומי. לקבלת הרשימה העדכנית ביותר של SBC נתמכים, ראה רשימת SBC נתמכים.

תומך בעד 250 שיחות במקביל משער מקומי יחיד המבוסס על רישום וביותר מ-250 שיחות במקביל משער מקומי יחיד המבוסס על אישורים. שערים מקומיים מבוססי אישורים יכולים לתמוך בעד 6500 שיחות במקביל, אך הדבר מבוסס על סוג הקישוריות שיש לשער המקומי (Over-the-Top לעומת צילומי חיבור) ודגם ה- SBC שעליו פרוס השער המקומי. מגבלות אלה הן במהותה מגבלת ספירת ברירת המחדל הן עבור שיחות PSTN מקומיות מבוססות שער והן לשיחות בין אתרים בין נקודות קצה. לקבלת מידע נוסף, ראה התחלת העבודה עם השער המקומי.

כל שיחות החורגות ממגבלה זו נדחות עם 403 אסור. ניתן להפעיל את הפקודה הקולית הפעילה של הצג שיחה בשער המקומי בכל מופע כדי לקבוע את המספר הכולל של שיחות פעילות.

תנאי רשת ירודים בין שער מקומי לגישה SBC יכולים להגביל את ביצועי חיבור האיתות, מה שמוביל למגבלת שיחות במקביל נמוכה עוד יותר. חביון חד כיווני בין השער המקומי למרכז הנתונים לא יעלה על 100 אלפיות השנייה והריצוד צריך להיות פחות מ -10 אלפיות השנייה ואילו אובדן המ נות הוא פחות מ -0.5%.

תכונות ושימוש בתכונות

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

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

סקור את התצורה בממשק המשתמש של מנהל המערכת

ייצוא תצורה - ייצוא בכמות גדולה או AXL

כלי תובנות הגירה (מומלץ)

כלי שותפים של צד שלישי של סיסקו (מומלץ).

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

סקירה של רשומות CDR גולמיות

סקירת Unified CM נתוני RTMT

כלי תובנות הגירה באמצעות נתוני CDR

סקירה של ניתוח UC המחובר לענן ב

עוצמת השיחה

נקודות קצה רשומות

(CAC) מיקומים

ניצול תא המטען.

כלי שותפים של צד שלישי של סיסקו.

סיסקו ממליצה להתחיל עם הכלי 'תובנות ההעברה' של Webex Control Hub לצורך ניתוח זה. תוכל לייבא את קובץ הייצוא שלך. TAR ואת קבצי Unified CM CDR (אופציונלי, אך נדרש לניתוח ניצו ל תכונות) לכלי. הכלי יפיק את הדוחות הבאים מבוססי CSV שניתן להשתמש בהם כדי להתחיל את הניתוח:

טבלה 5. דוחות שנוצרו מקוב Unified CM ץ.tar
שם הדוח
תיאור דוח
ImportedDataBulk.csv
כל המשתמשים והמכשירים מנ Unified CM תונים
DeviceEligibility.csv
מזהה מכשירים הזכאים להעברה Webex Calling אליהם (טלפונים IP, התקני מערכת הפעלה בחדר, ATAs וצד שלישי)
DevicePoolNumbers.txt
רשימת כל המספרים במא גר מכשירים מסוים
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
פרטים על מכשירים ומשתמשים שיש להעביר יחד בהתבסס על קווים משותפים, פיילוט ציד, תור שיחות, חניית שיחות ותצורת קבוצת איסוף שיחות
HuntGroupMigrationInsight.csv
מידע מפורט על קווי ציד שהוקצו, קבוצות קווים וסוכנים משויכים
SharedlineGroupMigrationReport.csv
סקירה כללית של האופן שבו מספרי טלפון (מספרי ספריות) משותפים בין משתמשים

טבלה 6. דוחות שנוצרו מקב Unified CM צי.tar ו- CDR gzip
שם הדוח
תיאור דוח
FeatureUsageBasedDeviceEligibilityReport.csv
מידע על זכא ות להעברת מכשירים בהתבסס על השימוש בתכונה
FeatureUsageWithLastUsageDateReport.csv
ספירת שימוש למספר הפעמים שהתקשרו טייסי ציד ותור שיחות יחד עם תאריך השימוש האחרון
UserWorkspaceLastUsage.csv
תאריך שימוש אחרון עבור משתמשים וסביבות עבודה עבור לקוחות רכים וטלפונים קשיחים כאחד
DIDUsageReport.csv
שימוש DID הן עבור DID שהוקצו והן לא מוקצים

לקבלת פרטים נוספים אודות דוחות תובנות ההעברה, ראה תובנות העברה.

אם אתה זקוק למידע נוסף אודות התכונות והשימוש לאחר סקירת המידע בדוחות Migration Insights, Cisco ממליצה לשקול את אחד מכלי ההעברה של שותפי צד שלישי של Cisco ו/או לבדוק את הת צורות ב- GUI או בנתוני הייצוא של התצורה.

שילובים של סיסקו: חיבור יוניטי UCCX UCCE

דואר קולי הוא חלק בלתי נפרד מההצעה ומובנה באופן מקורי בפתרון. אינו יכול להשתלב עם פתרון דואר קולי מבוסס מקום כגון Unity Connection או Unity Connection Express. יתר על כן, אין דרך מקורית להעביר הודעות דואר קולי או ברכות קיי מות לחיבור Unity לשירות הדואר הקולי המקורי הזמין עם. לחלק מכלי ההעברה של שותף צד שלישי של סיסקו יש יכולות להעביר חלק מהנתונים הללו. לקבלת מידע נוסף על דואר קולי עבור, ראה קביעת תצורה וניהול של הגדרות דואר קולי עבור משתמש. Webex Calling

תומך גם בתיבות דואר קולי ופקס משותפות. לקבלת מידע נוסף, ראה ניהול דואר קולי משותף ותיבת פקס נכנסת עבור. Webex Calling

יש תכונה מובנית של שיחה אוטומטית הכלולה כחלק מפלטפורמת הליבה. תכונה זו מאפשרת מעבר של מטפלי השיחות של חיבור Unity שלך ופונקציונליות מלווה אוטומטית. הכלי רכזת הבקרה, הע בר תכונות מ-Unified CM, תומך ב העברת תצורות חיבור Unity למשיבים אוטומטיים. לקבלת מידע נוסף אודות השימוש בכלי זה, ראה העברת התקנים ות כונות מ- Unified CM אלWebex Calling.

הקלטת שיחות

כולל שתי אפשרויות להקלטת שיחות ללא עלות נוספת.

הקלטת שיחות Webex

הקלטת Dubber Go (הצעת שותפים) - שילוב בין דובר שבו כל המדיה המוקלטת נשמרת בצורה מאובטחת בענן.

טבלת אפשרויות ההקלטה הכל ולה מדגישה כמה תכונות עיקריות של שתי אפשרויות הק לטת השיחות הזמינות ללא עלות נוספת.

טבלה 7. אפשרויות הקלטה כלולות
Webex דאבר גו

זמין לכל המשתמשים זמין לכל המשתמשים

הקלטות ללא הגבלה הקלטות ללא הגבלה

תקופת שמירה של שנה* תקופת שמירה של 30 יום

אחסון בנפח של 100 ג'יגה-בתים לכל ארגון -

קציני ציות יכולים לגשת להקלטות שיחות ולנהל אותן -

ממשקי API לניהול הקלטות -

מנהלי מערכת יכולים להגדיר ולנהל את הגישה של המשתמשים להקלטות השיחות שלהם
משתמשים יכולים לנהל את ההקלטות שלהם באמצעות רכזת משתמשים ו/או אפליקציית Webex.
רק משתמשים יכולים לגשת ולנהל את ההקלטות שלהם
מפורטל הדובר שלהם.

אם הארגון שלך דורש יכולות הקלטה נוספות כגון הקלטת שיחות תאימות, תקופות שמירה ארוכות יותר, אחסון רב יותר, ניתוח AI ו/או גישה למנהל מערכת, קיימות הצעות בת שלום או תוספות הן של Cisco והן מספקי הקלטות של צדדים שלישיים. לקבלת מידע נוסף על ספקי הקלטה, תצורות ושירותי שותפים נוספים, ראה ניהול הק לטת שיחות עבור Webex Calling.

שילובים של צד שלישי

תומך במגוון שילובים של צד ^שלישי כולל אך לא רק SBCs עבור שערים מקומיים, טלפוני IP, טלפונים אינטרקום, רמקולים/זיגרים, ATA וכו'. בנוסף למכשירי צד שלישי ^אלה, Webex Calling תומך ב פתרונות שונים של ^צד שלישי לתמיכת לקוחות, ניתוח, הקלטה, חיוב וכו'. לקבלת מידע נוסף על פתרונות ^צד שלישי, ראה Webex App Hub.

טבלה 4. תוכנית מעבר משתמשים לפי אתר
אתר משתמש/מיקום	מידע טרום המעבר והדרכות	תקופת מעבר	תמיכה לאחר המעבר
ניו יורק (1,525 משתמשים)	שבוע של אפריל 1	אפריל 15 - אפריל 27	שבוע של 29 באפריל
SFO (1,600 משתמשים)	שבוע של 6 במאי	20 במאי - 31 במאי	שבוע של 3 ביוני
RTP (1,275 משתמשים)	שבוע של 3 ביוני	17 ביוני - 28 ביוני	שבוע של יולי 1

טבלה 5. דוחות שנוצרו מקוב Unified CM ץ.tar
שם הדוח תיאור דוח
ImportedDataBulk.csv כל המשתמשים והמכשירים מנ Unified CM תונים
DeviceEligibility.csv מזהה מכשירים הזכאים להעברה Webex Calling אליהם (טלפונים IP, התקני מערכת הפעלה בחדר, ATAs וצד שלישי)
DevicePoolNumbers.txt רשימת כל המספרים במא גר מכשירים מסוים
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv פרטים על מכשירים ומשתמשים שיש להעביר יחד בהתבסס על קווים משותפים, פיילוט ציד, תור שיחות, חניית שיחות ותצורת קבוצת איסוף שיחות
HuntGroupMigrationInsight.csv מידע מפורט על קווי ציד שהוקצו, קבוצות קווים וסוכנים משויכים
SharedlineGroupMigrationReport.csv סקירה כללית של האופן שבו מספרי טלפון (מספרי ספריות) משותפים בין משתמשים

טבלה 6. דוחות שנוצרו מקב Unified CM צי.tar ו- CDR gzip
שם הדוח תיאור דוח
FeatureUsageBasedDeviceEligibilityReport.csv מידע על זכא ות להעברת מכשירים בהתבסס על השימוש בתכונה
FeatureUsageWithLastUsageDateReport.csv ספירת שימוש למספר הפעמים שהתקשרו טייסי ציד ותור שיחות יחד עם תאריך השימוש האחרון
UserWorkspaceLastUsage.csv תאריך שימוש אחרון עבור משתמשים וסביבות עבודה עבור לקוחות רכים וטלפונים קשיחים כאחד
DIDUsageReport.csv שימוש DID הן עבור DID שהוקצו והן לא מוקצים

טבלה 7. אפשרויות הקלטה כלולות
Webex	דאבר גו
זמין לכל המשתמשים	זמין לכל המשתמשים
הקלטות ללא הגבלה	הקלטות ללא הגבלה
תקופת שמירה של שנה*	תקופת שמירה של 30 יום
אחסון בנפח של 100 ג'יגה-בתים לכל ארגון	-
קציני ציות יכולים לגשת להקלטות שיחות ולנהל אותן	-
ממשקי API לניהול הקלטות	-
מנהלי מערכת יכולים להגדיר ולנהל את הגישה של המשתמשים להקלטות השיחות שלהם משתמשים יכולים לנהל את ההקלטות שלהם באמצעות רכזת משתמשים ו/או אפליקציית Webex.	רק משתמשים יכולים לגשת ולנהל את ההקלטות שלהם מפורטל הדובר שלהם.

תכנית

תוכנית פרויקט ברמה גבוהה

מסע הגירה - צעד אחד או שניים?

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

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

שלב 1

שלב 2

תוכנית פרויקט ברמה גבוהה

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

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

הגדרת היקף ההעברה (לדוגמה, אילו משתמשים, מכשירים ותכונות יע ברו)

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

תיאום הערכות מוכנות לרשת, ו

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

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

מסע הגירה - צעד אחד או שניים?

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

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

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

שירותי שיחות עברו מ-

מספרי טלפון ותוספים הועברו מ-

לקוח רך עבר מג'אבר ל- - יירשם ל

רישום הטלפון עבר מ-.

שירות השיחות של המשתמש, הלקוח הרך והטלפון עוברים בו זמנית

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

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

הגישה השנייה היא הגירה דו-שלבית. בשלב 1, משתמשים עוברים לשירותי השיחות אך נשארים פעילים. ואז בשלב 2, המשתמשים מועברים מ Unified CM -. אפשרות זו מומלצת ללקוחות גדולים יותר לניהול השינויים של משתמשי הקצה ורוצים לה פריד בין שינוי הלקוח הרך של המשתמש לבין השינוי בשירות השיחה. האיור הבא הע בר לקוח רך; ולאחר מכן העבר שירות שיחות, לקוח רך וטלפון Webex Calling למטה מדגיש סוג זה של העברה.

שלב 1

לקוח רך עבר מ- - יירשם ל.

שלב 2

שירותי שיחות עברו מ-.

מספרי טלפון ותוספים עברו מ-.

ההרשמה עברה מ-.

רישום הטלפון עבר מ-.

העבר לקוח רך; ואז העבר שירות שיחות, לקוח רך וטלפון אל Webex Calling

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

האפשרות שתבחר תלויה באופן שבו ברצונך לנהל את המעבר של המשתמשים שלך ל- and. ההמלצה היא לקחת את זה בשלבים (אפשרות 2). זה מאפשר לך למזער את השינויים של משתמש הקצה בבת אחת ולחלק את המאמץ לחלקים שונים של הפרויקט. עם זאת, אם אתה מעדיף שמשתמשים יושפעו רק פעם אחת, השימוש באפשרות 1 תקף גם הוא.

כאשר מסתכלים על המסע המומלץ (אפשרות 1), איור מפ ת המעבר ברמה גבוהה של Jabber ל-Webex App להלן מציג את המעבר ברמה גבוהה עבור שלב 1.

מפת מעבר ברמה גבוהה של ג'אבר לאפליקציית Webex

בשלב זה משתמשים עוברים מ- Jabber ל- עבור כל שירותי השיחות שלהם. עם זאת, פלטפורמת השיחות עדיין Unified CM והיא תרשום את שירותי השיחות שלה אליה. כפי שניתן לראות במ פת המעבר ברמה גבוהה של Jabber ל-Webex App, הת שתית המקומית אינה משתנה, והיא פועלת באותו אופן שבו Jabber עושה זאת. השינוי היחיד הוא הדורש חיבור אל.

לקבלת מידע נוסף אודות מעבר זה, ראה מדריך מפת מעבר ו פריסה של Jabber ל-Webex תחת הקטע לקוח בדף מעבר לשיתוף פעולה.

Unified CMלדמות Webex Calling מפת מעבר ברמה גבוהה הוא המעבר ברמה גבוהה מ- ל-. זהו שלב 2 של המסע המומלץ.

Unified CMלמ Webex Calling פת מעבר ברמה גבוהה

אם תחליט להשתמש בגישה של שלב יחיד, זה חל גם כן.

בשלב זה משתמשים עוברים לקבוצות. בשלב זה המשתמשים מתחילים להשתמש בשירותי השיחות שלהם, רישום שיחות ורישום טלפון IP.

מכיוון שמשתמשים עוברים בקבוצות, משתמשי Enterprise יפוצלו בין שתי פלטפורמות השיחות במהלך המעבר. שלב 1 באיור Unified CMמפ Webex Calling ת מעבר ברמה גבוהה מתאר מצב זה. בשלב זה נדרש תכנון כיצד לנהל שיחות בין משתמשים בשתי הפלטפורמות וכיצד ינותבו שיחות PSTN. בכל פעם שעוברת מעבר לקבוצת משתמשים, יידרשו תוכניות חיוג ועדכוני ניתוב שיחות בשער (ים) המקומיים.

לאחר שכל המשתמשים, הלקוחות הרכים והמכשירים הועברו אל (שלב 2), ניתן להסיר ולהשבית את כל תשתית ה- UC המקומית.

עיצוב

בחירת אזור

מיקומים

PSTN

תוכנית חיוג

תוכנית חיוג מקומית ב

תוכנית חיוג

הקלטה

1. בחירת ספק הקלטת שיחות

2. בחירת אזור

שיחת חירום

רישוי

הקצאה ידנית דרך

תבניות הקצאת רישיון אוטומטיות

הקצאה בכמות גדולה באמצעות תבנית CSV

הקצאה מבוססת API

דרישות רישיון

הקצאת משתמשים

קבוצות משתמשים

גישה מומלצת בעת מעבר מ-

עיצוב קבוצות משתמשים

כניסה יחידה (SSO)

תמיכה מרובה של IdP

1. מיזוגים ורכישות

2. מחלקות IT עצמאיות מרו בות

3. קבוצות משתמשים או דומיינים שונים

4. תמיכה בפרוטוקולי אימות שונים

5. אבטחה ותאימות משופרים

6. חווית משתמש פשוטה

שני MFA עם SSO עבור

תכונות

מלווה אוטומטי

התקשר לפארק

איסוף שיחות

תור שיחה

קבוצת האנט

מצבי הפעלה

קבוצת פיג'ינג

הקלטות

טווח הגעה למספר יחיד

קבוצת דואר קולי

בחירת אזור

זמין ברחבי העולם ומועבר ממרכזי נתונים מיותרים במספר אזורים: ארה"ב (דאלאס, שיקגו), קנדה (ונקובר, טורונטו), אירופה (פרנקפורט, אמסטרדם), בריטניה (לונדון, מנצ'סטר), אוסטרליה (מלבורן, סידני), יפן (טוקיו, אוסקה), ערב הסעודית (ריאד, ג' דה) והודו (מומבאי, צ'נאי). ה- POP המדיה מספקים שירותי מדיה כדי לייעל את זמני התקשורת הלו ך ושוב. מרכז הנתונים של סינגפור למשל משמש לייעל את זמני הנסיעה הלוך ושוב לתקשורת עבור לקוחות במדינות אסיה שבהן זמני הלוך ושוב לאזור אוסטרליה או יפן עשויים להיות לא אופטימליים. מרכזי הנתונים מחוברים זה לזה על ידי עמוד שדרה רב-ג'יגה-ביט ומ יותר לחלוטין. האיור של מרכזי נתונים המופצים ברחבי העולם מציג סקירה כללית של כל מרכזי הנתונים. לקבלת הרשימה העדכנית ביותר של מרכזי נתונים זמינים, ראה מי קומי מרכז נתונים עבור Webex Calling.

מרכזי נתונים מבוזרים ברחבי העולם

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

לקבלת זמינות במדינה, ראה היכן Webex זמין? .

מיקומים

כדי להתכונן להקצאת מיקומים יש לאסוף את המידע הנדרש עבור כל מיקומי יעד ההעברה. המידע הדרוש לכל מיקום מסוכם ב מידע ללכידה עבור כל מיקום.
טבלה 1. מידע ללכידה עבור כל מיקום
מידע הערה
טווח (ים) הרחבה לכל מיקום יכולים להיות הרחבות המתחילות בספרות שונות. יש לחסוך ספרה אחת לספרת ההיגוי החיוג הבין-אתרים (לדוגמה 8) וספרה אחת לספרת ההיגוי של PSTN (לדוגמה 9). שום טווח הרחבה לא יכול להתחיל עם אחת מש תי הספרות הללו.
כל טווחי ההרחבה של כל המיקומים חייבים להיות בא ורך שווה.
טווח (ים) DID -
ספרת היגוי PSTN -
קוד האתר כל קודי האתר של כל המיקומים צריכים להיות ייחודיים ובעלי אורך זהה.
מספר ראשי בעת יצירת מיקום יש לספק שני DIDs. אחד כמספר ראשי (לדוגמה שיוקצה לשירות מלווה אוטומטי) ואחד עבור פורטל הדואר הקולי.
הקצאת DID אחד למספר הדואר הקולי.
מספר דואר קולי
מספר הרישיונות רישיונות נדרשים לפי סוג כולל סטנדרטי, מקצועי, סביבת עבודה, רשימת מסלולים, תוכנית שיחות יוצאות.
שיחות במקביל בשעות העמוסות סכום השיחות במקביל בין התקנים ובין התקנים לשער המקומי (PSTN ושיחות למכשירים). נדרש כדי לקבוע את רוחב הפס הנדרש לגישה לאינטרנט.
ארץ -
אזור זמן -
שפה -
איש קשר (שם, טלפון, דוא"ל) -
כתובת (כתובת רחוב, עיר, מדינה, מיקוד) -
מיקום פיזי הניתן לשליחה של שירותי חירום לנקודות קצה מיקום הניתן למשלוח של המכשיר המשמש לשיחות חירום כולל בדרך כלל את הדברים הבאים: כתובת בניין, כתובת בנין+מספר קומה, כתובת בנין+מספר סוויטה, או כתובת בניין + מספר קומה + מספר משרד/קובי.
לכל מכשיר מיקום רשת פיזי ייחודי לשירותי חירום מיקום רשת פיזית לשיחות חירום כולל בדרך כלל את הדברים הבאים: מתג/יציאת מתג להתקנים קוויים, מזהי ערכת שירות בסיסיים (BSSID) של נקודת גישה אלחוטית (BSSID) עבור התקנים מחוברים אלחוטיים ו/או רשתות משנה IP מקומיות עבור התקני נקודת קצה.

PSTN

בעת תכנון פריסה, ללקוחות יש שלוש אפשרויות קישוריות PSTN עיקריות: תוכניות שיחות של Cisco (שירות PSTN המועבר בענן המנוהל על ידי Cisco), ספקי PSTN המחוברים לענן (CCPP, שבהם ספקים מספקים שירות PSTN דרך הענן) ו- PSTN מקומי (שבו שערים מקומיים מחברים את הרשת הארגונית ל- PSTN). עם הצגת גזע PSTN לפריסות היברידיות (למידע נוסף, ראה גזע PSTN עבור פריסות היברידיות ב- PSTN trunking), ארגונים Webex Calling מקבלים גמישות נוספת בגישת ה העברה שלהם. תכונה זו מאפשרת ללקוחות להעביר את ה- PSTN שלהם ל- CCPP בתחילת מסע המעבר ולהתחיל לעבור ל- PSTN בענן עבור משתמשים, תוך מינוף CCPP כדי לשמור על שירות PSTN עבור משתמשים שנשארים בסיסקו במהלך העברה בשלבים.

גישה היברידית זו מאפשרת לארגונים להעביר תחילה קבוצות משתמשים נבחרות לענן, מבלי לשנות באופן מיידי את כל סביבת הטלפוניה שלהם. עם זאת, הוא מציג מורכבות וסיכון נוספים, במיוחד סביב התאמת לוגי קת ניתוב שיחות קיימת לתמיכה בארכיטקטורה החדשה. יכולת פעולה הד דית עם יישומים מדור קודם, כגון שרתי פקס, מרכזי קשר או מערכות עימוד, דורשת גם שיקול זהיר. האתגרים הטכניים העיקריים עשויים לכלול הבטחת משא ומתן חלק מקצה לקצה על codec ואיתות DTMF (Dual-Tone Multi-Frequency) בסביבה המעורבת, כמו גם אימות תאימות עם תכונות טלפוניה מיוחדות. תכנון ובדיקה נכונים חיוניים כדי למזער את ההפרעות ולשמור על שירותי קול אמינים לאורך כל תהליך ההעברה. בנוסף, שיקולים מסחריים חשובים, שכן מטעף היברידי דורש רישיון שימוש המבוסס על מספר השיחות במקביל בין הסביבה המקומית לבין ספק ה - PSTN המחובר לענן (CCPP).

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

העברה ל- CCCP בהתחלה לעומת שמירה על PSTN מקומי

האיור מעבר ל- CCCP בהתחלה לעומת שמירה על PSTN מקומי מציג את שתי אפשרויות ההעברה של PSTN שהוס ברו לעיל. האיור משמאל מציג את התרחיש שבו כל המשתמשים והיישומים המקומיים צורכים שירותי PSTN המחוברים לענן באמצעות תא מטען מקומי ושער מקומי המחבר את המקומי אליו ואילו האיור בצד ימין מציג את התרחיש שבו ה- PSTN המקומי הקי ים נשאר במקומו ומשתמשים משתמשים משתמשים ב- PSTN מקומי דרך חיבור השער המקומי בין Webex Calling המק ומי ו. במהלך המעבר ניתן לעבור למיקומים באמצעות PSTN מחובר לענן.

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

תוכנית חיוג

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

תוכנית חיוג מקומית ב

במהלך המעבר כדי לאפשר דו קיום של מכשירים הר Unified CM שומים על ועל גבי תוכנית החיוג הארגונית יש לשנות כך שניתן יהיה לעמוד לפחות בדרישות הבאות:

+E.164 חיוג מ- אל

חיוג תוסף מ- אל (בתוך האתר אך גם בין אתרים אם טווחי ההרחבה ייחודיים)

חיוג בין אתרים מקוצר מ-

חיוג מאולץ ברשת מ- ל

התקשרות חוזרת מספריית שיחות שלא נענו ליעדים

שיחות PSTN מ- PSTN אם במהלך המעבר נעשה שימוש ב- PSTN מקומי עבור

שיחות PSTN מ- ל- if במהלך המעבר נעשה שימוש בחיתוך PSTN לפריסות היברידיות כדי לספק גישה ל- PSTN למשתמשים מקומיים באמצעות Cloud Connect עבור

מאולץ ברשת מ- ל

חיוג תוסף מ- (בין אתרים).

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

תוכנית החיוג של שיטות עבודה מומלצות של איור מציגה את גישת תוכנית החיוג המומלצת כמתו אר בא רכיטקטורה מועדפת עבור פריסות מקומיות ארגוניות של Cisco Collabor ation 12.x, CVD. המאפיינים העיקריים של גישה זו כוללים:

מחיצה יחידה עבור מספרי ספריות +E.164

ניתוב ליבה המבוסס על דפוסי מסלול +E.164

נורמליזציה של כל הרגלי החיוג ל- +E.164 באמצעות דפוסי תרגום

שימוש בתבנית תרגום הקוראת ירושת מרחב חיפוש (אפשרות השתמש במרחב החיפוש של המ קור המוגדר על דפוסי תרגום).

תוכנית חיוג לשיטות מומלצות

לדוגמה, חיוג PSTN (9+1+10D) ממכשיר ב- SJC המסופק עם מ רחב חיפוש שיחות קו SJCInternational יתאים תחילה לתבנית התרגום 9.1 [2-9] XX [2-9] XXXXXX שמנרמל את מספר הצד המתקשר ל- +E.164. לאחר מכן, החיפוש המשני משתמש שוב באותו מרחב חיפוש קריאה SJCInternational (קורא לי רושה של שטח חיפוש) והמחרוזת +E.164 ספרות תתאים למספר ספריית +E.164 במחיצת DN או לאחד מדפוסי המסלול של PSTN במחיצה USPSTNNational או SJCpStnLocal. הרגלי חיוג מקוצרים בתוך האתר ובין אתרים מיו שמים על ידי התרגומים במחיצת ESN ו- SJCTO E 164. בעוד מחיצת ESN היא מחיצה גלובלית (נגישה לטלפונים בכל המיקומים) מחיצת SJCTOE164 נגישה רק למשתמשים במיקום SJC. זה בהנחה של טווח י הרחבה חופפים.

הצעד הראשון לאפשר שיחות מ- אל הוא לוודא כי יעדי +E.164 מנותבים בהתאם. ניתן להשיג זאת על ידי הוספת מחיצה לתוכנית החיוג, הוספת דפוסי מסלול +E.164 עבור כל היעדים למחיצה זו, ולבסוף הוספת המחיצה לכל מרחבי החיפוש המתקשרים המייצגים מחלקות שירות שאליהן צריך להיות מסוגל להגיע. יצירת מחיצה ייעודית נדרשת כדי לאפשר יצירת סוג שירות מובחן לשיחות שמ קורן. כדי להימנע מלולאות שיחה, שטח החיפוש של השיחות הנכנסות בתא המטען מהשער המקומי לא א מורה להיות בעלת גישה למחיצה.

+E.164 ניתוב אל Webex Calling

כפי שמוצג באיור +E.164 ניתוב אלWebex Calling, כדי לאפשר ניתוב מ- אל למיקום עם טווח +E.164 DID +1 221 555 2XXX וקוד אתר 121, יש להוסיף למחיצה ד פוס מסלול דחוף התואם לטווח +E.164 זה.

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

כדי לאפשר חיוג מקוצר בין אתרים לאתר, תבנית המסלול הנדרשת 8121.2XXX מתווספת למחיצה. עבור אתרים שיועברו לדפוס נורמליזציה של חיוג 8121.2XXX שמנרמל את חיוג ESN ל-+E. 164, ייתכן שכבר קיימים במחיצת ESN. במקרה זה נראה כי 8121.2XXX מיותר, אך ברגע שכל ה- DNs של המיקום המתאים הועברו לדפוס התרגום לנורמליזציה של חיוג 8121.2XXX ניתן להסיר ואז תבנית המסלול 8121.2XXX מאפשרת חיוג ESN אפילו למשתמשים בהרחבה בלבד בטווח זה.

באמצעות שינויי תוכנית חיוג אלה ניתן לבצע שיחות למיקום לא רק על ידי חיוג מקוצר בין אתרים ו- +E.164. כמו כן, חיוג PSTN בינלאומי וללאומי אפשרי מכיוון שהרגלי חיוג אלה מנורמלים תחילה ל-+E.164 באמצעות דפוסי התרגום הקיימים לנורמליזציה של חיוג ולאחר מכן מנותבים אליו על ידי התאמת דפוס המסלול +E.164 במחיצה.

ניתן לספק את התאמת תבנית המסלול +E.164 בטווח ה- DID של המיקום בזמן שכל ה- DID עדיין מתארחים. אלגוריתם ההתאמה הטוב ביותר של דפוסי ההתאמה מוודא שכאשר מחויגים מספר המתארח בו, מספר הספרייה +E.164 המוגדר בו הוא התאמה טובה יותר מתבנית הנתיב +E.164 המוגדרת בתווים כלליים המצביעה עליה כך שהשיחות יורחבו לקו מופעל ולא נשלחו אליו.

תוכנית חיוג

לכל משתמש מסופק סיומת ו/או מספר טלפון +E.164. אורך ההרחבה הוא הגדרה גלובלית קבועה: לכל התוספים בפריסה יש אורך זהה. ניתן להשתמש בחיוג הרחבה בין משתמשים הן במיקום והן בין מיקומים. חיוג תוסף בין אתרים מקו צר (המקרה האחרון) פועל רק אם התוסף שחויג הוא ייחודי.

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

אורך התוסף, התנהגות החיוג בין מיקומים, אורך הקידומת לחיוג בין מיקומים וספרת ההיגוי בקידומת הניתוב לחיוג בין מיקומים מוגדרים בהגדרות שירות השיחות ב:

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

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

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

אפשר חיוג סיומת בין מיקומים: החלף כדי להפעיל/להשבית חיוג סיומות בין מיקומים. אפשרות זו צריכה להיות מופעלת רק אם כל התוספים בא רגון הם ייחודיים. אם האפשרות מושבתת, יש לחייג מספרים משמעותיים ארגוניים (קוד היגוי, קוד אתר, סיומת) או מספרי טלפון בין מי קומים.

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

דוגמה למס פור ארגוני בטבלה מצי גה דוגמה לשלושה מיקומים שבהם טווחי ה הרחבה של שני מיקומים, NYC ו- RTP, זהים. הקמת ערכת מס פור ארגונית עם ספרת היגוי בין אתרים 8, ואחריה קוד אתר בן שלוש ספרות, וההרחבה בת ארבע הספרות יוצרת הרגל חיוג בין אתרים מקוצר שאינו חופף.

טבלה 2. דוגמה למספור ארגוני
אתר טווח הרחבה קוד האתר טווח ארגוני

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

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

הטבלה טו וחי הארכה באורך קבוע מציגה דוגמה לשלושה מיקומים וטווחי הארכה בא ורך קבוע. מכיוון שיש להימנע מהרגלי חיוג חופפים, חשוב לוודא כי עבור כל טווח הרחבה הספרה הראשונה של הטווח אינה תואמת את ספרת ההיגוי לחיוג בין אתרים מקוצר. אם לדוגמה 8 נבחרה כספרת ההיגוי לחיוג בין אתרים, אזי אין טווח הרחבה באתר כלשהו יכול להתחיל ב- 8. בדרך כלל, התוספים במיקום נתון תואמים את הספרות האחרונות של ה- DID שהוקצו למיקום זה. כדי למנוע התנגשויות ניתן לשנות את הספרה הראשונה של התוסף. אם, לדוגמה, נעשה שימוש ב- DID בטווח +1 408 555 8XXX במיקום, במקום להשתמש ב- 8XXX כטווח הרחבה ניתן להשתמש ב- 7XXX עבור התוספים באתר זה

טבלה 3. טווחי הארכה באורך קבוע
אתר טווח הרחבה הרחבות קוד האתר טווח ארגוני

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

מחרוזות חיוג שבע ספרות שחייגו במכשיר באמצעות תוכנית החיוג האמריקאית חופפות לתבנית בת שבע ספרות לחיוג מקומי בתוכנית החיוג האמריקאית הטעונה מראש. כדי למנוע חפיפות בין הרגלי חיוג ברשת ומחוץ לרשת (PSTN), ניתן להשתמש בקוד גישה חיצוני חובה במיקום זה. אם סכימת המספור הארג ונית הקיימת והחיוג המקוצר המקביל בין אתרים חופפים לדפוסים בחיוגה הלאומית, אז במהלך המעבר לסכימת המספור כדי למנוע חפיפות ניתן לשנות גם לצורה ארוכה או קצרה יותר. הדרך הקלה ביותר להשיג זאת היא להוסיף ספרת ריפוד נוספת לסכימת המספור. סכימת החיוג החדשה הארוכה יותר בין אתרים צריכה להיות מאומצת רק על ידי משתמשים שכבר עברו אליה. משתמשים עדיין יכולים להמשיך לחייג שבע ספרות. תוכנית החיוג הארגונית המופעלת במקרה זה צריכה לוודא שהחיוג המקוצר בן שבע ספרות מ- ל- ל- י Unified CM הפוך ל-+E.164 או לפורמט החיוג המקוצר שנפרס עליו. זה צריך להיעשות לפני שליחת השיחה לשער המקומי.

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

טבלה 4. מעבר חיוג בן שבע ספרות

אתר הרחבות קוד האתר טווח ארגוני אודה לאתר אנטרפרייז

NYC 2XXX 22 8 22 2XXX 822 8 822 2XXX

SFO 8XXX 23 8 23 7XXX 823 8 823 7XXX

RTP 1XXX 24 8 24 11XX 824 8 824 11XX

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

הקלטה

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

1. בחירת ספק הקלטת שיחות

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

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

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

דרישות עסקיות: בחירת הספק צריכה להיות מונעת על ידי הערכה של גורמים עסקיים כגון ציות לתקנות (דוגמה - MiFID II, HIPAA), א בטחת איכות, יישוב סכסוכים או צרכי הכשרה

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

2. בחירת אזור

קביעת האזור שבו מאוחסנות ומעובדות הקלטות שיחות היא קריטית לתאימות ולביצועים:

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

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

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

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

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

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

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

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

תחזיות צמיחה: שקול צמיחה צפויה בהיקפי השיחות או הרחבת היקף ה הקלטה, שעשויה לנבוע מהגדלת קנה מידה עסקי, דרישות רגולטוריות חדשות או הצטרפות של משתמשים או מיקומים נוספים.

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

שיחת חירום

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

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

כל הלקוחות צריכים לפרוס, לכל הפחות, את תצורת שיחות החירום הבסיסית. שיחת חירום בסיסית דורשת להקצות לפחות מספר+E.164 אחד בבעלות לקוח לכל מיקום שהוגדר ב-. עבור שיחות חירום בסיסיות, כל מיקום יוגדר על ידי כתובת רחוב שאליה נשלחים שירותי משטרה, כיבוי אש או אמבולנס במקרה חירום. ברוב המקרים, המספר הראשי של המיקום הוא הבחירה הטובה ביותר לייצג את המיקום הפיזי של החירום. בדרך כלל, הקצאת הכתובת למספר +E.164 מתואמת עם ספק PSTN. התמונות שלהלן מציגות את הקצאת המספר הראשי שישמש כמספר השיחה לחירום למיקום ריצ'רדסון.

מיקום תצורת ECBN

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

תצורת ECBN של משתמש

עבור פריסות טלפוניה מבוססות ארה"ב שחייבות לספק פתרונות שיפור לשיחות חירום, משתמש ב- Horizon Mobility של RedSky המשולב בניתוב שיחות חירום. בעת שימוש ב- RedSky לניתוב שיחות, מנהל מערכת חייב להירשם לחשבון דרך סיסקו ולהגדיר את המידע המתאים ב הגדרות שיחה -> שירות כדי להפעיל תכונה זו. לאחר הפעלת שירות RedSky ברמת המערכת, מנהל מערכת יאפשר את שירות RedSky בכל רמת מיקום. הפעלת שיחות חירום משופרות במיקום תפעיל את השירות עבור כל המכשירים שהוקצו למיקום זה. התקנים התומכים בשיחות חירום משופרות הם טלפונים MPP של סיסקו, טלפונים של Cisco PhoneOS ושל סיסקו.

ישנן שתי הגדרות להפעלת שיחות חירום משופרות במיקום. יש להשתמש באפש רות אפשר ל- RedSky לקבל מידע על קישוריות רשת ושיחות בדיקה כדי לוודא שתצורת RedSky עבור מיפוי התקנים ותשתיות נכונה. הגדרה זו מאפשרת גם לבצע שיחות בדיקה ל- 933 כדי לבצע אימות מיקום באמצעות מערכת IVR של RedSky כדי לקרוא את מיקום המתקשר. למרות שמסמך זה לא יכסה את תצורת RedSky למעקב אחר מיקום, מנהל מערכת צריך לבדוק תמיד את גילוי המיקום שלו לפני הפעלת שיחות חירום לנתיב ל- RedSky. לאחר השלמת הבדיקה ואומת כמדויקת, מנהל המערכת ינתב שיחות ל- RedSky על ידי החלפת שיחות החירום במסלול ל- RedSky. מתג זה יפנה את כל שיחות החירום למיקום ל- RedSky למ סירה למרכז המשיבון עבור המיקום.

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

רישוי

ישנן מספר אפשרויות להקצאת רישיונות למשתמשים.

הקצאה ידנית דרך

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

מנהלי מערכת יכולים לערוך רישיונות שירות עבור משתמשים בודדים ולהקצות רישיונות שיחות ישירות.

תבניות הקצאת רישיונות אוטומטיות

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

ניתן לבצע רישוי אוטומטי באמצעות סנכרון ספריות או עדכונים ידניים למשתמש, אך ל משתמשים חייב להיות מספר טלפון תקף בפורמט +E.164 ומספרי הטלפון חייבים להתקיים במי קום לפני הקצאת המשתמש. אם התנאים אינם מתקיימים (למשל פורמט מספר טלפון לא חוקי), רישיונות לא יוקצו.

הקצאה בכמות גדולה באמצעות תבנית CSV

העלה קובץ CSV עם פרטי משתמש והקצאות רישיון כדי להוסיף או לשנות מספר משתמשים בו זמנית.

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

הקצאה מבוססת API

השתמש בממשקי API כדי להקצות רישיונות ולנהל משתמשים באופן תכנותי.

תומך בפעולות API לניהול משתמשים ורישיונות (אנשים, SCIM 2.0 ו- API של רישיונות), שניתן למנף לאוטומציה של הקצאת רישיונות. ממשק ה- API של הרישיונות מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ותוספים.
טבלה 5. אפשרויות הקצאת משתמשים - סיכום
שיטת הקצאה יתרונות חסרונות
דרך ידנית פשוט למעט משתמשים.
מאפשר שליטה מדויקת ומפורטת על הקצ את רישיון.
לא ניתן להרחבה, גוזל זמן
נוטה לטעות אנושית במהלך כניסה ידנית.

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

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

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

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

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

לקבלת מידע נוסף, ראה הגדרת הקצאות רי שיונות אוטומטיות ב- Control Hub והגד רת תבניות הקצאת רישיונות אוטומטיות ל Webex Calling משתמשים.

דרישות רישיון

סעיף זה מכסה רק רישיונות קשורים. סוגי רישיונות אחרים (דוגמה - רישום מכשיר Webex, העברת הודעות, פ גישות) אינם מכוסים. כחלק מתהליך התכנון יש לקבוע את דרישות הרי שיון. יש לחשב את ספירת הרישיונות עבור סוגי הרישיונות הבאים:

סטנדרטי: מספר משתמשים בודדים הדורשים תכונות טלפוניה סטנדרטיות.

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

סביבת עבודה לאזור משות ף: מספר מיקומי שימוש משותף או אזורים משותפים הדורשים יכולות שיחות סטנדרטיות.

סיוע ללקוח: מספר הסוכנים והמפקחים הזקוקים לתכונות סיוע ללקוח. הסיוע ללקוח כולל את הרישיון המקצועי.

שיחות רשימת מסלולים: מספר שיחות PSTN המחוברות לענן הנדרשות בין משתמשים מקומיים ו/או יישומי צד שלישי מיוחדים מקומיים.

מסוף מלווה: מספר המשתמשים הזקוקים לגישה ללקוח המסוף הנלווה.

תוכנית שיחות של סיסקו (תוכנית שיחות יוצאות): מספר המשתמשים הזקוקים למספר PSTN ו/או גישה לשיחות PSTN יוצאות עבור שירות PSTN של Cisco.

אין סוג רישיון ייעודי עבור סביבות עבודה מקצועיות. סביבות עבודה מקצועיות צורכות רישיון מקצועי.

סביבות עבודה מסוג Hotdesk בלבד מציעות שירות מארח הדלפק חם ושיחות חירום ממארח הדלפק חם ו אינן דורשות רישיון כלשהו. לקבלת מידע נוסף, ראה הוספ ה וניהול של התקני Hot Desk בלבד.

כדי לקבוע את סוג הרישיון הנדרש עבור כל משתמש וסביבת עבודה בהתבסס על התכונות הדרושות, ראה תכונות זמינות לפי סוג רישיון עבור Webex Calling.

כדי להבדיל בין הפונקציונליות המוצעת על ידי תורי שיחות בשילוב עם הרישיון המקצועי בניגוד לסיוע ללקוח, ראה תור Webex Calling שיחות והשוואת תכונות סיוע ללקוח.

הקצאת משתמשים

בעת הקצאת משתמשים ב- Webex, קיימות מספר אפשרויות זמינות, שכל אחת מהן מתאימה לצרכים ול סביבות ארגוניות שונות:

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

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

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

אפליקציית אשף Entra ID (Azure AD): שיטה זו מיועדת לארגונים המשתמשים ב- Microsoft Entra ID (Azure AD), ומספקת סנכרון אוטומטי כמעט בזמן אמת של חשבונות משתמש ותכונות ישירות מ- Entra ID אל. הוא מנוהל באופן מלא בפנים ודורש התקנה מינימלית.

יישומי SCIM 2.0: עבור סביבות שאינן של Microsoft או ספקי זהות אחרים כמו Okta או Duo, אפליקציות סנכרון מבוססות SCIM מאפשרות הקצאה אוטומטית של משתמשים וביטול הקצאה באמצעות מיפוי תכונות וסנכרון קבו צתי.

Unified CMסנכרון משתמש: אפשרות זו מאפשרת ליצור חשבונות משתמש המבוססים על משתמשי קצה קיימים על ידי סנכרון מ- אל. פעולה זו מחייבת הפעלה של UC מחובר לענן (CCUC) באשכולות המקומיים. עם זאת, בדרך כלל מומלץ לסנכרן משתמשים מספריית ענן מרכזית כמו Entra ID ולא ישירות מ.

הקצאת API: ניתן להשתמש בממשקי API ציבוריים (אנשים, SCIM 2.0) כדי לספק משתמשים. היתרון העיקרי בשימוש בממשקי API הוא האפשרות לשלב את הקצאת המשתמש במערכות ארגוניות אחרות.
טבלה 6. אפשרויות הקצאת משתמשים עבור
שיטת הקצאה תיאור יתרונות חסרונות
ידני יצירה/ניהול משתמשים בנפרד ב פשוט למעט משתמשים; אין צורך בתשתית לא ניתן להרחבה; גוזל זמן עבור משתמשים רבים
בכמות גדולה (קובץ CSV) ייבוא/עדכן משתמשים בכמות גדולה באמצעות CSV ב יעיל לקבוצות; אין צורך בקידוד הכנה ידנית ל- CSV; פחות דינמי
ממשק API של אנשים ו- SCIM 2.0 ניהול משתמשים תכנותי באמצעות ממשקי API של Webex גמיש; תומך באוטומציה ואינטגרציה דורש פיתוח ותשתיות
סנכרון ספריות סנכרון אוטומטי מ- AD, Entra ID, אפליקציות SCIM, Unified CM אוטומציה של מחזור חיים; תומך בסינון ומיפוי מורכבות התקנה: לחלק מהאפשרויות יש תכונות מוגבלות או דורשות ת שתית
סקירה כללית וטבלה אלה משקפים את אפשרויות הקצאת המשתמשים העיקריות, היתרונות והמגבלות שלהן כדי לעזור לך לבחור את הגישה הטובה ביותר לצרכי הארגון שלך.

קבוצות משתמשים

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

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

ניהול פשוט: ניהול רישיונות, הגדרות ומד יניות עבור מספר משתמשים בו זמנית.

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

מדרגיות: תומך עד 250,000 חברים לקבוצה.

אינטגר ציה: סנכרן קבוצות מ- Microsoft Entra ID (Azure AD) או Active Directory לניהול משתמשים וקבוצות אוטומטי.

גמישות: צור קבוצות מקומיות או סנכרן קבוצות אבטחה; נהל חברות בקבוצה באופן ידני או באמצעות קבצי CSV.

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

מקרי השימוש העיקריים עבור קבוצות משתמשים בעת הקצאה הם:

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

תבניות הגדרות: החל אוספים של הגדרות שירות (למשל, העברת הודעות, פגישה, שיחות) על קבוצות לחוויית משתמש עקבית.

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

אוטומציה ואינטגר ציה: השתמש בממשקי API או בסנכרון ספריות לניהול מחזור חיים אוטומטי של משתמשים וקבוצות.

הטבלה הבאה מסכמת את האפשרויות השונות לניהול קבוצות משתמשים וני הול קבוצות ב-.
טבלה 7. אפשרויות לניהול קבוצות וחברות קבוצתיות
אופציה תיאור יתרונות חסרונות

הקצאה קבוצתית (קבוצות) צור ונהל קבוצות ישירות. הוספה/הסרה של חברים באופן ידני או באמצעות CSV. שליטה מלאה על חברות בקבוצה
יישום מיידי של רישיונות ות בניות
קל ליצור ולערוך קבוצות נדרשים עדכונים ידניים
סיכון לשגיאות בהעלאות CSV ידניות
אין סנכ רון אוטומטי עם ספריות חיצוניות

קבוצות מסונכרנות ממזהה Entra (Azure AD) או Active Directory סנכרן אוטומטית קבוצות אבטחה וחברות מ שירותי ספריות חיצוניים. סנכרון אוטומטי מפחית עבודה ידנית
מבטיח עקביות עם המדריך הארגוני
תומך בארגונים גדולים
לא ניתן לערוך חברות בקבוצה ב-
עיכוב סנכרון עד 12 שעות
קבוצות מקוננות דורשות בחירה ידנית

קבוצות ו- SCIM 2.0 API (קבוצות) השתמש בקבוצות או ב- SCIM 2.0 API לניהול קבוצות וחברות פרוגרמטי אוטומציה ואינטגרציה עם מערכות אחרות
ניתן להרחבה לסביבות גדולות או מורכ בות
דורש מאמץ פיתוח
המורכבות תלויה בשימוש ב- API

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

גישה מקיפה זו לניהול קבוצות משתמשים מאפשרת לארגונים לנהל ביעילות רישיונות משתמשים, הגדרות ומדיניות, ומבטיחה חוויות שיתוף פעולה עקביות וניתנות להרחבה.

גישה מומלצת בעת מעבר מ-

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

סיסקו ממליצה להשתמש בספריית ענן מרכזית כגון Microsoft Entra ID (Azure AD) כ מקור האמת היחיד לזהויות משתמשים. סנכרון משתמשים מ- Entra ID כדי להבטיח עקביות, מפשט את הניהול ותומך ביכולות כניסה יחידה (SSO).

כדי להבטיח שכל המשתמשים נמצאים גם ב- Entra ID, ארגונים צריכים לוודא שחשבונות המשתמש ב- תואמים לחשבונות ב- Entra ID. ניתן לעשות זאת על ידי ייצוא רשימות משתמשים והשוואתן עם רשימות משתמשים של Entra ID.

לסיכום, שיטת ההקצאה המומלצת היא לסנכרן משתמשים מ- Microsoft Entra ID (Azure AD) ל- Webex באמצעות אשף Azure AD או יישומי SCIM. הקצאה בכמות גדולה ידנית ו- CSV זמינות כשיטות משלימות אך הן פחות ניתנות להרחבה ונוטות יותר לשגיאות עבור ארגונים גדולים. הבטחה ש-Entra ID הוא המקור הסמכותי וכי כל המשתמשים קיימים ב- Entra ID היא קריטית להעברה מוצלחת וחוויית משתמש עקבית ברחבי סביבות.

המעבר משירות ספריות מקומי, למשלActive Directory, לשירות ספריות ענן, כמו Entra ID (מזהה Azure), אינו תלוי במעבר השיחה. סיסקו ממליצה לסיים את המעבר לשירות ספריות ענן לפני תחילת מעבר השיחות.

עיצוב קבוצות משתמשים

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

שם קבוצה: שם ייחודי של הקבוצה.

רישיונות: רישיונות שיוקצו לקבוצה זו (אם קיימים) והיקף (יש להקצות רישיונות למשתמשים קיימים או רק למשתמשים חדשים)

תבניות הגדרות: תבניות שיחות של אפליקציות Webex ו- משתמשים.

סנכרון ספריות: האם קבוצה זו תסונכרן מהספרייה הארגונית או שמא מדובר בקבוצת Webex מקומית המסופקת ב- Control Hub או באמצעות ממשק API.

תיאור: כיצד תשמש קבוצה זו ואילו משתמשים צריכים להיות חברים בקבוצה זו

פרטים אלה ישמשו בהמשך שלב היישום ליצירת קבוצות או קבוצות מקומיות בספריית הארגון ולנהל חברות בקבוצה של משתמשים.

כניסה יחידה (SSO)

סיסקו ממליצה להשתמש ב- SSO לאימות משתמשים. לשימוש ב- SSO יש כמה יתרונות משכנעים, כולל:

אימות משתמש פשוט יותר: משתמשים יכולים להיכנס פעם אחת באמצעות האישורים הארגוניים שלהם (למשל מ- Azure ID) כדי לגשת ליישומים משולבים אחרים, מה שמבטל את הצורך בסיסמאות מרובות ול הפחית את הנחיות הכניסה. זה משפר את האבטחה על ידי הבטחת סיסמאות ארגוניות לעולם לא מאוחסנות או מועברות לאחר האימות.

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

אבטחה משופרת: SSO מפחית את עייפות הסיסמאות ואת הסיכון להפרות הקשורות לסיסמה על ידי ריכוז האי מות באמצעות ספקי זהות מהימנים (IDP).

שילוב קל של אימות רב-גורמי (MFA): ניתן לתמוך בקלות ב - MFA באמצעות פתרון ניהול גישה לזהויות כמו Cisco Duo או באמצעות תמיכה ב- M FA של ה- IdP.

ישנן מספר אפשרויות ליישם SSO עבור שירותים:

SSO מבוסס SAML 2.0: הפרו טוקול הראשי הנתמך לשילוב SSO, המאפשר החלפה מאובטחת של מידע אימות בין Id P לבין ספק השירות.

חיבור OpenID (OIDC): נתמך כפרוטוקול אימות מודרני חלופי לשילוב SSO.

זהות Webex: נתמכת גם כאפשרות של ספק זהות.

SSO מוגדר ומנוהל באופן מרכזי באמצעות, ודורש החלפת מטא נתונים בין ה- IdP שנבחר.

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

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

סיסקו דואו

אוקטה

Microsoft Active Directoryשירותי פדרציה (ADFS)

מיקרוסופט Azure

פינגפדרט

אופנאם

F5 BIG-IP.

IDP אלה תואמים לתקני SAML 2.0 או OpenID Connect ואומתו לתאימות לפתרונות שיתוף פעולה של סיסקו.

תמיכה מרובה של IdP

מאפשר לארגונים להגדיר SSO עם מספר IDPs כדי להתאים לסבי בות IT מורכבות כגון מיזוגים, רכישות או מחלקות IT מבוזרות שבהן קבוצות שונות משתמשות ב-IDP שונים. ניתן ליישם תמיכה מרובה של IdP באמצעות תכונת IdP מרובה בתוך מערכת IAM ארגונית כמו Cisco Duo או באמצעות שילוב של מערכת IAM ארגונית.

התמיכה המרובה של ספק הזהות (IdP) מטפלת במספר מקרי שימוש מרכזיים שבהם ארגונים דורשים אימות גמיש ומאובטח בסביבות IT מגוונות:

1. מיזוגים ורכישות

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

2. מחלקות IT עצמאיות מרובות

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

3. קבוצות משתמשים או דומיינים שונים

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

4. תמיכה בפרוטוקולי אימות שונים

תומך ב- IDP של SAML ו- OpenID Connect (OIDC), ומאפשר לארגונים לשלב סוגים שונים של ספקי זהות בהתאם לתשתית הקיימת שלהם ולדרישות האבטחה שלהם.

5. אבטחה ותאימות משופרים

על ידי הפעלת IDP מרובים, ארגונים יכולים ליישם מנגנוני אימות חזקים יותר, כולל אימות רב-גורמי (MFA) באמצעות שילובים כמו Duo, ולאכוף מדיניות אבטחה עקבית על פני בסיסי משתמשים מגוונים.

6. חווית משתמש פשוטה

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

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

שני MFA עם SSO עבור

Duo Access Gateway (DAG) יכול לאמת משתמשים באמצעות ספריות קיימות מקומיות או מבוססות ענן, כגון Active Directory (AD) ו- OpenLDAP. הוא תומך גם באינטגרציה עם ספקי זהות אחרים כמו מיקרוסופט ADFS, מיקרוסופט Azure, אוקטה, OneLogin, CAS ו- Shibboleth. גמישות זו מאפשרת לארגונים להשתמש בת שתית הספריות הנוכחית שלהם עבור Webex SSO עם Duo MFA.

Duo פועל כשכבת אימות חזקה על גבי אימות הספרייה הראשית. הוא מת פקד כספק זהות (IdP) המשתמש ב- SAML 2.0 כדי לאכוף אימות דו-גורמי (2FA) לפני מתן גישה ל. Duo מעריך את הקשר של משתמשים, מכשירים ורשת מול מדיניות הניתנת להגדרה כדי לאפשר או לדחות גישה, ומשפר את האבטחה מעבר לשם משתמש וסיסמה בלבד. Duo מספק גם בקרות מדיניות גמישות, כגון דרישת MFA בכל כניסה עבור יישומים מסוימים ותדירות נמוכה יותר עבור אחרים.

היתרונות של Cisco Duo כוללים:

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

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

שילוב עם ספריות קיימות: תומך ב - AD מקומי, OpenLDAP, ספריות ענן וספקי SSO שונים, תוך צמצום שינויי תשתית.

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

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

הרשמה לשירות עצמי: הר שמה מובנית והנחת צמד משפרות את חווית המשתמש במהלך הגדרת MFA.

Duo MFA עם SSO למנף ספריות קיימות כמו ו Active Directory - OpenLDAP, או ספ קי זהות ענן, לאימות משתמשים. תפקידו של Duo הוא לספק גורם אימות שני חזק ומונע מדיניות המשולב באמצעות SAML 2.0, שיפור האבטחה תוך שמירה על נוחות המשתמש באמצעות SSO. היתרונות כוללים תנוחת אבטחה משופרת, אכיפת מדיניות גמישה, אינטגרציה חלקה וחווית משתמש טובה יותר.

סיסקו ממליצה ליישם SSO למשתמשים. לקבלת אבטחה משופרת שילוב עם Cisco Duo מומלץ.

יש לפרוס את אסטרטגיית ה- IAM ו- SSO הארגונית לפני תחילת המעבר מ -.

תכונות

יש השלמה מלאה של תכונות ליבה הכלולות בשירות. זה כולל תכונות שיחות רבות ברמה ארגונית שהיו זמינות במשך שנים רבות. ייתכן שלא תראה שוויון של 100% בין תכונות לתכונות, אולם כפי שאתה יכול לראות באיור שלהלן, תכונות השיחות העיקריות זמינות ב.

Webex Callingתכונות ברמה ארגונית

מלבד תכונות המשתמש הרבות, יש תכונות מערכת ליבה הכלולות בפלטפורמה. אלה כוללים תכונות כמו דיי לים אוטומטיים, תורי שיחות, פארק שיחות וכו '. אתה יכול לראות את כל תכונות מערכת הליבה הזמינות תחת שירות → שיחות → תכונות כפי שמתואר בת כונות Webex Calling הליבה של איור.

Webex Callingתכונות ליבה

מלווה אוטומטי

השיחה האוטומטית מאפשרת אוטומציה 24/7 של טיפול בשיחות נכנסות, המאפשר טיפול יעיל בשיחות ללא צורך באדם לענות לכל שיחה.

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

השיחה האוטומטית תומכת בתכונות העיקריות הבאות:

לוחות זמנים עסקיים ואחרי שעות העבודה

לוח זמנים לחג

אפשרות תפריט חיוג כדי לכוון את הלקוחות שלך לאן שהם צריכים ללכת

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

אפשרות חיוג לפי שם

אפשרויות העברת שיחות

ניתוח ודוחות של רכזת בקרה.

לקבלת מידע נוסף, ראה ניהול שיחות טלפון אוטומ טיות.

התקשר לפארק

Call park נותן למשתמשים את היכולת בקלות לשים שיחה ב המתנה כדי שמשתמש אחר יוכל לאחזר בקלות כאשר הם זמינים לקחת אותה. זה גם משחרר את המשתמש שענה לשיחה המק ורית לבצע או לקבל שיחות אחרות בזמן שהשיחה חונה.

ישנם שני סוגים של פארקי שיחות זמינים ב:

Call park direct - מאפשר לכל משתמש להחנות שיחה לתוסף של משתמש אחר או לתוסף פארק שיחות, כפי שהוגדר על ידי מנהל המערכת

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

בהתבסס על התצורה וסוג הפארק, משתמשים יכולים לאחזר שיחות על ידי חיוג *88+><extension of parked call>, לחיצה על מקש הקו המשויך לתו סף פארק השיחות או באמצעות מקש רך בטלפון ה- IP שלהם.

אפשרות החזרה זמינה לזיכרון שיחה חונה לאחר תקופה מוגדרת למשתמש שהחנה את השיחה או למשתמש חלופי.

לקבלת מידע נוסף, ראה ניהול חניית שיחות במרכז הבקרה.

איסוף שיחות

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

המשתמשים בקבוצה חייבים להיות באותו מיקום.

משתמשים יכולים להשתמש בטלפון השולחני או בטלפון השולחני שלהם כדי לאסוף שיחה.

:

תומך בהתראות חזותיות ושמע

הודעת שיחה נכנסת

איסוף שיחות טוסט מבוסס FACK (חיוג *98) או הודעה

התראות לאיסוף שיחות עבור רב-שורות.

טלפונים שולחניים:

הודעת שיחה נכנסת

פעמוני שמע והתראה חזותית דרך נורית המכשיר. ה- 6821 תומך רק בפעוני שמע

כאשר סוג ההודעה נבחר ב- אינו ללא

הודעות איסוף שיחות רק עבור קווים ראשיים בלבד.

לקבלת מידע נוסף, ראה קביעת תצורה של קבוצת איסוף שיחות.

תור שיחה

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

הקריאה של סיסקו לשילוב Microsoft Teams מאפשרת לסוכנים לגשת לשיחות ותכונות תור שיחות ישירות מלקוח Microsoft Teams שלהם.

תורי שיחות תומכים בתכונות העיקריות הבאות:

ברכות והודעות (קבלת פנים, נחמה, לחישה וכו ')

החזק מוזיקה

התקשרות חוזרת

מדיניות ניתוב תור (שירות לילה, חגים, העברה)

כניסה/יציאה בתור סוכן

ניהול סטטוס תור סוכן

או תמיכה טלפונית בשולחן העבודה

סוכן מפקח מתקשר לפקח, מאמן, דוברה או משתלט באמצעות קודי גישה לתכונות (FACS)

(גישה למנהל) עבור:

ניהול תור

ניתוח ודיווח של סוכנים ותור

ניהול תור, סוכן ומפקח.

לקבלת מידע נוסף, ראה קביעת תצורה של תור שיחות.

כולל תכונת תוספת לסיוע לקוח המספקת יכולות תור שיחות נוספות ומע ניקה לסוכנים ולמפקחים חווית משתמש טובה יותר בתוך. להשוואה בין התכונות של תור השיחות ותכונות סיוע ללקוח, ראה Webex Callingהשוואת תכונות תור שיחות וסיוע ללקוח.

קבוצת האנט

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

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

לקבלת מידע נוסף, ראה ניהול קבוצות ציד במרכז הבקרה.

מצבי הפעלה

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

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

משתמש מורשה יכול לעבור בין תרחישים שונים אלה (מצבים) להעברת שיחות אם הוא צריך לשנות היכן מנותבות שיחות נכנסות לתקופה מסוימת. משתמשים אלה יכולים לנהל את המצבים באמצעות טלפונים 6800/7800/8800 MPP שלהם, טלפונים 9800 או במרכז המשתמשים במצבים ניהול.

לקבלת מידע נוסף, ראה ניתוב שיחות בהתבסס על מצבי הפעלה ב- Webex Calling.

קבוצת פיג'ינג

קבוצות הדפינג מאפשרות למשתמשים לבצע שיחה בכיוון אחד כדי לשלוח הודעת שמע לקבוצת משתמשים. כל קבוצה יכולה להכיל עד 75 משתמשי יעד ו/או סביבות עבודה שאליהם מגיעים באמצעות חיוג למספר או סיומת מוגדרת מראש.

כאשר משתמש מתקשר לקבוצת עימוד, מתבצעת שיחה בו זמנית לכל היעדים שהוקצו בקבו צה, ובשלב זה המתקשר יכול לדבר את ההודעות שלו ולנתק לאחר סיום ההודעות.

לקבלת מידע נוסף, ראה קביעת תצורה של קבוצת עימוד ב- Control Hub.

הקלטות

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

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

לקבלת מידע נוסף אודות תכונה זו ורשימה של הקלטות של צד שלישי, ראה ניהול הק לטת שיחות עבור Webex Calling.

טווח הגעה למספר יחיד

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

לקבלת מידע נוסף אודות תכונה זו ועל האופן שבו מנהל מערכת מגדיר אותה, ראה קביעת תצורה של טווח הגעה למספר יחיד (Office Anywhere).

לקבלת מידע נוסף על האופן שבו משתמש יכול לנהל ולהגדיר תכונה זו עבור עצמו ב - Webex User Hub (פורטל), ראה קביעת תצורה של טווח הגעה למספר יחיד (משרד בכל מקום).

קבוצת דואר קולי

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

דואר קולי למטרות כלליות עבור מחלקה או קבוצת עבודה

הוספת אפשרות של דואר קולי למלווה אוטומטי או לקבוצת ציד

כדי לשלוח שיחות הצפה מתור שיחות

משתמשים הזקוקים רק לתיבת דואר קולי.

לקבלת מידע נוסף, ראה ניהול דואר קולי משותף ותיבת פקס נכנסת עבור. Webex Calling

מסוף הנלווה מופיע בדף תכונות שיחות ב- Webex, אולם זוהי תכונה תוספת הדורשת רכישת רישיון המסוף הנלווה לשימוש.

לקבלת מידע נוסף, ראה התחלת העבודה עם מסוף הנלווה.

לקבלת מידע על כל התכונות, כולל תכונות תוספות מסוימות, ראה תכונות זמינות לפי סוג רישיון עבור Webex Calling.

טבלה 1. מידע ללכידה עבור כל מיקום
מידע	הערה
טווח (ים) הרחבה	לכל מיקום יכולים להיות הרחבות המתחילות בספרות שונות. יש לחסוך ספרה אחת לספרת ההיגוי החיוג הבין-אתרים (לדוגמה 8) וספרה אחת לספרת ההיגוי של PSTN (לדוגמה 9). שום טווח הרחבה לא יכול להתחיל עם אחת מש תי הספרות הללו. כל טווחי ההרחבה של כל המיקומים חייבים להיות בא ורך שווה.
טווח (ים) DID	-
ספרת היגוי PSTN	-
קוד האתר	כל קודי האתר של כל המיקומים צריכים להיות ייחודיים ובעלי אורך זהה.
מספר ראשי	בעת יצירת מיקום יש לספק שני DIDs. אחד כמספר ראשי (לדוגמה שיוקצה לשירות מלווה אוטומטי) ואחד עבור פורטל הדואר הקולי. הקצאת DID אחד למספר הדואר הקולי.
מספר דואר קולי
מספר הרישיונות	רישיונות נדרשים לפי סוג כולל סטנדרטי, מקצועי, סביבת עבודה, רשימת מסלולים, תוכנית שיחות יוצאות.
שיחות במקביל בשעות העמוסות	סכום השיחות במקביל בין התקנים ובין התקנים לשער המקומי (PSTN ושיחות למכשירים). נדרש כדי לקבוע את רוחב הפס הנדרש לגישה לאינטרנט.
ארץ	-
אזור זמן	-
שפה	-
איש קשר (שם, טלפון, דוא"ל)	-
כתובת (כתובת רחוב, עיר, מדינה, מיקוד)	-
מיקום פיזי הניתן לשליחה של שירותי חירום לנקודות קצה	מיקום הניתן למשלוח של המכשיר המשמש לשיחות חירום כולל בדרך כלל את הדברים הבאים: כתובת בניין, כתובת בנין+מספר קומה, כתובת בנין+מספר סוויטה, או כתובת בניין + מספר קומה + מספר משרד/קובי.
לכל מכשיר מיקום רשת פיזי ייחודי לשירותי חירום	מיקום רשת פיזית לשיחות חירום כולל בדרך כלל את הדברים הבאים: מתג/יציאת מתג להתקנים קוויים, מזהי ערכת שירות בסיסיים (BSSID) של נקודת גישה אלחוטית (BSSID) עבור התקנים מחוברים אלחוטיים ו/או רשתות משנה IP מקומיות עבור התקני נקודת קצה.

טבלה 2. דוגמה למספור ארגוני
אתר	טווח הרחבה	קוד האתר	טווח ארגוני
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

טבלה 3. טווחי הארכה באורך קבוע
אתר	טווח הרחבה	הרחבות	קוד האתר	טווח ארגוני
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

טבלה 4. מעבר חיוג בן שבע ספרות

אתר	הרחבות	קוד האתר	טווח ארגוני	אודה לאתר	אנטרפרייז
NYC	2XXX	22	8 22 2XXX	822	8 822 2XXX
SFO	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

טבלה 5. אפשרויות הקצאת משתמשים - סיכום
שיטת הקצאה	יתרונות	חסרונות
דרך ידנית	פשוט למעט משתמשים. מאפשר שליטה מדויקת ומפורטת על הקצ את רישיון.	לא ניתן להרחבה, גוזל זמן נוטה לטעות אנושית במהלך כניסה ידנית.
תבניות רישיון אוטומטיות	ניתן להרחבה מפחית שגיאות ידניות ניתן להחיל על משתמשים חדשים ו קיימים.	דורש מספרי טלפון ומיקומים חוקיים. מורכב יותר לה גדרה כמו כן דורש קבוצות משתמשים לכל קבוצת משתמשים עם דרישות רישוי שוות ערך.
העלאה בכמות גדולה של CSV	יעיל עבור קבוצות משתמשים גדולות מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ותוספים.	דורש עיצוב CSV זהיר פוטנציאל לשגיאות אם מספרי טלפון או סיומות חסרים או שגויים.
הקצאה מבוססת API	אוטומטי, גמיש. מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ותוספים.	דורש פיתוח וידע API.

טבלה 6. אפשרויות הקצאת משתמשים עבור
שיטת הקצאה	תיאור	יתרונות	חסרונות
ידני	יצירה/ניהול משתמשים בנפרד ב	פשוט למעט משתמשים; אין צורך בתשתית	לא ניתן להרחבה; גוזל זמן עבור משתמשים רבים
בכמות גדולה (קובץ CSV)	ייבוא/עדכן משתמשים בכמות גדולה באמצעות CSV ב	יעיל לקבוצות; אין צורך בקידוד	הכנה ידנית ל- CSV; פחות דינמי
ממשק API של אנשים ו- SCIM 2.0	ניהול משתמשים תכנותי באמצעות ממשקי API של Webex	גמיש; תומך באוטומציה ואינטגרציה	דורש פיתוח ותשתיות
סנכרון ספריות	סנכרון אוטומטי מ- AD, Entra ID, אפליקציות SCIM, Unified CM	אוטומציה של מחזור חיים; תומך בסינון ומיפוי	מורכבות התקנה: לחלק מהאפשרויות יש תכונות מוגבלות או דורשות ת שתית

טבלה 7. אפשרויות לניהול קבוצות וחברות קבוצתיות
אופציה	תיאור	יתרונות	חסרונות
הקצאה קבוצתית (קבוצות)	צור ונהל קבוצות ישירות. הוספה/הסרה של חברים באופן ידני או באמצעות CSV.	שליטה מלאה על חברות בקבוצה יישום מיידי של רישיונות ות בניות קל ליצור ולערוך קבוצות	נדרשים עדכונים ידניים סיכון לשגיאות בהעלאות CSV ידניות אין סנכ רון אוטומטי עם ספריות חיצוניות
קבוצות מסונכרנות ממזהה Entra (Azure AD) או Active Directory	סנכרן אוטומטית קבוצות אבטחה וחברות מ שירותי ספריות חיצוניים.	סנכרון אוטומטי מפחית עבודה ידנית מבטיח עקביות עם המדריך הארגוני תומך בארגונים גדולים	לא ניתן לערוך חברות בקבוצה ב- עיכוב סנכרון עד 12 שעות קבוצות מקוננות דורשות בחירה ידנית
קבוצות ו- SCIM 2.0 API (קבוצות)	השתמש בקבוצות או ב- SCIM 2.0 API לניהול קבוצות וחברות פרוגרמטי	אוטומציה ואינטגרציה עם מערכות אחרות ניתן להרחבה לסביבות גדולות או מורכ בות	דורש מאמץ פיתוח המורכבות תלויה בשימוש ב- API

ליישם

מוכנות לרשת

הגדרה ראשונית

אימות תחום

תביעה (המרה) של משתמשים קיימים

קביעת תצורה ובדיקה של סנכרון ספריות

הגדרה ובדיקה של כניסה יחידה (SSO)

לרכוש, לספק ולאמת רישיונות

Webex Callingהגדרות שירות

הגירת פיילוט

רכישת PSTN

הגדר מיקומים

אינטגרציה עם בקרת שיחות מקומית

העברת משתמשים בקבוצות

סביבות עבודה

התקני אספקה

קביעת תצורה של תכונות

בדיקת קבלה

מוכנות רשת

השלב הראשון במעבר הוא להבטיח קישוריות אינטרנט אמינה ומאובטחת בין הרשת המקומית לענן.

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

מנהלי רשת ואבטחה חייבים להבין את הזרימות הללו במונחים של:

כיוון (נכנס לעומת יוצא)

פרוטוקולים (דוגמה - SIP TLS, SRTP, HTTPS)

טו@@ וחי כתובות IP המשמשים שירותים

מספרי יצי אה שיש לפתוח או לאפשר.

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

לקבלת מידע על הזרימות הנדרשות כולל כתובת IP, יציאות ופרוטוקולים, ראה מידע הפניה ליציאה עבור Webex Calling. השתמש ב מידע זה כדי להגדיר את חומת האש, פרוקסי ותשתיות רשת אחרות בפריסה הקיימת כדי לאפשר זרימות רשת.

פריצת אינטרנט מבוזרת מכל סניף או אתר היא הגישה המומלצת לשירותי שיתוף פעולה בע נן כגון. על ידי מתן אפשרות לתנועה לצאת באופן מקומי, מודל זה:

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

מתרחב ביעילות ככל שיותר משתמשים ואתרים עוברים

עובד בצורה חלקה עם SD-WAN, שיכול לנתב באופן דינמי הפעלות לנקודת הכניסה הקרובה לענן לקבלת ביצועים מיטביים

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

בנוסף, על ארגונים להבטיח רוחב פס אינטרנט נאות בכל אתר. רוחב הפ ס צריך להיות בגודל בהתבסס על המספר הצפוי של שיחות במקביל, ה- codec שנבחר (למשל, Opus או G.711), בתוספת תקורה לאיתות, שידורים חוזרים וצמיחה. זה מתיישב עם שלב ה הכנה של מחזור החיים של PPDIO ומבסס בסיס איתן להגירה.

הגדרה ראשונית

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

אימות תחום

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

ודא שכל הדומיינים המשויכים לכתובות הדוא"ל של המשתמשים שלך מאומתים. אימות תחום אינו בלעדי; ניתן לאמת את אותו תחום בארגונים מרובים.

לקבלת מידע נוסף על ניהול תחומים, ראה ניהול התחומים שלך.

תביעה (המרה) של משתמשים קיימים

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

לקבלת מידע נוסף על תביעות משתמשים, ראה ת ביעת משתמשים למשתמשי הארגון שלך (המרה).

הגדר ובדיקה של סנכרון ספריות

כדי לאפשר ניהול משתמשים וקבוצות חלק, באפשרותך לסנכרן משתמשים וקבוצות מה ספרייה הארגונית שלך או Microsoft Entra ID (לשעבר Azure AD) או Microsoft Active Directory (AD) אל. תהליך זה מבטיח כי זהויות משתמשים וחברות קבוצתיות נשמרות באופן עקבי ברחבי הסביבה שלך.

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

השיטה היעילה ביותר לסינון המשתמשים המסונכרנים היא למנף חברות בקבוצת ספריות:

1
יצירת קבוצת סנכרון ייעודית: בספרייה הארג ונית שלך (Microsoft Entra ID או AD), צור קבוצת אבטחה ספציפית לסנכרון (לדוגמה, קבוצת סנכרון).

2
אכלס את הקבוצה עם משתמשי יעד: הוסף לקבוצה זו רק את המשתמשים שברצונך לסנכרן (כגון קבוצת בדיקה בשלב הפיילוט). זה מאפשר לך לשלוט בחוזקה מי נכלל בתהליך הסנכרון.

3
קביעת תצורה של הסכם הסנכרון באמצעות סינון מבוסס קבוצה: בעת הגדרת הסכם הס נכרון בהקצאת Directory Connector או Entra ID, הגדר את התחום כך שיכלול רק משתמשים שהם חברים בקבוצה המיועדת.

עבור מזהה Microsoft Entra, באפשרותך להשתמש בהקצאות מבוססות קבוצה בהגדרות הקצאה

עבור AD, באפשרותך להגדיר מסנן LDAP שיכלול רק משתמשים השייכים לקבוצה ש צוינה.

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

שלבי יישום לדוגמה:

בספרייה פעילה:

צור קבוצת אבטחה בשם קבוצת סנכרון.

הוסף את משתמשי הפיילוט הרצויים לקבוצה זו.

הגדר מחבר ספריות עם מסנן LDAP כגון: (MemberOf=CN= קבוצת סנכרון WebEx, OU = קבוצות, DC=התחום שלך, DC=COM).

במיקרוסופט הזן מזהה:

יצירת קבוצה בשם קבוצת סנכרון

הקצאת הקבוצה להגדרות הקצאה של מזהה Entra

רק משתמשים בקבוצה זו יוקצו ל.

בדוק תמיד סנכרון מבוסס קבוצה בסביבה שאינה ייצור לפני הגשת בקשה לארגון כולו

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

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

הפניות:

סנכרן משתמשי זיהוי כניסה לרכזת הבקרה

הגדר את אפליקציית אשף ה- Entra ID במרכז הבקרה

מחבר ספרייה

הגדרה ובדיקה של כניסה יחידה (SSO)

כניסה יחידה (SSO) משפרת את האבטחה ומפשטת את גישת המשתמשים בכך שהיא מאפשרת למשתמשים לאמת פעם אחת עם האישורים הארגוניים שלהם ולקבל גישה חלקה אל. תומך בשילוב SSO עם מכשירי IDP תואמים ל- SAML 2.0, כולל Microsoft Entra ID (לשעבר Azure AD), פתרונות מאוחדים Active Directory (AD) ומדידים שונים של צד שלישי.

בשלב זה יש ליישם ולבדוק את הגדרת SSO המתוכננת.

הפניות:

שילוב כניסה יחידה ברכזת הבקרה

קביעת תצורה של כניסה יחידה לניהול webex

הגדר כניסה יחידה באמצעות מזהה Microsoft Entra

SSO עם מספר IDP

ניהול SSO באינטגרציה ברכזת הבקרה

לרכוש, לספק ולאמת רישיונות

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

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

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

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

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

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

Webex Callingהגדרות שירות

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

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

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

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

הגירת פיילוט

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

העברת הפיילוט צריכה למנף את אותו שילוב של כלים המסופקים ב- Cisco ושירותי העברה של צד שלישי המתו כננים לפריסה הארגונית הרחבה יותר, ולהבטיח שהת הליכים, זרימות העבודה של האוטומציה ונקודות האינטגרציה מאומתים ביסודיות בתנאים מייצגים.

המטרות העיקריות של פריסת פיילוט זו הן כפולות: ראשית, לאמת ולשכלל את תהליכי המעבר מקצה לקצה כולל זרימות עבודה להקצאת משתמשים, נהלי העברת נתונים ותצורות נקודות קצה; ושנית, לאמת באופן מקיף את הפונקציונליות של שירותים שהועברו בתנאים תפעוליים בעולם האמיתי.

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

התובנות שנצברו בשלב הפיילוט הזה מסייעות ב אופטימיזציה של גלי ההגירה הבאים ולהבטחת מעבר חלק ומפחית סיכונים עבור הארגון כולו.

רכישת PSTN

כדי לרכוש שירותי PSTN עבור, בחר תחילה אפשרות קישוריות PSTN ב-.

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

אם מעבר מלא (שלב 2) לענן הוא המטרה הסופית כולל PSTN, אז תידרש תוכנית שיחות של סיסקו או אפשרות Cloud Connect עבור PSTN.

עבוד עם הספק שבחרת כדי להזמין ולהעביר מספרי טלפון לפני שתגדיר אותם. הזמנת מספרי טלפון או הפעלת הזמנות יציאות נדרש/אפשרית רק עבור PSTN מקומי ו- Cloud Connect עבור. עבור תוכניות שיחות של סיסקו, ההזמנה וההעברה יוזמות מתוך Control Hub ברגע שנוצר המיקום, ובמדינות שבהן תוכנית השיחות של סיסקו זמינה. לקבלת מידע נוסף על תוכניות שיחות של Cisco, ראה תחילת העבודה עם תוכניות Cisco.

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

הגדר מיקומים

לפני הוספת משתמשים ומכשירים, עליך לספק מיקומי שיחות. עבור כל מיקום, יש להכניס כתובת רחוב חוקית. בארה"ב ובקנדה, כתובת זו מאומתת ומשמשת את הפלטפורמה ל שליחת מידע על מיקום PIDF-LO לשיחות חירום.

בעת קביעת תצורה של מיקומים המשתמשים ב- PSTN מקומי, עליך להגדיר את השערים המקומיים בהתאם. בתוך, יש ליצור תא מטען וקבוצת מסלולים עבור כל שער מקומי, ולאחר מכן קבוצת המסלול מוקצה כבחירת PSTN עבור המיקום. סיסקו ממליצה בחום לבחור תמיד קבוצת מסלולים כבחירת PSTN, מכיוון שגישה זו מאפשרת להוסיף בקלות גזעים נוספים בעתיד, התומכים הן במדרגיות והן ביתירות. סיסקו ממליצה גם לאפשר תמיכה בזהות כפולה ותמיכה ב- P-Charge-Info בכל תא מטען PSTN, מכיוון שהדבר מפשט את זיהוי הצד הניתן לחיוב עבור שיחות יוצאות ישירות או מופנות. אם ספק ה- PSTN שלך משתמש בכותרת אחרת לחיוב, באפשרותך להעתיק את המידע מהכותרת P-Charge-Info בשער המקומי לכותרת החיוב הנדרשת.

עבור מיקומים המשתמשים ב- Cloud Connect עבור או בתוכנית השיחות של Cisco כאפשרות PSTN שלהם, פשוט בחר את בחירת ה- PSTN המתאימה למי קום במהלך ההתקנה. אם המיקום משתמש ב- Cloud Connect עבור PSTN מקומי או ב- PSTN מקומי, יהיה עליך להוסיף את מספרי הטלפון שהוזמנו בשלב הקו דם. ניתן להוסיף מספרים כלא פעילים אם אינך מעוניין שיכללו אותם בני תוב שיחות מיד; באפשרותך להפעיל מספרים אלה מאוחר יותר כאשר הם מוקצים למשתמשים או לתכונות.

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

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

שילוב עם בקרת שיחות מקומית

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

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

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

העברת משתמשים בקבוצות

כאשר אתה מעביר משתמשים מ- אל, ייתכן שלא תוכל להעביר את כל המשתמשים בו זמנית. זה יכול לנבוע מסיבות מרובות, לרבות אך לא רק מספר האתרים או המשתמשים, כמה זמן לוקח לעבור לאתר ו /או קבוצת משתמשים בו זמנית, משאבי IT או אתר מוגבלים לתמיכה בחלון השינוי, משך חלון השינוי, מורכבות השינוי וכו'.

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

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

מעקב אחר משתמשים אחרים המשתמשים ב- BLFs

באותו טייס ציד, תור שיחה וכו '

קווים משותפים

שימוש באיסוף שיחות

שימוש באותם מספרי חניון שיחות

אינטרקום

מנהל/מנהל.

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

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

השתמש בפלט מהכלי Migration Insights או מכלי צד שלישי שבו השתמשת בשלב ההכנה כדי לקבוע אילו משתמשים ותכונות יש לקבץ יחד. פלט זה היה אמור לשמש לפיתוח תוכנית ההעברה שלך ויספק לך תובנות לגבי האופן שבו תקבץ משתמשים ותכונות שצריכים לעבור יחד.

השלבים העיקריים בעת מעבר קבוצת משתמשים הם:

זיהוי משתמשים להעברה משותפת

ודא שכל המשתמשים נמצאים

ודא שכל ה- TN עבור המשתמשים קיימים ב

ודא פורמט מספר טלפון נכון בספרייה

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

אימות או קביעת תצורה של כל שירותי השיחות והתכונות עבור קבוצת המשתמשים (לפני המעבר או במהלך המעבר בהתאם)

בספרייה הארגונית הוסף משתמשים לקבוצת המשתמשים המותאמים לשי חות

כלי מינוף - כלי העברת משתמשים ותכונות ו/או כלים של צד שלישי

השבת/מחק מספר ספריית משתמש/מכשיר ותכונות/שירותים להתקשר לאחר המעבר.

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

סביבות עבודה

ב-, סביבת עבודה מתייחסת למיקום משותף (כמו חדר ישיבות, חלל הצטופפות או שולחן עבודה חם) שניתן להקצות למכשירים, הרחבות ומשתמשים. שלא כמו טלפונים מסורתיים של Unifed CM, סביבות עבודה הן:

ממוקד מיקום: קשור למרחבים פיזיים.

גמיש למכשיר: יכול להכיל מכשיר אחד או יותר (טלפונים שולחניים, לוחות וכו ').

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

לקבלת מידע נוסף על סביבות עבודה ב-, ראה סביבות עבודה.

התקני אספקה

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

כל הטלפונים הנתמכים שעליך לעבור מהם יצטרכו להיות מוגדרים כמשתמש או כסביבת עבודה ויש להגדיר מחדש את הטלפון הפיזי כדי להירשם אליו. בנוסף, הטלפונים מסדרת 7800 ו- 8800 זקוקים לשדרוג הקושחה שלהם מקושחה ארגונית לקו שחה מרובת פלטפורמות (MPP). תהליך זה כולל טעינת קושחת מעבר לפני טעינת קושחת MPP הנדרשת לרישום. זה גם דורש רישיון ההגירה המתאים. סיסקו שיפ רה את התהליך הזה במהלך השנים האחרונות כדי להקל עליך לשדרג את טלפוני הקושחה הארגוניים שלך לקושחת MPP. לקבלת מידע נוסף על השלבים להשלמת שדרוג הקושחה, ראה המרת טלפונים IP מסדרת Cisco 7800 ו- 8800 בין קושחת ארגונית ו- MP P.

בנוסף לשלבים המפורטים במאמר זה, יש לו כלי מובנה, העבר את הטלפון שלך אל, שבו תוכל להשתמש כדי Webex Calling לסייע בהעברת הטלפונים 7800 ו- 8800 שלך מקושחה ארגונית ל- MPP. כלי זה גם מאפשר לך להוסיף את הטלפונים ולהקצות אותם למשתמשים או סביבות העבודה המתאימות. לקבלת מידע נוסף על השימוש בכלים, ראה העברת הטלפון שלך.

עבור כל טלפונים מסדרת 9800 הרשומים עם דרישת העברת הקושחה לעיל אינה חלה. טלפונים אלה מריצים את PhoneOS, הנת מך על ידי שניהם וגם. כדי להעביר טלפונים אלה אליהם תצטרך להוסיף אותםWebex Calling, להקצות אותם למשתמש או לסביבת עבודה ולאחר מכן לאפס את הטלפונים להגדרות היצרן. רצף האתחול של Phon eOS לרישום איור להלן מציג את רצף האתחול של PhoneOS וכיצד הטלפון יירשם לאחר הוספתו, גם אם הטלפון עדיין מסופק ו/או אפשרויות DHCP (דוגמה - 150) נמצאות בשימוש.

רצף אתחול PhoneOS לרישום

תומך באיפוס להגדרות היצרן של מכשירי PhoneOS כדי לאפשר כניסה ל- Zero-Touch. מנהלים יכולים לאפס מרחוק את הטלפונים 9800 ו- 8875 דרך ד פי הניהול של CUCM, מה שמבטל את הצורך בגישה פיזית לטלפונים כדי להרכיב את הטלפונים אליהם. תכונה זו נתמכת בחבילות המכשירים החל מה- 9 בספטמבר 2025:

CUCM v15 - מנהל תקשורת מאוחד גרסה 15

CUCM v14 - מנהל תקשורת מאוחד גרסה 14.

למידע נוסף על תהליך ההרשמה לסדרת 9800, ראה תהליך ההרשמה.

בנוסף לטלפוני ה- IP של סיסקו, ייתכן שיהיה צורך בהקצאת התקנים אחרים כגון מתאמי טלפון אנלוגיים (ATA), טלפונים אלחוטיים (Wifi, DECT), התקני וידאו, שערים קוליים ו התק ^נים וטלפונים של צד שלישי. לרבים מהמכשירים הללו אין נתיב שדרוג קושחה כמו טלפוני ה- IP כדי להעביר אותם מקושחה ארגונית לקושחת ענ ן. לכן, תספק כל אחד מהמכשירים הללו ב- Control Hub. לא ניתן להעביר לחלק מאלה והמודל המקביל יצטרך להחליף אותו (למשל ATA 191/192) ואחרים ידרשו תצורה ידנית מחדש ו/או שינויים בתוכנה.

שערים קוליים - כדי להעביר את השער המקומי, ראה העברת ש ער מקומי.
לקבלת מידע נוסף להגדרת תצורת השער הקולי VG400, VG410 או VG420 ברכזת הבקרה, ראה שער מקומי

מתאם טלפון אנלוגי (ATA) - כדי להתחיל עם סיסקו ATA 191 ו- 192, עיין בסי סקו ATA.

טלפון אלחוטי Wifi - לשילוב טלפון אלחוטי 840 ו- 860, ראה שילוב טלפון אלחוטי Webex.

טלפונים אלחוטיים DECT - כדי להתחיל עם סדרת ה- IP DECT 6800 החדשה של סיסקו, ראה סיסקו IP DECT.

כדי לבנות ולנהל רשת DECT דיגיטלית ב- Control Hub, ראה ניהול רשת DEC T

לקבלת מידע נוסף על סיסקו IP DECT 6800, ראה מדריך פריסה

התק ^{נים וט} לפונים של צד שלישי - עבוד עם ספקים ^של צד שלישי בדרישות המכשיר/טלפון ותהליך העברתם או החלפתם לתמיכה.

הגדר תכונות

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

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

מנהלי שיחות אוטומטיות - לניהול שיחות אוטומטיות, ראה שיחות אוטומטיות

פארק שיחות - לניהול פארק שיחות, ראה פארק שיחות

איסוף שיחות - כדי להגדיר קבוצת איסוף שיחות, ראה אי סוף שיחות

תורי שיחות - כדי להגדיר תור שיחות, ראה תור שיחות

קבוצות ציד - לניהול קבוצות ציד, ראה ניהול קבוצת ציד

מצבי הפעלה - לניתוב שיחות בהתבסס על מצבי הפעלה, ראה ניתוב שיחות בהתבסס על מצבי הפעלה

קבוצות דיוור - לקביעת תצורה של קבוצת עימוד, ראה קביעת תצורה של קבוצת הדפינג

הקלטות - לניהול הקלטת שיחות עבור, ראה ניהול הקלטות

טווח הגעה למספר יחיד - כדי להגדיר טווח הגעה למספר יחיד (במשרד בכל מקום), ראה קביעת תצורה של מספר יחיד

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

בדיקת קבלה

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

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

הקצאת משתמשים והקצאת מספרים

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

אימות הקצאת מספרים כולל אישור שלכל משתמש מוקצה התוסף והמספר החיצוני הנכונים, וכי מספרים אלה מנותבים כהלכה הן בזרימות שיחות פנימיות (ברשת) והן בזרימות שיחות חיצוניות (PSTN) . חשוב לבדוק אם יש חפיפות, הקצאות חסרות או תצורות שגויות שעלולות להוביל לשגיאות ניתוב שיחות או הפרעות בשירות.

זרימות שיחות PSTN והצגת מזהה המתקשר

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

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

זרימות שיחות ברשת

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

טיפול בשיחות משתמש ואימות תכונות

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

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

תורי שיחות: ניסיון סוכן ומפקח

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

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

קבוצות ציד: חלוקת שיחות

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

משיבים אוטומטיים: הודעות ופעולות תפריט

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

פעולת דואר קולי

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

אופטימיזציה

העברת PSTN ל- Cloud Connect עבור

בצע אופטימיזציה של התשתית המקומית

השתמש בניתוח ופתרון בעיות

העברת PSTN ל- Cloud Connect עבור

לאחר שכל נקודות הקצה והמשתמשים מועברים לשיחות ענן המטרה היחידה של Unified CM היא לפעול כמעבר בין שערי PSTN ודרך שער מקומי. להסרת שערי PSTN ושער מקומי מהתמונה באמצעות Cloud Connect כגישה ל- PSTN לכל Webex Calling המשתמשים יש מספר יתרונות, כולל הפחתת עלויות ושיפור האמינות. כדי להעביר את הגישה המקומית ל-PSTN ל-Cloud Connect עבור , בצע את השלבים הבאים:

Cloud Connect לבחירת שותפים.

עיין ברשימת Cloud Connect עבור שותפים ובחר מבין השותפים הזמינים עבור המיקום של הארגון שלך.

חיבור ענן לאימות.

לפני החלפת גישת PSTN עבור מיקומים ל- Cloud Connect, יש לאמת ולאמת את הקישוריות ל- PSTN באמצעות שותף Cloud Connect שנבחר. לשם כך, יש לספק מיקום בדיקה עם חלק מ משתמשי הבדיקה המסופקים במיקום הבדיקה הזה. גישת PSTN עבור מיקום בדיקה זה מוגדרת לאחר מכן לשותף Cloud Connect לפני אימות קישוריות PSTN באמצעות טלפוני הבדיקה. לאחר אימות מוצלח, ניתן לבטל את הקצאת מיקום הבדי קה.

העברת מספרים.

כדי להתכונן לקיצוץ ל- Cloud Connect יש לבצע הזמנת יציאה עבור כל המספרים שהו קצו כעת לתא המטען של PSTN המסתיים בו. יש להעביר את כל המספרים לשותף Cloud Connect. כדי לשמור על יכולת הגעה בין מיקומים, יש להעביר את כל המספרים של כל המיקומים בו זמנית.

עבור לשותף Cloud Connect.

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

כפי שנדון בסעיף PSTN של פרק העיצוב, לקוחות יכולים גם לבחור להעביר את גישת ה- PSTN שלהם ל- Cloud Connect בתחילת המעבר באמצעות גזע PSTN לפריסות היברידיות. לקבלת מידע נוסף, ראה מטעף PSTN לפריסות היברידיות. Webex Calling במקרה זה במהלך המעבר הגישה ל- PSTN היא דרך השער המקומי ולאחר העברת כל המשתמשים אליו אין שלב העברה נוסף הקשור ל- PSTN מלבד ביטול ההפעלה והשערים המקומיים.

בצע אופטימיזציה של התשתית המקומית

לאחר שכל המשתמשים עברו וכל נקודות הקצה עברו לרישום ענן (או הוצאו משימוש), עדכן את הת שתית המקומית המתאימה כעת כאשר שיחות ענן נמצאות בשימוש. עדכוני התשתית כוללים:

הסר רשומות בקרת שיחות והודעות מקומ DNS SRV יות משרתי ה- DNS המקומיים כולל cisco_uds. _tcp. <domain>, כניס ה_כוס. _tcp. <domain>. רשומות SRV אלה אינן נדרשות עוד לגילוי שירות לקוחות.

הסר רש DNS SRV ומות הקשורות לקצה ממערכת ה- DNS הציבורית כולל collab_edge. _tls. <domain>. רשומות SRV אלה אינן נדרשות עוד לגילוי שירות לקוחות של שירותי קצה לשיתוף פעולה.

עדכן את כל היקפי DHCP הרלוונטיים כדי להסיר את האפשרות 66 ואת כתובות שרת TFTP/אתחול אפשרות 150. היקפים אלה אינם נדרשים עוד לגילוי וה ורדה של תצורת בקרת שיחות נקודות קצה.

עדכן/הסר עמיתים חיוגים מתאימים בשער מקומי/קובייה שמנתבים שיחות אל וממנה. Unified CM עמיתים בחיוג אלה אינם נדרשים עוד לניתוב שיחות מקומיות.

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

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

ניקוי: לאחר העברת גישת PSTN ל- PSTN המחובר לענן, ניתן לבטל גזעי PSTN, שערי PSTN ושער מקומי.

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

DNs השייכים למשתמשים שהועברו צריכים להיות ממוקמים במ חיצה נסתרת כדי למנוע כשלים בניתוב שיחות וכדי להבטיח שלכל ה- CSS יש גישה עדיפה לנתיב הענן של אותם DNs.

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

החלפת מתג רשת

החלפת נקודת גישה אלחוטית

שינויים בהיקף DHCP

שינויים פיזיים בתוך הבניין (אם נפתרים לקובית/משרד)

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

השתמש בניתוח ופתרון בעיות

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

ניתוח איכות מדיה

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

פתרון בעיות באיכות המדיה

פתרון בעיות יכול להשתלב גם עם מוצרים אחרים של סיסקו כמו מתגי ThousandEyes ו- Meraki כדי לספק חוויה משולבת עשירה עוד יותר ב- Control Hub. לקבלת מידע נוסף על שימוש בניתוח Webex Callingופתרון בעיות, ראה פתרון בעיות בשי Webex Calling חות ב- Control Hub.

מבוא

לפני שתתחיל

סקירה

רכיבי ליבה

סקירת תהליך PPDIO

תיאור כללי של PPDIO

שימוש ב-PPDIO עבור פרויקטים של העברה של Unified CM ל-Webex Calling

להתכונן

לתכנן

לעצב

להטמיע

למטב

לולאות משוב PPDIO

גישת ההגירה

לפני שתתחיל

מדריך זה מיועד לצוותים או לאנשים פרטיים בעלי ניסיון בהגדרה וניהול של Cisco Unified Communications Manager (Unified CM) ונקודות קצה של Cisco, כולל טלפוני IP שולחניים, התקני וידאו ולקוחות תוכנה של Jabber. לאורך מסמך זה, ישנם קישורים למסמכי מוצר ותמיכה שיסייעו לך.

מסמך זה מתמקד במעברים מ-Unified CM ל-Webex Calling מרובה דיירים בלבד. המונח Webex Calling במסמך זה מתייחס תמיד ל-Webex Calling מרובה דיירים.

לפני תחילת המעבר מ-Unified CM ל-Webex Calling, חיוני שתהיה לך הבנה מקיפה של פתרון Webex Calling ורכיביו המתאימים. הגירה מוצלחת דורשת היכרות עם ארכיטקטורת Webex Calling, מודלי שירות, אפשרויות פריסה ותכונות נלוות כדי למפות כראוי עומסי עבודה קיימים של Unified CM ולתכנן תוכנית מעבר יעילה.

הבנה מעמיקה של רכיבי Webex Calling הבאים חיונית לגיבוש אסטרטגיית מעבר יעילה ומוכנות תפעולית.

Control Hub

הקצאת ספריות ומשתמשים

פלטפורמת שיחות Webex

נקודות קצה נתמכות של שיחות

אפשרויות קישוריות PSTN

תוכנית חיוג וניהול מספרים של Webex Calling

תכונות אבטחה ותאימות.

למידע נוסף, ראו ארכיטקטורה מועדפת של סיסקו עבור שיחות Webex.

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

כלי הגירה של Webex: כלים חינמיים בשירות עצמי המובנים במרכז הבקרה כדי לייעל את המעבר שלך ל-Webex Calling

ספקי הגירה מוסמכים: ספקי תוכנה וכלים שאושרו על ידי סיסקו ופיתחו פתרונות הגירה כדי לסייע לשותפים וללקוחות של Webex בהעברות מורכבות וגדולות. פתרונות אלה יכולים לעזור לפשט, לנהל ולהאיץ את המעבר ל-Webex Calling

סיוע בהגדרת Webex: שירות הגירה בהובלת סיסקו, המדריך לקוחות ושותפים בפריסה ובקביעת התצורה של Webex Calling, הנדרשות להעברה מוצלחת של משתמשי ושירותי Unified CM ל-Webex Calling.

סקירה

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

מטרת מסמך זה היא לספק הנחיות פריסה ללקוחות המעוניינים במיוחד לעבור מ-Unified CM מקומי ל-Webex Calling בענן. מדריך פריסה זה מניח שלקורא יש הבנה בסיסית של מעבר השיחות בין Unified CM ל-Webex Calling, כולל מה משתנה בעת ביצוע מעבר זה ומה ההבדלים בעת העברת עומס העבודה של השיחות מהאינטרנט לענן. לפני שתמשיך, ודא שסקרת את המידע הזמין במפת המעבר ואתה מכיר אותו. מסמך מפת מעבר זה מספק מידע על השינויים וההבדלים של מעבר זה.

כפי שמוצג באיור ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות וגישה מרחוק, פריסה מקומית טיפוסית כוללת רכיבי תשתית שונים של שיתוף פעולה ברשת, פלטפורמת בקרת שיחות, פלטפורמת קצה, נקודות קצה של חומרה ותוכנה, ובמקרים מסוימים אפילו פלטפורמות לשיחות ועידה ותזמון. בארכיטקטורת סיסקו זה יכלול Unified CM לבקרת שיחות, Expressway לגישה מרחוק ושירותי קצה בין עסקים (B2B), ו-Cisco Meeting Server. / ניהול פגישות של Cisco לשיחות ועידה מקומיות, Unity Connection להודעות קוליות, וחומרה הפונה למשתמש (טלפוני IP של Cisco, מערכות וידאו לשולחן ולחדר של Cisco) ותוכנה (Cisco Jabber) נקודות קצה מבוססות IP. רכיבים אלה עשויים להשתנות מעט בסביבות מסוימות, אך זוהי נקודת ההתחלה למעבר המתואר בהמשך מסמך זה.

ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות וגישה מרחוק

הארכיטקטורה המוצגת באיור ארכיטקטורת שיתוף פעולה מקומית: בקרת שיחות וגישה מרחוק מבוססת על הארכיטקטורה המועדפת (PA) עבור פריסות מקומיות של Cisco Collaboration Enterprise. למידע נוסף על Enterprise On-Premise, ראו ארכיטקטורות מועדפות לשיתוף פעולה של סיסקו.

לִפנֵי: הטבלה רכיבי תשתית שיחות מקומיות מפרטת את המרכיבים המרכזיים של הארכיטקטורה המקומית לפני המעבר ל-Webex Calling בענן.

טבלה 1. לִפנֵי: רכיבי תשתית שיחות מקומיות
מוצר תיאור

Unified CM בקרת שיחות מקומית המספקת שירותי רישום מכשירים וניתוב שיחות

סיסקו Expressway-C/E תשתית קצה המספקת פונקציונליות של גישה ניידת ומרוחקת (MRA) ופונקציונליות של עסק לעסק (B2B), המאפשרת לנקודות קצה מרוחקות להתחבר בצורה מאובטחת מחוץ לארגון. Expressway נפרס בזוגות כדי לספק חציית חומת אש עבור נקודות קצה חיצוניות.

שרת פגישות סיסקו (CMS), ניהול פגישות סיסקו (CMM) וחבילת ניהול נוכחות טלפונית של סיסקו (TMS) תשתית ועידות קוליות, וידאו ושיחות וידאו מקומיות המספקות פגישות מרובות נקודות, ניהול פגישות ויכולות תזמון. [Optional]

Cisco Unity Connection פלטפורמת הודעות קוליות מקומית המספקת יכולות דואר קולי ומסרים מאוחדים. [Optional]

Cisco Desk, Cisco Room, Cisco Board, טלפוני Cisco IP ו-Cisco Jabber מכשירים מבוססי IP הרשומים ב-Unified CM ומספקים יכולות שיחות קוליות ווידאו

כפי שמודגם באיור החלטת מעבר: שיחות מקומיות ל-Webex Calling, לקוחות שיש להם בקרת שיחות מקומית עם Unified CM ונקודות קצה של IP לשולחן העבודה ולווידאו יכולים לבחור להעביר את הארכיטקטורה לארכיטקטורת ענן של Webex Calling.

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

דגמי טלפונים שאינם נתמכים על ידי Webex Calling

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

תוכנית חיוג מורכבת, קטגוריות שירות מפורטות מאוד או שניהם

גישה מגבילה, מוגבלת או לא אמינה לאינטרנט

מדיניות מחמירה בנוגע לפרטיות נתונים ובעלות

דרישת תאימות להקלטה ואחסון מדיה במקום או בתוך המדינה

אינטגרציות של צד שלישי ללא אינטגרציה חלופית בת קיימא של Webex Calling

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

החלטת מעבר: שיחות מקומיות ל-Webex Calling
לקוחות המעוניינים להתחיל למנף שירותי שיחות ענן צריכים לשקול את Webex Calling. שירות שיחות ענן זה מאפשר ללקוח למנף את הארכיטקטורה הגלובלית של Webex לצורך קנה מידה וקישוריות. משתתפים ברשת הארגונית ומשתתפים מרוחקים מחוץ לרשת הארגונית יכולים לתקשר באמצעות נקודות קצה חומרתיות מבוססות IP and/or יישומי לקוח רך למחשב שולחני או נייד.

מסמך זה מתמקד בלקוחות עם פריסות בקרת שיחות של Unified CM המעוניינים להבין את השלבים הכלליים, השיקולים והדרישות להפעלת פריסת Webex Calling כפי שמתואר בסעיף הבא.

רכיבי ליבה

ארכיטקטורת היעד עבור הגירה זו כוללת מספר רכיבים חדשים. זה כולל את שירות Webex Calling לשיחות מבוססות ענן, אפליקציית Webex, מחבר מדריך כתובות של Cisco לשילוב זהויות ושער מקומי (LGW) לגישה ל-PSTN, כמו גם שילוב שיחות מקומיות לענן. תוכניות שיחות של Cisco או Cloud Connect PSTN (CCP) המבוצעות על ידי שותף Cloud Connect for Webex Calling הן אפשרויות נוספות לגישה ל-PSTN.

כפי שמוצג באיור לאחר: ארכיטקטורת שיחות Webex, הרכיבים החדשים (שיחות Webex, מחבר Directory, שער מקומי ושער הישרדות) מתווספים לפריסה המקומית הקיימת.

לְאַחַר: ארכיטקטורת שיחות Webex

לְאַחַר: הטבלה רכיבי תשתית שיחות ענן מפרטת את האלמנטים החדשים של הארכיטקטורה לאחר המעבר ל-Webex.

טבלה 2. לְאַחַר: רכיבי תשתית שיחות ענן
מוצר תיאור

Webex Calling שירות שיחות מבוסס ענן המסופק מפלטפורמת Webex ומספק רישום נקודות קצה וניתוב שיחות

Cisco Directory Connector יישום Windows הפועל על מחשב תחום של Windows ומספק סנכרון זהויות בין Active Directory המקומי של הארגון לבין מאגר הזהויות של ארגון Webex.
עבור לקוחות שעוברים מ-Active Directory מקומי ל-Entra ID, שילוב הזהויות עם Webex במקום Cisco Directory Connector משתמש באפליקציית Entra ID Wizard.

שער מקומי שער מקומי משמש כגשר בין רשת התקשורת המאוחדת המקומית של הלקוח לבין ענן Webex Calling. ניתן לפרוס אותו באופן מקומי או לארח אותו על ידי שותף, ולספק גישת PSTN עבור נקודות קצה רשומות בענן וכן שילוב שיחות בין נקודות קצה רשומות ב-Unified CM לנקודות קצה רשומות בענן. נתב שירותים משולבים של סיסקו IOS-XE (סדרות ISR 1100 ו-4000), Cisco Catalyst 8200/8300 סדרה, תוכנת Cisco Catalyst 8000V Edge, ובקרי גבולות סשן (SBC) מוסמכים שונים של צד שלישי יכולים לשמש כ-LGW עבור גישת הגירה מדורגת.

שער יכולת הישרדות שער הישרדות (SGW) הוא שער רשת מקומי מבוסס IOS-XE המספק שירותי שיחות גיבוי לנקודות קצה של Webex Calling באתר במהלך הפסקות רשת.

תוכנית שיחות של סיסקו, Cloud Connect עבור שיחות Webex תוכנית השיחות של Cisco ו-Cloud Connect עבור Webex Calling הן אפשרויות מבוססות ענן לגישה ל-PSTN עבור נקודות קצה של Webex Calling. גישה ל-PSTN מתאפשרת על ידי ספק PSTN בענן ואינה דורשת ציוד מקומי.

יישום Webex אפליקציית לקוח הפועלת על מערכת הפעלה שולחנית (Windows, Mac) או מערכת הפעלה ניידת (Android, iOS) ורשומה ישירות לפלטפורמת Webex Calling לצורך פונקציונליות שיחות.

סקירת תהליך PPDIO

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

תהליך PPDIO

תיאור כללי של PPDIO

לְהַכִין: הערכת הסביבה הנוכחית, איסוף דרישות ויישור קשרים בין בעלי עניין כדי ליצור בסיס איתן.

תוכנית: פיתוח תוכניות פרויקט מפורטות, כולל לוחות זמנים, משאבים ואסטרטגיות להפחתת סיכונים.

לְעַצֵב: תכנן את פתרון היעד המותאם לצרכים העסקיים והטכניים.

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

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

שימוש ב-PPDIO עבור פרויקטים של העברה של Unified CM ל-Webex Calling

בעת המעבר מ-Unified CM ל-Webex Calling, תהליך ה-PPDIO מספק מפת דרכים ברורה כדי להבטיח מעבר חלק ויעיל:

הכנה

הערכת סביבת ה-CM המאוחדת הקיימת ומוכנות להעברה

איסוף נתונים מפורטים על משתמשים, מכשירים, רשת ותלויות

איסוף פרטי מיקום כולל כתובת לתגובת חירום, מספר משתמשים, גישה לאינטרנט, גישה ל-PSTN

זהה סיכונים והגדרת היקף הפרויקט כדי ליישר קו בין כל בעלי העניין.

לתכנן

צור תוכנית הגירה מקיפה עם לוחות זמנים של קבוצות, הקצאות משאבים ולוחות זמנים

הגדרת משימות כגון שדרוגי קושחה של מכשירים, הקצאת רישיונות וקליטת משתמשים

תיאום חלונות הגירה עם סיסקו ושותפיה כדי למזער את ההפרעות.

לעצב

מיפוי תצורות, תוכניות חיוג ופרופילי משתמשים נוכחיים של Unified CM למקבילות של Webex Calling

עיצוב סביבת Webex Calling, כולל אסטרטגיית PSTN (ביניים וסופי), מיקומים, תפקידי משתמש ונקודות אינטגרציה כמו Local Gateway (CUBE) וסינכרון ספריות

תכנן תרחישי דו-קיום שבהם Unified CM ו-Webex Calling פועלים בו זמנית במהלך ההעברה.

להטמיע

השתמש בכלי הגירה של Control Hub לצד כלים של צד שלישי כדי לבצע שינויים במצב קושחה של מכשירים, הגדרת תכונות והעברות משתמשים

שימוש בפעולות בכמות גדולה והקצאה באמצעות ממשקי API של Webex כדי לייעל העברות ותצורות בקנה מידה גדול

ביצוע הקצאת רישיונות, רישום מכשירים ועדכוני תצורה

אימות הצלחת ההגירה באמצעות בדיקות ואימות תפעולי.

למטב

ניטור רציף של ביצועי Webex Calling וחוויית המשתמש

שפר תצורות וזרימות עבודה על סמך נתונים תפעוליים ומשוב

מינוף יכולות אוטומציה ואינטגרציה כדי לשפר את היעילות וההרחבה

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

גישת PPDIO משופרת זו מבטיחה העברה מבוקרת, שקופה ויעילה מ-Unified CM ל-Webex Calling, תוך מינוף הכלים, ממשקי ה-API ומערכת האקולוגית של השותפים של סיסקו כדי לשמור על המשכיות עסקית ולשפר את יכולות שיתוף הפעולה.

לולאות משוב PPDIO

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

איטרציות בעת ביצוע PPDIO

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

תהליך PPDIO מאוחד בסיוע CM

בעת ביצוע מעבר מ-Unified CM ל-Webex Calling, כל שלב בתהליך PPDIO יכול להפיק תועלת משמעותית ממידע שנאסף מסביבת Unified CM הקיימת. לדוגמה, ניתן לחלץ מתוך התצורה הנוכחית של Unified CM רשימת מלאי מקיפה של משתמשים, מספרי טלפון, תכונות שיחות ורכיבי תוכנית חיוג. נתונים אלה משלימים מידע המסופק ישירות על ידי בעלי עניין ומסייעים לייעל את פעילויות התכנון והעיצוב. מינוף כלים מתאימים לאוטומציה של חילוץ וניתוח נתונים לא רק משפר את הדיוק אלא גם מאיץ את התהליך הכולל. באמצעות תובנות מהפריסה הקיימת, ניתן לבצע את המעבר ל-Webex Calling בצורה יעילה יותר מאשר יישום מסורתי חדש, תוך שמירה על מתודולוגיית PPDIO מובנית. תהליך זה מודגם באיור תהליך PPDIO מאוחד בסיוע CM.

גישת ההגירה

כשאתם מתכננים את המעבר שלכם מ-Unified CM מקומי ל-Webex Calling, עליכם לקבוע כיצד תיגשו למסע הזה. ראשית תצטרכו להחליט אם ההגירה תהיה גישה של בזק (הכל בבת אחת) או גישה שלבית (העברת קבוצות של users/devices לאורך תקופה ממושכת).

ביצוע הגירה מסוג flash-cut מעביר את כל המשתמשים והמכשירים שלך בצורה המהירה ביותר. בעזרת שיטה זו, תעבירו את כל המשתמשים והמכשירים מ-Unified CM מקומי ל-Webex Calling בו זמנית. למעשה, זהו חלון הגירה יחיד עבור כל המשתמשים והמכשירים. לאחר השלמת העברה זו, כל המשתמשים והמכשירים שלך יהיו בפלטפורמת Webex Calling וכל תשתית ה-CM המאוחד שלך תוכל לצאת משימוש. עם זאת, ארגונים רבים אינם יכולים להשתמש בגישה זו עקב היקף וגודל פריסת השיחות שלהם.

הגישה השנייה היא הגירה בשלבים. רוב הארגונים ישתמשו בגישה זו מכיוון שהיא מספקת שליטה, ניהול וסקלביליות טובים יותר עם ההגירה. כמו כן, הוא מתאים יותר לפריסות UC גדולות יותר and/or פריסות על פני מספר אזורים. לכן, מסמך זה מתמקד בגישה השלבית עם שני שלבים במעבר.

כפי שמוצג באיור למטה מעבר שלב אחר שלב של שיחות: היברידי וענן, שלב המעבר הראשון (שלב 1) מביא לפריסה דו-קיום עם סביבות שיחות כפולות. בשלב זה, חלק מהמשתמשים, המכשירים ולקוחות הרכים עוברים ל-Webex Calling בעוד שאחרים עדיין נמצאים בבקרת השיחות של Unified CM המקומית. שלב המעבר הסופי (שלב 2) מביא לסביבת שיחות ענן טהורה שבה כל המשתמשים, המכשירים ולקוחות הרכים עברו במלואם לפלטפורמת Webex Calling.

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

מעבר הדרגתי של שיחות: היברידי וענן

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

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

מעבר תלת-פאזי מומלץ

טרום הגירה: שלב זה מתמקד בהכנת סביבות Webex ו-Unified CM להעברה. זה לא עוסק בתכנון או תצורות ספציפיות של שיחות, אלא בהשלמת פעילויות שניתן לבצע כעת ולפני תחילת כל פרויקט הגירה של Webex Calling. המטרה היא לבנות את היסודות עבור שתי הסביבות כהכנה לנדידה.

הכנת הגירה: שלב זה הוא המקום שבו מתחילים את המאמץ להתכונן למעבר ל-Webex Calling. כאן, יש צורך לבחון ולעדכן את הדרישות העסקיות והטכניות. אל תספיקו רק לבצע שינויים במה שנפרס כעת עם Unified CM, ובמקום זאת תגדירו מחדש את הדרישות העסקיות והטכניות שהחברה שלכם צריכה היום ובעתיד על ידי מינוף העוצמה של Webex Calling. בנוסף, זהו השלב בו תשלימו את העיצוב, תכנון התצורה וההגירה שלכם planning/schedule.

הגירה (פריסה ויציאה משימוש): שלב זה הוא המקום שבו מתרחשת ההגירה בפועל של משתמשים, מכשירים, מספרי טלפון ולקוחות רכים. כפי שצוין לעיל, ניתן להשלים שלב זה עבור כולם בבת אחת (flash-cut) או על פני מספר חלונות שינוי (phased-cut). תוכניות אימוץ, הדרכה ותקשורת עם משתמשי הקצה הן קריטיות, כך שהמשתמשים שלכם מודעים לשינויים, כיצד להשתמש בפלטפורמת השיחות החדשה וידעו מתי השינוי יתרחש. השלב האחרון הוא להוציא משימוש את כל תשתית ה-UC המקומית שאינה בשימוש עוד.

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

האיור פעילויות טרום-העברה להלן מדגיש חמש קטגוריות ספציפיות של פעילויות הקשורות להעברה של Webex Calling.

פעילויות טרום הגירה

טבלה 2. לְאַחַר: רכיבי תשתית שיחות ענן
מוצר	תיאור
Webex Calling	שירות שיחות מבוסס ענן המסופק מפלטפורמת Webex ומספק רישום נקודות קצה וניתוב שיחות
Cisco Directory Connector	יישום Windows הפועל על מחשב תחום של Windows ומספק סנכרון זהויות בין Active Directory המקומי של הארגון לבין מאגר הזהויות של ארגון Webex. עבור לקוחות שעוברים מ-Active Directory מקומי ל-Entra ID, שילוב הזהויות עם Webex במקום Cisco Directory Connector משתמש באפליקציית Entra ID Wizard.
שער מקומי	שער מקומי משמש כגשר בין רשת התקשורת המאוחדת המקומית של הלקוח לבין ענן Webex Calling. ניתן לפרוס אותו באופן מקומי או לארח אותו על ידי שותף, ולספק גישת PSTN עבור נקודות קצה רשומות בענן וכן שילוב שיחות בין נקודות קצה רשומות ב-Unified CM לנקודות קצה רשומות בענן. נתב שירותים משולבים של סיסקו IOS-XE (סדרות ISR 1100 ו-4000), Cisco Catalyst 8200/8300 סדרה, תוכנת Cisco Catalyst 8000V Edge, ובקרי גבולות סשן (SBC) מוסמכים שונים של צד שלישי יכולים לשמש כ-LGW עבור גישת הגירה מדורגת.
שער יכולת הישרדות	שער הישרדות (SGW) הוא שער רשת מקומי מבוסס IOS-XE המספק שירותי שיחות גיבוי לנקודות קצה של Webex Calling באתר במהלך הפסקות רשת.
תוכנית שיחות של סיסקו, Cloud Connect עבור שיחות Webex	תוכנית השיחות של Cisco ו-Cloud Connect עבור Webex Calling הן אפשרויות מבוססות ענן לגישה ל-PSTN עבור נקודות קצה של Webex Calling. גישה ל-PSTN מתאפשרת על ידי ספק PSTN בענן ואינה דורשת ציוד מקומי.
יישום Webex	אפליקציית לקוח הפועלת על מערכת הפעלה שולחנית (Windows, Mac) או מערכת הפעלה ניידת (Android, iOS) ורשומה ישירות לפלטפורמת Webex Calling לצורך פונקציונליות שיחות.

להתכונן

דרישות עסקיות וטכניות

מדוע איסוף דרישות חשוב:

דרישות עסקיות

דרישות טכניות

מוכנות ודרישות הרשת

הגדר UC מחובר לענן

הערכת הסביבה הנוכחית

רישוי

Locations/Sites

מלאי קיים devices/clients

אימות זכאות המכשיר

משתמשים

קישוריות PSTN

תכונות & שימוש בתכונות

אינטגרציות של סיסקו: Unity Connection UCCX UCCE

הקלטת שיחות

אינטגרציות של צד שלישי

דרישות עסקיות וטכניות

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

מדוע איסוף דרישות חשוב:

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

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

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

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

דרישות עסקיות

דרישות עסקיות אופייניות כוללות:

מספר המשתמשים והמיקומים שיש להעביר

תכונות ושירותים רצויים (לדוגמה, ניתוב שיחות, דואר קולי, שיחות ועידה, שיחות מענה אוטומטיות, תורי שיחות)

מדיניות תאימות ואבטחה

אילוצי תקציב וציפיות עלויות

צורכי הדרכת משתמשים ותמיכה

ציר זמן של הגירה ושיקולי המשכיות עסקית.

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

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

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

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

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

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

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

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

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

אבטחת אבטחת ספק: הערכת אישורי האבטחה והצהרות התאימות של סיסקו על מנת להבטיח אמינות.

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

הדרכת משתמשים וצורכי תמיכה הם מרכיבים חיוניים במהלך המעבר מ- אל כדי להבטיח מעבר חלק ואימוץ על ידי משתמשים. שיקולים מרכזיים כוללים:

תוכניות הכשרה: פיתוח מפגשי הדרכה מותאמים אישית לקבוצות משתמשים שונות (משתמשי קצה, מנהלים, צוות תמיכה) כדי להכיר להם תכונות, ממשקי משתמש וזרימות עבודה חדשות.

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

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

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

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

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

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

דרישות טכניות

יש לאסוף ולתעד מספר דרישות טכניות מרכזיות לצורך הגירה מוצלחת מ- אל , כולל פרטים עבור:

מוכנות הרשת וקיבולת רוחב פס

הערכת רשת מקיפה היא קריטית כדי להבטיח שהתשתית הקיימת שלך תוכל לתמוך בסביבת Webex Calling החדשה. זה כולל:

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

איכות השירות (QoS): יישום מדיניות QoS כדי לתעדף תעבורת קול ולמזער השהייה, ריצוד ואובדן חבילות.

חיבור WAN ואינטרנט: אימות שקישורי WAN וחיבורי אינטרנט עומדים בדרישות לשיחות מבוססות ענן, כולל יכולות יתירות וגיבוי לגיבוי.

חומת אש ותצורת NAT: וידוא שהגדרות חומת האש והגדרות ה-NAT מאפשרות את האיתות ותעבורת המדיה הנדרשים עבור .

אינטגרציה עם מערכת קיימת

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

שירותי ספריות: הערכת אינטגרציה עם ספריית ארגונית לצורך הקצאת משתמשים ואימות אוטומטיים.

אפליקציות CRM ועסקים: זיהוי נקודות אינטגרציה עם מערכות ניהול קשרי לקוחות ויישומים עסקיים קריטיים אחרים.

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

תאימות והקצאה של נקודות קצה

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

תמיכה במכשיר: אישור שטלפוני ומכשירי IP קיימים נתמכים על ידי או זיהוי תחליפים נדרשים.

תהליכי הקצאה: הקמת שיטות הקצאה אוטומטיות או יעילות לקליטה יעילה של נקודות קצה.

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

תצורות אבטחה ותקני הצפנה

אבטחה היא בעלת חשיבות עליונה בתקשורת ענן:

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

אימות ובקרת גישה: יישום מנגנוני אימות מאובטחים (כגון SSO, אימות רב-גורמי) ובקרות גישת משתמשים מפורטות.

הַתאָמָה: הבטחת עמידה בפתרון בתקני רגולציה ותאימות רלוונטיים בתעשייה (לדוגמה, GDPR, HIPAA).

ניטור אבטחה: שילוב עם כלי SIEM והגדרת התראות על אירועי אבטחה פוטנציאליים.

טבלה 1. הערכה לדוגמה
דרישה שיקולים מרכזיים

מוכנות רשת ורוחב פס רוחב פס, איכות שירות, WAN/Internet, Firewall/NAT

אינטגרציה עם מערכות קיימות ספריות, CRM, מרכזיה, Email/Calendar

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

תצורות אבטחה והצפנה הצפנה, אימות, תאימות, ניטור אבטחה

הדרכת משתמשים וניהול שינויים תוכניות הדרכה, תיעוד, תקשורת שינויים

ניידות מספרים ותוכנית חיוג מִספָּר migration/porting, תרגום תוכנית חיוג

אינטגרציות של צד שלישי זימון, מרכז קשר, פקס, מכשירים אנלוגיים

מוכנות ודרישות הרשת

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

קישוריות רשת אמינה עם איכות שירות מספקת (רוחב פס, אובדן חבילות, RTT) היא דרישה בסיסית להבטחת חוויית המשתמש הטובה ביותר מקצה לקצה עבור כל נקודות הקצה, הלקוחות והיישומים התומכים בקול ווידאו המשתמשים.

ללקוחות ולשותפים יש אפשרויות קישוריות מעבר לאינטרנט OTT (Over-the-top) שיכולות לייעל את החיבור, כולל Webex Edge Connect. למידע נוסף על פרטי עיצוב Webex Edge Connect, ראה ארכיטקטורה מועדפת של Cisco עבור Webex Edge Connect עבור פגישות Webex, שיחות מרובות דיירים ומופע ייעודי.

לקוחות יכולים להשתמש ב- CScan להערכת רשת, המספקת מידע על איכות הרשת של הלקוח, מספר השיחות שניתן לבצע, זמן ההשהיה וכן הלאה. למידע נוסף על כלי CScan, ראה שימוש ב-CScan לבדיקת איכות רשת Webex Calling.

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

תכנון רוחב פס

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

טבלת חישובי רוחב הפס של סוגי השיחה של Webex Calling מציגה את סוגי השיחות הזמינים בפריסה יחד עם ה-codec ורוחב הפס המרבי הנדרש עבור כל סוג שיחה. כפי שמוצג בטבלת חישובי רוחב פס של סוג שיחה של Webex Calling ניתן לחשב את רוחב הפס הנדרש של שיחת שמע עבור כל סוג שיחה באמצעות הנוסחה הכללית הבאה:

מספר השיחות הצפויות במקביל * רוחב פס לכל שיחה מבוסס על קודק = תפוקת רשת נדרשת.
טבלה 2. חישובי רוחב פס של סוג השיחה של Webex Calling
סוגי שיחות קודק - רוחב פס חישובי רוחב פס
/ טלפון שולחני -> אופוס - 70 קילו-ביט לשנייה מספר שיחות בו זמנית * 70 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> טלפון שולחני אופוס – 70 קילו-ביט לשנייה מספר שיחות בו זמנית * 70 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> PSTN דרך LGW G.711 – 80 kbps מספר שיחות בו זמנית * 80 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> PSTN דרך PSTN בענן (למשל, תוכנית שיחות של סיסקו) G.711 – 80 kbps מספר שיחות בו זמנית * 80 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> ארגון דרך LGW G.722 – 80 kbps מספר שיחות בו זמנית * 80 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> הודעה קולית אופוס – 70 קילו-ביט לשנייה מספר שיחות בו זמנית * 70 קילו-ביט לשנייה = תפוקת רשת נדרשת

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

כל רגלי השיחות תמיד מעוגנות ב-SBCs של הגישה. כדי לקבוע את רוחב הפס הנדרש של האינטרנט עבור כל מיקום נתון, יש לקחת בחשבון לא רק את השיחות הבין-מיקומיות, אלא גם את השיחות בתוך המיקום ושיחות אל ומ-Local Gateway באותו מיקום. לדוגמה, שיחה תוך-אתרית בין שני טלפוני MPP תדרוש עד 2 דופלקס מלא של 70 kbps בגישה לאינטרנט של המיקום.

הטבלה דוגמאות לחישוב רוחב פס של שיחות Webex מציגה דוגמה לתרגיל חישוב רוחב פס מלא, בהנחה שכל המכשירים נמצאים באותו אתר.
טבלה 3. דוגמאות לחישוב רוחב פס של שיחות Webex
סוגי שיחות מספר שיחות בו זמנית רוחב פס כולל
אפליקציית Webex / טלפון שולחני → אפליקציית Webex 15 2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → טלפון שולחני 15 2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → PSTN דרך LGW 50 2 * 50 * 80 קילו-ביט לשנייה = 8,000 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → PSTN דרך Cloud Connect עבור שיחות Webex 0 0 * 80 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → ארגוני דרך LGW 15 2 * 15 * 80 קילו-ביט לשנייה = 2,400 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → הודעה קולית של Webex Calling 5 5 * 70 קילו-ביט לשנייה = 350 קילו-ביט לשנייה
סך כל השיחות / רוחב פס 100 שיחות 14,950 קילו-ביט לשנייה / 14.95 מגה-ביט לשנייה

כל ערכי רוחב הפס בטבלאות לעיל מתייחסים לרוחב פס של IP. רוחב הפס של הקישור גבוה יותר בהתאם לאנקפסולות WAN.

רוחב הפס בטבלאות לעיל הוא עבור שיחות שמע. עבור רוחב פס של שיחות וידאו, אפליקציית Webex ו-MPP 8845/65 טלפונים תומכים בוידאו H.264 ברזולוציה מקסימלית של 720p וברוחב פס מרבי של 1,500 kbps לשיחה. עם זאת, כמות רוחב הפס הנצרכת בכל נקודה במהלך השיחה תשתנה בהתאם לקצב סיביות משתנה הטמון בתקשורת וידאו.

איכות השירות (QoS)

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

יעדי השהייה, ריצוד ואובדן חבילות

הספים הבאים מומלצים לאיכות קול אופטימלית כאשר שיחות עוברות דרך האינטרנט (OTT):

זמן השהיה - פחות מ-100ms לכיוון אחד

ריצוד - פחות מ-10 אלפיות השנייה

אובדן חבילות - 0.5% או פחות.

חומת אש ו-NAT

ודא שחומת האש מוגדרת לאפשר תעבורה כפי שמפורט במאמר הזמין בכתובת מידע על יציאות עבור Webex Calling. בנוסף, יש לאפשר גישה לדומיינים ולטווחי IP המפורטים באותו מדריך ולהימנע מ-SIP ALG מכיוון שהוא מפריע לאיתות SIP. יש להימנע מתעבורת מדיה דרך פרוקסי.

DNS ו-NTP

ודא רזולוציית DNS נכונה של דומיינים ושרתי NTP אמינים כדי לסנכרן שעוני מכשירים לאימות ורישום תעודות TLS.

תכנון מעבר לגיבוי

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

שרידות האתר

שרידות האתר מבטיחה שהעסק שלך תמיד נגיש, גם אם חיבור הרשת שלך מתנתק. Site Survivability משתמש בשער ברשת המקומית שלך כדי לספק שירות קריאות גיבוי לנקודות קצה באתר עבור מצבים בהם חיבור הרשת מתנתק. שקלו את שרידות האתר באמצעות שער שרידות (SGW) מקומי אם דרישות העסק דורשות שיחות רציפות במקרה של הפסקת רשת. למידע נוסף על בדיקת שרידות אתר, ראה שרידות אתר עבור Webex Calling.

הגדר UC מחובר לענן

Cloud Connected UC (CCUC) הוא פתרון ניהול ואנליטיקה מבוסס ענן שנועד לספק נראות, ניהול ותובנות מרכזיות עבור פריסות מקומיות (כגון Unified CM) ובענן (). היא משמשת כגשר בין סביבות מקומיות מסורתיות לבין שירותי הענן של סיסקו, ותומכת בארגונים לאורך כל מסע המעבר מ- ל-.

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

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

הערכת הסביבה הנוכחית

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

חשוב לבחון את ההיבטים הבאים כחלק ממאמץ זה.

רישוי

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

פלטפורמה

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

משתמשים ומכשירים

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

שער מקומי

אם נדרש אלמנט הגבול המאוחד של Cisco (CUBE) לגישה ל-PSTN עבור מעבר זה, יש לשקול גם רישוי CUBE. שיקולי רישוי CUBE מכוסים בהמשך מסמך זה.

Locations/Sites

יש לקחת בחשבון את מספר וסוגי האתרים (מרכזיים גדולים, אזוריים, סניפים וכן הלאה) בפריסה הקיימת שלך בעת תכנון המעבר הזה. הבנה מלאה של אתרי הפריסה הקיימים תסייע בתכנון אסטרטגי למעבר מוצלח, במיוחד בכל הנוגע לקביעת אילו אתרים להעביר ובאיזה סדר. הבנה מפורטת של דרישות תוכנית החיוג (מספור, הרגלי חיוג, סוגי הגבלות וכן הלאה), קישוריות רשת האתר ורוחב הפס (אינטרנט, WAN, LAN) וגישה ל-PSTN (מקומי או מרכזי, IP או TDM) עבור כל אתר תהיה קריטית בעת קבלת החלטות הגירה. למידע נוסף על מודלים נפוצים של פריסה ושיקולים מרכזיים, עיין במידע על מודלים של פריסה משותפת הזמינים ב- Collaboration SRND.

שיקול חשוב נוסף בעת המעבר ל- הוא זמינות המיקום. מציע יכולות, מנויים ומכשירים שונים הזמינים בהתאם למיקום הפריסה שלך. למידע נוסף על זמינות גיאוגרפית, ראה היכן Webex זמין?.

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

מלאי קיים devices/clients

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

טלפונים שולחניים

עבור טלפוני שמע ווידאו שולחניים, רק טלפוני השולחן מסדרות 6800, 7800, 8800 ו-9800 נתמכים עם . זוהי תת-קבוצה של טלפוני Cisco IP הנתמכים עם . ישנם כמה דגמים וגרסאות של הטלפונים 6800, 7800 ו-8800 שלא ניתן להשתמש בהם עם . למידע נוסף על הדגמים וגרסאות החומרה הנתמכות, ראה מכשירים נתמכים עבור Webex Calling.

לא ניתן לשדרג את טלפוני ה-IP מסדרת Cisco 6800 מקושחה ארגונית לקושחה מרובת פלטפורמות (MPP), הנדרשת עבור . לכן, כל טלפון 6800 הרשום למכשיר עם קושחה ארגונית חייב להיות מוחלף בדגם 6800 MPP או בדגם טלפון נתמך אחר.

יש לשדרג את טלפוני ה-IP מסדרות Cisco 7800 ו-8800 לקושחת טלפון רב-פלטפורמתי (MPP) לפני המעבר ורישומם ל-. כדי לקבוע אילו דגמים 7800 ו-8800 וגרסאות חומרה תומכים בקושחת MPP, ראה המרת טלפוני IP מסדרת Cisco 7800 ו-8800 בין קושחת Enterprise לקושחת MPP.

דגמי 8845, 8865 ו-8865NR הגיעו לסוף המכירה ולא מומלץ להעביר אותם ל- .

גרסאות ישנות יותר של טלפונים מסדרת 8800 (8811, 8841, 8851, 8851NR, 8861) אינן מומלצות לשימוש עם Webex Calling. טלפונים עם גרסאות חומרה VID 14 או גרסאות קודמות יירשמו עם אך עשויים להיתקל בבעיות ביצועים עקב החומרה.

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

יהיה צורך להחליף את כל שאר טלפוני ה-IP בטלפונים מסדרת 6800, 7800, 8800 או 9800 הנתמכים על ידי Webex Calling. למידע נוסף על טלפוני IP וטלפונים שולחניים נתמכים עם , עיין במאמר בכתובת מכשירים נתמכים עבור Webex Calling.

נקודות קצה של וידאו

נקודות קצה של וידאו אישי ווידאו בחדר, כולל סדרת הלוחות של Cisco, סדרת החדרים וסדרת השולחן, יכולות להירשם באופן טבעי ל-SIP. כל אחת מנקודות הקצה הללו שצריכות להפיק אודיו and/or שיחות PSTN דורשות רישיון שיחה:

מכשירים משותפים בחדרי ישיבות, מרחבי נוכחות וכו' דורשים רישיון של Professional Workspace או של Workspace.

מכשיר אישי של משתמש קצה דורש רישיון מקצועי או סטנדרטי.

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

כאשר התקני וידאו מועברים מרישום ל- , ה-URI עבור נקודות קצה אלו ישתנה מכיוון שהן רשומות כעת בענן.

דגמי הטלפון 8845, 8865 ו-8875 הם טלפוני וידאו אישיים הנתמכים עם .

לקוחות רכים

זהו לקוח התוכנה היחיד הנתמך על ידי , בניגוד ל-Unified CM התומך גם באפליקציית Webex וגם ב-Jabber, והוא לקוח התוכנה המוגדר כברירת מחדל החדש עבור משתמשי קצה.

בהתאם למצב/י הפריסה המיושמים עבור ג'אבר (הודעות מיידיות בלבד, טלפון בלבד, and/or מצבי UC מלאים), ייתכן שתצטרכו לשקול גם את המעבר של מערכת ההודעות and/or עומסי עבודה של פגישות, החל מג'אבר ועד ל-. ניתן לפרוס אותו במצב טלפון בלבד אם הוא ישמש כלקוח שיחות בלבד או שניתן לפרוס אותו כ- Webex Suite המלא אם עומסי עבודה אחרים, למשל Webex Messaging, קיימים. and/or פגישות Webex מועברות לאפליקציה עם שיחות.

זה משפר את חוויית המשתמש הסופי על ידי מתן תכונות בינה מלאכותית כמו audio/video אינטליגנציה, תמלול שיחות ואחרים. לקבלת מידע נוסף, ראה https://www.webex.com/all-new-webex.

לפני העברת משתמשים אליך, תצטרך להעביר את לקוחות הג'אבר שלהם ל- . יש לך שתי אפשרויות להשלמת המעבר הזה.

לפני שאתה מעביר אותם ל

כאשר אתה מעביר אותם ל-.

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

למידע נוסף, ראו מסע הגירה - צעד אחד או שניים?.

לרשימה מלאה של המכשירים הנתמכים עבור , ראה מכשירים נתמכים עבור Webex Calling.

אימות זכאות המכשיר

כפי שצוין קודם לכן, תומך בתת-קבוצה של טלפוני Cisco IP ודורש סוג קושחה שונה עבור טלפוני סדרה 7800 ו-8800. טלפוני CM מאוחדים מפעילים את הקושחה הארגונית, בעוד שטלפונים מפעילים את הקושחה של טלפון מרוב פלטפורמות (MPP). מומלץ לוודא אילו טלפונים רשומים זכאים לשדרוג לקושחת MPP במהלך שלב ההכנה. זה נותן לך זמן להחליף טלפונים שאינם זכאים באחד מדגמי הטלפונים הנתמכים או לזהות תוכנית חלופית, כמו העברת משתמש לאפליקציית Webex בלבד.

כדי לסייע בקביעת זכאות הטלפונים, ל-Control Hub יש כלי מובנה בשם העבר את הטלפון שלך ל-Webex Calling. בעת שימוש בכלי זה לבדיקת זכאות המכשיר, בחר באפשרות ההגירה צור רישיון התקן בלבד.

אפשרות כלי Control Hub לאימות זכאות של טלפוני CM מאוחדים עבור Webex Calling

אפשרות זו מאפשרת לך להעלות קובץ CSV המכיל את הטלפונים כדי שתוכל לבדוק את הזכאות של כל טלפון. על ידי בחירה באפשרות הגירה זו, הטלפונים לא יתווספו מכיוון שאתה עדיין בשלב ההכנה ועדיין לא מוכן לעשות זאת. למידע נוסף, ראה העבר את הטלפון שלך ל- Webex Calling .

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

בדוק ידנית כל טלפון ואמת את הדגם וגרסת החומרה (PID VID)

7800/8800 תווית טלפון עם פרטי דגם וגרסת חומרה

השתמש בכלי המוכנות לטלפון IP של Cisco

הורד את הכלי מ https://github.com/joemar2/mpp_readiness_check.

כלי זה אינו כלי רשמי של סיסקו וגם אינו נתמך על ידי TAC. יש לו תמיכה במאמץ הטוב ביותר אך השימוש בו הוא חינמי.

יש להפעיל כלי זה על מכונה שנמצאת מקומית ויכולה לגשת לשרתים ולטלפוני ה-IP. יש לו אפשרות להפעיל גישה לאינטרנט בטלפוני IP, וזה מומלץ ונדרש כדי לקבל את התוצאות הטובות ביותר. לכן, יש להשתמש בו בשעות הפנאי כדי למנוע הפרעה למשתמשי הקצה. הפלט של הכלי מספק דוח המפרט אילו מבין טלפונים מסדרות 7800 ו-8800 זכאים לשדרוג לקושחת MPP. מכיוון שהוא ניגש ישירות לטלפון, הוא יכול לאמת את המכשירים לא ידועים שדווחו מכלי Control Hub.

דוח כלי מוכנות לטלפון IP של סיסקו

משתמשים

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

פריסת ה-with Calling

פריסת ה- עם

הגדרת שירותים עבור משתמש

כדי להפוך את המשתמשים לניתנים לחיפוש במדריך (לחץ להתקשרות, פרטי קשר של משתמשים, חיפוש בספר טלפונים).

מומלץ להקצות את כל המשתמשים לפני או בתחילת הפרויקט. זה כולל משתמשים שעדיין משתמשים ב-Unified CM עבור פלטפורמת השיחות שלהם שאינה תלויה במכשיר השיחות שלהם (טלפון IP, Jabber, ). כאשר משתמשים מועברים אל (and/or תעדכן את הרישיונות שלהם כדי לאפשר את השירותים הדרושים להם. על ידי הקצאת כל משתמשי השיחות הארגוניים לפני תחילת המעבר, זה מאפשר למשתמש שעבר ל- או ל- לחפש בספרייה משתמש שיחות ארגוני שעדיין נמצא ב-Jabber. and/or על . זה מבטיח שמשתמשים שעברו מעבר יוכלו למצוא את פרטי הקשר של כל משתמש אחר ולבצע אליהם שיחת טלפון באמצעות חיפוש הספרייה.

האיור חיפוש ספרייה מציג דוגמה למשתמש המחפש משתמש אחר. תוצאות החיפוש מציגות את פרטי הקשר של המשתמש ויכולות להיות עבור משתמש שעדיין ב-Jabber ו/או עבור משתמש שעבר ל- and/or .

חיפוש בספריית אפליקציות Webex

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

לדוגמה, אם המשתמשים בפריסה מחולקים לשלושה אתרים עיקריים, ניו יורק (NYC), סן פרנסיסקו (SFC) ופארק משולש המחקר (RTP), תוכנית מעבר משתמשים עשויה להיראות כמו התוכנית המתוארת בטבלה תוכנית מעבר משתמשים לפי אתר.
טבלה 4. תוכנית מעבר משתמשים לפי אתר
אתר המשתמש / מִקוּם מידע והדרכות טרום מעבר תקופת מעבר תמיכה לאחר המעבר
ניו יורק (1,525 משתמשים) שבוע ה-1 באפריל 15 באפריל – 27 באפריל שבוע ה-29 באפריל
SFO (1,600 משתמשים) שבוע ה-6 במאי 20 במאי – 31 במאי שבוע ה-3 ביוני
RTP (1,275 משתמשים) שבוע ה-3 ביוני 17 ביוני – 28 ביוני שבוע ה-1 ביולי

גורם חשוב נוסף הוא העברת משתמשים יחד שיש להם תלות זה בזה. זה יכול לכלול אך לא רק את הדברים הבאים:

ניטור BLF

אותו ציד pilot/group

שיתוף קווי

חלק מאותה קבוצת מענה שיחה

שימוש באותם מספרי חניית שיחות

אינטרקום

Admin/Exec.

ניתן לעיין בתצורה (ממשק משתמש גרפי או ייצוא) או להשתמש בכלי Migration Insights כדי לזהות את קבוצות המשתמשים עם תלויות אלה.

קישוריות PSTN

ניתן לגשת לרשת התקשורת הסלולרית (PSTN) בשלוש דרכים: תוכניות שיחות של סיסקו, Cloud Connect for (לשעבר Cloud Connected PSTN), ו-PSTN מקומי (שער מקומי). עם זאת, מיקום יחיד כפי שמוגדר בתוך ניתן להקצות רק לאפשרות PSTN אחת.

רשת PSTN מקומית עם שער מקומי (LGW) היא מרכיב חיוני באסטרטגיית המעבר. זה מספק קישוריות בין הפריסה המקומית and/or PSTN והפלטפורמה תומכים הן ב-Cisco והן בבקרי גבולות סשן (SBC) מוסמכים של צד שלישי שניתן להשתמש בהם כשער מקומי. לרשימה העדכנית ביותר של רישומי SBC נתמכים, ראה רשימת רישומי SBC נתמכים.

תומך בעד 250 שיחות בו-זמניות משער מקומי יחיד המבוסס על רישום ובמעל 250 שיחות בו-זמניות משער מקומי יחיד המבוסס על תעודה. שערים מקומיים מבוססי תעודות יכולים לתמוך בעד 6500 שיחות בו זמנית, אך זה מבוסס על סוג הקישוריות שיש לשער המקומי (Over-the-Top לעומת peering interconnect) ועל מודל ה-SBC עליו נפרס השער המקומי. מגבלות אלו הן למעשה מגבלת הספירה המוגדרת כברירת מחדל הן עבור שיחות PSTN מקומיות מבוססות שער והן עבור שיחות בין אתרים בין נקודות קצה ו-. למידע נוסף, ראה התחל עם שער מקומי.

כל שיחה שחורגת ממגבלה זו נדחתה עם 403 Forbidden. ניתן להריץ את הפקודה show call active voice בשער המקומי בכל מופע כדי לקבוע את המספר הכולל של שיחות פעילות.

תנאי רשת גרועים בין שער מקומי לבין SBC הגישה יכולים להגביל את ביצועי חיבור האיתות, מה שמוביל למגבלת שיחות בו-זמנית נמוכה עוד יותר. זמן ההשהיה החד-כיוונית בין השער המקומי למרכז הנתונים לא יעלה על 100 מילישניות, והריצוד צריך להיות פחות מ-10 מילישניות בעוד שאובדן חבילות (packets loss) יהיה פחות מ-0.5 מילישניות. %.

תכונות & שימוש בתכונות

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

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

סקירת תצורה בממשק המשתמש הגרפי של המנהל

ייצוא הגדרות -- ייצוא בכמות גדולה או AXL

כלי תובנות הגירה (מומלץ)

כלי שותפים של צד שלישי של סיסקו (מומלץ).

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

סקירת רשומות CDR גולמיות

סקירת נתוני RTMT מאוחדים של CM

כלי תובנות הגירה המשתמש בנתוני CDR

סקירה של ניתוח UC מחובר לענן ב

עוצמת השיחות

נקודות קצה רשומות

מיקומי (CAC)

ניצול תא המטען.

כלי שותפים של צד שלישי של סיסקו.

סיסקו ממליצה להתחיל עם כלי Webex Control Hub Migration Insights עבור ניתוח זה. ייבאו את קובץ ה-.TAR לייצוא ואת קבצי ה-Unified CM CDR (אופציונליים, אך נדרשים לניתוח ניצול תכונות) לתוך הכלי. הכלי ייצור את הדוחות הבאים מבוססי ה-CSV בהם ניתן להשתמש כדי להתחיל את הניתוח:

טבלה 5. דוחות שנוצרו מקובץ .tar של Unified CM
שם הדוח
תיאור הדוח
ImportedDataBulk.csv
כל המשתמשים והמכשירים מנתוני Unified CM
DeviceEligibility.csv
מזהה מכשירים הזכאים למעבר ל-Webex Calling (טלפוני IP, התקני מערכת הפעלה של חדר, ATA וצד שלישי)
DevicePoolNumbers.txt
רשימה של כל המספרים במאגר התקנים מסוים
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
פרטים על מכשירים ומשתמשים שיש להעביר יחד בהתבסס על קווים משותפים, Hunt Pilot, תור שיחות, חניית שיחות ותצורת קבוצת מענה שיחות
HuntGroupMigrationInsight.csv
מידע מפורט על קווי ציד שהוקצו, קבוצות קווי ציד וסוכנים קשורים
SharedlineGroupMigrationReport.csv
סקירה כללית של אופן שיתוף מספרי טלפון (מספרי מדריך) בין משתמשים

טבלה 6. דוחות שנוצרו מקבצי .tar ו-CDR.gzip של Unified CM
שם הדוח
תיאור הדוח
FeatureUsageBasedDeviceEligibilityReport.csv
מידע על זכאות להעברת מכשירים בהתבסס על השימוש בתכונות
FeatureUsageWithLastUsageDateReport.csv
ספירת שימוש עבור מספר הפעמים ש-Hunt pilot ותור/י הקריאה נקראו יחד עם תאריך השימוש האחרון
UserWorkspaceLastUsage.csv
תאריך שימוש אחרון עבור משתמשים וסביבות עבודה עבור לקוחות רכים וטלפונים קשיחים כאחד
DIDUsageReport.csv
שימוש ב-DID עבור DID שהוקצו וגם עבור DID שלא הוקצו

לפרטים נוספים על דוחות תובנות מעבר, ראו תובנות מעבר.

אם אתם זקוקים למידע נוסף על התכונות והשימוש לאחר סקירת המידע בדוחות תובנות ההעברה, סיסקו ממליצה לשקול אחד מכלי ההעברה של שותפי צד שלישי של סיסקו. and/or כדי לסקור את התצורות בממשק המשתמש הגרפי או בנתוני ייצוא התצורה.

אינטגרציות של סיסקו: Unity Connection UCCX UCCE

דואר קולי הוא חלק בלתי נפרד מההצעה ומובנה באופן טבעי בפתרון. לא ניתן להשתלב עם פתרון דואר קולי מבוסס-מקום כגון Unity Connection או Unity Connection Express. יתר על כן, אין דרך מקורית להעביר הודעות דואר קולי או ברכות קיימות של חיבור Unity לשירות הדואר הקולי המקורי הזמין עם . לחלק מכלי ההגירה של שותפי צד שלישי של סיסקו יש יכולות להעביר חלק מהנתונים הללו. למידע נוסף על דואר קולי עבור , ראה הגדרת וניהול הגדרות דואר קולי עבור משתמש Webex Calling.

תומך גם בתיבות דואר קוליות ופקס משותפות. למידע נוסף, ראה ניהול דואר קולי ופקס נכנס משותף עבור Webex Calling.

כולל תכונת ניתוב אוטומטי מובנית הכלולה כחלק מפלטפורמת הליבה. תכונה זו מאפשרת מעבר של מטפלי השיחות ופונקציונליות המענה האוטומטי של Unity Connection שלך. כלי מרכז הבקרה, העברת תכונות מ-Unified CM, תומך בהעברת תצורות Unity Connection ל-Auto-Attendants. למידע נוסף על השימוש בכלי זה, ראו העברת מכשירים ותכונות מ-Unified CM ל-Webex Calling.

הקלטת שיחות

כולל שתי אפשרויות להקלטת שיחות ללא עלות נוספת.

הקלטת שיחות Webex

הקלטה של Dubber Go (הצעת שותפים) - אינטגרציה בין Dubber ל-dubber שבה כל המדיה המוקלטת נשמרת בצורה מאובטחת בענן.

אפשרויות הקלטה כלולות הטבלה מדגישה כמה תכונות עיקריות של שתי אפשרויות הקלטת שיחות הזמינות ללא עלות נוספת.

טבלה 7. אפשרויות הקלטה כלולות
Webex דאבר גו

זמין לכל המשתמשים זמין לכל המשתמשים

הקלטות ללא הגבלה הקלטות ללא הגבלה

תקופת שמירה של שנה אחת* תקופת שמירה של 30 יום

אחסון של 100 ג'יגה-בייט לכל ארגון -

קציני ציות יכולים לגשת ולנהל הקלטות שיחות -

ממשקי API לניהול הקלטות -

מנהלי מערכת יכולים להגדיר ולנהל את גישת המשתמשים להקלטות השיחות שלהם
משתמשים יכולים לנהל את ההקלטות שלהם באמצעות User Hub and/or אפליקציית Webex.
רק משתמשים יכולים לגשת ולנהל את ההקלטות שלהם
מפורטל המדבבים שלהם.

אם הארגון שלכם דורש יכולות הקלטה נוספות כמו הקלטת שיחות בנושאי תאימות, תקופות שמירה ארוכות יותר, אחסון נוסף, ניתוח בינה מלאכותית, and/or גישת מנהל, הצעות בתשלום או תוספים קיימים הן מסיסקו והן מספקי הקלטות של צד שלישי. למידע נוסף על ספקי הקלטות, תצורות ושירותי שותפים נוספים, ראה ניהול הקלטת שיחות עבור Webex Calling.

אינטגרציות של צד שלישי

תומך במגוון אינטגרציות של צד^{שלישי , כולל אך לא רק SBCs עבור שערים מקומיים, טלפוני IP, טלפוני אינטרקום, Speaker/Pagers, ATAs וכו'. בנוסף למכשירים אלה של^צד שלישי , Webex Calling תומך בפתרונות שונים של} צד שלישי^{עבור תמיכת לקוחות, ניתוח נתונים, הקלטה, חיוב וכו'. למידע נוסף על פתרונות של^צד שלישי , ראה Webex App Hub.}

טבלה 1. הערכה לדוגמה
דרישה	שיקולים מרכזיים
מוכנות רשת ורוחב פס	רוחב פס, איכות שירות, WAN/Internet, Firewall/NAT
אינטגרציה עם מערכות קיימות	ספריות, CRM, מרכזיה, Email/Calendar
תאימות והקצאה של נקודות קצה	תמיכה במכשירים, הקצאה, עדכוני קושחה
תצורות אבטחה והצפנה	הצפנה, אימות, תאימות, ניטור אבטחה
הדרכת משתמשים וניהול שינויים	תוכניות הדרכה, תיעוד, תקשורת שינויים
ניידות מספרים ותוכנית חיוג	מִספָּר migration/porting, תרגום תוכנית חיוג
אינטגרציות של צד שלישי	זימון, מרכז קשר, פקס, מכשירים אנלוגיים

טבלה 2. חישובי רוחב פס של סוג השיחה של Webex Calling
סוגי שיחות	קודק - רוחב פס	חישובי רוחב פס
/ טלפון שולחני ->	אופוס - 70 קילו-ביט לשנייה	מספר שיחות בו זמנית * 70 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> טלפון שולחני	אופוס – 70 קילו-ביט לשנייה	מספר שיחות בו זמנית * 70 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> PSTN דרך LGW	G.711 – 80 kbps	מספר שיחות בו זמנית * 80 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> PSTN דרך PSTN בענן (למשל, תוכנית שיחות של סיסקו)	G.711 – 80 kbps	מספר שיחות בו זמנית * 80 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> ארגון דרך LGW	G.722 – 80 kbps	מספר שיחות בו זמנית * 80 קילו-ביט לשנייה = תפוקת רשת נדרשת
/ טלפון שולחני -> הודעה קולית	אופוס – 70 קילו-ביט לשנייה	מספר שיחות בו זמנית * 70 קילו-ביט לשנייה = תפוקת רשת נדרשת

טבלה 3. דוגמאות לחישוב רוחב פס של שיחות Webex
סוגי שיחות	מספר שיחות בו זמנית	רוחב פס כולל
אפליקציית Webex / טלפון שולחני → אפליקציית Webex	15	2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → טלפון שולחני	15	2 * 15 * 70 קילו-ביט לשנייה = 2,100 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → PSTN דרך LGW	50	2 * 50 * 80 קילו-ביט לשנייה = 8,000 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → PSTN דרך Cloud Connect עבור שיחות Webex	0	0 * 80 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → ארגוני דרך LGW	15	2 * 15 * 80 קילו-ביט לשנייה = 2,400 קילו-ביט לשנייה
אפליקציית Webex / טלפון שולחני → הודעה קולית של Webex Calling	5	5 * 70 קילו-ביט לשנייה = 350 קילו-ביט לשנייה
סך כל השיחות / רוחב פס	100 שיחות	14,950 קילו-ביט לשנייה / 14.95 מגה-ביט לשנייה

טבלה 4. תוכנית מעבר משתמשים לפי אתר
אתר המשתמש / מִקוּם	מידע והדרכות טרום מעבר	תקופת מעבר	תמיכה לאחר המעבר
ניו יורק (1,525 משתמשים)	שבוע ה-1 באפריל	15 באפריל – 27 באפריל	שבוע ה-29 באפריל
SFO (1,600 משתמשים)	שבוע ה-6 במאי	20 במאי – 31 במאי	שבוע ה-3 ביוני
RTP (1,275 משתמשים)	שבוע ה-3 ביוני	17 ביוני – 28 ביוני	שבוע ה-1 ביולי

טבלה 5. דוחות שנוצרו מקובץ .tar של Unified CM
שם הדוח תיאור הדוח
ImportedDataBulk.csv כל המשתמשים והמכשירים מנתוני Unified CM
DeviceEligibility.csv מזהה מכשירים הזכאים למעבר ל-Webex Calling (טלפוני IP, התקני מערכת הפעלה של חדר, ATA וצד שלישי)
DevicePoolNumbers.txt רשימה של כל המספרים במאגר התקנים מסוים
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv פרטים על מכשירים ומשתמשים שיש להעביר יחד בהתבסס על קווים משותפים, Hunt Pilot, תור שיחות, חניית שיחות ותצורת קבוצת מענה שיחות
HuntGroupMigrationInsight.csv מידע מפורט על קווי ציד שהוקצו, קבוצות קווי ציד וסוכנים קשורים
SharedlineGroupMigrationReport.csv סקירה כללית של אופן שיתוף מספרי טלפון (מספרי מדריך) בין משתמשים

טבלה 6. דוחות שנוצרו מקבצי .tar ו-CDR.gzip של Unified CM
שם הדוח תיאור הדוח
FeatureUsageBasedDeviceEligibilityReport.csv מידע על זכאות להעברת מכשירים בהתבסס על השימוש בתכונות
FeatureUsageWithLastUsageDateReport.csv ספירת שימוש עבור מספר הפעמים ש-Hunt pilot ותור/י הקריאה נקראו יחד עם תאריך השימוש האחרון
UserWorkspaceLastUsage.csv תאריך שימוש אחרון עבור משתמשים וסביבות עבודה עבור לקוחות רכים וטלפונים קשיחים כאחד
DIDUsageReport.csv שימוש ב-DID עבור DID שהוקצו וגם עבור DID שלא הוקצו

טבלה 7. אפשרויות הקלטה כלולות
Webex	דאבר גו
זמין לכל המשתמשים	זמין לכל המשתמשים
הקלטות ללא הגבלה	הקלטות ללא הגבלה
תקופת שמירה של שנה אחת*	תקופת שמירה של 30 יום
אחסון של 100 ג'יגה-בייט לכל ארגון	-
קציני ציות יכולים לגשת ולנהל הקלטות שיחות	-
ממשקי API לניהול הקלטות	-
מנהלי מערכת יכולים להגדיר ולנהל את גישת המשתמשים להקלטות השיחות שלהם משתמשים יכולים לנהל את ההקלטות שלהם באמצעות User Hub and/or אפליקציית Webex.	רק משתמשים יכולים לגשת ולנהל את ההקלטות שלהם מפורטל המדבבים שלהם.

לתכנן

תוכנית פרויקט ברמה גבוהה

מסע הגירה - צעד אחד או שניים?

אפשרות 1: הגירת משתמשים בשלב אחד

אפשרות 2: הגירת משתמשים בשני שלבים

שלב 1

שלב 2

תוכנית פרויקט ברמה גבוהה

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

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

הגדרת היקף ההגירה (למשל, אילו משתמשים, מכשירים ותכונות יעברו)

קביעת מפגשי הדרכה למשתמשי קצה ולצוותי תמיכה

תיאום הערכות מוכנות הרשת, ו

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

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

מסע הגירה - צעד אחד או שניים?

דורש מהמשתמשים להשתמש ב- עבור לקוח התוכנה المتخدم שלהם. לכן, אם משתמשים עדיין משתמשים ב- , יש לכם שתי אפשרויות מתי תוכלו להעביר אותם ל- . ניתן לבצע הגירת משתמשים בשלב אחד או הגירת משתמשים בשני שלבים.

אפשרות 1: הגירת משתמשים בשלב אחד

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

שירותי השיחות הועברו מ- אל

מספרי טלפון ושלוחות הועברו מ- אל

לקוח רך עבר מ-Jabber ל- - יירשם ל

רישום טלפון הועבר מ- אל.

שירות שיחות של המשתמש, לקוח רך & הטלפון עובר אליו באותו הזמן

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

אפשרות 2: הגירת משתמשים בשני שלבים

הגישה השנייה היא הגירה בשני שלבים. בשלב 1, המשתמשים מועברים מ- ל- אך נשארים פעילים עבור שירותי שיחות. לאחר מכן, בשלב 2, המשתמשים מועברים מ-Unified CM ל- . אפשרות זו מומלצת ללקוחות גדולים יותר לניהול שינויים במשתמש הקצה ורוצים להפריד בין שינוי הלקוח הרך של המשתמש לבין שינוי השירות הקורא. האיור הבא העברת לקוח רך; לאחר מכן העברה של שירות קריאה, לקוח רך & טלפון ל-Webex Calling להלן מדגיש סוג זה של העברה.

שלב 1

לקוח רך עבר מ- ל- - ירשום ל-.

שלב 2

שירותי השיחות הועברו מ- אל .

מספרי טלפון ושלוחות הועברו מ- אל .

הרישום הועבר מ- אל.

רישום טלפון הועבר מ- אל.

העברת לקוח רך; לאחר מכן העברת שירות שיחות, לקוח רך & טלפון ל-Webex Calling

עדיין ניתן לבצע הגירה בשלבים שבה קבוצות של משתמשים מועברות בזמנים שונים בשני השלבים.

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

בהתבוננות במסע המומלץ (אפשרות 1), מפת המעבר ברמה גבוהה מ-Jabber לאפליקציית Webex האיור שלהלן מציג את המעבר ברמה גבוהה עבור שלב 1.

מפת מעבר ברמה גבוהה מ-Jabber ל-Webex App

בשלב זה המשתמשים מועברים מג'אבר ל- עבור כל שירותי השיחות שלהם. עם זאת, פלטפורמת השיחות עדיין Unified CM ושירותי השיחות שלה ירשום ל- . כפי שניתן לראות באיור של מפת המעבר ברמה גבוהה מ-Jabber ל-Webex App, התשתית המקומית לא משתנה, והיא פועלת באותו אופן שבו Jabber פועל. השינוי היחיד הוא שדרוש חיבור אל .

למידע נוסף על מעבר זה, ראו מפת מעבר מ-Jabber ל-Webex ומדריך פריסה תחת סעיף הלקוח בדף מעבר שיתוף פעולה.

מפת מעבר ברמה גבוהה מ-Unified CM ל-Webex Calling האיור הוא המעבר ברמה גבוהה מ- ל-. זהו שלב 2 במסע המומלץ.

מפת מעבר ברמה גבוהה מ-Unified CM ל-Webex Calling

אם תחליט להשתמש בגישת הצעד החד-שלבי, גם זה חל.

בשלב זה המשתמשים מועברים לקבוצות. בנקודה זו המשתמשים מתחילים להשתמש בשירותי השיחות שלהם, רישום שיחות ורישום טלפון IP.

מכיוון שהמשתמשים עוברים בקבוצות, משתמשי Enterprise יחולקו בין שתי פלטפורמות השיחות במהלך המעבר. שלב 1 באיור מפת מעבר ברמה גבוהה של Unified CM ל-Webex Calling מתאר מצב זה. במהלך שלב זה נדרש תכנון כיצד לנהל שיחות בין משתמשים בשתי הפלטפורמות וכיצד ינותבו שיחות PSTN. בכל פעם שקבוצת משתמשים עוברת ל- , יידרשו עדכוני תוכניות חיוג וניתוב שיחות ב- , ובשער/י השער המקומי/ים.

לאחר שכל המשתמשים, הלקוחות הרכים והמכשירים עברו לשלב 2 (שלב 2), ניתן יהיה להסיר ולהוציא את כל תשתית ה-UC המקומית משימוש.

לעצב

בחירת אזור

מיקומים

PSTN

תוכנית חיוג

תוכנית חיוג מקומית

תוכנית חיוג

הקלטה

1. בחירת ספק הקלטת שיחות

2. בחירת אזור

שיחות חירום

רישוי

הקצאה ידנית דרך

תבניות הקצאת רישיונות אוטומטיות

הקצאה בכמות גדולה באמצעות תבנית CSV

הקצאה מבוססת API

דרישות רישיון

הקצאת משתמשים

קבוצות משתמשים

גישה מומלצת בעת מעבר מ- אל

עיצוב קבוצות משתמשים

כניסה יחידה (SSO)

תמיכה במספר IdP

1. מיזוגים ורכישות

2. מספר מחלקות IT עצמאיות

3. קבוצות משתמשים או דומיינים שונים

4. תמיכה בפרוטוקולי אימות שונים

5. אבטחה ותאימות משופרים

6. חוויית משתמש פשוטה יותר

Duo MFA עם SSO עבור

תכונות

ניתוב אוטומטי

חניית שיחות

מענה לשיחות

תור שיחות

קבוצת גישוש

מצבי הפעלה

קבוצת זימון

הקלטות

טווח מספר יחיד

קבוצת דואר קולי

בחירת אזור

זמין ברחבי העולם ומסופק ממרכזי נתונים מיותרים במספר אזורים: ארה"ב (דאלאס, שיקגו), קנדה (ונקובר, טורונטו), אירופה (פרנקפורט, אמסטרדם), בריטניה (לונדון, מנצ'סטר), אוסטרליה (מלבורן, סידני), יפן (טוקיו, אוסקה), ערב הסעודית (ריאד, ג'דה) והודו (מומבאי, צ'נאי). מערכות ה-PoP של המדיה מספקות שירותי מדיה כדי לייעל את זמני הנסיעה הלוך ושוב של המדיה. מרכז הנתונים בסינגפור, לדוגמה, משמש לאופטימיזציה של זמני הנסיעה הלוך ושוב של מדיה עבור לקוחות במדינות אסיה, שבהן זמני הנסיעה הלוך ושוב לאזור אוסטרליה או יפן עשויים להיות לא אופטימליים. מרכזי הנתונים מחוברים באמצעות רשת שדרה מרובת ג'יגה-ביט ויתירה לחלוטין. האיור מרכזי נתונים מבוזרים ברחבי העולם מציג סקירה כללית של כל מרכזי הנתונים. לקבלת הרשימה העדכנית ביותר של מרכזי נתונים זמינים, ראה מיקומי מרכזי נתונים עבור Webex Calling.

מרכזי נתונים מבוזרים ברחבי העולם

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

למידע על זמינות במדינות שונות, ראה היכן Webex זמין?.

מיקומים

כדי להתכונן להקצאת מיקומים, יש לאסוף את המידע הנדרש עבור כל מיקומי יעד ההגירה. המידע הדרוש לכל מיקום מסוכם ב- מידע שיש לאסוף עבור כל מיקום.
טבלה 1. מידע שיש לאסוף עבור כל מיקום
מידע הערה
טווח/י הרחבה לכל מיקום יכולות להיות סיומות המתחילות בספרות שונות. יש להשאיר ספרה אחת עבור ספרת ההיגוי לחיוג בין-אתרי (לדוגמה 8) וספרה אחת עבור ספרת ההיגוי לחיוג PSTN (לדוגמה 9). אף טווח סיומת לא יכול להתחיל באחת משתי הספרות הללו.
כל טווחי ההרחבה של כל המיקומים חייבים להיות באורך שווה.
טווח/י DID -
ספרת היגוי PSTN -
קוד האתר כל קודי האתר של כל המיקומים צריכים להיות ייחודיים ובעלי אורך זהה.
מספר ראשי בעת יצירת מיקום יש להקצות שני DIDs. אחד כמספר ראשי (לדוגמה, להקצאה לשירות מענה אוטומטי) ואחד עבור פורטל התא הקולי.
הקצאת DID אחד עבור מספר התא הקולי.
מספר תא קולי
מספר רישיונות רישיונות נדרשים לפי סוג כולל רגיל, מקצועי, סביבת עבודה, רשימת מסלולים, תוכנית שיחות יוצאות.
שיחות בו זמנית בשעות העמוסות סכום השיחות המקבילות בין מכשירים ובין מכשירים לשער המקומי (PSTN ושיחות למכשירים). נדרש כדי לקבוע את רוחב הפס הנדרש לגישה לאינטרנט.
מדינה -
אזור זמן -
שפה -
איש קשר (שם, טלפון, דוא"ל) -
כתובת (כתובת רחוב, עיר, מדינה, מיקוד) -
מיקום פיזי של שירותי חירום עבור נקודות קצה מיקום שיגור המכשיר המשמש לשיחות חירום כולל בדרך כלל את הדברים הבאים: כתובת הבניין, כתובת הבניין + מספר קומה, כתובת הבניין + מספר סוויטה, או כתובת הבניין + מספר קומה + office/cubical מִספָּר.
מיקום רשת פיזי ייחודי לכל מכשיר עבור שירותי חירום מיקום רשת פיזית עבור שיחות חירום כולל בדרך כלל את הדברים הבאים: מֶתֶג / יציאת מתג עבור התקנים קוויים, מזהי סט שירות בסיסי (BSSIDs) של נקודת גישה אלחוטית (AP) עבור התקנים המחוברים באופן אלחוטי, and/or רשתות משנה IP מקומיות עבור התקני קצה.

PSTN

בעת תכנון פריסה, ללקוחות יש שלוש אפשרויות קישוריות PSTN עיקריות: תוכניות שיחות של סיסקו (שירות PSTN המסופק בענן ומנוהל על ידי סיסקו), ספקי PSTN מחוברים לענן (CCPP, שבהם ספקים מספקים שירות PSTN דרך הענן), ו-PSTN מקומי (כאשר שערים מקומיים מחברים את רשת הארגון ל-PSTN). עם הצגת PSTN trunking עבור פריסות היברידיות (למידע נוסף, ראה PSTN trunking עבור פריסות היברידיות של Webex Calling בכתובת PSTN trunking), ארגונים מקבלים גמישות נוספת בגישת ההעברה שלהם. תכונה זו מאפשרת ללקוחות להעביר את שירותי ה-PSTN שלהם ל-CCPP בתחילת מסע המעבר ולהתחיל במעבר ל-PSTN בענן עבור משתמשים, תוך מינוף CCPP כדי לשמור על שירות PSTN עבור משתמשים שנשארים ב-Cisco במהלך הגירה מדורגת.

גישה היברידית זו מאפשרת לארגונים להעביר קבוצות משתמשים נבחרות לענן תחילה, מבלי לבצע שיפוץ מיידי של כל סביבת הטלפוניה שלהם. עם זאת, הדבר מציג מורכבות וסיכון נוספים, במיוחד סביב התאמת לוגיקת ניתוב שיחות קיימת לתמיכה בארכיטקטורה החדשה. יכולת פעולה הדדית עם יישומים מדור קודם, כגון שרתי פקס, מרכזי קשר או מערכות זימון, דורשת גם היא שיקול דעת. אתגרים טכניים מרכזיים עשויים לכלול הבטחת משא ומתן חלק מקצה לקצה של קודק ואיתות DTMF (Dual-Tone Multi-Frequency) בסביבה המעורבת, וכן אימות תאימות עם תכונות טלפוניה מיוחדות. תכנון ובדיקות נכונים חיוניים כדי למזער שיבושים ולשמור על שירותי קול אמינים לאורך כל תהליך ההעברה. בנוסף, שיקולים מסחריים חשובים, מכיוון ש-trunking היברידי דורש רישיון שימוש המבוסס על מספר השיחות המקבילות בין הסביבה המקומית לבין ספק ה-PSTN המחובר לענן (CCPP).

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

מעבר ל-CCCP בהתחלה לעומת שמירה על PSTN מקומי

האיור מעבר ל-CCCP בהתחלה לעומת שמירה על PSTN מקומי מציג את שתי אפשרויות מעבר ה-PSTN שהוסברו לעיל. האיור משמאל מציג את התרחיש שבו כל המשתמשים והאפליקציות המקומיות צורכים שירותי PSTN מחוברים לענן דרך trunk מקומי ושער מקומי המחבר את ה-PSTN המקומי אל , בעוד שהאיור מימין מציג את התרחיש שבו ה-PSTN המקומי הקיים נשאר במקומו ומשתמשים ב-Webex Calling משתמשים ב-PSTN מקומי דרך חיבור השער המקומי בין המקומי ל-. במהלך המעבר ניתן לעבור למיקומים באמצעות PSTN מחובר לענן.

בשני התרחישים, שיחות בין המערכת המקומית למשתמש משתמשות בחיבור Local Gateway. יש לתכנן ולשנות את גודל החיבור בין המערכת המקומית ל- בהתאם למספר הצפוי של שיחות בו-זמניות וליתירות הנדרשת.

תוכנית חיוג

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

תוכנית חיוג מקומית

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

+E.164 מחייג מ- אל

חיוג שלוחה מ- אל (בתוך האתר וגם בין האתרים אם טווחי השלוחות ייחודיים)

חיוג מקוצר בין אתרים מ- אל

חיוג כפוי ברשת מ- אל

שיחה חוזרת מספריית שיחות שלא נענו ליעדים ב

שיחות PSTN מ-PSTN ל-PSTN אם במהלך המעבר נעשה שימוש ב-PSTN מקומי עבור

קריאות PSTN מ- אל אם במהלך המעבר, PSTN trunking עבור פריסות היברידיות משמש כדי לספק גישת PSTN למשתמשים מקומיים דרך Cloud Connect עבור

כפויה ברשת מ- אל

שלוחה מחייגת מ- אל (בין אתרים).

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

האיור תוכנית חיוג של שיטות עבודה מומלצות מציג את גישת תוכנית החיוג המומלצת כפי שמתואר ב- ארכיטקטורה מועדפת עבור פריסות מקומיות של Cisco Collaboration 12.x Enterprise, CVD. מאפיינים עיקריים של גישה זו כוללים:

מחיצה יחידה עבור +E.164 מספרי מדריך

ניתוב ליבה מבוסס על +E.164 דפוסי מסלול

נורמליזציה של כל הרגלי החיוג ל +E.164 שימוש בתבניות תרגום

שימוש בתבנית תרגום שקוראת לירושה של מרחב חיפוש (אפשרות השתמש במרחב חיפוש של המקור שקורא למרחב מוגדרת על תבניות תרגום).

תוכנית חיוג שיטות עבודה מומלצות

לדוגמה, חיוג למספר PSTN (9+1+10D) ממכשיר ב-SJC שהוקצה לו מרחב חיפוש קריאות קו SJCInternational יקבל תחילה התאמה על ידי 9.1[2-9]XX[2-9]XXXXXX תבנית תרגום אשר מנרמלת את מספר הצד שאליו התקשר ל- +E.164. החיפוש המשני משתמש לאחר מכן באותו מרחב חיפוש שקורא ל- SJCInternational שוב (קורא לירושה של מרחב החיפוש) ו- +E.164-digit המחרוזת תתאים על ידי +E.164 מספר ספרייה במחיצה DN או על ידי אחת מתבניות הנתיב של PSTN במחיצה USPSTNNational או SJCPSTNLocal. הרגלי חיוג מקוצרים בתוך האתר ובין האתרים מיושמים על ידי התרגומים במחיצות ESN ו- SJCtoE164. בעוד שמחיצה ESN היא מחיצה גלובלית (נגישה לטלפונים בכל המיקומים), מחיצה SJCTOE164 נגישה רק למשתמשים במיקום SJC. זה בהנחה שטווחי הרחבה חופפים.

הצעד הראשון כדי לאפשר שיחה מ- אל היא לוודא ש +E.164 היעדים מנותבים בהתאם. ניתן להשיג זאת על ידי הוספת מחיצה לתוכנית החיוג, הוספה +E.164 תבניות מסלול עבור כל היעדים למחיצה זו, ולבסוף הוספת המחיצה לכל מרחבי חיפוש הקריאה המייצגים מחלקות שירות שצריכות להיות מסוגלות להגיע . יצירת מחיצה ייעודית נדרשת כדי לאפשר יצירת מחלקה מובחנת של שירות עבור שיחות שמקורן ב- . כדי להימנע מלולאות שיחות, מרחב חיפוש השיחות הנכנסות ב-trunk מהשער המקומי לא אמור להיות בעל גישה למחיצה.

+E.164 ניתוב ל-Webex Calling

כפי שמוצג באיור +E.164 ניתוב ל-Webex Calling, כדי לאפשר ניתוב מ-אל עבור מיקום עם +E.164 טווח DID +1 221 555 2XXX וקוד אתר 121, תבנית מסלול דחופה התואמת לכך +E.164 יש להוסיף טווח למחיצה .

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

כדי לאפשר חיוג מקוצר בין אתרים לאתר, תבנית הנתיב הנדרשת 8121.2XXX מתווספת למחיצה. עבור אתרים שיעברו לתבנית נרמול חיוג 8121.2XXX שמנרמלת חיוג ESN ל +E.164 ייתכן שכבר קיים במחיצת ESN. במקרה כזה נראה כי ה- 8121.2XXX מיותר, אך ברגע שכל ה-DNs של המיקום המתאים הועברו לתבנית תרגום נרמול החיוג 8121.2XXX ניתן להסיר ואז תבנית הנתיב 8121.2XXX מאפשרת חיוג ESN גם עבור משתמשי שלוחה בלבד בטווח זה.

עם שינויים אלה בתוכנית החיוג, ניתן לבצע שיחות למיקום לא רק על ידי חיוג למספרים מקוצרים בין אתרים וגם +E.164. כמו כן, חיוג PSTN בינלאומי ולאומי אפשרי מכיוון שהרגלי חיוג אלה מנורמלים תחילה ל +E.164 דרך דפוסי התרגום של נרמול החיוג שכבר קיימים ולאחר מכן מנותבים אליהם על ידי התאמה ל- +E.164 תבנית מסלול במחיצה.

ה +E.164 ניתן להקצות התאמת דפוסי מסלול בטווח DID של המיקום כאשר כל ה-DID עדיין מתארחים ב- . אלגוריתם התאמת דפוסי ההתאמה הטוב ביותר של מוודא שכאשר מספר המאוחסן ב- מחייג, אז ה- +E.164 מספר הספרייה שהוקצה בו תואם טוב יותר ממספר התו הכללי +E.164 תבנית מסלול המצביעה אל כך שהשיחות יועברו לקו מופעל ולא יישלחו אל .

תוכנית חיוג

לכל משתמש יש הרחבה and/or א +E.164 מספר טלפון. אורך ההרחבה הוא הגדרה גלובלית קבועה: לכל ההרחבות בפריסה יש אורך זהה. ניתן להשתמש בחיוג שלוחה בין משתמשים הן בתוך מיקום והן בין מיקומים. חיוג מקוצר לשלוחה בין-אתרית (המקרה האחרון) פועל רק אם השלוחה שחויגה היא ייחודית.

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

אורך השלוחה, אופן חיוג השלוחה הבין-מיקומית, אורך הקידומת לחיוג בין-מיקומי וספרת ההיגוי בקידומת הניתוב לחיוג בין-מיקומית מוגדרים בהגדרות שירות השיחות ב :

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

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

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

אפשר חיוג שלוחה בין מיקומים: החלף אל enable/disable חיוג שלוחה בין מיקומים. יש להפעיל אפשרות זו רק אם כל ההרחבות בארגון הן ייחודיות. אם האפשרות מושבתת, יש לחייג מספרים משמעותיים של הארגון (קוד היגוי, קוד אתר, שלוחה) או מספרי טלפון בין מיקומים.

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

הטבלה דוגמה למספור ארגוני מציגה דוגמה לשלושה מיקומים שבהם טווחי הסיומת של שני מיקומים, NYC ו-RTP, זהים. קביעת סכמת מספור ארגונית עם ספרת היגוי בין-אתרית 8, ואחריה קוד אתר בן שלוש ספרות, והרחבה בת ארבע ספרות יוצרת הרגל חיוג מקוצר בין-אתרי שאינו חופף.

טבלה 2. דוגמה למספור ארגוני
אתר טווח הרחבה קוד האתר טווח ארגוני

ניו יורק 2XXX 202 8 202 2XXX

משרד עורכי דין 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

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

הטבלה טווחי הארכה באורך קבוע מציגה דוגמה לשלושה מיקומים וטווחי הארכה באורך קבוע. מכיוון שיש להימנע מהרגלי חיוג חופפים, חשוב לוודא שעבור כל טווח שלוחה הספרה הראשונה בטווח אינה תואמת לספרת ההיגוי לחיוג מקוצר בין אתרים. אם לדוגמה 8 נבחר כספרת ההיגוי לחיוג בין אתרים, אז אף שלוחה באתר לא יכולה להתחיל ב- 8. בדרך כלל, הסיומות במיקום נתון תואמות את הספרות האחרונות של מספרי ה-DID שהוקצו למיקום זה. כדי למנוע התנגשויות, ניתן לשנות את הספרה הראשונה של השלוחה. אם, לדוגמה, DIDs ב- +1 אם משתמשים בטווח 408 555 8XXX במיקום מסוים, אז במקום להשתמש ב-8XXX כשלוחות ניתן להשתמש בטווח 7XXX עבור השלוחות באותו אתר.

טבלה 3. טווחי הארכה באורך קבוע
אתר טווח הרחבה שלוחות קוד האתר טווח ארגוני

ניו יורק 2XXX 2XXX 202 8 202 2XXX

משרד עורכי דין 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

מחרוזות חיוג בנות שבע ספרות המחויגות במכשיר באמצעות תוכנית החיוג האמריקאית חופפות לתבנית בת שבע ספרות לחיוג מקומי בתוכנית החיוג האמריקאית שהוטענה מראש. כדי למנוע חפיפות בין הרגלי חיוג מקוונים ומחוצה להם (PSTN), ניתן להשתמש בקוד גישה חיצוני חובה באותו מיקום. אם סכמת המספור הקיימת של הארגון וחיוג מקוצר בין-אתרי המתאים חופפים לדפוסים בחיוג הארצי, אז במהלך המעבר לסכמת המספור ניתן גם לשנות אותה לצורה ארוכה או קצרה יותר, כדי למנוע חפיפות. הדרך הקלה ביותר להשיג זאת היא להוסיף ספרת ריפוד נוספת לסכימת המספור. סכימת החיוג הבין-אתרי החדשה והארוכה יותר צריכה להיות מאומצת רק על ידי משתמשים שכבר עברו ל- . משתמשים שעדיין מחוברים יכולים להמשיך לחייג שבע ספרות. תוכנית החיוג הארגונית במקרה זה צריכה לוודא שחיוג מקוצר בן שבע ספרות מ-Unified CM יהפוך לאחת מהאפשרויות הבאות: +E.164 או לפורמט החיוג המקוצר שנפרס ב- . יש לעשות זאת לפני שליחת הקריאה לשער המקומי.

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

טבלה 4. מעבר חיוג של שבע ספרות

אתר שלוחות קוד אתר טווח ארגוני אודה לאתר אנג' ארגוני

ניו יורק 2XXX 22 8 22 2XXX 822 8 822 2XXX

משרד עורכי דין 8XXX 23 8 23 7XXX 823 8 823 7XXX

RTP 1XXX 24 8 24 11XX 824 8 824 11XX

בתרחיש בו פועלים פורמטים שונים של מספרים ארגוניים, ואם מספרי ארגון מוצגים כפרטי צד מתקשר עבור שיחות מ- אל (לדוגמה - שיחות ממכשירים ללא DID), חשוב גם ליישם מיפוי בין פורמטי המספרים השונים עבור פרטי צד מתקשר כדי להבטיח שההתקשרות החוזרת תפעל. ניתן להשיג מיפוי זה באמצעות תבנית טרנספורמציה של צד קורא (calling party) על גבי ה-trunk בין ה-Local Gateway.

הקלטה

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

1. בחירת ספק הקלטת שיחות

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

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

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

דרישות עסקיות: בחירת הספק צריכה להתבסס על הערכת גורמים עסקיים כגון תאימות רגולטורית (דוגמה - MiFID II, HIPAA), אבטחת איכות, יישוב סכסוכים או צורכי הכשרה.

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

2. בחירת אזור

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

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

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

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

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

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

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

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

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

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

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

שיחות חירום

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

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

על כל הלקוחות לפרוס, לכל הפחות, את תצורת שיחות החירום הבסיסית. שיחות חירום בסיסיות דורשות שלפחות לקוח אחד בבעלותו +E.164 מספר שיוקצה לכל מיקום המוגדר ב- . עבור שיחות חירום בסיסיות, כל מיקום יוגדר על ידי כתובת רחוב שאליה נשלחו שירותי משטרה, כיבוי אש או אמבולנס במקרה חירום. ברוב המקרים, המספר הראשי של המיקום הוא הבחירה הטובה ביותר לייצוג המיקום הפיזי של מקרה החירום. בדרך כלל, הקצאת הכתובת ל- +E.164 המספר מתואם עם ספק ה-PSTN. התמונות למטה מציגות את הקצאת המספר הראשי שישמש כמספר חירום חוזר עבור מיקום ריצ'רדסון.

תצורת ECBN של מיקום

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

תצורת ECBN של המשתמש

עבור פריסות טלפוניה בארה"ב שחייבות לספק פתרונות משופרים לשיחות חירום, נעשה שימוש ב-Horizon Mobility של RedSky המשולב בניתוב שיחות חירום. בעת שימוש ב-RedSky לניתוב שיחות, מנהל מערכת חייב להירשם לחשבון דרך Cisco ולהגדיר את המידע המתאים ב- שיחות -> הגדרות שירות כדי להפעיל תכונה זו. לאחר ששירות RedSky הופעל ברמת המערכת, מנהל מערכת יפעיל את שירות RedSky בכל רמת מיקום. הפעלת שירות שיחות חירום משופר במיקום תפעיל את השירות עבור כל המכשירים שהוקצו למיקום זה. מכשירים התומכים בשיחות חירום משופרות הם טלפוני Cisco MPP, טלפוני Cisco PhoneOS ו- Cisco .

ישנן שתי הגדרות להפעלת שיחות חירום משופרות במיקום מסוים. יש להשתמש באפשרות אפשר ל-RedSky לקבל מידע על קישוריות רשת וקריאות בדיקה כדי לוודא שתצורת RedSky עבור מיפויי המכשיר והתשתית נכונה. הגדרה זו מאפשרת גם לבצע שיחות ניסיון למוקד 933 כדי לבצע אימות מיקום באמצעות מערכת ה-IVR של RedSky כדי לקרוא את מיקום המתקשר. למרות שמסמך זה לא יכסה את תצורת RedSky למעקב מיקום, מנהל מערכת צריך תמיד לבדוק את גילוי המיקום שלו לפני הפעלת שיחות חירום לניתוב ל-RedSky. לאחר השלמת הבדיקה ואימות מדויקותה, מנהל המערכת ינתב שיחות ל-RedSky על ידי החלפת ניתוב שיחות חירום ל-RedSky. כפתור זה יפנה את כל שיחות החירום עבור המיקום ל-RedSky לצורך העברה למרכז המשיבון של המיקום.

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

רישוי

ישנן מספר אפשרויות להקצאת רישיונות למשתמשים.

הקצאה ידנית דרך

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

מנהלי מערכת יכולים לערוך רישיונות שירות עבור משתמשים בודדים ולהקצות רישיונות שיחות ישירות.

תבניות הקצאת רישיונות אוטומטיות

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

רישוי אוטומטי יכול להתבצע באמצעות סנכרון ספריות או עדכוני משתמשים ידניים, אך על המשתמשים להיות בעלי רישיון תקף. +E.164 מספר טלפון מעוצב ומספרי הטלפון חייבים להתקיים במיקום לפני הקצאת משתמשים. אם התנאים לא מתקיימים (למשל, פורמט מספר טלפון לא תקין), לא יוקצו רישיונות.

הקצאה בכמות גדולה באמצעות תבנית CSV

העלה קובץ CSV עם פרטי משתמש והקצאות רישיונות כדי להוסיף או לשנות מספר משתמשים בו זמנית.

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

הקצאה מבוססת API

השתמשו בממשקי API כדי להקצות רישיונות באופן תכנותי ולנהל משתמשים.

תומך בפעולות API לניהול משתמשים ורישיונות (People, SCIM 2.0 ו-API של רישיונות), אשר ניתן למנף לאוטומציה של הקצאת רישיונות. ממשק ה-API של הרישיונות מאפשר הקצאה בו-זמנית של רישיונות, מספרי טלפון ושלוחות.
טבלה 5. אפשרויות הקצאת משתמשים - סיכום
שיטת הקצאה יתרונות חסרונות
ידני דרך פשוט עבור מעט משתמשים.
מאפשר שליטה מדויקת ומפורטת על הקצאת רישיונות.
לא ניתן להרחבה, גוזל זמן
מועד לטעויות אנוש במהלך הזנה ידנית.

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

העלאה בכמות גדולה של CSV יעיל עבור קבוצות משתמשים גדולות
מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ושלוחות.
דורש עיצוב CSV מדויק
אפשרות לשגיאות אם מספרי טלפון או שלוחות חסרים או שגויים.
הקצאה מבוססת API אוטומטי, גמיש.
מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ושלוחות.
דורש ידע בפיתוח וב-API.

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

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

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

למידע נוסף, ראו הגדרת הקצאות רישיונות אוטומטיות ב-Control Hub ו- הגדרת תבניות הקצאת רישיונות אוטומטיות עבור משתמשי Webex Calling.

דרישות רישיון

סעיף זה מכסה רק רישיונות קשורים. סוגי רישיונות אחרים (לדוגמה - רישום מכשירי Webex, העברת הודעות, פגישות) אינם מכוסים. כחלק מתהליך התכנון יש לקבוע את דרישות הרישיון. יש לחשב את ספירת הרישיונות עבור סוגי הרישיונות הבאים:

סטנדרטי: מספר המשתמשים הבודדים הזקוקים לתכונות טלפוניה סטנדרטיות.

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

סביבת עבודה לאזור משותף: מספר מיקומים לשימוש משותף או אזורים משותפים הדורשים יכולות שיחות סטנדרטיות.

סיוע ללקוחות: מספר סוכנים ומפקחים הזקוקים לתכונות של סיוע ללקוח. סיוע הלקוחות כולל את הרישיון המקצועי.

קריאות רשימת מסלולים: מספר שיחות PSTN מחוברות לענן נדרשות בין משתמשים מקומיים and/or יישומים ייעודיים של צד שלישי מקומי.

מסוף מטפל: מספר המשתמשים הזקוקים לגישה ללקוח מסוף ה-Attendent.

תוכנית שיחות של סיסקו (תוכנית שיחות יוצאות): מספר המשתמשים הזקוקים למספר PSTN and/or גישה לשיחות PSTN יוצאות עבור שירות Cisco PSTN.

אין סוג רישיון ייעודי עבור סביבות עבודה מקצועיות. סביבות עבודה מקצועיות צורכות רישיון מקצועי.

מרחבי עבודה של שירות Hot desk בלבד מציעים את שירות מארח Hot desking ושיחות חירום ממארח Hot desk ואינם דורשים רישיון. למידע נוסף, ראו הוספה וניהול של התקני Hot Desk בלבד.

כדי לקבוע את סוג הרישיון הנדרש עבור כל משתמש וסביבת עבודה בהתבסס על התכונות הנדרשות, ראה תכונות זמינות לפי סוג רישיון עבור Webex Calling.

כדי להבדיל בין הפונקציונליות המוצעת על ידי תורי שיחות בשילוב עם הרישיון המקצועי לבין סיוע ללקוחות, ראה השוואה בין תכונות תור שיחות וסיוע ללקוחות של Webex Calling.

הקצאת משתמשים

בעת הקמת משתמשים ב-Webex, קיימות מספר אפשרויות זמינות, כל אחת מתאימה לצרכים ולסביבות ארגוניות שונות:

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

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

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

אפליקציית אשף Entra ID (Azure AD): שיטה זו, המיועדת לארגונים המשתמשים ב-Microsoft Entra ID ‏(Azure AD), מספקת סנכרון אוטומטי, כמעט בזמן אמת, של חשבונות משתמשים ומאפיינים ישירות מ-Entra ID אל . הוא מנוהל במלואו מבפנים ודורש הגדרה מינימלית.

יישומי SCIM 2.0: עבור סביבות שאינן של מיקרוסופט או ספקי זהויות אחרים כמו Okta או Duo, אפליקציות סנכרון מבוססות SCIM מאפשרות הקצאת משתמשים וביטול הקצאת משאבים אוטומטית באמצעות מיפוי תכונות וסנכרון קבוצות.

סנכרון משתמשי CM מאוחד: אפשרות זו מאפשרת יצירת חשבונות משתמש על סמך משתמשי קצה קיימים על ידי סנכרון מ- אל . זה דורש ש-Cloud Connected UC ‏(CCUC) יפעל באשכולות המקומיים. עם זאת, בדרך כלל מומלץ לסנכרן משתמשים מספריית ענן מרכזית כמו Entra ID ולא ישירות מ-.

הקצאת API: ניתן להשתמש בממשקי API ציבוריים (People, SCIM 2.0) להקצאת משתמשים. היתרון העיקרי של שימוש בממשקי API הוא האפשרות לשלב את הקצאת המשתמשים עם מערכות ארגוניות אחרות.
טבלה 6. אפשרויות הקצאת משתמשים עבור
שיטת הקצאה תיאור יתרונות חסרונות
ידני Create/manage משתמשים באופן פרטני ב פשוט עבור מעט משתמשים; אין צורך בתשתית לא ניתן להרחבה; גוזל זמן עבור משתמשים רבים
בכמות גדולה (קובץ CSV) Import/update משתמשים בכמות גדולה באמצעות CSV ב יעיל לקבוצות; אין צורך בקידוד הכנה ידנית של CSV; פחות דינמי
אנשים ו-SCIM 2.0 API ניהול משתמשים פרוגרמטי באמצעות ממשקי API של Webex גמיש; תומך באוטומציה ובאינטגרציה דורש פיתוח ותשתיות
סנכרון ספר טלפונים סנכרון אוטומטי מ-AD, Entra ID, אפליקציות SCIM ו-Unified CM אוטומציה של מחזור החיים; תומכת בסינון ומיפוי מורכבות ההתקנה: לחלק מהאפשרויות יש תכונות מוגבלות או דורשות תשתית
סקירה כללית וטבלה זו משקפות את אפשרויות הקצאת המשתתפים העיקריות, את היתרונות והמגבלות שלהן כדי לעזור לך לבחור את הגישה הטובה ביותר לצורכי הארגון שלך.

קבוצות משתמשים

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

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

ניהול פשוט: ניהול רישיונות, הגדרות ומדיניות עבור משתמשים מרובים בו זמנית.

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

מדרגיות: תומך בעד 250,000 חברים בכל קבוצה.

אינטגרציה: סנכרן קבוצות מ-Microsoft Entra ID ‏(Azure AD) או מ-Active Directory לניהול אוטומטי של משתמשים וקבוצות.

גמישות: צור קבוצות מקומיות או סנכרן קבוצות אבטחה; נהל את החברות בקבוצה באופן ידני או באמצעות קבצי CSV.

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

מקרי השימוש העיקריים עבור קבוצות משתמשים בעת הקצאת משאבים הם:

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

תבניות הגדרות: החל אוספים של הגדרות שירות (למשל, העברת הודעות, פגישה, שיחות) על קבוצות לקבלת חוויית משתמש עקבית.

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

אוטומציה ואינטגרציה: השתמשו בממשקי API או בסנכרון ספריות לניהול אוטומטי של מחזור חיי משתמשים וקבוצות.

הטבלה הבאה מסכמת את האפשרויות השונות לניהול קבוצות משתמשים וניהול קבוצות ב- .
טבלה 7. אפשרויות לניהול קבוצות וחברות בקבוצות
אפשרות תיאור יתרונות חסרונות

הקצאת קבוצות (קבוצות) צור ונהל קבוצות ישירות ב-. Add/remove חברים באופן ידני או באמצעות CSV. שליטה מלאה על חברות בקבוצה
יישום מיידי של רישיונות ותבניות
קל ליצור ולערוך קבוצות נדרשים עדכונים ידניים
סיכון לשגיאות בהעלאות ידניות של קבצי CSV
אין סנכרון אוטומטי עם ספריות חיצוניות

קבוצות מסונכרנות מ-Entra ID (Azure AD) או מ-Active Directory סנכרן אוטומטית קבוצות אבטחה וחברויות משירותי ספריות חיצוניים. סנכרון אוטומטי מפחית עבודה ידנית
מבטיח עקביות עם מדריך החברות
תומך בארגונים גדולים
לא ניתן לערוך את חברות הקבוצה ב
עיכוב סנכרון עד 12 שעות
קבוצות מקוננות דורשות בחירה ידנית

קבוצות ו-SCIM 2.0 API (קבוצות) השתמש ב-Groups או ב-SCIM 2.0 API לניהול קבוצות פרוגרמטיות וחברות אוטומציה ואינטגרציה עם מערכות אחרות
ניתן להרחבה עבור סביבות גדולות או מורכבות
דורש מאמץ פיתוח
המורכבות תלויה בשימוש ב-API

בעוד שקבוצות מסונכרנות מבטיחות עקביות ומציעות נקודת ניהול אחת, גישה היברידית המשלבת קבוצות מסונכרנות וקבוצות (המנוהלות במרכז הבקרה או באמצעות ממשקי API) אפשרית. לדוגמה, קבוצות להקצאת רישיונות יכולות להיות קבוצות מסונכרנות, וקבוצה נפרדת של קבוצות יכולה לשמש להקצאת תבניות משתמשים וקריאות.

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

גישה מומלצת בעת מעבר מ- אל

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

סיסקו ממליצה להשתמש בספריית ענן מרכזית כגון Microsoft Entra ID ‏(Azure AD) כמקור האמת היחיד עבור זהויות משתמשים. סנכרון משתמשים מ-Entra ID מבטיח עקביות, מפשט את הניהול ותומך ביכולות כניסה יחידה (SSO).

כדי להבטיח שכל המשתמשים ב-Entra ID נוכחים גם ב-Entra ID, ארגונים צריכים לוודא שחשבונות המשתמשים תואמים לחשבונות ב-Entra ID. ניתן לעשות זאת על ידי ייצוא רשימות משתמשים והשוואתן לרשימות משתמשים של Entra ID.

לסיכום, שיטת הקצאת המשאבים המומלצת היא לסנכרן משתמשים מ-Microsoft Entra ID (Azure AD) ל-Webex באמצעות אשף Azure AD או אפליקציות SCIM. הקצאה ידנית ו-CSV בכמות גדולה זמינות כשיטות משלימות, אך הן פחות ניתנות להרחבה ומועדות יותר לשגיאות עבור ארגונים גדולים. הבטחה ש-Entra ID הוא המקור הסמכותי ושכל המשתמשים קיימים ב-Entra ID היא קריטית להצלחת הגירה וחוויית משתמש עקבית בין סביבות שונות.

מעבר משירות ספריות מקומי, כמו Active Directory, לשירות ספריות ענן, כמו Entra ID ‏(Azure ID), אינו תלוי במעבר הקריאה. סיסקו ממליצה לסיים את המעבר לשירות ספריות ענן לפני תחילת המעבר לקריאה.

עיצוב קבוצות משתמשים

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

שם קבוצה שם ייחודי של הקבוצה.

רישיונות: רישיונות להקצאה לקבוצה זו (אם ישנם) והיקף (האם יש להקצות רישיונות למשתמשים קיימים או רק למשתמשים חדשים)

תבניות הגדרות: תבניות שיחות של אפליקציית Webex ומשתמשים.

סנכרון ספריות: האם קבוצה זו תסונכרן מספריית הארגון או שזו קבוצת Webex מקומית המוקצית במרכז הבקרה או דרך API.

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

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

כניסה יחידה (SSO)

סיסקו ממליצה להשתמש ב-SSO לאימות משתמשים. לשימוש ב-SSO יש כמה יתרונות משכנעים, כולל:

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

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

אבטחה משופרת: SSO מפחית את עייפות הסיסמאות ואת הסיכון לפריצות הקשורות לסיסמאות על ידי ריכוז האימות באמצעות ספקי זהויות מהימנים (IdPs).

שילוב קל של אימות רב-גורמי (MFA): ניתן לתמוך בקלות ב-MFA באמצעות פתרון ניהול גישה לאיתויות כמו Cisco Duo או באמצעות תמיכה ב-MFA של ה-IdP.

ישנן מספר אפשרויות ליישום SSO עבור שירותים:

SSO מבוסס SAML 2.0: הפרוטוקול העיקרי הנתמך לשילוב SSO, המאפשר חילופי מידע מאובטחים בין ספק ה-IdP לספק השירות.

חיבור OpenID (OIDC): נתמך כפרוטוקול אימות מודרני חלופי לשילוב SSO.

זהות Webex: נתמך גם כאפשרות של ספק זהויות.

SSO מוגדר ומנוהל באופן מרכזי דרך , מה שמחייב חילופי מטא-דאטה בין לבין ה-IdP שנבחר.

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

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

סיסקו דואו

Okta

שירותי הפדרציה של Microsoft Active Directory (ADFS)

Microsoft Azure

PingFederate

OpenAM

F5 IP גדול.

ספקי IdP אלה תואמים לתקני SAML 2.0 או OpenID Connect ואומתו לתאימות עם פתרונות שיתוף פעולה של סיסקו.

תמיכה במספר IdP

מאפשר לארגונים להגדיר SSO עם מספר ספקי IdP כדי להתאים לסביבות IT מורכבות כגון מיזוגים, רכישות או מחלקות IT מבוזרות שבהן קבוצות שונות משתמשות ב-IdPs שונים. ניתן ליישם תמיכה ב-IdP מרובים באמצעות התכונה 'IdP מרובים' בתוך מערכת IAM ארגונית כמו Cisco Duo או באמצעות שילוב שלה.

התמיכה בספקי זהויות מרובים (IdP) של מטפלת במספר מקרי שימוש מרכזיים שבהם ארגונים דורשים אימות גמיש ומאובטח בסביבות IT מגוונות:

1. מיזוגים ורכישות

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

2. מספר מחלקות IT עצמאיות

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

3. קבוצות משתמשים או דומיינים שונים

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

4. תמיכה בפרוטוקולי אימות שונים

תומך בספקי IdP של SAML ו-OpenID Connect (OIDC), המאפשרים לארגונים לשלב סוגים שונים של ספקי זהויות בהתאם לתשתית הקיימת ולדרישות האבטחה שלהם.

5. אבטחה ותאימות משופרים

על ידי הפעלת מספר IdPs, ארגונים יכולים ליישם מנגנוני אימות חזקים יותר, כולל אימות רב-גורמי (MFA) באמצעות אינטגרציות כמו Duo, ולאכוף מדיניות אבטחה עקבית על פני בסיסי משתמשים מגוונים.

6. חוויית משתמש פשוטה יותר

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

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

Duo MFA עם SSO עבור

Duo Access Gateway (DAG) יכול לאמת משתמשים באמצעות ספריות קיימות מקומיות או מבוססות ענן כגון Active Directory (AD) ו-OpenLDAP. הוא תומך גם באינטגרציה עם ספקי זהויות אחרים כמו Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS ו-Shibboleth. גמישות זו מאפשרת לארגונים להשתמש בתשתית הספריות הנוכחית שלהם עבור Webex SSO עם Duo MFA.

Duo פועל כשכבת אימות חזקה מעל אימות הספרייה הראשית. הוא מתפקד כספק זהויות (IdP) המשתמש ב-SAML 2.0 כדי לאכוף אימות דו-שלבי (2FA) לפני מתן גישה ל-. Duo מעריך את הקשר המשתמש, המכשיר והרשת מול מדיניות ניתנת להגדרה כדי לאפשר או לדחות גישה, ומשפר את האבטחה מעבר לשם משתמש וסיסמה בלבד. Duo מספק גם בקרות מדיניות גמישות, כגון דרישה ל-MFA בכל כניסה עבור אפליקציות מסוימות ופחות בתדירות עבור אחרות.

יתרונות סיסקו דואו כוללים:

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

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

אינטגרציה עם ספריות קיימות: תומך ב-AD מקומי, OpenLDAP, ספריות ענן וספקי SSO שונים, וממזער שינויים בתשתית.

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

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

הרשמה בשירות עצמי: הרשמה מובנית והנחיית דואו משפרות את חוויית המשתמש במהלך הגדרת MFA.

Duo MFA עם SSO ממנפת ספריות קיימות כמו Active Directory ו-OpenLDAP, או ספקי זהויות ענן, לאימות משתמשים. תפקידה של Duo הוא לספק גורם אימות שני חזק, מונחה מדיניות, המשולב באמצעות SAML 2.0, לשפר את האבטחה תוך שמירה על נוחות המשתמש באמצעות SSO. היתרונות כוללים שיפור במצב האבטחה, אכיפת מדיניות גמישה, אינטגרציה חלקה וחוויית משתמש טובה יותר.

סיסקו ממליצה ליישם SSO עבור משתמשים. לשיפור האבטחה, מומלץ להשתמש בשילוב עם Cisco Duo.

יש לפרוס את אסטרטגיית ה-IAM וה-SSO הארגוניים לפני תחילת המעבר מ- ל-.

תכונות

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

תכונות ברמה ארגונית של Webex Calling

בנוסף לתכונות המשתמש הרבות, יש תכונות מערכת ליבה הכלולות בפלטפורמה. אלה כוללים תכונות כמו שיחות אוטומטיות, תורי שיחות, חניית שיחות וכו'. ניתן לראות את כל תכונות הליבה הזמינות של המערכת תחת שירות → שיחות → תכונות כפי שמוצג באיור תכונות ליבה של Webex Calling.

תכונות ליבה של Webex Calling

ניתוב אוטומטי

מערכת השיפוט האוטומטית מאפשרת 24/7 אוטומציה של טיפול בשיחות נכנסות, המאפשרת טיפול יעיל בשיחות ללא צורך במענה לכל שיחה.

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

מערכת הניתוב האוטומטית תומכת בתכונות המרכזיות הבאות:

לוחות זמנים עסקיים ושעות לאחר שעות הפעילות

לוח חופשות

אפשרות תפריט חיוג כדי לכוון את הלקוחות שלך ליעד שאליו הם צריכים להגיע

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

אפשרות חיוג לפי שם

אפשרויות העברת שיחות

ניתוחים ודוחות של Control Hub.

למידע נוסף, ראו ניהול שירותי ניתוב אוטומטיים.

חניית שיחות

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

ישנם שני סוגים של חניות שיחות זמינים ב :

חניית שיחה ישירה - מאפשר לכל משתמש לחנות שיחה לשלוחה של משתמש אחר או לשלוחה של חניית שיחה, כפי שהוגדר על ידי המנהל.

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

בהתבסס על התצורה וסוג החניה, משתמשים יכולים לאחזר שיחות על ידי חיוג *88+><extension of parked call>, לחיצה על מקש הקו המשויך לשלוחת חניית השיחות או שימוש במקש בחירה בטלפון ה-IP שלהם.

קיימת אפשרות אחזור להחזרת שיחה חונה לאחר פרק זמן מוגדר למשתמש שחנה את השיחה או למשתמש חלופי.

למידע נוסף, ראה ניהול חניית שיחות ב-Control Hub.

מענה לשיחות

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

המשתמשים בקבוצה חייבים להיות באותו מיקום.

משתמשים יכולים להשתמש ב- או בטלפון השולחני שלהם כדי לענות שיחה.

:

תומך בהתראות חזותיות וקוליות

הודעה על שיחה נכנסת

מבוסס FAC (חיוג *98) או התראות טוסט לקבלת שיחות

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

טלפונים שולחניים:

הודעה על שיחה נכנסת

צלצולי שמע והתראה חזותית דרך נורית ה-LED של השלט. ה-6821 תומך רק בצלצולי שמע

כאשר סוג ההתראה שנבחר אינו ללא

התראות על מענה שיחה רק לקווים ראשיים.

למידע נוסף, ראה הגדרת קבוצת מענה שיחות.

תור שיחות

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

הקריאה של סיסקו לשילוב עם Microsoft Teams מאפשרת לסוכנים גישה לשיחות ותכונות בתור השיחות ישירות מלקוח Microsoft Teams שלהם.

תורי שיחות תומכים בתכונות המרכזיות הבאות:

ברכות והודעות (ברוכים הבאים, ניחומים, לחישה וכו')

החזק מוזיקה

שיחה חוזרת

מדיניות ניתוב תורים (שירות לילה, חגים, העברה)

תור הסוכנים login/logout

ניהול סטטוס תור הסוכנים

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

ניטור שיחות של סוכן מפקח, אימון, פריצה או השתלטות באמצעות קודי גישה לתכונות (FACs)

(גישת מנהל) עבור:

ניהול תורים

ניתוח ודיווח של סוכנים ותורים

ניהול תור, סוכן ומפקח.

למידע נוסף, ראה הגדרת תור שיחות.

כולל תכונת תוסף של סיוע ללקוח המספקת יכולות תור שיחות נוספות ומעניקה לסוכנים ולמנהלים חוויית משתמש טובה יותר בתוך . להשוואה בין תכונות תור השיחות וסיוע ללקוחות, ראה השוואה בין תכונות תור השיחות וסיוע ללקוחות של Webex Calling.

קבוצת גישוש

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

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

למידע נוסף, ראה ניהול קבוצות ציד ב-Control Hub.

מצבי הפעלה

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

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

משתמש מורשה יכול לעבור בין תרחישי (מצבים) שונים של העברת שיחות אם עליו לשנות את מיקום ניתוב השיחות הנכנסות למשך פרק זמן מסוים. משתמשים אלה יכולים לנהל את המצבים באמצעותם 6800/7800/8800 טלפוני MPP, טלפוני 9800 או במרכז המשתמשים ב ניהול מצבים.

למידע נוסף, ראה ניתוב שיחות המבוסס על מצבי פעולה ב-Webex Calling.

קבוצת זימון

קבוצות זימון מאפשרות למשתמשים לבצע שיחה חד-כיוונית כדי לשלוח הודעת שמע לקבוצת משתמשים. כל קבוצה יכולה להכיל עד 75 משתמשי יעד and/or סביבות עבודה שאליהן מגיעים על ידי חיוג למספר או שלוחה מוגדרים מראש.

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

למידע נוסף, ראה הגדרת קבוצת החלפה ב-Control Hub.

הקלטות

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

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

למידע נוסף על תכונה זו ורשימה של הקלטות של צד שלישי, ראה ניהול הקלטת שיחות עבור Webex Calling.

טווח מספר יחיד

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

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

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

קבוצת דואר קולי

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

הודעה קולית כללית עבור מחלקה או קבוצת עבודה

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

כדי לשלוח שיחות גלישה מתור שיחות

משתמשים הזקוקים רק לתיבת תא קולי.

למידע נוסף, ראה ניהול דואר קולי ופקס נכנס משותף עבור Webex Calling.

מסוף ה-Attendant מופיע בדף תכונות השיחות ב-Webex, אולם זוהי תכונה נוספת הדורשת רכישת רישיון למסוף ה-Attendant כדי להשתמש בה.

למידע נוסף, ראה תחילת העבודה עם מסוף Attendant.

למידע על כל התכונות, כולל תכונות נוספות, ראה תכונות זמינות לפי סוג רישיון עבור Webex Calling.

טבלה 1. מידע שיש לאסוף עבור כל מיקום
מידע	הערה
טווח/י הרחבה	לכל מיקום יכולות להיות סיומות המתחילות בספרות שונות. יש להשאיר ספרה אחת עבור ספרת ההיגוי לחיוג בין-אתרי (לדוגמה 8) וספרה אחת עבור ספרת ההיגוי לחיוג PSTN (לדוגמה 9). אף טווח סיומת לא יכול להתחיל באחת משתי הספרות הללו. כל טווחי ההרחבה של כל המיקומים חייבים להיות באורך שווה.
טווח/י DID	-
ספרת היגוי PSTN	-
קוד האתר	כל קודי האתר של כל המיקומים צריכים להיות ייחודיים ובעלי אורך זהה.
מספר ראשי	בעת יצירת מיקום יש להקצות שני DIDs. אחד כמספר ראשי (לדוגמה, להקצאה לשירות מענה אוטומטי) ואחד עבור פורטל התא הקולי. הקצאת DID אחד עבור מספר התא הקולי.
מספר תא קולי
מספר רישיונות	רישיונות נדרשים לפי סוג כולל רגיל, מקצועי, סביבת עבודה, רשימת מסלולים, תוכנית שיחות יוצאות.
שיחות בו זמנית בשעות העמוסות	סכום השיחות המקבילות בין מכשירים ובין מכשירים לשער המקומי (PSTN ושיחות למכשירים). נדרש כדי לקבוע את רוחב הפס הנדרש לגישה לאינטרנט.
מדינה	-
אזור זמן	-
שפה	-
איש קשר (שם, טלפון, דוא"ל)	-
כתובת (כתובת רחוב, עיר, מדינה, מיקוד)	-
מיקום פיזי של שירותי חירום עבור נקודות קצה	מיקום שיגור המכשיר המשמש לשיחות חירום כולל בדרך כלל את הדברים הבאים: כתובת הבניין, כתובת הבניין + מספר קומה, כתובת הבניין + מספר סוויטה, או כתובת הבניין + מספר קומה + office/cubical מִספָּר.
מיקום רשת פיזי ייחודי לכל מכשיר עבור שירותי חירום	מיקום רשת פיזית עבור שיחות חירום כולל בדרך כלל את הדברים הבאים: מֶתֶג / יציאת מתג עבור התקנים קוויים, מזהי סט שירות בסיסי (BSSIDs) של נקודת גישה אלחוטית (AP) עבור התקנים המחוברים באופן אלחוטי, and/or רשתות משנה IP מקומיות עבור התקני קצה.

טבלה 2. דוגמה למספור ארגוני
אתר	טווח הרחבה	קוד האתר	טווח ארגוני
ניו יורק	2XXX	202	8 202 2XXX
משרד עורכי דין	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

טבלה 3. טווחי הארכה באורך קבוע
אתר	טווח הרחבה	שלוחות	קוד האתר	טווח ארגוני
ניו יורק	2XXX	2XXX	202	8 202 2XXX
משרד עורכי דין	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

טבלה 4. מעבר חיוג של שבע ספרות

אתר	שלוחות	קוד אתר	טווח ארגוני	אודה לאתר	אנג' ארגוני
ניו יורק	2XXX	22	8 22 2XXX	822	8 822 2XXX
משרד עורכי דין	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

טבלה 5. אפשרויות הקצאת משתמשים - סיכום
שיטת הקצאה	יתרונות	חסרונות
ידני דרך	פשוט עבור מעט משתמשים. מאפשר שליטה מדויקת ומפורטת על הקצאת רישיונות.	לא ניתן להרחבה, גוזל זמן מועד לטעויות אנוש במהלך הזנה ידנית.
תבניות רישיון אוטומטיות	ניתן להרחבה מפחית שגיאות ידניות ניתן ליישם על משתמשים חדשים וקיימים.	נדרשים מספרי טלפון ומיקומים תקינים. מורכב יותר להקמה דורש גם קבוצות משתמשים עבור קבוצת משתמשים עם דרישות רישוי מקבילות.
העלאה בכמות גדולה של CSV	יעיל עבור קבוצות משתמשים גדולות מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ושלוחות.	דורש עיצוב CSV מדויק אפשרות לשגיאות אם מספרי טלפון או שלוחות חסרים או שגויים.
הקצאה מבוססת API	אוטומטי, גמיש. מאפשר הקצאה בו זמנית של רישיונות, מספרי טלפון ושלוחות.	דורש ידע בפיתוח וב-API.

טבלה 6. אפשרויות הקצאת משתמשים עבור
שיטת הקצאה	תיאור	יתרונות	חסרונות
ידני	Create/manage משתמשים באופן פרטני ב	פשוט עבור מעט משתמשים; אין צורך בתשתית	לא ניתן להרחבה; גוזל זמן עבור משתמשים רבים
בכמות גדולה (קובץ CSV)	Import/update משתמשים בכמות גדולה באמצעות CSV ב	יעיל לקבוצות; אין צורך בקידוד	הכנה ידנית של CSV; פחות דינמי
אנשים ו-SCIM 2.0 API	ניהול משתמשים פרוגרמטי באמצעות ממשקי API של Webex	גמיש; תומך באוטומציה ובאינטגרציה	דורש פיתוח ותשתיות
סנכרון ספר טלפונים	סנכרון אוטומטי מ-AD, Entra ID, אפליקציות SCIM ו-Unified CM	אוטומציה של מחזור החיים; תומכת בסינון ומיפוי	מורכבות ההתקנה: לחלק מהאפשרויות יש תכונות מוגבלות או דורשות תשתית

טבלה 7. אפשרויות לניהול קבוצות וחברות בקבוצות
אפשרות	תיאור	יתרונות	חסרונות
הקצאת קבוצות (קבוצות)	צור ונהל קבוצות ישירות ב-. Add/remove חברים באופן ידני או באמצעות CSV.	שליטה מלאה על חברות בקבוצה יישום מיידי של רישיונות ותבניות קל ליצור ולערוך קבוצות	נדרשים עדכונים ידניים סיכון לשגיאות בהעלאות ידניות של קבצי CSV אין סנכרון אוטומטי עם ספריות חיצוניות
קבוצות מסונכרנות מ-Entra ID (Azure AD) או מ-Active Directory	סנכרן אוטומטית קבוצות אבטחה וחברויות משירותי ספריות חיצוניים.	סנכרון אוטומטי מפחית עבודה ידנית מבטיח עקביות עם מדריך החברות תומך בארגונים גדולים	לא ניתן לערוך את חברות הקבוצה ב עיכוב סנכרון עד 12 שעות קבוצות מקוננות דורשות בחירה ידנית
קבוצות ו-SCIM 2.0 API (קבוצות)	השתמש ב-Groups או ב-SCIM 2.0 API לניהול קבוצות פרוגרמטיות וחברות	אוטומציה ואינטגרציה עם מערכות אחרות ניתן להרחבה עבור סביבות גדולות או מורכבות	דורש מאמץ פיתוח המורכבות תלויה בשימוש ב-API

להטמיע

מוכנות הרשת

הגדרה ראשונית

אימות דומיין

תביעה (המרה) של משתמשים קיימים

הגדרה ובדיקה של סנכרון ספריות

הגדרה ובדיקה של כניסה יחידה (SSO)

רכישה, אספקה ואישור של רישיונות

הגדרות שירות Webex Calling

הגירת פיילוט

השגת PSTN

הגדרת מיקומים

שילוב עם בקרת שיחות מקומית

העברת משתמשים בקבוצות

סביבות עבודה

הקצאת מכשירים

הגדרת תכונות

בדיקת קבלה

מוכנות הרשת

הצעד הראשון במעבר הוא להבטיח קישוריות אינטרנט אמינה ומאובטחת בין הרשת המקומית לענן.

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

מנהלי רשת ואבטחה חייבים להבין את הזרימות הללו במונחים של:

כיוון (כניסה לעומת יציאה)

פרוטוקולים (דוגמה - SIP TLS, SRTP, HTTPS)

טווחי כתובות IP המשמשים שירותים

מספרי פורטיםשחייבים להיפתח או להתיר.

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

למידע על הזרימות הנדרשות, כולל כתובת IP, יציאות ופרוטוקולים, ראה מידע על יציאות עבור Webex Calling. השתמש במידע זה כדי להגדיר את חומת האש, שרתים פרוקסיים ותשתית רשת אחרת בפריסה הקיימת כדי לאפשר זרימות רשת.

פריצת אינטרנט מבוזרת מכל סניף או אתר היא הגישה המומלצת עבור שירותי שיתוף פעולה בענן כגון . על ידי מתן אפשרות לתנועה לצאת באופן מקומי, מודל זה:

מפחית עיכובים ורעידות הלוך ושוב, ומשפר את איכות השיחה הכוללת

מתרחב ביעילות ככל שיותר משתמשים ואתרים עוברים ל

עובד בצורה חלקה עם SD-WAN, שיכול לנתב באופן דינמי סשנים לנקודת הכניסה הקרובה ביותר לענן לקבלת ביצועים אופטימליים

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

בנוסף, על ארגונים להבטיח רוחב פס אינטרנט מספק בכל אתר. יש להתאים את גודל רוחב הפס למספר הצפוי של שיחות בו-זמניות, לקודק הנבחר (למשל, Opus או G.711), בתוספת תקורה עבור איתות, שידורים חוזרים וצמיחה. זה מתיישב עם שלב ההכנה של מחזור החיים של PPDIO ויוצר בסיס איתן למעבר.

הגדרה ראשונית

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

אימות דומיין

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

ודא שכל הדומיינים המשויכים לכתובות הדוא"ל של המשתמשים שלך מאומתים. אימות דומיין אינו בלעדי; ניתן לאמת את אותו דומיין על פני מספר ארגונים.

למידע נוסף על ניהול דומיינים, ראו ניהול הדומיינים שלכם.

תביעה (המרה) של משתמשים קיימים

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

למידע נוסף על תביעת משתמשים, ראה תביעת משתמשים לארגון שלך (המרת משתמשים).

הגדרה ובדיקה של סנכרון ספריות

כדי לאפשר ניהול חלק של משתמשים וקבוצות, באפשרותך לסנכרן משתמשים וקבוצות מספריית החברה שלך, בין אם באמצעות Microsoft Entra ID (לשעבר Azure AD) או Microsoft Active Directory (AD). תהליך זה מבטיח שזהויות משתמשים וחברות בקבוצות יישמרו באופן עקבי ברחבי הסביבה שלך.

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

השיטה היעילה ביותר לסינון אילו משתמשים מסונכרנים היא למנף חברות בקבוצת ספריות:

1
צור קבוצת סנכרון ייעודית: בספריית הארגון שלך (Microsoft Entra ID או AD), צור קבוצת אבטחה ספציפית לסינכרון (לדוגמה, קבוצת סינכרון).

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

3
הגדר את הסכם הסנכרון עם סינון מבוסס קבוצות: בעת הגדרת הסכם הסנכרון ב- Directory Connector או בהקצאת Entra ID, הגדר את ההיקף כך שיכלול רק משתמשים שהם חברים בקבוצה הייעודית.

עבור מזהה Microsoft Entra, ניתן להשתמש בהקצאות מבוססות קבוצות בהגדרות ההקצאה.

עבור AD, ניתן להגדיר מסנן LDAP כך שיכלול רק משתמשים השייכים לקבוצה שצוינה.

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

שלבי יישום לדוגמה:

במדריך האקטיבי:

צור קבוצת אבטחה בשם קבוצת סינכרון.

הוסף את משתמשי הפיילוט הרצויים לקבוצה זו.

הגדר מחבר ספריות עם מסנן LDAP כגון: (memberOf=CN=Webex סנכרון Group,OU=Groups,DC=yourdomain,DC=com).

במזהה הזנה של מיקרוסופט:

צור קבוצה בשם קבוצת סינכרון

הקצה את הקבוצה להגדרות הקצאת המשאבים של Entra ID

רק משתמשים בקבוצה זו יוקצו ל-.

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

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

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

הפניות:

סנכרון משתמשי Entra ID לתוך Control Hub

הגדר את אפליקציית אשף מזהה Entra במרכז הבקרה

מחבר ספרייה

הגדרה ובדיקה של כניסה יחידה (SSO)

כניסה יחידה (SSO) משפרת את האבטחה ומפשטת את גישת המשתמשים בכך שהיא מאפשרת למשתמשים לאמת פעם אחת עם אישורי החברה שלהם ולקבל גישה חלקה ל-. תומך בשילוב SSO עם ספקי IdP תואמי SAML 2.0, כולל Microsoft Entra ID (לשעבר Azure AD), פתרונות מאוחדים של Active Directory (AD) וספקי IdP שונים של צד שלישי.

בשלב זה יש ליישם ולבדוק את הגדרת ה-SSO שתוכננה.

הפניות:

שילוב כניסה יחידה במרכז הבקרה

הגדרת כניסה יחידה עבור ניהול WebEx

הגדרת כניסה יחידה עם מזהה Microsoft Entra

כניסה יחידה (SSO) עם מספר ספקי IdP

ניהול SSO בשילוב ב-Control Hub

רכישה, אספקה ואישור של רישיונות

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

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

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

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

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

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

הגדרות שירות Webex Calling

חיוני לבצע סקירה מקיפה ותצורה של הגדרות השירות הגלובליות בתוך .

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

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

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

הגירת פיילוט

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

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

המטרות העיקריות של פריסת פיילוט זו הן שתיים: ראשית, לאמת ולשפר את תהליכי המעבר מקצה לקצה, כולל זרימות עבודה להקצאת משתמשים, הליכי העברת נתונים ותצורות נקודות קצה; ושנית, לאמת באופן מקיף את הפונקציונליות של השירותים המועברים בתנאי תפעול אמיתיים.

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

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

השגת PSTN

כדי לרכוש שירותי PSTN עבור , תחילה בחר אפשרות קישוריות PSTN ב- .

אם ארגון מתכנן לשמור על בקרת שיחות כפולה היברידית ( שלב 1 באיור מעבר שיחות מדורג: היברידי וענן), בין אם באופן זמני או ללא הגבלת זמן, הם יצטרכו לפרוס שער מקומי אחד או יותר עבור PSTN מקומי כדי לאפשר שיחות בין נקודות קצה.

אם המטרה הסופית, כולל PSTN, היא מעבר מלא ( שלב 2) לענן, אזי עבור PSTN יידרש תוכנית שיחות של Cisco או אפשרות Cloud Connect.

עבוד עם הספק שבחרת כדי להזמין ולנייד מספרי טלפון לפני שתגדיר אותם ב-. הזמנת מספרי טלפון או ביצוע הזמנות העברה הן רק required/possible עבור PSTN מקומי ו-Cloud Connect עבור . עבור תוכניות שיחות של Cisco, ההזמנה והניידת מתבצעות מתוך Control Hub ברגע שהמיקום נוצר, ובמדינות בהן תוכנית שיחות של Cisco זמינה. למידע נוסף על תוכניות Cisco Calling, ראו תחילת העבודה עם תוכניות Cisco.

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

הגדרת מיקומים

לפני הוספת משתמשים ומכשירים ל- , עליך להקצות מיקומי שיחות. עבור כל מיקום, יש להזין כתובת רחוב תקפה. בארה"ב ובקנדה, כתובת זו מאומתת ומשמשת את הפלטפורמה לשליחת פרטי מיקום PIDF-LO עבור שיחות חירום.

בעת הגדרת מיקומים המשתמשים ב-PSTN מקומי, עליך להגדיר את השערים המקומיים בהתאם. ב- , יש ליצור קבוצת מסלולים (trunk) וקבוצת מסלולים עבור כל שער מקומי, ולאחר מכן קבוצת המסלולים מוקצית כבחירת PSTN עבור המיקום. סיסקו ממליצה בחום לבחור תמיד קבוצת מסלולים כבחירת PSTN, מכיוון שגישה זו מאפשרת לך להוסיף בקלות רשתות גז (Trunks) נוספות בעתיד, ותומכת הן במדרגיות והן ביתירות. סיסקו ממליצה גם להפעיל זהות כפולה ותמיכה ב-P-Charge-Info בכל רשת PSTN, מכיוון שזה מפשט את זיהוי הגורם לחיוב עבור שיחות ישירות או מופנות יוצאות. אם ספק שירותי ה-PSTN שלך משתמש בכותרת שונה לחיוב, תוכל להעתיק את המידע מכותרת P-Charge-Info בשער המקומי לכותרת החיוב הנדרשת.

עבור מיקומים המשתמשים ב-Cloud Connect או בתוכנית השיחות של Cisco כאפשרות PSTN שלהם, פשוט בחר את אפשרות ה-PSTN המתאימה למיקום במהלך ההגדרה. אם המיקום משתמש ב-Cloud Connect עבור שירות PSTN או ברשת PSTN מקומית, תצטרכו להוסיף את מספרי הטלפון שהוזמנו בשלב הקודם. ניתן להוסיף מספרים כלא פעילים אם אינך מעוניין שהם ייכללו בניתוב השיחות באופן מיידי; תוכל להפעיל מספרים אלה מאוחר יותר כאשר הם יוקצו למשתמשים או לתכונות.

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

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

שילוב עם בקרת שיחות מקומית

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

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

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

העברת משתמשים בקבוצות

בעת העברת משתמשים מ- אל, ייתכן שלא תוכל להעביר את כל המשתמשים בו זמנית. זה יכול לנבוע ממספר סיבות, כולל אך לא רק מספר האתרים או המשתמשים, כמה זמן לוקח להעביר אתר and/or קבוצת משתמשים בו זמנית, משאבי IT או אתר מוגבלים לתמיכה בחלון השינויים, משך חלון השינוי, מורכבות השינוי וכו'.

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

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

ניטור משתמשים אחרים באמצעות BLFs

באותו פיילוט ציד, תור שיחות וכו'

קווים משותפים

שימוש במתן שיחה

שימוש באותם מספרי חניית שיחות

אינטרקום

Executive/Admin.

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

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

השתמש בפלט מכלי Migration Insights או מכלי צד שלישי בו השתמשת בשלב ה- prepare כדי לקבוע אילו משתמשים ותכונות יש לקבץ יחד. פלט זה היה אמור לשמש לפיתוח תוכנית ההגירה שלך והוא ייתן לך תובנות לגבי האופן שבו תקבץ משתמשים ותכונות שצריכים לעבור יחד.

השלבים המרכזיים בעת העברת קבוצת משתמשים הם:

זיהוי משתמשים להעברה משותפת

ודא שכל המשתמשים נמצאים

ודא שכל ה-TNs עבור המשתמשים קיימים ב

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

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

אימות או הגדרה של כל שירותי ותכונות השיחות עבור קבוצת המשתמשים (לפני או במהלך המעבר, לפי הצורך)

בספריית החברה הוספת משתמשים לקבוצת משתמשים התומכים בשיחות

כלי מינוף - כלי הגירת משתמשים ותכונות and/or כלים של צד שלישי

Disable/Delete user/device מספר טלפון ושיחות features/services לאחר המעבר.

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

סביבות עבודה

ב- , סביבת עבודה מתייחסת למיקום משותף (כגון חדר ישיבות, מרחב נצמד או שולחן עבודה חם) שניתן להקצות לו מכשירים, שלוחות ומשתמשים. בניגוד לטלפונים מסורתיים של Unifed CM, סביבות העבודה הן:

ממוקד מיקום: קשורים למרחבים פיזיים.

גמישות במכשיר: יכול להכיל מכשיר אחד או יותר (טלפונים שולחניים, לוחות וכו').

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

למידע נוסף על סביבות עבודה ב- , ראו סביבות עבודה.

הקצאת מכשירים

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

כל טלפון נתמך שעליך לעבור ממנו יהיה צורך להגדיר אותו כמשתמש או כסביבת עבודה, ויהיה צורך להגדיר מחדש את הטלפון הפיזי כדי להירשם אל . בנוסף, יש לשדרג את הקושחה של טלפוני סדרת 7800 ו-8800 מקושחה ארגונית לקושחה של טלפון רב-פלטפורמתי (MPP). תהליך זה כולל טעינת קושחת מעבר לפני טעינת קושחת MPP הנדרשת לרישום. זה דורש גם את רישיון ההגירה המתאים. סיסקו שיפרה תהליך זה במהלך השנים האחרונות כדי להקל עליכם לשדרג את טלפוני הקושחה הארגוניים שלכם לקושחת MPP. למידע נוסף על השלבים להשלמת שדרוג הקושחה, ראה המרת טלפוני IP מסדרות Cisco 7800 ו-8800 בין קושחת Enterprise לקושחת MPP.

בנוסף לשלבים המפורטים במאמר זה, קיים כלי מובנה, העבר את הטלפון שלך ל-Webex Calling, בו תוכל להשתמש כדי לסייע בהעברת הטלפונים שלך מדגם 7800 ו-8800 מקושחת Enterprise לקושחת MPP. כלי זה מאפשר לך גם להוסיף את הטלפונים ולהקצות אותם למשתמשים או לסביבות העבודה המתאימים. למידע נוסף על השימוש בכלים, ראה העברת הטלפון שלך.

עבור כל טלפון מסדרת 9800 הרשומים עם דרישת העברת הקושחה הנ"ל אינה חלה. טלפונים אלה מריצים את PhoneOS, הנתמך על ידי גם ו- . כדי להעביר את הטלפונים האלה, תצטרך להוסיף אותם ל-Webex Calling, להקצות אותם למשתמש או לסביבת עבודה ולאחר מכן לאפס את הטלפונים להגדרות היצרן. רצף אתחול של PhoneOS לרישום האיור למטה מציג את רצף האתחול של PhoneOS וכיצד הטלפון יירשם לאחר הוספתו ל- , גם אם הטלפון עדיין מופעל and/or אפשרויות DHCP (דוגמה - 150) נמצאות בשימוש.

רצף אתחול של PhoneOS לרישום

תומך באיפוס להגדרות היצרן של מכשירי PhoneOS כדי לאפשר הטמעה ללא מגע. מנהלי מערכת יכולים לאפס מרחוק את הטלפונים 9800 ו-8875 להגדרות היצרן דרך דפי ניהול CUCM, מה שמבטל את הצורך בגישה פיזית לטלפונים כדי להטמיע אותם ב-. תכונה זו נתמכת עם חבילות המכשיר החל מ-9 בספטמבר 2025:

CUCM גרסה 15 - מנהל תקשורת מאוחד גרסה 15

CUCM גרסה 14 - מנהל תקשורת מאוחד גרסה 14.

למידע נוסף על תהליך הרישום עבור סדרת 9800, ראו תהליך רישום.

בנוסף לטלפוני ה-IP של סיסקו, ייתכן שיידרש הקצאת התקנים אחרים כגון מתאמי טלפון אנלוגיים (ATA), טלפונים אלחוטיים (Wifi, DECT), התקני וידאו, שערי קול, והתקנים וטלפונים של^צד שלישי . לרבים מהמכשירים הללו אין נתיב שדרוג קושחה כמו לטלפוני IP כדי להעביר אותם מקושחה ארגונית לקושחה בענן. לכן, תקצה כל אחד מהמכשירים הללו במרכז הבקרה. חלק מאלה לא ניתנים למעבר ויהיה צורך להחליף אותם במודל המקביל (למשל ATA 191/192) ואחרים ידרשו הגדרה מחדש ידנית and/or שינויי תוכנה.

שערי קול - כדי להעביר את השער המקומי שלך, ראה העברת שער מקומי.
למידע נוסף על הגדרת שער הקול VG400, VG410 או VG420 ב-Control Hub, ראה שער מקומי

מתאם טלפון אנלוגי (ATA) - כדי להתחיל עם Cisco ATA 191 ו-192, ראה Cisco ATA.

טלפון אלחוטי Wifi - כדי לשלב את הטלפונים האלחוטיים 840 ו-860, ראה שילוב טלפון אלחוטי Webex.

טלפונים אלחוטיים DECT - כדי להתחיל להשתמש בסדרת Cisco IP DECT 6800 החדשה שלך, ראה Cisco IP DECT.

כדי לבנות ולנהל רשת DECT דיגיטלית ב-Control Hub, ראה ניהול רשת DECT

למידע נוסף על Cisco IP DECT 6800, ראו מדריך פריסה

מכשירים וטלפונים של^{צדשלישי} - עבודה עם ספקי צד^שלישי ב device/phone דרישות והתהליך להגירתן או להחלפתן לתמיכה.

הגדרת תכונות

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

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

מערכות שיחות אוטומטיות - לניהול מערכות שיחות אוטומטיות, ראה מערכות שיחות אוטומטיות

חניית שיחות - כדי לנהל חניית שיחות, ראה חניית שיחות

מענה לשיחות - כדי להגדיר קבוצת מענה לשיחות, ראה מענה לשיחות

תור שיחות - כדי להגדיר את תור השיחות, ראה תור שיחות

קבוצות ציד - לניהול קבוצות ציד, ראה ניהול קבוצת ציד

מצבי הפעלה - לניתוב שיחות המבוסס על מצבי הפעלה, ראה ניתוב שיחות המבוסס על מצבי הפעלה

קבוצות דיוור - כדי להגדיר קבוצת דיוור, ראה הגדרת קבוצת דיוור

הקלטות - כדי לנהל הקלטת שיחות עבור , ראה ניהול הקלטות

גישה למספר יחיד - כדי להגדיר גישה למספר יחיד (בכל מקום במשרד), ראה הגדרת מספר יחיד

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

בדיקת קבלה

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

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

הקצאת משתמשים והקצאת מספרים

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

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

זרימת שיחות PSTN והצגת זיהוי מתקשר

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

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

זרימת שיחות ברשת

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

טיפול בשיחות משתמש ואימות תכונות

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

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

תורי שיחות: ניסיון של סוכן ומפקח

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

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

קבוצות ציד: חלוקת שיחות

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

שירותי ניתוב אוטומטיים: הכרזות ופעולות תפריט

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

פעולת תא קולי

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

למטב

הגירת PSTN ל-Cloud Connect עבור

אופטימיזציה של תשתית מקומית

שימוש בניתוח נתונים ופתרון בעיות

הגירת PSTN ל-Cloud Connect עבור

לאחר שכל נקודות הקצה והמשתמשים מועברו לשיחות ענן, המטרה היחידה של Unified CM היא לשמש כמעבר בין שערי PSTN ודרך Local Gateway. הסרת שערי PSTN ושער מקומי מהתמונה באמצעות Cloud Connect כגישת PSTN עבור כל משתמשי Webex Calling כוללת מספר יתרונות, כולל הפחתת עלויות ושיפור האמינות. כדי להעביר גישת PSTN מקומית ל-Cloud Connect עבור , בצע את השלבים הבאים:

Cloud Connect לבחירת שותפים.

עיין ברשימת השותפים של Cloud Connect ובחר מבין השותפים הזמינים עבור מיקום הארגון שלך.

חיבור ענן לצורך אימות.

לפני העברת גישת PSTN עבור מיקומים ל-Cloud Connect, יש לאמת ולאמת את הקישוריות ל-PSTN דרך שותף Cloud Connect שנבחר. למטרה זו, יש להקצות מיקום בדיקה עם מספר משתמשי בדיקה המוקצים במיקום בדיקה זה. גישת PSTN עבור מיקום בדיקה זה מוגדרת לאחר מכן לשותף Cloud Connect לפני אימות קישוריות PSTN באמצעות טלפוני הבדיקה. לאחר אימות מוצלח, ניתן לבטל את הקצאת הכוח של מיקום הבדיקה.

ניוד מספרים.

כדי להתכונן למעבר ל-Cloud Connect, יש לבצע הזמנת פורט עבור כל המספרים המוקצים כעת לקו ה-PSTN שמסתיים ב-. יש להעביר את כל המספרים לשותף Cloud Connect. כדי לשמור על נגישות בין מיקומים, יש להעביר את כל המספרים של כל המיקומים בו זמנית.

עבור לשותף של Cloud Connect.

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

כפי שנדון בסעיף PSTN בפרק התכנון, לקוחות יכולים גם לבחור להעביר את גישת ה-PSTN שלהם ל-Cloud Connect בתחילת המעבר באמצעות trunking של PSTN עבור פריסות היברידיות. למידע נוסף, ראה PSTN trunking עבור פריסות היברידיות של Webex Calling. במקרה כזה, במהלך המעבר, גישת PSTN מתבצעת דרך שער מקומי ולאחר העברת כל המשתמשים אין שלב הגירה נוסף הקשור ל-PSTN מלבד הוצאה משימוש ושערי הגישה המקומיים.

אופטימיזציה של תשתית מקומית

לאחר שכל המשתמשים הועברו וכל נקודות הקצה הועברו לרישום בענן (או שהוצאו משימוש), יש לעדכן את התשתית המקומית המתאימה כעת, לאחר ששיחות ענן נמצאות בשימוש. עדכוני התשתית כוללים:

הסר רשומות DNS SRV של בקרת שיחות והודעות מקומיות משרתי ה-DNS המקומיים, כולל cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. רשומות SRV אלו אינן נדרשות עוד לגילוי שירותי לקוח.

הסר רשומות DNS SRV הקשורות לקצה ממערכת ה-DNS הציבורית, כולל collab_edge._tls.<domain>. רשומות SRV אלו אינן נדרשות עוד לגילוי שירותי לקוח של שירותי קצה שיתוף פעולה.

עדכון כל טווחי DHCP הרלוונטיים כדי להסיר את אפשרות 66 ואפשרות 150 TFTP/boot כתובות השרת. טווחים אלה אינם נדרשים עוד לגילוי והורדה של תצורת בקרת קריאות קצה.

Update/remove עמיתים מתאימים לחיוג ב- Local Gateway/CUBE נתיב זה קורא אל Unified CM וממנו. עמיתים לחיוג אלה אינם נדרשים עוד לניתוב שיחות מקומי.

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

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

ניקיון: לאחר העברת גישת PSTN ל-PSTN מחובר לענן, ניתן להוציא משימוש את רשתות PSTN, שערי PSTN ושער מקומי.

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

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

עדכון המיקום הפיזי הניתן לשיגור ורכיב הרשת ב- Horizon Mobility בכל פעם שמתרחשים שינויים. פעילויות נפוצות הדורשות עדכונים הן:

החלפת מתג רשת

החלפת נקודת גישה אלחוטית

שינויים בטווח ה-DHCP

שינויים פיזיים בתוך הבניין (אם נפתור את ההחלטה ל cubical/office)

הרחבה או הצטמצמות פיזית של שטחי משרדים בתוך בניין.

שימוש בניתוח נתונים ופתרון בעיות

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

ניתוח איכות המדיה

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

פתרון בעיות איכות המדיה

פתרון בעיות יכול גם להשתלב עם מוצרים אחרים של סיסקו כמו ThousandEyes ומתגי Meraki כדי לספק חוויה משולבת עשירה עוד יותר ב-Control Hub. למידע נוסף על שימוש בניתוח ופתרון בעיות של Webex Calling, ראה פתרון בעיות של שיחות Webex Calling ב- Control Hub.

1	יצירת קבוצת סנכרון ייעודית: בספרייה הארג ונית שלך (Microsoft Entra ID או AD), צור קבוצת אבטחה ספציפית לסנכרון (לדוגמה, קבוצת סנכרון).
2	אכלס את הקבוצה עם משתמשי יעד: הוסף לקבוצה זו רק את המשתמשים שברצונך לסנכרן (כגון קבוצת בדיקה בשלב הפיילוט). זה מאפשר לך לשלוט בחוזקה מי נכלל בתהליך הסנכרון.
3	קביעת תצורה של הסכם הסנכרון באמצעות סינון מבוסס קבוצה: בעת הגדרת הסכם הס נכרון בהקצאת Directory Connector או Entra ID, הגדר את התחום כך שיכלול רק משתמשים שהם חברים בקבוצה המיועדת. עבור מזהה Microsoft Entra, באפשרותך להשתמש בהקצאות מבוססות קבוצה בהגדרות הקצאה עבור AD, באפשרותך להגדיר מסנן LDAP שיכלול רק משתמשים השייכים לקבוצה ש צוינה.
4	הרחב את הקבוצה לפי הצורך: ככל שתתקדם לשלבי פריסה רחבים יותר, פשוט הוסף משתמשים או קבוצות נוספים לקבוצת הסנכרון. היקף הסנכרון ית רחב אוטומטית כך שיכלול משתמשים אלה, ויאפשר השקה מבוקרת והדרג תית. שלבי יישום לדוגמה: בספרייה פעילה: צור קבוצת אבטחה בשם קבוצת סנכרון. הוסף את משתמשי הפיילוט הרצויים לקבוצה זו. הגדר מחבר ספריות עם מסנן LDAP כגון: (MemberOf=CN= קבוצת סנכרון WebEx, OU = קבוצות, DC=התחום שלך, DC=COM). במיקרוסופט הזן מזהה: יצירת קבוצה בשם קבוצת סנכרון הקצאת הקבוצה להגדרות הקצאה של מזהה Entra רק משתמשים בקבוצה זו יוקצו ל. בדוק תמיד סנכרון מבוסס קבוצה בסביבה שאינה ייצור לפני הגשת בקשה לארגון כולו בדוק באופן קבוע את החברות בקבוצה כדי לוודא שרק משתמשים מורשים מסונכרנים לניהול שוטף, בצע אוטומציה של עדכוני חברות בקבוצה בהתבסס על כללים עסקיים או מערכות משאבי אנוש במידת האפשר. הפניות: סנכרן משתמשי זיהוי כניסה לרכזת הבקרה הגדר את אפליקציית אשף ה- Entra ID במרכז הבקרה מחבר ספרייה

מוצר	תיאור
Unified CM	בקרת שיחות מקומית המספקת שירותי רישום מכשירים וניתוב שיחות
סיסקו Expressway-C/E	תשתית קצה המספקת פונקציונליות של גישה ניידת ומרוחקת (MRA) ופונקציונליות של עסק לעסק (B2B), המאפשרת לנקודות קצה מרוחקות להתחבר בצורה מאובטחת מחוץ לארגון. Expressway נפרס בזוגות כדי לספק חציית חומת אש עבור נקודות קצה חיצוניות.
שרת פגישות סיסקו (CMS), ניהול פגישות סיסקו (CMM) וחבילת ניהול נוכחות טלפונית של סיסקו (TMS)	תשתית ועידות קוליות, וידאו ושיחות וידאו מקומיות המספקות פגישות מרובות נקודות, ניהול פגישות ויכולות תזמון. [Optional]
Cisco Unity Connection	פלטפורמת הודעות קוליות מקומית המספקת יכולות דואר קולי ומסרים מאוחדים. [Optional]
Cisco Desk, Cisco Room, Cisco Board, טלפוני Cisco IP ו-Cisco Jabber	מכשירים מבוססי IP הרשומים ב-Unified CM ומספקים יכולות שיחות קוליות ווידאו

1	צור קבוצת סנכרון ייעודית: בספריית הארגון שלך (Microsoft Entra ID או AD), צור קבוצת אבטחה ספציפית לסינכרון (לדוגמה, קבוצת סינכרון).
2	מלאו את הקבוצה במשתמשי היעד: הוסף לקבוצה זו רק את המשתמשים שברצונך לסנכרן (כגון קבוצת בדיקה במהלך שלב הפיילוט). זה מאפשר לך לשלוט היטב במי כלול בתהליך הסנכרון.
3	הגדר את הסכם הסנכרון עם סינון מבוסס קבוצות: בעת הגדרת הסכם הסנכרון ב- Directory Connector או בהקצאת Entra ID, הגדר את ההיקף כך שיכלול רק משתמשים שהם חברים בקבוצה הייעודית. עבור מזהה Microsoft Entra, ניתן להשתמש בהקצאות מבוססות קבוצות בהגדרות ההקצאה. עבור AD, ניתן להגדיר מסנן LDAP כך שיכלול רק משתמשים השייכים לקבוצה שצוינה.
4	להרחיב את הקבוצה לפי הצורך: ככל שתתקדמו לשלבי פריסה רחבים יותר, פשוט הוסיפו משתמשים או קבוצות נוספות לקבוצת הסנכרון. טווח הסנכרון יתרחב אוטומטית ויכלול משתמשים אלה, מה שיאפשר פריסה מבוקרת והדרגתית. שלבי יישום לדוגמה: במדריך האקטיבי: צור קבוצת אבטחה בשם קבוצת סינכרון. הוסף את משתמשי הפיילוט הרצויים לקבוצה זו. הגדר מחבר ספריות עם מסנן LDAP כגון: (memberOf=CN=Webex סנכרון Group,OU=Groups,DC=yourdomain,DC=com). במזהה הזנה של מיקרוסופט: צור קבוצה בשם קבוצת סינכרון הקצה את הקבוצה להגדרות הקצאת המשאבים של Entra ID רק משתמשים בקבוצה זו יוקצו ל-. יש לבדוק תמיד סנכרון מבוסס קבוצות בסביבה שאינה סביבת ייצור לפני החלה על הארגון כולו. בדוק באופן קבוע את החברות בקבוצה כדי לוודא שרק משתמשים מורשים מסונכרנים לניהול שוטף, עדכוני חברות בקבוצה אוטומציה בהתבסס על כללי עסקיים או מערכות משאבי אנוש במידת האפשר. הפניות: סנכרון משתמשי Entra ID לתוך Control Hub הגדר את אפליקציית אשף מזהה Entra במרכז הבקרה מחבר ספרייה

Cisco AI Assistant

תודה על המשוב.

מדריך פריסת העברה

לפני שתתחיל

סקירה כללית

רכיבי ליבה

סקירת תהליך PPDIO

תיאור כללי של PPDIO

שימוש ב- PPDIO עבור פרויקטים Unified CM של Webex Calling הגירה

הכן

תוכנית

עיצוב

ליישם

אופטימיזציה

לולאות משוב PPDIO

גישת הגירה

הכן

דרישות עסקיות וטכניות

מדוע איסוף דרישות חשוב:

דרישות עסקיות

דרישות טכניות

מוכנות רשת ודרישות

הגדרת UC המחובר לענן

הערכת הסביבה הנוכחית

רישוי

מיקומות/אתרים

מלאי התקנים/לקוחות קיימים

בדוק את זכאות המכשיר

משתמשים

קישוריות PSTN

תכונות ושימוש בתכונות

שילובים של סיסקו: חיבור יוניטי UCCX UCCE

הקלטת שיחות

שילובים של צד שלישי

תכנית

תוכנית פרויקט ברמה גבוהה

מסע הגירה - צעד אחד או שניים?

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

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

שלב 1

שלב 2

עיצוב

בחירת אזור

מיקומים

PSTN

תוכנית חיוג

תוכנית חיוג מקומית ב

תוכנית חיוג

הקלטה

1. בחירת ספק הקלטת שיחות

2. בחירת אזור

שיחת חירום

רישוי

הקצאה ידנית דרך

תבניות הקצאת רישיונות אוטומטיות

הקצאה בכמות גדולה באמצעות תבנית CSV

הקצאה מבוססת API

דרישות רישיון

הקצאת משתמשים

קבוצות משתמשים

גישה מומלצת בעת מעבר מ-

עיצוב קבוצות משתמשים

כניסה יחידה (SSO)

תמיכה מרובה של IdP

1. מיזוגים ורכישות

2. מחלקות IT עצמאיות מרובות

3. קבוצות משתמשים או דומיינים שונים

4. תמיכה בפרוטוקולי אימות שונים

5. אבטחה ותאימות משופרים

6. חווית משתמש פשוטה

שני MFA עם SSO עבור

תכונות

מלווה אוטומטי

התקשר לפארק

איסוף שיחות

תור שיחה

קבוצת האנט

מצבי הפעלה

קבוצת פיג'ינג

הקלטות