SDP

Модель TCP/IP (RFC 1122)
Прикладний рівень
BGP DHCP DNS FTP Gopher GTP HTTP HTTPS IMAP IRC LDAP MGCP MQTT NNTP NTP POP3 RIP RPC RTCP RTP RTSP SDP SIP SMTP SNMP SOAP SSH STUN Telnet TLS/SSL VNC XMPP докладніше
Транспортний рівень
TCP UDP DCCP SCTP RSVP ECN докладніше
Мережевий рівень
IP IPv4 IPv6 ICMP ICMPv6 IGMP IPsec докладніше
Канальний рівень
ARP RARP NDP MPLS OSPF Tunnels (L2TP) MAC-адреса Ethernet DSL ISDN FDDI Драйвер докладніше

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

Таблиці

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

Назва	Сесія або медіа рівні	Залежно від кодування
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

Посилання

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