SDP

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

SDP (англ. Session Description Protocol, протокол опису сеансу зв’язку) — мережевий протокол, призначений для опису сеансу передачі потокових даних, включаючи телефонію ТМЗК і VoIP, інтернет-радіо та програми мультимедіа.

Історія створення[ред.ред. код]

Session Description Protocol (SDP) була спочатку задумана, як спосіб описання багатоадресних сесій, здійснюється на Mbone. Сесія оголошення Protocol (SAP) була розроблена в якості групового механізму для просування SDP повідомлень. Хоча специфікаціяSDP дозволяє одноадресні операції, вона не є повною. На відміну від групових, де є загальне уявлення про роботу сесії, яка використовується у всіх учасників одноадресної сесій залучивши двох учасників, і для повної уяви про сесію потрібна інформація від обох учасників, та угода про параметри між ними. Як, наприклад, групова сесія вимагає передачу одного групового адреса для конкретного потоку засобів масової інформації. Однак, для одноадресної сесії, дві адреси необхідні - по одному для кожного учасника. В якості іншого прикладу, групова сесія вимагає вказівки які кодеки будуть використовуватися в роботі сесії. Однак, для одноадресних, набір кодеків повинен бути визначений шляхом знаходження перекриття в множині підтримки кожного учасника. У результаті SDP виразності, щоб описати одноадресні сесії, відсутня семантика й оперативні деталі про те,як це фактично робиться. У цьому документі засоби, які визначенні, як прості речення / відповідь модель, заснована на SDP. У цій моделі, один з учасників сесії генерує повідомлення, що SDP являє собою пропозицію - набір медіа-потоків і кодеки які оферент хоче використовувати, поряд з адресами IP і портами оферента хотіли б використовуватися для отримання інформації. Пропозиція передачі іншому учаснику, називається відповіддю. Відповідальник генерує відповідь, повідомлення SDP, яка реагує на пропозицію надану оферентом. Відповідь відповідних засобів масової інформації є потоком для кожного потоку в реченні, яке вказує, чи є потік прийнятим чи ні, поряд з кодеками, які будуть використовуватися з IP адресами та портами, які відповідальник хоче використовувати для отримання інформації. Це також можливо для багатоадресної сесії на роботу, аналогічну одноадресної один, його параметр узгоджуються між парою користувачів у разі одноадресних, але обидві сторони посилають пакети з тією ж груповою адресою. У цьому документі також обговорюються застосування пропозиція / відповідь моделі багатоадресних потоків. Ми також встановлюємо правила такі як пропозиція / відповідь модель використовується для оновлення сесії після первинної пропозиції / відповідь обміну. Кошти, які пропонує і відповіді передаються за межами рамки цього документа. Пропозиція / відповідь моделі визначається обов'язковим механізмом базового використання Session Initiation Protocol ('SIP).

Терміни, які використовуються в даному документі[ред.ред. код]

Агент, агент реалізації протоколу, який бере участь у Пропозиція / відповідь обміну. Є два агенти, які беруть участь у Пропозиція / відповідь обміну. Відповідь: повідомлення SDP відповідає відповіді на пропозицію отриману від оферента. Відповідальний: агент, який отримує сесії з іншого агента описує аспекти бажаного ЗМІ зв'язку, а потім відповідь на це зі своєю сесії опис. Пропозиція: повідомлення SDP надіслана оферентом. Оферент: агент, який генерує сесії опису з метою створення або зміни сесії.

Протоколи операцій[ред.ред. код]

Пропозиція про обмін/відповідь про наявність більш високого рівня протоколу (такого як SIP), який здатний обмінюватися SDP з метою створення сесії між агентами. Протокол операції починається тоді, коли один агент посилає первинну пропозицію для іншого агента. Пропозиція початкова, якщо вона знаходиться поза будь-яким контекстом, що може бути встановлено в більш високому рівні протоколу. Передбачається, що вищий шар протоколу забезпечує зміст якогось контексту, який дозволяє різний SDP обмін, що пов'язаний між собою. Агент отримавши пропозицію може викликати відповідь, чи може відхилити пропозицію. Засоби для відхилення пропозиції залежать від більш високого рівня протоколу. Пропозиція / відповідь обміну автономна, якщо відповідь буде відхилена, сесія переходить у стан, що передує пропозиція ( може бути відсутність сесії). У будь-який час, будь який агент може генерувати нову пропозицію, що оновлює сесію. Однак, він не повинен генерувати нову пропозицію, якщо вона має отриману пропозицію на яку він ще не відповів чи не відхилив. Крім того, він не повинен генерувати нову пропозицію, якщо вона викликала первинні пропозиції, для яких він ще не отримав відповіді на виклик або відмову. Якщо агент отримує пропозицію після того, як послав пропозицію, але до отримання відповіді на неї, це вважається "засліплення" . Термін засліплення спочатку використовувався в комутованих телекомунікаційних мережах, щоб описати стан, при якому два перемикачі спробували захопити доступні замикання в той самий момент часу. Ось, це означає, що агент намагався відправити оновлення запропонування в той же час. Чим вищий шар протоколу тим більші кошти необхідно надати для вирішення таких умов впорядкування повідомлень у кожному напрямку. SIP відповідає цим вимогам.

Схеми мережевих протоколів[ред.ред. код]

Сесія SDP може реалізовувати декілька потоків даних. У протоколі SDP в наш час[Коли?] визначені аудіо, відео, дані, управління і додатки (потокові), подібні до MIME типами електронної пошти в Інтернет-адресах.
Повідомлення SDP, що передається від одного вузла іншому може вказувати:
  • адреси місця призначення, які можуть бути для медіа-потоків мультикастинга-адресами
  • номери UDP портів для відправника та одержувача
  • медіа-формати (наприклад кодеки), які можуть застосовуватися під час сесії
  • час старту і зупинки. Використовується у випадку широкомовних сесій, наприклад, телевізійних або радіопрограм. Можна внести час початку, завершення і часи повторів сесії
Попри те, що Session Description Protocol надає можливість опису мультимедіа-даних, у ньому не вистачає

механізмів узгодження параметрів сесії, які мають намір використовувати партнери. Документ RFC 3264 надає модель узгодження на основі механізму пропозиції / відгуку, в якій вузли обмінюються SDP повідомленнями з метою досягти порозуміння щодо формату даних, в якому буде здійснюватися обмін.

Таблиці[ред.ред. код]

Таблиця основних функцій , сесій та рівнів

Назва Сесія або медіа рівні Залежно від кодування
cat Session No
tool Session Yes
ptime Session No
maxptime Media No
rtpmap Media No
recvonly Media No
sendrecv Either No
sendonly Either No
inactive Either No
orient Either No
type Session No
charset Session No
sdplang Either No
lang Either No
framerate Media No
quality Media No
fmtp Media No

Приклад SDP повідомлення[ред.ред. код]

v=0
o=- 1815849 0 IN IP4 194.67.15.181
s=Cisco SDP 0
c=IN IP4 194.67.15.181
t=0 0
m=audio 20062 RTP/AVP 99 18 101 100
a=rtpmap:99 G.729b/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202