У Lync майже кожен клієнт або сервер може бути клієнтом ICE (наприклад Front-End AVMCU, Mediation Server, Windows Client) і використовувати Edge Server для зв'язку між собою (наприклад сеанс аудіо зв'язку). При цьому Edge Server визначається як ICE сервер забезпечує інформацією ICE клієнтів для ініціалізації сеансу зв'язку.
ICE надає два рівня рішення, при цьому кожен клієнт Lync і Lync сервер можуть використовувати їх для зв'язку між собою.
ICE сервер (стосовно Lync - це роль Edge) використовується для настройки медіа сесії. Основна відмінність між цими двома рішеннями - це те, що медіа трафік йде безпосередньо між клієнтами у випадку з STUN і ретранслюється через Edge Server у випадку з TURN.
Слід розуміти, що іноді обраний шлях не може бути кращим вибором протягом всієї сесії. Тому Lync підтримує механізм Candidate Promotion (через SIP - Re-INVITE), який забезпечує зміну шляху медіа трафіку під час сеансу без втрат медіа даних або сигналізації. На практиці подібний сценарій зустрічається рідко, так як перший кандидат є кращим (а часто і єдиним).
Сценарії установки медіа сеансу
Сценарій External Peer-to-Peer
У даному сценарії описаний випадок, коли обидва клієнти зовнішні, наприклад один користувач перебуває вдома, а інший в готелі. Такий випадок досить поширений, унаслідок частого використання територіально віддалених співробітників працюють з дому, а також співробітників перебувають у відрядженні.
- Найкращий шлях завжди є локальним (на малюнку він позначений червоним кольором) тому при знаходженні клієнтів в одній мережі вони ніколи не будуть використовувати Edge. Але в цьому сценарії два клієнта знаходяться в різних мережах, тому безпосередньо з'єднається у них не вийде.
- Наступним варіантом є використання «reflexive candidate» - забезпечується Edge сервером (використовуючи STUN). У більшості випадків таке з'єднання буде дозволено брандмауером мережі абонента. Як це працює описано в наступному розділі.
- Коли всі інші варіанти будуть недоступні, Lync буде використовувати Edge Server в якості релея.
У підсумку можна описати ситуацію таким чином: після визначення неможливості з'єднається безпосередньо вибирається шлях через брандмауери цих мереж, і якщо це неможливо то використовується Edge Server в якості ретранслятора медіа трафіку.
Сценарій Mixed Peer-to-Peer
У цьому сценарії один абонент знаходиться в своїй домашній мережі (тобто зовнішній клієнт) а інший знаходиться в корпоративній мережі (тобто внутрішній клієнт).
- Так само як і в попередньому сценарії, прямий шлях неможливий, оскільки зовнішній клієнт не зможе знайти локальний ip внутрішнього клієнта
- Сервер reflexive кандидата внутрішнього клієнта має публічний ip корпоративного брандмауера, і часто корпоративний брандмауер не дозволяє STUN трафік на внутрішнього клієнта з метою його захисту, тому перевірка доступності вузла в цьому випадку не пройде. В цьому випадку Lync буде використовувати наступний спосіб зв'язку.
- Так як всі інші способи недоступні Lync буде використовувати Edge Server в якості релея.
У цьому сценарії корпоративний брандмауер не дозволить використовувати STUN так як необхідно буде створювати окремі правила для кожного клієнта в корпоративній мережі що абсолютно неприпустимо, тому буде використовуватися Edge Server в якості релея.
У цьому сценарії присутні кілька клієнтів і серверних ролей Lync.
Вихідні дані: зовнішній клієнт (припустимо з дому) підключається до конференції і відправляє свої медіа дані на Front End Server.
- У випадку з конференцією внутрішні абоненти транслюють трафік на Front End.
- FE у випадку з зовнішніми клієнтами поводиться також як і внутрішні клієнти Lync в попередньому прикладі, тобто транслює медіа трафік через Edge Server.
- Edge Server є ICE сервером, оскільки він забезпечує зв'язок між клієнтами шляхом надання інформації про кандидатів на початку, і ретрансляції даних протягом всієї конференції.
- Внутрішні клієнти передають дані, ігноруючи Edge Server. Edge будуть використовувати тільки зовнішні клієнти (наприклад федеративні Lync клієнти).