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

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

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

סקירה כללית של Meet ב-eCDN

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

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

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

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

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

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

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

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

אחרי שיוצרים את שירות האינטרנט, צריך להגדיר את מסוף Admin כך שישתמש במדיניות של On-premises service peering ולכלול את כתובת ה-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 פרטית, צריך למפות את הכתובת לקבוצת הפירינג המתאימה. צריך לשלוח את כתובת ה-IP הפרטית לשרת ברשת ולבצע המרה ידנית לקבוצת שותפים באמצעות השיטה get-peering-group(). מזהה קבוצת הפירינג מוחזר בתשובה. כשמתקשרים עם Google, מועבר מזהה קבוצת הפירינג שנוצר במקום כתובות IP פרטיות.

בדוגמת הקוד הבאה אפשר לראות איך קוראים לשיטה 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:
{
  "allowed": boolean,
  "result": string,
  "error": null
}

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

פורמט תשובה מדור קודם

השדה allowed לא היה חלק מפורמט התגובה בגרסאות קודמות. במקום זאת, ערכים שמורים מיוחדים של result יקבעו אם כתובת ה-IP של הצופה תיחסם מביצוע peering:

Legacy response body:
{
  "result": string,
  "error": null,
}

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

החלפת נתונים של SDP offer-answer

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

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

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

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

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

Request body:
{
  "data": "SDP_DATA"
},

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

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

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

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

Request body:
{
  "data": "ENCRYPTED_DATA_STRING"
},

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

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

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

הגדרת מסוף Admin

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

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

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

נושאים קשורים

• כדי ללמוד איך להשתמש ב-eCDN ב-Meet, פועלים לפי השלבים במאמר אירוח שידורים חיים מרובי-משתתפים.

• במאמר לפני שמתחילים לארח שידורים חיים מרובי-משתתפים מוסבר איך מגדירים eCDN.

• במאמר איך מכינים את הרשת לפגישות ולשידורים חיים ב-Meet מוסבר איך להגדיר את הרשת.

• הוראות לכניסה למסוף Google Admin כאדמין מופיעות במאמר כניסה למסוף Admin.