פרוטוקול של הכנס

המסמך הזה נועד לתאר את ההתפתחות שאנו נעשה לניהול מסיבות (אודיו/וידאו). המטרה היא לשפר את ההיישום הנוכחי אשר פשוט ממזג שיחות SIP ו לספק תצוגה רשת, כדי לראות היכן המשתתפים רשומים, ניתן להטיל את המשתתפים באופן עצמאי, או את תצוגת הוידאו שונה (להראות רק משתתף אחד)

הגדרות

• מארח: הוא המשתמש המערבב את הזרמים האודיו/ווידיאו עבור האחרים

• משתתף: כל משתמש בכנס, אפילו המארח

הסרת אחריות

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

תכנון אפשרי

• גריד: כל חבר מופיע עם אותו גובה/רוחב

• ONE_BIG_WITH_SMALL: חבר אחד מתקרב והראשון השני מופיע

• ONE_BIG: חבר אחד לוקח את המסך המלא

שתי שיטות חדשות זמינות לניהול את תכנון הכנס בCallManager:

/**
 * Change the conference layout
 * @param confId
 * @param layout    0 = matrix, 1 = one big, others in small, 2 = one in big
 */
void setConferenceLayout(const std::string& confId, int layout);

/**
 * Change the active participant (used in layout != matrix)
 * @param confId
 * @param participantId    If participantId not found, the local video will be shown
 */
void setActiveParticipant(const std::string& confId, const std::string& participantId);

ההבנה היא די פשוטה. הכל ניהול על ידי conference.cpp (להקשר את המשתתף למקורות) ו video_mixer.cpp (להעניק את התכנון הנדרש).

סינכרון מידע של מסיבות

הערה: למעשה, המילה משתתף משמשת עבור callId מעורב בוועידה. זה יכול להוביל בהתחלה למספר בעיות עבור האפיי

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

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

מידע על תארים

התארה נשמרת כVectorMapStringString עבור לקוחות ובתוך וקטור עם פורמט הבא:

Layout = {
    {
        "uri": "participant", "x":"0", "y":"0", "w": "0", "h": "0", "isModerator": "true"
    },
    {
        "uri": "participant1", "x":"0", "y":"0", "w": "0", "h": "0", "isModerator": "false"
    }
    (...)
}

המפתחות אפשריות הן:

• uri = uri של חשבון

• מכשיר = תעודת זהות של המכשיר

• מדיה = תעודת זהות של מדיה

• פעיל = אם המשתתף פעיל

• x = עמדה (x) בווידאו

• y = עמדה (y) בווידאו

• w = גודל (רוחב) בווידאו

• h = גודל (גובה) בווידאו

• videoMuted = אם הסרטון הוא מוט

• audioLocalMuted = אם האודיו מופרע מקומית

• audioModeratorMuted = אם האודיו מתמנע על ידי המודרייטורים

• isModerator = אם זה מתמקח

• יד מורמת = אם היד מורמת

• פעילות קול = אם הזרם יש פעילות קול

• הקלטה = אם השותף הקלטת את הוועידה

API חדש

שיטה חדשה (בCallManager) וסיגנל חדש לקבל מידע ועדכונים של הכנסים הנוכחיים זמינים:

VectorMapStringString getConferenceInfos(const std::string& confId);

void onConferenceInfosUpdated(const std::string& confId, const VectorMapStringString& infos);

האובייקט של Conference (שמקיים רק אם אנחנו מערבבים שיחות, זה אומר שאנחנו הבעלים) מנהל את המידע של כל הוועידה, על בסיס LayoutInfos של כל אובייקט של Call.

אז, כל Call אובייקט עכשיו יש מידע תארים ואם עדכון, לבקש את Conference אובייקט עדכון המידע שלו.

מנהל שלועידה שולח את המידע שלו דרך ערוץ SIP כודעת עם סוג MIME הבא: application/confInfo+json

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

לסיכום, Call ניהול תכנונים קיבל, Conference-managed תכנונים נשלחו.

שינוי מצב הקונפרנס

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

לפרוטוקול יש את הצרכים הבאים:

הוא צריך לטפל בהזמנות ברמות מרובות. למעשה, עבור מסיבה זה 3 רמות להגדיר משתתף:

• החשבון שהוא זהות המשתתף

• מכשירים, כי כל חשבון יכול להצטרף באמצעות מכשירים רבים

• מדיה, כיוון שיכול להיות מספר סרטונים על ידי מכשירים (למשל, מצלמה אחת וחלוקת מסך אחד)

כדי לחסוך רוחב קו, הלקוחות צריכים להיות מסוגלים לשלוח הזמנות מרובות בו זמנית.

פעולות כלליות

כדי לשנות את תכנון, המודרטור יכול לשלוח עומס מועיל עם ”הבקשה/הסדר+json“ כתיב: שבו 0 הוא רשת, 1 הוא משתמש אחד בגדול, אחרים בקלות, 2 הוא אחד בגדול

פעולות החשבון

לעת עתה, אין פעולה תומכת, עם זאת, בעתיד מודרייטור: נכון/לא נכון צריך להיות מטופל כדי לשנות מנהל.

פעולות המכשיר

• hangup: true לתלות מכשיר מהעידת (רק מתרגלים)

• raisehand: true/false לשנות את מצב היד הרמה. רק ניתן לעשות על ידי המכשיר עצמו, אחרת נפל.

פעולות התקשורת

• muteAudio רק מתאמים יכולים להשתיק את הקול של משתתף

• muteVideo עדיין לא תומך.

• active להדגים את התקשורת כפעילה.

• קולפעילות להדגיש את מצב הפעילות הקולית של זרם מדיה (משמע רק לאודיו)

דוגמה

So, the application/confOrder+json will contain:

{
    "989587609427420" : {
        "moderator": true, /* false  */
        "devices": {
            "40940943604396R64363": {
                "hangup": true,
                "raisehand": true, /* false */
                "media":{
                    "3532532662432" : {
                        "muteAudio": true, /* false */
                        "muteVideo": true, /* false */
                        "active": true, /* false */
                        "voiceActivity": true /* false */
                    }
                }
            }
        }
    },
    "layout": 0, /* 1, 2 */
}

הערה: סוג התקשורת צריך להיות כלול במידע של מסיבות וניתן להשתמש בו עבור הלקוח כדי לשפר את הצגה (למשל, אל תשתף מסך)

שליטה במודרייטורים

למעשה יש 3 אפשרויות:

• קונפיגור של חשבון שינוי כדי להוסיף רשימה של מתמודדים (ב config.yml (defaultModerators יכול להכיל רשימה של מתמודדים דפוטים)

• אם localModeratorsEnabled נכון, כל החשבונות של המכשיר יהיו מתמודדים

• אם allModeratorsEnabled נכון, כל אחד בוועידה יהיה מודרטור

עתיד

• זרמים נפרדים כדי לאפשר יותר שליטה?

הערות/הערות

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