בדף הזה מוסבר איך להשתמש ב-API של רשת להעברת תוכן (eCDN) של Google Meet Enterprise On-Premises לשידור חי ב-Google Meet.
פתרון ה-API שמתואר כאן מאפשר ללקוחות להשתמש בכל התכונות של Meet eCDN בלי לחשוף ל-Google מידע על כתובות IP פרטיות. אתם יכולים להגדיר שירות אינטרנט חדש מקומי ברשת שלכם, שיעביר מזהה במקום את פרטי כתובת ה-IP הפרטית.
סקירה כללית של Meet eCDN
eCDN מובנה ב-Meet ומתחיל לפעול אוטומטית במהלך שידורים חיים אחרי שאדמין ב-Google Workspace מגדיר אותו. כש-eCDN מופעל ב-Meet, צופים בשידור חי ברשת מקומית יכולים לשתף מדיה בשידור חי עם עמיתים אחרים ברשת באמצעות שיתוף עמית לעמית (P2P). ברוב המכשירים, המדיה בשידור החי מגיעה מעמיתים קרובים ולא צריך לאחזר אותה מהשרתים של Google. כך מצטמצם רוחב הפס הכולל שנדרש לצופים. מידע נוסף על ההגדרה והשימוש ב-Meet eCDN זמין במאמר אירוח שידורים חיים מרובי-משתתפים.
כדי להשתמש ב-eCDN, הצופים בשידור החי ב-Meet צריכים להיות מסודרים בקבוצות של עמיתים. קבוצת עמיתים היא אוסף של צמתים שמורשים לשתף מדיה ביניהם. מכשירים בקבוצת שיתוף יכולים לשתף או להיות חסומים משיתוף. מכשירים מורשים יכולים להתחבר רק למכשירים אחרים באותה קבוצת עמיתים. מידע נוסף על קבוצות עמיתים זמין במאמר לפני שמתחילים לארח שידורים חיים גדולים.
מתי כדאי להשתמש ב-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 פרטיות לקבוצת פירינג
לקוח ה-eCDN מבצע קריאה בכל פעם שהוא מנסה להתחבר מחדש לשרת המעקב של ה-eCDN. אחרי שמכשיר מזהה כתובת IP פרטית, צריך למפות את הכתובת לקבוצת הפירינג המתאימה. צריך לשלוח את כתובת ה-IP הפרטית לשרת ברשת ולפתור אותה באופן ידני לקבוצת peering באמצעות השיטה 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:
{
"result": "PEERING_GROUP_ID",
"error": null,
}
בטבלה הבאה מוצגים פורמטים צפויים של תגובות:
סטטוס HTTP | שגיאה | מזהה קבוצת שותפים | תגובת הלקוח |
---|---|---|---|
200 | null | מחרוזת לא ריקה | הלקוח צריך להיות ממוין לקבוצת עמיתים ולהמשיך להתחבר לשרת המעקב של ה-eCDN. |
200 | null | NOT_FOUND |
הלקוח מסיים את הסשן ב-eCDN. |
200 | null | BLOCKED |
הלקוח מסיים את הסשן ב-eCDN. |
200 | מחרוזת אחרת שאינה ריקה | null | הלקוח מסיים את הסשן ב-eCDN. |
302 (נמצא) | הלקוח עוקב אחרי ההפניה האוטומטית לכתובת ה-URL החדשה שצוינה בכותרת Location של גוף התגובה. |
||
כל קוד סטטוס אחר | כל מחרוזת | כל מחרוזת | הלקוח מסיים את הסשן ב-eCDN. |
החלפת נתונים של 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 פועלת כרגיל. העמיתים מנתבים את המדיה דרך רשת הפירינג הרגילה, ותעבורת המדיה לא עוברת דרך ה-API ולא משתמשת בו.

בדוגמה הבאה של קוד אפשר לראות איך קוראים לשיטה 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 | שגיאה | מזהה קבוצת שותפים | תגובת הלקוח |
---|---|---|---|
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
הוא שם שירות האינטרנט שלכם.
מידע נוסף על הגדרת מדיניות שיוך זמין במאמר הגדרת קיבוץ רשתות.
נושאים קשורים
כדי ללמוד איך להשתמש ב-eCDN ב-Meet, פועלים לפי השלבים במאמר בנושא אירוח שידורים חיים מרובי-משתתפים.
מידע על הגדרת eCDN זמין במאמר לפני שמתחילים לארח שידורים חיים מרובי-משתתפים.
במאמר איך מכינים את הרשת לפגישות ולשידורים חיים ב-Meet מוסבר איך להגדיר את הרשת.
הוראות לכניסה למסוף Google Admin כאדמין מופיעות במאמר כניסה למסוף Admin.