Azərbaycanca AzərbaycancaБеларускі БеларускіDansk DanskDeutsch DeutschEspañola EspañolaFrançais FrançaisIndonesia IndonesiaItaliana Italiana日本語 日本語Қазақ ҚазақLietuvos LietuvosNederlands NederlandsPortuguês PortuguêsРусский Русскийසිංහල සිංහලแบบไทย แบบไทยTürkçe TürkçeУкраїнська Українська中國人 中國人United State United StateAfrikaans Afrikaans
Підтримка
www.wikidata.uk-ua.nina.az

SDP англ Session Description Protocol протокол опису сеансу зв язку мережевий протокол призначений для опису сеансу пере

SDP

SDP

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

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

SDP створювався як складова частина (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). . IETF. Архів оригіналу за 23 грудня 2016. Процитовано 25 липня 2010.


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

Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет

SDP angl Session Description Protocol protokol opisu seansu zv yazku merezhevij protokol priznachenij dlya opisu seansu peredachi vklyuchayuchi telefoniyu TMZK i VoIP internet radio ta programi multimedia SDP buv zadumanij dlya opisannya multimedijnih dlya anonsuvannya sesiyi zaproshennya sesiyi i uzgodzhennya parametriv SDP sam ne peredaye media dani a vikoristovuyetsya mizh vuzlami zv yazku dlya uzgodzhennya tipu media formatu i vsih pov yazanih z cim parametriv Nabir vlastivostej i parametriv nazivayetsya profilem sesiyi SDP peredbachaye mozhlivist rozshirennya dlya dodavannya novih tipiv media danih i formativ SDP stvoryuvavsya yak skladova chastina SAP ale znajshov inshe vikoristannya v poyednanni z protokolami Real time Transport Protocol RTP Real time Streaming Protocol RTSP Session Initiation Protocol SIP i navit yak samostijnij format dlya opisannya grupovih sesij Zagalni vidomostiSession Description Protocol SDP buv zadumanij yak sposib opisannya bagatoadresnih sesij v seredovishi Mbone Session Announcement Protocol SAP buv rozroblenij yak grupovij mehanizm dlya peredachi SDP povidomlen Hocha specifikaciya SDP dozvolyaye odnospryamovanu robotu vona ne ye povnoyu Na vidminu vid grupovoyi peredachi de ye zagalne uyavlennya pro robotu sesiyi yaka vikoristovuyetsya vsima uchasnikami odnoadresna sesiya maye dvoh uchasnikiv i dlya povna uyava pro sesiyu vimagaye nayavnist informaciyi vid oboh uchasnikiv ta uzgodzhennya parametriv mizh nimi Yak priklad grupova sesiya vimagaye nayavnosti odniyeyi grupovoyi adresi dlya konkretnogo potoku multimedijnih danih Odnak dlya odnoadresnoyi sesiyi neobhidno zadavati dvi adresi po odnij dlya kozhnogo uchasnika Nastupnij priklad grupova sesiya vimagaye viznachennya kodekiv yaki budut vikoristovuvatisya pri roboti sesiyi Odnak dlya odnoadresnih sesij nabir kodekiv povinen buti viznachenij shlyahom znahodzhennya peretinu v mnozhini kodekiv sho pidtrimuyutsya oboma uchasnikami sesiyi U rezultati hocha z SDP buv dosvid zastosuvannya dlya opisu odnoadresnih sesij v cij temi brakuye informaciyi pro semantiku i robochih detalej yak ce mozhna praktichno realizuvati Isnuyut prikladi realizaciyi cogo u viglyadi prostoyi modeli zapit vidpovid na osnovi SDP U cij modeli odin z uchasnikiv sesiyi generuye povidomlennya SDP sho yavlyaye soboyu zapit nabir media potokiv i kodekiv yaki storona sho robit zapit hoche vikoristovuvati a takozh IP adresi i porti yaki b kliyent hotiv bi vikoristovuvatisya dlya otrimannya informaciyi Kliyent peredaye ci povidomlennya inshomu uchasniku yakij nazivayetsya vidpovidachem Vidpovidach povertaye vidpovid takozh u viglyadi povidomlennya SDP na propoziciyu nadanu kliyentom Vidpovid mistit vidpovidnij media potik dlya kozhnogo potoku v zapiti i informaciyu pro te chi ye potik prijnyatim chi ni razom iz kodekami yaki budut vikoristovuvatisya z IP adresami ta portami yaki kliyent hoche vikoristovuvati dlya otrimannya informaciyi Analogichna robota yak z odnoadresnoyu sesiyeyu takozh mozhliva i pri roboti z grupovoyu sesiyeyu yiyi parametri uzgodzhuyutsya mizh parami koristuvachiv yak u vipadku iz odnoadresnoyu sesiyeyu ale obidvi storoni adresuyut svoyi paketi na odnu grupovoyu adresoyu Model Zapit vidpovid ye obov yazkovim bazovim mehanizmom vikoristannya protokolu Session Initiation Protocol SIP Termini yaki vikoristovuyutsya v danomu dokumentiAgent agent realizaciyi protokolu yakij bere uchast u Propoziciya vidpovid obminu Ye dva agenti yaki berut uchast u Propoziciya vidpovid obminu Vidpovid povidomlennya SDP vidpovidaye vidpovidi na propoziciyu otrimanu vid oferenta Vidpovidalnij agent yakij otrimuye sesiyi z inshogo agenta opisuye aspekti bazhanogo ZMI zv yazku a potim vidpovid na ce zi svoyeyu sesiyi opis Propoziciya povidomlennya SDP nadislana oferentom Oferent agent yakij generuye sesiyi opisu z metoyu stvorennya abo zmini sesiyi Protokoli operacijPropoziciya pro obmin vidpovid pro nayavnist bilsh visokogo rivnya protokolu takogo yak SIP yakij zdatnij obminyuvatisya SDP z metoyu stvorennya sesiyi mizh agentami Protokol operaciyi pochinayetsya todi koli odin agent posilaye pervinnu propoziciyu dlya inshogo agenta Propoziciya pochatkova yaksho vona znahoditsya poza bud yakim kontekstom sho mozhe buti vstanovleno v bilsh visokomu rivni protokolu Peredbachayetsya sho vishij shar protokolu zabezpechuye zmist yakogos kontekstu yakij dozvolyaye riznij SDP obmin sho pov yazanij mizh soboyu Agent otrimavshi propoziciyu mozhe viklikati vidpovid chi mozhe vidhiliti propoziciyu Zasobi dlya vidhilennya propoziciyi zalezhat vid bilsh visokogo rivnya protokolu Propoziciya vidpovid obminu avtonomna yaksho vidpovid bude vidhilena sesiya perehodit u stan sho pereduye propoziciya mozhe buti vidsutnist sesiyi U bud yakij chas bud yakij agent mozhe generuvati novu propoziciyu sho onovlyuye sesiyu Odnak vin ne povinen generuvati novu propoziciyu yaksho vona maye otrimanu propoziciyu na yaku vin she ne vidpoviv chi ne vidhiliv Krim togo vin ne povinen generuvati novu propoziciyu yaksho vona viklikala pervinni propoziciyi dlya yakih vin she ne otrimav vidpovidi na viklik abo vidmovu Yaksho agent otrimuye propoziciyu pislya togo yak poslav propoziciyu ale do otrimannya vidpovidi na neyi ce vvazhayetsya zasliplennya Termin zasliplennya spochatku vikoristovuvavsya v komutovanih telekomunikacijnih merezhah shob opisati stan pri yakomu dva peremikachi sprobuvali zahopiti dostupni zamikannya v toj samij moment chasu Os ce oznachaye sho agent namagavsya vidpraviti onovlennya zaproponuvannya v toj zhe chas Chim vishij shar protokolu tim bilshi koshti neobhidno nadati dlya virishennya takih umov vporyadkuvannya povidomlen u kozhnomu napryamku SIP vidpovidaye cim vimogam Shemi merezhevih protokolivSesiya SDP mozhe realizovuvati dekilka potokiv danih U protokoli SDP v nash chas koli viznacheni audio video dani upravlinnya i dodatki potokovi shozhih do MIME tipiv elektronnoyi poshti Povidomlennya SDP sho peredayetsya vid odnogo vuzla inshomu mozhe vkazuvati adresi miscya priznachennya yaki mozhut buti dlya media potokiv multikastinga adresami nomeri UDP portiv dlya vidpravnika ta oderzhuvacha media formati napriklad kodeki yaki mozhut zastosovuvatisya pid chas sesiyi chas startu i zupinki Vikoristovuyetsya u vipadku shirokomovnih sesij napriklad televizijnih abo radioprogram Mozhna vnesti chas pochatku zavershennya i chasi povtoriv sesiyi Popri te sho Session Description Protocol nadaye mozhlivist opisu multimedia danih u nomu ne vistachaye mehanizmiv uzgodzhennya parametriv sesiyi yaki mayut namir vikoristovuvati partneri Dokument RFC 3264 nadaye model uzgodzhennya na osnovi mehanizmu propoziciyi vidguku v yakij vuzli obminyuyutsya SDP povidomlennyami z metoyu dosyagti porozuminnya shodo formatu danih v yakomu bude zdijsnyuvatisya obmin TabliciTablicya osnovnih funkcij sesij ta rivniv Nazva Sesiya abo media rivni Zalezhno vid koduvannyacat Session Notool Session Yesptime Session Nomaxptime Media Nortpmap Media Norecvonly Media Nosendrecv Either Nosendonly Either Noinactive Either Noorient Either Notype Session Nocharset Session Nosdplang Either Nolang Either Noframerate Media Noquality Media Nofmtp Media NoPriklad SDP povidomlennyav 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 202PosilannyaRosenberg J Schulzrinne H June 2002 IETF Arhiv originalu za 23 grudnya 2016 Procitovano 25 lipnya 2010 Ce nezavershena stattya pro Internet Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi

Дата публікації:
Топ