Англійська для розробників WebRTC
Освоєння англійської лексики, яку розробники використовують для сигналізації, переговорів ICE і медіа- доріжок під час обговорення коду аудіо і відео у реальному часі з командою.
Репутація WebRTC як важкої для зневадження походить в основному від плутанини словника — «виклик не з’єднається» може означати помилку сигналізації, помилку переговорів ICE або невідповідність медіа-кодека, і кожен з них вимагає абсолютно іншого виправлення. Команда, яка точно називає шар, може сортувати за хвилини, а не за години. Цей посібник містить інформацію англійською мовою, яку використовують під час обговорення коду WebRTC з командою.
Ключовий словник
** Сигналізація ** — процес поза діапазоном (WebRTC не визначає його, тому він побудований з WebSockets або подібним) обміну описами сеансів і кандидатами між учасниками до того, як з’ єднання може бути встановлено. “Виклик зазнає невдачі перед будь-яким потоком медіа, і консоль браузера не показує жодних помилок ICE — це вказує на проблему сигналізації, а не проблему з’єднання WebRTC.”
** SDP (Session Description Protocol) ** — текстовий формат, що описує можливості сеансу мультимедіа (кодек, роздільна здатність, ключі шифрування), обмін як пропозиція і відповідь між учасниками під час сигналізації.
- “В відповіді SDP віддаленого вузла не вказано кодек, який пропонує наша сторона — це невідповідність у переговорах SDP, а не проблема мережі.” *
** Кандидат на ICE ** — потенційний мережевий шлях (локальний IP, адреса, відображена NAT через STUN, або ретранслювана адреса через TURN), який WebRTC збирає і обмінюється, щоб знайти маршрут між двома вузлами. “Ми збираємо тільки кандидатів на хости, а не кандидатів на STUN або TURN — саме тому це не спрацьовує між двома вузлами в різних мережах, але працює добре в одній і тій же локальній мережі.”
STUN / TURN сервер — сервер STUN допомагає вузлу виявити його публічну адресу за NAT; сервер TURN ретранслює медіа- трафік повністю, коли прямий шлях вузла до вузла неможливий. “Це з’єднання успішно тільки через реле TURN, ніколи не безпосередньо - це говорить нам, що ми маємо справу з симетричним NAT, який STUN сам по собі не може перетнути.”
** Переговори щодо ICE** — процес обміну і перевірки пар кандидатів між двома вузлами для пошуку робочого шляху мережі, який може закінчитися успіхом, невдачею або займе неочікувано довгий час, залежно від умов мережі. “Переговори ICE застрягли у стані «перевірки» протягом десяти секунд, поки не зазнали невдачі — давайте перевіримо, чи наші дані для входу на сервер TURN є дійсними.”
** Медіа доріжка (і переоцінювання) ** — окремий аудіо або відео потік, доданий до з’ єднання з одноранговим вузлом; додавання або вилучення доріжок після початкового з’ єднання вимагає переоцінювання обміну пропозицією/ відповіддю SDP. “Додання доріжки спільного використання екрана під час виклику вимагає перезапуску — ми не можемо просто приєднати її до існуючого з’ єднання однорангового зв’ язку і очікувати, що віддалена сторона підбере її автоматично.”
Звичайні фрази
- Чи це не вдається при сигналізації, або після сигналізації під час переговорів ICE?
- Чи ми збираємо STUN і TURN кандидатів, чи тільки хост-кандидатів?»
- Чи є це невідповідністю SDP, або справжньою помилкою з’єднання?
- Чи додавання цієї доріжки вимагає переговорів, або її можна додати до існуючого з’єднання?
- «Чи використовується реле TURN, що означає, що прямий peer-to-peer не працює тут?»
Приклади висловлювань
Перегляд запиту на звантаження: “Цей код розриває і відтворює все однорангове з’ єднання лише для додавання доріжки спільного використання екрана — давайте зробимо належне перезаписування замість цього, щоб існуючі аудіо і відео доріжки не були перервані.”
Пояснення рішення про проектування:
- “Ми розгорнули наш власний сервер TURN, а не покладаючись тільки на STUN, тому що значний відсоток наших користувачів знаходяться за симетричними NAT, де з’єднання тільки STUN постійно не працює.” *
Опис події: “Виклики між двома конкретними офісними мережами зазнавали невдачі, і виявилося, що їх брандмауер блокував UDP-порти, необхідні STUN — TCP-заснований TURN як резервний виправив це.”
Професійні поради
- Скажімо **“сигналізація помилки” ** проти **“ICE переговорів помилки” ** точно - вони вказують на абсолютно різні частини стека і різні люди, як правило, володіють виправлення.
- При сортуванні проблем з’єднання, запитайте “які кандидати ми збираємо, і яка пара насправді успішно?” - це відразу ж сужає проблеми пересування NAT.
- Використовуйте « перезатвердження », коли описуєте додавання або вилучення доріжок під час виклику — це правильний термін, який відрізняє його від повного перез’ єднання.
- Розрізняти “STUN” (визначення вашої власної адреси) від “TURN” (пересилання трафіку, коли пряме з’ єднання зазнає невдачі) — їх об’ єднання неправильно діагностує проблеми з’ єднання.
Практичні вправи
- Поясніть двома реченнями різницю між помилкою сигналізації і помилкою переговорів ICE.
- Напишіть одне речення з поясненням того, коли потрібен сервер TURN замість однієї лише STUN.
- Опишете вашими словами, чому додавання нової доріжки медіа у середині виклику вимагає перезапуску.
Основні наукові праці: «Професійна діяльність
Як ми вже досліджували в цій статті, розуміння специфічного словника навколо WebRTC - сигналізації, ICE, медіа-треків - має вирішальне значення для ефективного співробітництва. Однак, для не-рідних носіїв англійської мови, просто знати визначення недостатньо. Спосіб, у який ви пояснюєте ці поняття, має таке ж велике значення, особливо, коли ви обговорюєте технічні деталі у професійному середовищі. Це часто включає нюансовані фрази і розуміння загальних очікувань щодо ясності і точності. Це про передачі вашого розуміння впевнено і значний внесок у дискусії, навіть якщо ваш перший проект не ідеально відшліфований. Не бійтеся запитати про пояснення - справжня цікавість завжди цінується. Пам’ятайте, мета не бездоганна граматика; це чітке спілкування.
Частий виклик виникає під час перегляду коду. Розглянемо цей сценарій: старший розробник, Сара, залишає коментар до PR, надісланого Давидом щодо логіки переговорів щодо аудіодоріжки. Замість того, щоб просто сказати «Це потрібно виправити», вона пише: «Я бачу деякі потенційні неефективності в тому, як ми обробляємо резервні кодеки тут. Чи можете ви розглянути обґрунтування пріоритету libopus над vp8 в цьому конкретному сценарії? Можливо, додавання перевірки, щоб переконатися, що пропускна здатність мережі користувача відповідає вимогам opus щодо бітованої швидкості, покращить стабільність. “ Зауважте різницю. Сара не просто вказує на проблему; вона спонукає Девіда пояснити своє мислення, демонструючи спільний підхід і підступно пропонуючи можливе рішення. Аналогічно, в каналах Slack, де обговорюються проблеми з продуктивністю, короткі фрази на кшталт «Дослідимо потенційний тригер, що впливає на переговори ICE» є набагато ефективнішими, ніж нечітка скарга на те, що «це не працює правильно». Бути конкретним з вашими спостереженнями - особливо при описі *впливу * проблеми - це ключ до вирішення проблем.
Інша поширена ситуація включає створення чітких описів PR. Розробник, Maria, додає підтримку для WebRTC SRST (Simultaneous Receiving Stream Transport) функції. Замість короткого «Додано SRST», вона пише: «Вреалізована підтримка SRST, що дозволяє клієнту динамічно регулювати його відеобітрейт на основі умов мережі і можливостей приймача. Це зменшує потенційні обмеження пропускної здатності і покращує сприйняту якість під час періодів коливань з’єднання. Реалізація використовує функціональність ffmpeg’s filtergraph для виконання масштабування і передачі в реальному часі. Потрібні подальші тестування для оцінки продуктивності під різними навантаженнями мережі.” Подробиці в описі Марії демонструють ретельне розуміння функції, її переваг і того, як вона була реалізована. Вона також запрошує до подальших питань і дозволяє рецензентам швидко зрозуміти обсяг змін.
Нарешті, пам’ятайте, що активне слухання відіграє величезну роль. Коли хтось пояснює складну концепцію, не чекайте, поки прийде ваша черга говорити. Перефразуйте те, що ви чули, щоб підтвердити розуміння: « Отже, якщо я правильно зрозумів, ви кажете, що нам слід приоритизувати використання кандидатів ICE з сервера для покращення стабільності? » Цей простий акт демонструє залучення і зменшує ймовірність непорозумінь. Вона також дає можливість для пояснення — «Чи можете ви розібратися, чому цей конкретний кандидат є перевагою?»
Ось простий приклад, який показує, як використовувати ffmpeg для аналізу бітова швидкість потоку медіа:
ffmpeg -i input.mp4 -f null - | openssl tsp -base64