תודה על המשוב.

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

להלן המפרט והדרישות ברמה גבוהה של TelSP:

• השותף מתכנן להשתמש ב- sip.telsp.com כד ומיין ברמה העליונה המשותף לכל הלקוחות שהם מנהלים.

• השותף הוא הבעלים של sip.telsp.com והוא יכול לנהל את תשתית ה- DNS ורשויות האישורים, לנהל כתובות DNS ולחתום על אישורים עבור תחום זה ותחומי המשנה שלו.

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

• לשותף שני אתרים פיזיים, ושני האתרים הללו חולקים קישוריות PSTN:

  • מיאמי

  • שיקגו

• TelSP מפעילה את השערים המקומיים שלה מטעם שני הלקוחות CuStA ו- CustB כפי שהם מכונים מכאן.

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

דוגמה לפריסה פשוטה

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

• תעודה —sip.tel sp.com

• גזעים

  • קוסט.סיפ.טלספ.com

  • קוסטב. סיפ. טלספ.com

• זהות תעודת עמיתים —sip.telsp.com

• תוצאה

  • נעשה שימוש בתעודה יחידה

  • גזעי לקוחות מרובים נתמכים

שיוך מיקום הלקוח לתא המטען והשער

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

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

עבור CUsta, פרטי תא המטען הם כדלקמן:

האיור מציג את הקשר של מיקום הלקוח לשער ותא המטען עבור CUsta:

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

עבור CustB נוצ רת הגדרה דומה עם הגזעים הבאים:

האיור מציג את הקשר של מיקום הלקוח ל- Gateway ו- Tr unk עבור CustB:

האיור מציג מיקום שלישי, כלומר ניו יורק, אותו תוכל להוסיף מאוחר יותר ולהצביע על תא המטען trunk_chicago כחיבור ה- P STN העיקרי שלו.

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

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

לכן קרא את ההנחיות החשובות הבאות:

• סיסקו אינה מחייבת כתובת IP לכל תא מטען.

• כתובת תא מטען יכולה להיות כתובת IP ייחודית או לכתובת המשותפת בין תא מטען אחר.

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

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

  2. מספק בידוד ברמת הרשת בין לקוחות

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

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

כתובת IP לכל שער: תצורת תא המטען והמלצות

עיין בדוגמאות אלה של מודלים שונים לתכנון:

דגם 1: כתובת IP ייחודית לכל תא מטען

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

ייצוג המידע בפורמט טבלאי:

באותו מודל, השותף יכול להשתמש בכתובת SRV. Webex Callingמאפשר רק "_לגימות. _tcp" כשילוב השירות והפרוטוקול לגילוי כתובת העמית אם מדובר ברשומת SRV.

דוגמה לאופן שבו רשומה SRV פותרת

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

דגם 2: IP משותף לכל שער, יציאות האזנה ייחודיות

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

באותו מודל, השותף משתמש בכתובת SRV. Webex Callingמאפשר רק "_לגימות. _tcp" כשילוב השירות והפרוטוקול לגילוי כתובת העמית אם מדובר ברשומת SRV.

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

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

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

השותף מחזיק ב- telsp.com ותתי הדומיינים שלו. לכן, שרת ה- DNS והסמכות לקבל אישורים חתומים על ידי רשות אישורים מאושרת מוטלת על השותף.

• Cisco Webexמצפה מהשותף לפרסם את כתובת ה- FQDN או ה- SRV כולל רשומות A ברשות הרבים.

• Cisco Webexמצפה מהשותף להשתמש באחת מרשויות האישורים המפורטות במ סמך זה.

בעת הגדרת גזעים באמצעות FQDN או SRV:

• לכל תא מטען עדיין חייב להיות FQDN ייחודי לניתוב וזיהוי

• רשומות DNS (רשומה או SRV) חייבות להיות מוגדרות כהלכה וניתנות לפתרון

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

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

הגדר את השער

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

כדי להגדיר את Cisco CUBE, השתמש בהליך זה: הגדר את התצורה של שער מקומי ב Cisco IOS - XE עבור Webex Calling

באפשרותך להגדיר SBCs מאושרים של צד שלישי, ראה: התחלת השימוש בשער מקומי

הגדר את השער המתארח של השותפים בהתאם להנחיות הבאות: התחל עם Local Gateway

הגדר כל תא מטען בהתאם להוראות הרלוונטיות למכשיר SBC. לקבלת הוראות Cisco CUBE, ראה: קביעת תצורה של שער מקומי ב Cisco IOS - XE עבור Webex Calling

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

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

בעת קביעת תצורה של גזעים ב-Control Hub, הגדר זהות אישור עמיתים כדי לאפשר שימוש באישור יחיד עבור התחום ברמה העליונה שלך בכל ארגוני הלקוחות . ודא שה-CN או ה-SAN של האישור כוללים תחום ברמה עליונה זו. עם זהות אישור עמיתים, השער המקומי משתמש באישור יחיד שה-CN או ה-SAN שלו מכילים את התחום המשו תף של השותף (לדוגמה, sip.telsp.com). אישורי תווים כלליים (לדוגמה, *.sip.telsp.com) אינם נתמכים. Webex Callingמקבל אישור זה עבור כל תא מטען לקוח שהוגדר במפורש עם ערך זה כזהות אישור עמיתים שלו. האישור חייב להכיל את ערך הז הות המדויק של אישור עמיתים שהוגדר ב- CN או SAN שלו. פעולה זו מבטלת את הצורך להגדיר אישורים נפרדים או ערכי CN/SAN עבור FQDNs תא מטען בודדים.

אימות דומיין ושימוש באישורים

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

• אימות תחום (ללקוח) — על כל ארגון לקוח לאמת באופן עצמאי את הדומיין (לדוגמה, sip.telsp.com) על ידי הוספת רשומת TXT ייחודית ב- DNS. זה מבטיח כי השותף הוא הבעלים של הדומיין ו מונע שימוש לא מורשה.

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

התנהגות זהות של אישור עמיתים

זהות אישור עמיתים מגדירה את הזהות המצ Webex Calling פה באישור המוצג על ידי השער המקומי.

כאשר מוגדר:

• Webex Callingמאמת את האישור על-ידי התאמת זהות ה-Peer Certit שהו גדרה עם CN או SAN בתעודה

• אם הערכים תואמים, חיבור ה- TLS יתקבל

• אם הערכים אינם תואמים, החיבור נדחה

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

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

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

1. דוגמה לתצורה חוקית:

   • תעודת CN —sip.tel sp.com

   • תעודת SAN — קוסט.sip.telsp.com

   • זהות תעודת עמיתים - custa.sip.telsp.com

   • תא המטען FQDN - תא המטען. מיאמי.קוסט.סיפ.טלספ.com

   תוצאה — החיבור מצליח מכיוון שזהות אישור עמיתים (custa.sip.telsp.com) תואמת לערך SAN באישור, ו- FQDN תא המטען (trunk.miami.custa.sip.telsp.com) הוא תחום משנה של זהות אישור עמיתים שהוגדרה.

2. דוגמה לכשל בחיבור:

   • תעודת CN —sip.tel sp.com

   • תעודת SAN — קוסט.sip.telsp.com

   • זהות תעודת עמיתים —custb.sip.telsp.com

   • תא המטען FQDN - trunk.miami.custb.sip.telsp.com

   תוצאה — החיבור נכשל בלחיצת יד של TLS מכיוון שזהות אישור עמיתים (custb.sip.telsp.com) אינה קיימת ב- CN או SAN של האישור. ה- FQDN של תא המטען הוא נכון תת-דומיין של זהות אישור עמיתים, אך האישור אינו נושא זהות זו.

3. דוגמה לתצורה לא חוקית:

   • תעודת CN —sip.tel sp.com

   • תעודת SAN — קוסט.sip.telsp.com

   • זהות תעודת עמיתים - custa.sip.telsp.com

   • תא המטען FQDN - trunk.miami.custb.sip.telsp.com

   תוצאה — רכזת הבקרה דוחה תצורה זו בזמן שמירה מכיוון ש- FQDN תא המטען (trunk.miami.custb.sip.telsp.com) אינו שווה או תחום משנה של זהות אישור עמיתים שהוגדרה (custa.sip.telsp.com).

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

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

2. הוספת תחום ואימות — הוסף ואמת את התחום הבא המשמש ליצירת תא מט ען תחת הגדרות ניהול/ארגונ/דומיינים.

   לקוחB	לקוח C
   סיפ. טלספ.com	סיפ. טלספ.com

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

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

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

3. הגדר כתובת SBC עם FQDN—

   לשער מיאמי:

   פרמטר	לקוחB	לקוח C
   מיקום	דנוור	בוסטון
   שם תא המטען	תא המטען מיאמי	תא המטען מיאמי
   סוג תא המטען	מבוסס תעודה	מבוסס תעודה
   סוג מכשיר	למשל Cisco Unified Border Element(או התקן נתמך אחר)	למשל Cisco Unified Border Element(או התקן נתמך אחר)
   סוג כתובת SBC	FQDN	FQDN
   שם מארח	lgw. מיאמי	lgw. מיאמי
   דומיין	סיפ. טלספ.com	סיפ. טלספ.com
   נמל	5061	5062
   FQDN	LGW.מיאמי.לקוחות.סיפ.טלספ.com:5061	LGW.מיאמי.קושטר.סיפ.טלספ.com:5062
   המספר המרבי של שיחות במקביל (250-6500)	500	500

   לשער שיקגו:

   פרמטר	לקוחB	לקוח C
   מיקום	דטרויט	דאלאס
   שם תא המטען	מטען_שיקגו	מטען_שיקגו
   סוג תא המטען	מבוסס תעודה	מבוסס תעודה
   סוג מכשיר	למשל Cisco Unified Border Element(או התקן נתמך אחר)	למשל Cisco Unified Border Element(או התקן נתמך אחר)
   סוג כתובת SBC	FQDN	FQDN
   שם מארח	lgw. שיקגו	lgw. שיקגו
   דומיין	סיפ. טלספ.com	סיפ. טלספ.com
   נמל	5061	5062
   FQDN	LGW.CHICAGO.לקוחות.סיפ.טלספ.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   המספר המרבי של שיחות במקביל (250-6500)	500	500

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

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

4. זהות תעודת עמיתים—

   • קידומת — הקידומת היא אופציונלית. השאר אותו ריק כדי להגדיר את זהות אישור העמית לתחום בלבד. זהו מודל האישור המשותף המשמש במאמר זה (זהות אישור עמית—sip.telsp .com, המכסה את כל גזעי הלקוחות). לחלופין, הזן קידומת להגדרת זהות אישור ספציפית יותר (לדוגמה, קידומת: CustomerB, תחום: Customerb.sip.telsp.com עבור אישור לכל לקוח). ה- FQDN תא המטען עצמו נשאר מוגדר על ידי כתובת SBC שם מארח ושדות דומיין ו חייב להיות שווה או תת-דומיין של זהות אישור עמיתים שהתקבלה.

     דוגמה:

     קידומת — לקוח B

     דומין—sip.telsp.com

     תוצאה—לקוחות.sip.telsp.com

   • תחום: בחר תחום מרשימת התחומים המאומתים בא רגון הלקוח. זהות אישור עמיתים המתקבלת (קידומת + תחום) חייבת להתאים ל- CN או SAN של האישור ש- SBC שלך מציג. Webex Callingמשתמש בערך זה כדי לאמת את חיבור ה- TLS.

     

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

     אם זהות אישור עמיתים אינה תואמת את CN או SAN בתעודה המוצגת על ידי ה- SBC, Webex Calling דוחה את חיבור ה- TLS ותא המטען אינו מצליח ליצור.

5. שימוש בתא המטען — בחר מיקום שרירותי כלשהו לתא המטען, בשל הפעולות הבאות:

   • כל מיקום יכול להשתמש בתא המטען בחיבור PSTN.

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

   • כל תוכנית חיוג יכולה להשתמש בתא המטען.

6. עיין בהגדרות תא המטען עם המיקומים המשויכים:

   

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

   

   ניתן להגדיר קבוצת מסלולים שנייה rg_chicago_miami המנתבת קריאות לת א המטען trunk_chicago כאפשרות העיקרית ולתא המטען trunk_ miami כאפשרות משנית.

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

   

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

   

   

אספקה בקנה מידה עם ממשקי API

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

• אימות דומיין

• ניתוב שיחות