עבודה עם Meet eCDN On-Premises API

בדף הזה נסביר איך להשתמש ב-API המקומי של רשת העברת התוכן (eCDN) של Google Meet Enterprise לשידור חי ב-Google Meet.

פתרון ה-API שמתואר כאן מאפשר ללקוחות להשתמש במגוון התכונות המלא של eCDN ב-Meet בלי לחשוף ל-Google את פרטי ה-IP הפרטיים שלהם. אפשר להגדיר שירות אינטרנט חדש בארגון ברשת שלכם, שיעביר מזהה במקום את פרטי כתובת ה-IP הפרטית.

סקירה כללית על Meet eCDN

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

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

מתי כדאי להשתמש ב-API

אפשר ליצור קבוצות של קישור בין רשתות שכנות (peering) ב-eCDN באמצעות כמה מדיניות קישור בין רשתות שכנות (peering) שונות: random,‏ subnet או custom rules. השרת הזה משתף טבלה של טווחי רשתות פרטיות עם שרת המעקב של eCDN של Google, כדי למפות כתובות IP פרטיות של כל צומת עמית לקבוצת peering. המדיניות custom rules היא הפתרון המועדף והיא מתאימה לרוב סביבות הייצור.

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

פיתוח באמצעות Meet eCDN On-Premises API

ה-API של Meet eCDN On-Premises מספק מפרט של שרת אינטרנט שאפשר להטמיע ולארח באופן מקומי ברשת של הארגון. אתם יכולים ליצור שירות אינטרנט מותאם אישית שתואם ל-API כדי לבצע את כל המשימות שתלויות בפרטי IP פרטיים, כך שהמידע לא ישותף עם Google.

ה-API כולל את שני השלבים הקריטיים להתאמת כתובות IP פרטיות, שבדרך כלל מטופלים על ידי שרת המעקב של ה-eCDN: מיפוי של כתובות IP פרטיות לקבוצת peering והחלפת נתונים של הצעות ותשובות ב-Session Description Protocol ‏(SDP) במהלך איתות WebRTC.

אחרי שתסיימו ליצור את שירות האינטרנט, תצטרכו להגדיר את מסוף Admin כך שישתמש במדיניות peering של On-premises service ולכלול את כתובת ה-URL של שירות האינטרנט המותאם אישית.

דרישות

אם אתם צריכים להפעיל אחת מהדרישות האלה בארגון, תוכלו לבקש מהאדמין ב-Google Workspace:

  • כל שרת אינטרנט שמשתמש ב-HTTPS יכול להטמיע את ה-API הזה.

  • שימוש ב-HTTPS כדי למנוע כשלים בתוכן מעורב.

  • קבלה והחזרה של נתוני JSON. משתמשים בכל קידוד תוכן שנתמך בדפדפן.

  • הצגת נקודות קצה במסלול /vn, כאשר n היא גרסת ה-API שנבחרה. לדוגמה: /v1/get-peering-group.

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

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

  • השירות צריך להגדיר את הכותרות הבאות של שיתוף משאבים בין מקורות (CORS):

    • Access-Control-Allow-Origin: meet.google.com
    • Access-Control-Allow-Headers: GET, POST, OPTIONS
    • Access-Control-Allow-Credentials: true

מיפוי של כתובות IP פרטיות לקבוצת peering

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

איך כתובות IP פרטיות ממפות לקבוצת peering.
איור 1. מיפוי של כתובות IP פרטיות לקבוצת peering.

בקטע הקוד הבא מוסבר איך להפעיל את השיטה get-peering-group(), יחד עם תגובת השגיאה הפוטנציאלית וגוף התגובה הצפוי:

POST /v1/get-peering-group
Content-Type: application/json

Request body:
{
  "availableIPs": []{
    "format": "ipv4"|"ipv6",
    "address": "DETECTED_ADDRESS"
  }
}

Error response:
{
  "result": null,
  "error": "ERROR_MESSAGE",
}

Response body:
{
  "result": "PEERING_GROUP_ID",
  "error": null,
}

בטבלה הבאה מוצגים הפורמטים הצפויים של התשובות:

סטטוס HTTP שגיאה מזהה קבוצת ה-Peering תגובה של הלקוח
200 null מחרוזת לא ריקה הלקוח צריך להיות ממוין לקבוצת peering ולהמשיך להתחבר לשרת המעקב של eCDN.
200 NOT_FOUND null הלקוח מסיים את הסשן ב-eCDN.
200 BLOCKED null הלקוח מסיים את הסשן ב-eCDN.
200 מחרוזת אחרת שאינה ריקה null הלקוח מסיים את הסשן ב-eCDN.
302 (נמצא) הלקוח עוקב אחרי ההפניה האוטומטית לכתובת ה-URL החדשה שצוינה בכותרת Location של גוף התגובה.
קוד סטטוס אחר כל מחרוזת כל מחרוזת הלקוח מסיים את הסשן ב-eCDN.

החלפת נתונים של הצעה-תשובה ב-SDP

כדי ליצור חיבור WebRTC, המכשירים צריכים להחליף את הצעות ה-SDP והתשובות שלהם, כולל מועמדים ל-Interactive Connectivity Establishment ‏ (ICE) שמכילים פרטי IP פרטיים. הם עושים זאת כחלק מתהליך האותות של WebRTC.

לקוחות צריכים להצפין את המועמדים ל-ICE בתוך הרשת שלהם באמצעות Meet eCDN On-Premises API, באמצעות השיטה encrypt-sdp(). השיטה משתמשת במפתח שלא נחשף ל-Google אף פעם. לאחר מכן, ההצעה המוצפנת של SDP נשלחת לשותף באמצעות שרת המעקב של eCDN. לאחר מכן, השותף של הלקוח מפענח את המידע שקיבל ברשת שלו באמצעות השיטה decrypt-sdp(). לאחר מכן, Google מעבירה את המבצעים והתשובות בין השותפים המקושרים.

אחרי שהחיבור נוצר באמצעות ה-API המקומי של eCDN ב-Meet, ה-eCDN פועל כרגיל. השותפים מנתבים את התעבורה של המדיה דרך רשת ה-peering הרגילה, ותעבורת המדיה לא עוברת דרך ה-API או משתמשת בו.

איך הנתונים של הצעת ה-SDP והתשובה להצפינו ופורשו.
איור 2. הצפנה ופענוח של נתוני התשובה וההצעה ב-SDP.

בקטע הקוד הבא מוסבר איך להפעיל את השיטה encrypt-sdp() יחד עם תגובת השגיאה הפוטנציאלית וגוף התגובה הצפוי:

POST /v1/encrypt-sdp
Content-Type: application/json

Request body:
{
  "data": "SDP_DATA" // raw SDP data
},

Error response:
{
  "result": null,
  "error": "ERROR_MESSAGE", // error message
}

Response body:
{
  "result": "ENCRYPTED_DATA_STRING", // encrypted data as string
  "error": null,
}

בקטע הקוד הבא מוסבר איך לקרוא לשיטה decrypt-sdp() יחד עם תגובת השגיאה הפוטנציאלית וגוף התגובה הצפוי:

POST /v1/decrypt-sdp
Content-Type: application/json

Request body:
{
  "data": "ENCRYPTED_DATA_STRING", // encrypted data as string (size limit: 1 MB)
},

Error response:
{
  "result": null,
  "error": "ERROR_MESSAGE", // error message
}

Response body:
{
  "result": "SDP_DATA" // raw SDP data
  "error": null,
}

בטבלה הבאה מוצגים הפורמטים הצפויים של התשובות:

סטטוס HTTP שגיאה מזהה קבוצת ה-Peering תגובה של הלקוח
200 null מחרוזת לא ריקה הלקוח מצפה לשימוש בנתוני SDP שהומרו או קודדו כראוי.
200 כל מחרוזת שאינה ריקה null הלקוח מסיים את הסשן ב-eCDN.
302 (נמצא) הלקוח עוקב אחרי ההפניה האוטומטית לכתובת ה-URL החדשה שצוינה בכותרת Location של גוף התגובה.
קוד סטטוס אחר כל ערך כל ערך הלקוח מסיים את הסשן ב-eCDN.

הגדרת מסוף Admin

כדי להשתמש ב-Meet eCDN On-Premises API, צריך להגדיר את ה-eCDN ב מסוף Admin כך שיכלול את כתובת ה-URL של שירות האינטרנט המותאם אישית.

כדי להגדיר את ה-eCDN, יוצרים מדיניות קישור בין רשתות שכנות (peering) באמצעות On-premises service כדי להתאים באופן ידני את פרטי ה-IP לקבוצות של קישור בין רשתות שכנות. אפשר גם לכלול מספר יציאה אם לא משתמשים ב-443 שמוגדר כברירת מחדל. כתובת ה-URL צריכה להתאים לפורמט הבא: WEB_SERVICE.example.com:8080, כאשר WEB_SERVICE הוא שם שירות האינטרנט.

מידע נוסף על הגדרת מדיניות peering זמין במאמר הגדרת קיבוץ רשתות.