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

Webex Callingקצה

כדי לבצע רישום SIP או שיחה, בצע את השלבים הבאים:

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

• השלם את כל התנאים המוקדמים הקשורים לתצורת המשתמש והמכשיר.

• ודא שלנקודת הקצה יש קישוריות רשת ציבורית כדי להתחיל גילוי שירות.

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

IPv4 לעומת IPv6

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

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

• מצב ערימה כפולה - בוחר גרסת IP מועדפת באמצעות תצורה.

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

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

פתרון כתובת המארח מהכתו DNS SRV בת

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

wxc.edge.bcld.webex.com

מהדוגמה, נקודת הקצה המבצעת חיפוש DNS SRV עבור תחום זה עשויה להניב תגובה דומה לתגובה הבאה:

# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

במקרה זה, רשומה SRV מצביעה על רשומות 3 A.

sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com

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

שקול דרישות אלה עבור נקודות קצה.

• נקודת קצה חייבת להשתמש _sips._tcp(שילוב שירות ופרוטוקול) כקידומת כדי לבצע חיפוש DNS SRV לקבלת כתובת מארח ליזום תקשורת מבוססת TLS.

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

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

• ספציפית לשימוש ברש DNS SRV ומה, קריטריוני הבחירה של מארחים המבוססים על עדיפות ומשקל מוסברים ב- RFC 2782.

דרישות SIP מאובטח עם MTL (TLS הדדי)

הדרישות מוסברות בפירוט כאן.

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

• האישור חייב להיות חתום על ידי CA המוזכר באילו רשויות אישור שורש נתמכות לשיחות לפלטפורמות Cisco Webex שמע ווידאו?

• העלה את חבילת האמון המוזכ רת באילו רשויות אישור שורש נתמכ ות לשיחות Cisco Webex לפלטפורמות שמע ווידאו? ועכשיו אל הקו בייה.

• התעודה צריכה להיות תקפה תמיד:

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

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

  • אישורים המכילים רק שימוש במפתח מורחב לאימות שרת (EKU) נתמכים. Webex Callingאינו מאמת או אוכף את נוכחותו של EKU אימות לקוח במהלך הקמת לחיצת יד של TLS.

    חלק מבקרי גבול ההפעלה של צד שלישי (SBC) עשויים לאכוף אימות EKU קפדני ויכולים לדחות אישורים שאינם כוללים EKU לאימות לקוח. במקרים כאלה, ודא שה- SBC מוגדר לקבל אישורים עם אימות שרת EKU בלבד או להשבית אימות EKU קפדני (אם נתמך).

  • האישורים חייבים להכיל את שם התחום המוסמך המלא (FQDN) כשם נפוץ או כשם חלופי של נושא באישור עם FQDN שנבחר במרכז הבקרה. לדוגמה:

    • תא מטען שהוגדר ממרכז הבקרה של הארגון שלך עם london.lgw.cisco.com:5061 בתור FQDN חייב להכיל london.lgw.cisco.com באישור CN או SAN.

    • תא המטען שהוגדר ממרכז הבקרה של הארגון שלך עם london.lgw.cisco.com היה ה- SRV חייב להכיל london.lgw.cisco.com באישור CN או SAN. הרשומות שאליהן פותרת כתובת ה- SRV ( CNAME/רשומה א/כתובת IP) הן אופציונליות ב- SAN.

  • באפשרותך לשתף אישורים עם יותר משער מקומי אחד, עם זאת, ודא שדרישות ה- FQDN מתקיימות.

מחוץ להיקף

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

• דרישות F5 עבור CA וצופנים

• ממשק API מבוסס HTTP להורדת כללי חומת אש עבור Webex.

• ממשק API עבור חבילת אמון

• דרישת חומת אש והשבתת ALG