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

SDP був задуманий для описаннямультимедійнихсесій передачі даних для анонсування сесії, запрошення сесії, і узгодження параметрів. SDP сам не передає медіа дані, а використовується між вузлами зв’язку для узгодження типу медіа, формату, і всіх пов’язаних з цим параметрів. Набір властивостей і параметрів називаєтьсяпрофілем сесії. SDP передбачає можливість розширення для додавання нових типів медіа даних і форматів.

SDP створювався як складова частинаSession Announcement Protocol (SAP), але знайшов інше використання в поєднанні з протоколамиReal-time Transport Protocol (RTP),Real-time Streaming Protocol (RTSP),Session Initiation Protocol (SIP) і навіть як самостійний формат для описаннягрупових сесій.

Session Description Protocol (SDP) був задуманий, як спосіб описаннябагатоадресних сесій в середовищіMbone.Session Announcement 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 повідомленнями з метою досягтипорозуміння щодо формату даних, в якому буде здійснюватися обмін.

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

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

• Rosenberg, J.; Schulzrinne, H. (June 2002).An Offer/Answer Model with the Session Description Protocol(RFC 3264).IETF. Архіворигіналу за 23 грудня 2016. Процитовано 25 липня 2010.

Це незавершена стаття проІнтернет. Ви можетедопомогти проєкту,виправивши або дописавши її.

• Інтернет-протоколи
• Інтернет-стандарти
• Java

• Статті, що потребують прояснення
• Незавершені статті про Інтернет
• Сторінки, що використовують магічні посилання RFC