בדף הזה מוסבר איך להשתמש ב-API של רשת להעברת תוכן (eCDN) מקומית של Google Meet לשידור חי ב-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.comAccess-Control-Allow-Headers: GET, POST, OPTIONSAccess-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.