Protokol o zřízení relace

doušek , inž.  Session Initiation Protocol , Session Initiation Protocol  - protokol přenosu dat , který popisuje způsob navázání a ukončení uživatelské komunikační relace, včetně výměny multimediálního obsahu ( IP telefonie , video a audio konference , rychlé zprávy , online hry ) [1] .

Tento protokol popisuje, jak může klientská aplikace (například softwarový telefon ) požádat o zahájení připojení od jiného, ​​možná fyzicky vzdáleného klienta ve stejné síti pomocí svého jedinečného názvu. Protokol definuje způsob, jak vytvořit komunikační kanál a vyjednat protokoly pro výměnu informací mezi klienty (např. protokol RTP se používá pro výměnu hlasových dat ). Je povoleno přidávat nebo odebírat takové kanály během vytvořené relace, stejně jako připojovat a odpojovat další klienty (to znamená, že konferenční hovor je poskytován, když se výměny mohou zúčastnit více než dvě strany). SIP také určuje pořadí, ve kterém relace končí [2] .

Vývojáři protokolu SIP

SIP byl vyvinut IETF MMUSIC Working Group [3] . Protokol začal vyvíjet v roce 1996 Henning Schulzrinne ( Columbia University ) a Mark Handley ( University College London ). V listopadu 2000 byl SIP schválen jako signalizační protokol 3GPP a základní protokol pro architekturu IMS ( modifikace 3GPP TS.24.229 [4] ) [5] . SIP je spolu s H.323  jedním z protokolů aktivně využívaných pro přenos hlasu přes internet ( Voice over IP ) .

Principy protokolu

Pracovní skupina MMUSIC založila protokol na následujících principech:

Návrh protokolu

Klienti SIP tradičně používají pro připojení síťových prvků SIP port TCP nebo UDP 5060 . SIP se v zásadě používá k navazování a odpojování hlasových hovorů a videohovorů. Zároveň jej lze použít v jakýchkoli jiných aplikacích, kde je vyžadováno připojení, jako jsou místní rozhlasové stanice, mobilní terminály a podobně. Existuje velké množství RFC souvisejících se SIP , které definují chování takových aplikací. Pro přenos samotných hlasových a obrazových dat se používají jiné transportní protokoly, nejčastěji RTP .

Hlavním cílem při vývoji SIP bylo vytvořit signalizační protokol na bázi IP , který by mohl podporovat rozšířenou sadu funkcí a služeb pro zpracování hovorů poskytovaných stávající PSTN . Samotný protokol SIP tyto funkce nedefinuje, ale zaměřuje se pouze na registraci uživatele, navázání a ukončení hovoru a související signalizaci. Zároveň byl navržen tak, aby podporoval takové funkční prvky sítě, jako jsou proxy servery (Proxy Servery) a User Agenty (User Agents). Tyto prvky zajišťují základní sadu služeb: vytáčení, volání na telefonní přístroj, zvukové upozornění účastníka na stav hovoru.

Telefonní sítě založené na SIP mohou také podporovat pokročilejší služby typicky poskytované SS-7 , a to navzdory významným rozdílům mezi těmito dvěma protokoly. SS-7 se vyznačuje složitou, centralizovanou inteligentní sítí a jednoduchými, neinteligentními terminály (tradiční telefony). SIP naopak vyžaduje velmi jednoduchou (a tedy vysoce škálovatelnou) síť s inteligencí zabudovanou do koncových prvků na okraji (terminály postavené jako fyzická zařízení nebo programy).

SIP se používá spolu s několika dalšími protokoly a účastní se pouze signalizační části komunikační relace. SIP funguje jako nosič pro SDP , který popisuje parametry přenosu médií v rámci relace, jako jsou IP porty a použité kodeky . V typické aplikaci jsou relace SIP jednoduše proudy paketů RTP . RTP je přímým nositelem hlasových a obrazových dat.

První navrhovaná verze standardu (SIP 2.0) byla definována v RFC 2543 . Protokol byl dále vylepšen v RFC 3261 , ačkoli mnoho implementací je stále založeno na přechodných verzích standardu. Všimněte si, že číslo verze zůstává 2.0.

Adresování

Pro interakci se stávajícími síťovými aplikacemi IP a pro zajištění mobility uživatelů používá SIP adresu podobnou e-mailové adrese . Volané a volající adresy jsou Uniform Resource Pointers URI , tzv. SIP URI , obvykle ve formátu sip:идентификатор@домен, kde „identifikátor“ je jméno účastníka nebo telefonní číslo a „doména“ specifikuje server nebo IP-PBX, které lze specifikovat název domény nebo IP adresu.
Příklady:

Standard URI je specifikován v RFC 3986 .

Adresa má dvě části. První částí je jméno uživatele registrovaného v doméně nebo pracovní stanici. Druhá část adresy určuje název síťové domény, hostitele nebo IP adresu. Pokud druhá část identifikuje telefonní bránu, pak první část označuje telefonní číslo účastníka.

Uživatelská jména jsou pouze alfanumerické identifikátory. V IP telefonii se zpravidla používají čistě digitální identifikátory („čísla“) pro usnadnění rozšíření / nahrazení klasických telefonních sítí. Místní telefonní čísla mají obvykle 2-3-4 číslice.

Telefonní číslo přenášené na bránu je jakékoli dostupné přes ni, může to být buď číslo místní přípojky, nebo číslo mobilního či pevné linky. Adresa brány (IP adresa nebo název domény) se nastavuje v nastavení telefonu nebo klientského programu a uživateli stačí vytočit číslo, aby mohl uskutečnit hovor.

Architektura sítě

Protokol SIP má architekturu klient-server.

Klient vydává požadavky s uvedením toho, co chce od serveru přijímat. Server přijímá a zpracovává požadavky a vydává odpovědi obsahující oznámení o úspěchu požadavku, oznámení o chybě nebo informace požadované klientem.

Služba volání je distribuována mezi různé prvky sítě SIP. Hlavním funkčním prvkem, který implementuje funkce správy připojení, je uživatelský terminál. Jiné prvky sítě mohou být zodpovědné za směrování hovorů a někdy slouží k poskytování doplňkových služeb.

Terminál

Když jsou klient a server implementovány v koncovém zařízení a komunikují přímo s uživatelem, nazývají se User Agent Client ( anglicky  UAC , user agent client) - a User Agent Server ( anglicky  UAS , user agent server). Pokud jsou na zařízení přítomny UAC i UAS, pak se nazývá User Agent ( UA , uživatelský agent) a je to v podstatě SIP terminál .

Server ( UAS ) a klient ( UAC ) mají možnost přímé interakce s uživatelem. Ostatní klienti a servery SIP to neumí.

Proxy server

Proxy server (z anglického  proxy  – „representative“) zastupuje zájmy uživatele v síti. Přijímá požadavky, zpracovává je a provádí příslušné akce. Proxy server se skládá z klientské a serverové části, takže může přijímat volání, iniciovat požadavky a vracet odpovědi.
Proxy server nesmí měnit strukturu a obsah přenášených zpráv, pouze přidává informace o své adrese do speciálního pole Via.

Existují dva typy proxy serverů

Proxy může uživateli v reakci na první požadavek naznačit nutnost dodatečné autentizace - minimálně přihlášení (odpověď 407 Požadováno ověření proxy ), vč. digitální autentizace pro bezpečnost.

Server B2BUA

B2BUA - ( anglicky  back-to-back user agent , doslova: "back-to-back user agent") - varianta logického prvku serveru v aplikacích pracujících s protokolem SIP. B2BUA je konceptem podobný SIP proxy serveru , ale existují zde zásadní rozdíly. B2BUA server pracuje současně s několika (většinou dvěma) koncovými zařízeními - terminály a rozděluje hovor nebo relaci do různých sekcí. B2BUA pracuje s každým místem individuálně, jako UAS - ve vztahu k iniciátorovi a jako UAC - ve vztahu k terminálu přijímajícímu hovor. V tomto případě jsou signalizační zprávy přenášeny v rámci relace v obou směrech synchronně, ačkoli rozhodnutí o potřebě přenosu zprávy a jejím formátu činí B2BUA pro každou sekci samostatně. Každý z účastníků spojení (komunikační relace) na signalizační vrstvě interaguje s B2BUA jako s koncovým zařízením, ačkoli ve skutečnosti je server prostředníkem. To se odráží v adresových polích (jako Od, Komu a Kontakt) zpráv zasílaných serverem B2BUA. Klíčovým rozdílem mezi B2BUA je tedy zcela nezávislá signalizace všech úseků volání. To zejména znamená, že k interakci s každým jednotlivým uživatelem v rámci komunikační relace se používají jedinečné identifikátory a obsah stejných zpráv pro různé stránky se bude lišit. Uživatelští agenti koncových terminálů mohou komunikovat s B2BUA a za účasti proxy serverů.

Server B2BUA může poskytovat následující funkce:

Docela často je B2BUA součástí mediální brány , aby bylo možné plně spravovat mediální toky v rámci relace. Signalizační brána, která je součástí Connection/Session Border Controller  , je ukázkovým příkladem aplikace B2BUA.

Server přesměrování

Přesměrovací server se používá k přesměrování hovoru na aktuální umístění uživatele. Server přesměrování neukončuje hovory a neiniciuje své vlastní požadavky, ale pouze hlásí adresu požadovaného terminálu nebo proxy serveru pomocí odpovědí třídy 3XX ( 301 Trvale přesunuto nebo 302 Dočasně přesunuto ). Pro tyto účely může přesměrovací server spolupracovat s registrátorem SIP nebo lokalizačním serverem.

Uživatel však nesmí k navázání spojení použít přesměrovací server, pokud sám zná aktuální adresu požadovaného uživatele.

Registrační server (registrátor)

Protokol SIP znamená mobilitu uživatele, to znamená, že se uživatel může pohybovat v síti získáním nové adresy. Proto má SIP registrační mechanismus – upozornění na novou adresu od uživatelského agenta. Registrační server neboli registrátor ( registrátor ) slouží k fixaci a uložení aktuální adresy uživatele a je pravidelně aktualizovanou databází adresních informací. Obecně platí, že uživatel poskytuje registračnímu serveru informace o své adrese, jako je IP adresa nebo název domény a telefonní číslo předplatitele, pomocí požadavku REGISTER. Server může potvrdit úspěšnou registraci ( 200 OK) nebo odmítnout, pokud probíhá kontrola dat a uživatelský účet není nalezen ( 404 Not found) nebo je registrace uživatele aktuálně zakázána ( 403 Forbidden). Registrátor může uvést potřebu přihlášení uživatele pro ověření ( 401 Unauthorized), zatímco může klientovi nabídnout ověření na základě zašifrovaného hesla. Zařízení nebo software, který nepoužívá protokol SIP (například DBMS , MS Exchange , RADIUS server atd.), může sloužit jako zdroj informací pro autentizaci uživatele. Registrace koncového zařízení uživatele na serveru má určitou „životnost“ a musí být potvrzena novým požadavkem REGISTERklienta, jinak může dojít ke smazání údajů o adrese. Klient může také odeslat požadavek s nulovou životností registrace - požadavek na vynucení odstranění informací o adrese ze serveru (dokončení registrace).

V různých implementacích sítí SIP může existovat kombinace registračního serveru a dalších serverů v jedné aplikaci nebo zařízení, které pracuje přes jeden soket na jednom portu (obvykle UDP / 5060) - tedy jeden bod pro příjem a zpracování žádostí. Registrátory jsou tak často kombinovány s přesměrovacím serverem, B2BUA nebo SIP proxy. Například mnoho softwarových ústředen (například Asterisk , Yate , RTU ) obsahuje funkcionalitu SIP registrátora s ověřením registračních údajů každého uživatele. Informace o možnosti uživatele registrovat se a navazovat spojení je v tomto případě určena jeho jediným účtem. Na druhé straně účastnická zařízení IP telefonie ( telefony , účastnické brány ) ve většině případů vyžadují povinnou předregistraci na serveru pro další práci v telefonní síti.

Výsledkem je, že IP telefonní systém může vypadat podobně jako mobilní komunikační systém – po zapnutí se všechna účastnická zařízení zaregistrují na ústředně (PBX) a poté mohou přes něj volat a přijímat hovory, což buď přesměruje požadavek na jiný konec. uživatele nebo předá požadavek jinému přepínači.

Server umístění uživatele

Uživatel se může pohybovat v rámci různých sítí, navíc skutečná adresa uživatele může být neznámá, i když je známo jeho číslo. To je relevantní zejména pro službu přenositelnosti čísel (LNP/MNP) . K vyřešení těchto problémů existuje mechanismus pro určování polohy uživatele pomocí nástrojů třetích stran, které přímo nesouvisejí se SIP - Location Server , který ukládá aktuální adresu uživatele a je pravidelně aktualizovanou databází informací o adrese.  

Uživatel, který potřebuje informace o adrese jiného uživatele k navázání spojení, nekontaktuje přímo server umístění. Tuto funkci provádějí jiné SIP servery pomocí LDAP , R WHOIS , ENUM , RADIUS nebo jiných protokolů.

Zprávy protokolu SIP

Zprávy protokolu SIP (požadavky a odpovědi) jsou sekvence textových řetězců zakódovaných v souladu s RFC 2279 . Struktura a syntaxe zpráv SIP jsou totožné se strukturami používanými v protokolu HTTP .

Struktura zpráv SIP
Startovní čára
Tituly
Prázdný řádek
Tělo zprávy

Příklad požadavku INVITE :

POZVAT sip:[email protected] SIP/2.0 Záznamová trasa: <sip:[email protected];lr> Přes: SIP/2.0/UDP 10.0.0.10;branch=z9hG4bK3af7.0a6e92f4.0 Přes: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK12ee92cb;rport=5060 From: "78128210000" <sip:[email protected]>;tag=as149b2d97 Komu: <sip:[email protected]> Kontakt: <sip:[email protected]> Call-ID: [email protected] CSeq: 103 INVITE Maximální počet vpřed: 16 Datum: středa, 10. ledna 2001 13:16:23 GMT Povolit: POZVAT, ACK, ZRUŠIT, MOŽNOSTI, BYE, REFEROVAT, ODBĚROVAT, OZNÁMIT Podporováno: nahrazuje Content-Type: application/sdp Délka obsahu: 394 v=0 o=kořen 3303 3304 IN IP4 10.0.0.10 s=relace c=IN IP4 10.0.0.10 t=00 m=audio 40358 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telefonní událost/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=sendrecv

Žádosti

Původní verze protokolu SIP (v RFC 3261 ) definovala šest typů požadavků. Pomocí požadavků klient hlásí aktuální polohu, zve uživatele k účasti na komunikačních relacích, upravuje již vytvořené relace, ukončuje je atd. Typ požadavku je uveden na startovacím řádku.

  1. INVITE  – Pozve uživatele ke komunikační relaci. Obvykle obsahuje popis SDP relace.
  2. ACK  – Potvrzuje přijetí odpovědi na požadavek INVITE .
  3. BYE  - ukončí relaci. Může být přenášen kteroukoli ze stran účastnících se relace.
  4. ZRUŠIT  - zruší zpracování dříve podaných požadavků, ale neovlivní požadavky, které již skončily zpracování.
  5. REGISTER  – nese informace o adrese pro registraci uživatele na lokačním serveru.
  6. OPTIONS  - Požaduje informace o funkčnosti serveru.

V budoucnu byl protokol rozšířen, bylo k němu přidáno několik dalších typů požadavků:

  1. PRACK  je dočasné potvrzení ( RFC 3262 ).
  2. SUBSCRIBE  - Přihlaste se k odběru upozornění na události ( RFC 3265 ).
  3. NOTIFY  - upozornění předplatitele na událost ( RFC 3265 ).
  4. PUBLIKOVAT  - Publikování události na serveru ( RFC 3903 ).
  5. INFO  - přenos informací, který nemění stav relace ( RFC 2976 ).
  6. REFER  - Požadavek příjemce na odeslání požadavku SIP ( RFC 3515 ).
  7. MESSAGE  - rychlé zasílání zpráv pomocí SIP ( RFC 3428 ).
  8. AKTUALIZACE  - Úprava stavu relace bez změny stavu dialogu ( RFC 3311 ).

Odpovědi na dotazy

Odpovědi na žádosti hlásí výsledek zpracování žádosti nebo předávají požadované informace. Protokol SIP zdědil strukturu odpovědí a jejich typy od protokolu HTTP . Je definováno šest typů odezev, které nesou různé funkční zatížení. Typ odpovědi je zakódován jako třímístné číslo, přičemž nejdůležitější je první číslice, která definuje třídu odpovědi:

  1. 1XX  - informační odpovědi; označují, že se žádost zpracovává. Nejběžnější odpovědi tohoto typu jsou 100 pokusů , 180 zvonění , 183 průběh relace .
  2. 2XX  - poslední odpovědi, které označují, že požadavek byl úspěšně zpracován. V současné době jsou v tomto typu definovány pouze dvě odpovědi - 200 OK a 202 Akceptováno (pozn. kód 202 není v RFC 3261 ).
  3. 3XX  jsou konečné odpovědi informující zařízení volajícího uživatele o nové poloze volaného uživatele, jako je dočasná odpověď 302 Moved .
  4. 4XX  - závěrečné odpovědi informující o odmítnutí nebo chybě při zpracování nebo realizaci požadavku, například 403 Zakázáno nebo klasická HTTP odpověď 404 Nenalezeno . Další příklady: 406 Neakceptovatelný  - nepřijatelný (obsahem) požadavek, 486 Zaneprázdněn zde  - účastník je zaneprázdněn nebo 487 Požadavek ukončen  - volající uživatel ukončil spojení bez čekání na odpověď (zrušení požadavku).
  5. 5XX  - poslední odpovědi informující, že požadavek nelze zpracovat z důvodu selhání serveru, 500 Interní chyba serveru .
  6. 6XX  - závěrečné odpovědi informující, že nelze navázat spojení s volaným uživatelem, např. odpověď 603 Odmítnout znamená, že volaný uživatel odmítl příchozí hovor.

Algoritmy navazování spojení

Protokol SIP je řídicí protokol pro navazování, úpravy a ukončování streamovaného datového spojení. Přenosové parametry mediálních toků jsou popsány v protokolu SIP pomocí SDP (Session Description Protocol). Streamovaná média lze přenášet různými způsoby, mezi nimiž jsou nejoblíbenější transportní protokoly RTP a RTCP .

Protokol SIP definuje 3 hlavní scénáře pro navázání spojení: s účastí proxy serveru, s účastí přesměrovacího serveru a přímo mezi uživateli. Scénáře se liší v tom, jak je volaný uživatel nalezen a pozván. Základní algoritmy navazování spojení jsou popsány v RFC 3665 .

Příklad scénáře nastavení připojení zahrnující server přesměrování SIP a SIP proxy

Příklad skriptu nastavení připojení zahrnující server B2BUA

V níže uvedeném příkladu je mediální provoz přenášen přes server. Signalizační zprávy pro segmenty Alice - B2BUA a B2BUA - Boris jsou zcela nezávislé a jsou prováděny v rámci různých relací (změní se alespoň cílová a odesílací adresa, stejně jako Call ID relací). Alicin terminál nezná skutečné umístění Borisova terminálu a naopak. Může to vypadat jako interakce prostřednictvím některých softswitchů nebo hraničních kontrolérů relace (SBC) .

SIP-T a SIP-I

Pro interakci s tradičními telefonními sítěmi využívajícími signalizaci SS-7 byly vyvinuty modifikace protokolu SIP pro telefonii: Session Initiation Protocol for Telephones (SIP-T) a Session Initiation Protocol Internetworking (SIP-I). Protokol SIP-I byl vyvinut ITU-T , doporučení Q.1912.5 [6] , a SIP-T byl vyvinut IETF a popsán v RFC 3372. Hlavním úkolem těchto modifikací protokolu SIP je transparentní přenos ISUP zprávy přes síť IP. Tento úkol je splněn zapouzdřením signalizačních jednotek SS do zpráv SIP. Všechny požadované úlohy pro interakci mezi protokoly byly vyřešeny na základě protokolu SIP:

Požadavek na interoperabilitu Funkce SIP-T
Transparentnost signalizace ISUP Zapouzdření ISUP v těle zprávy SIP
Schopnost směrovat zprávy SIP v závislosti na parametrech ISUP Překlad ISUP parametrů v hlavičce SIP zprávy
Překlad informací o adrese během navázaného spojení Pomocí metody INFO

Srovnání s H.323

SIP je čitelný pro člověka a strukturovaný z hlediska požadavků a odpovědí. Zastánci SIP také tvrdí, že je jednodušší než H.323 [7] . Nicméně, některé[ kdo? ] mají tendenci si myslet, že zatímco původním cílem SIP byla jednoduchost, ve své současné podobě se stal stejně složitým jako H.323. jiný[ kdo? ] věří, že SIP je bezstavový protokol, který tak usnadňuje implementaci převzetí služeb při selhání a dalších funkcí, které jsou obtížné ve stavových protokolech, jako je H.323. SIP a H.323 nejsou omezeny na hlasovou komunikaci, mohou obsluhovat jakoukoli komunikační relaci, od hlasu po video nebo budoucí aplikace.

Porovnat parametr SIP H.323
Doplňkové služby Sada služeb podporovaných oběma protokoly je přibližně stejná.
Osobní mobilita uživatelů Má dobrou sadu nástrojů na podporu mobility Podpora osobní mobility, ale méně flexibilní
Rozšiřitelnost protokolu Pohodlná rozšiřitelnost, snadná kompatibilita s předchozími verzemi Rozšiřitelnost je podporována, ale existuje řada složitostí
Škálovatelnost sítě Oba protokoly poskytují dobrou škálovatelnost sítě
Doba navázání spojení Jedna transakce stačí Je vyžadováno více transakcí
Složitost protokolu Jednoduché, málo požadavků, formát textových zpráv Komplexní, mnoho požadavků a protokolů, binární reprezentace zpráv
Hardwarová kompatibilita Prakticky žádný. Každý výrobce SIP zařízení se řídí pouze sadou doporučení (RFC), která se mu líbí, protože sada těchto doporučení je velmi velká. Ve skutečnosti je kompatibilní pouze základní hovor Téměř kompletní. Normy jsou dobře zavedené a mají jasný soubor specifikací

Zabezpečení

Samostatná část RFC 3261 je věnována otázkám zabezpečení pomocí protokolu SIP . Šifrování signalizačního provozu je možné na úrovni přenosu pomocí TLS přes TCP/UDP. Kromě toho byl vyvinut standard SIPS ( anglicky  SIPS ), který ukládá další dohody o bezpečném přenosu dat prostřednictvím SIP. K šifrování multimediálního obsahu se používá protokol SRTP .

Viz také

Poznámky

  1. ↑ Hygienické odstředivé čerpadlo s CIP a SIP  // World Pumps. — 2004-05. - T. 2004 , no. 452 . - str. 8 . — ISSN 0262-1762 . - doi : 10.1016/s0262-1762(04)00189-0 .
  2. ↑ Alan B. Johnston. SIP: porozumění protokolu zahájení relace . - Boston: Artech House, 2001. - 1 online zdroj (xxi, 201 stran) str. - ISBN 1-58053-413-9 , 978-1-58053-413-0.
  3. ↑ Multiparty Multimedia Session Control (mmusic) – Charta archivována 6. prosince 2005.
  4. ↑ Specifikace 3GPP: 24.229 . Získáno 3. dubna 2008. Archivováno z originálu 22. března 2008.
  5. ↑ Článek „Předpoklady pro vznik NGN“ (nepřístupný odkaz) . Získáno 3. dubna 2008. Archivováno z originálu 13. dubna 2008. 
  6. ↑ Doporučení ITU-T Q.1912.5: Spolupráce mezi protokolem pro zahájení relace (SIP) a protokolem pro řízení hovorů nezávislým na nosiči nebo uživatelskou částí ISDN. . Získáno 11. dubna 2021. Archivováno z originálu dne 11. dubna 2021.
  7. ↑ Jim Van Meggelen, Leif Madsen, Jared Smith. Asterisk je budoucnost IP telefonie. - Symbol-Plus, Petrohrad-Moskva, 2009. - 656 s. - 2000 výtisků.  — ISBN 978-5-93286-128-8 .

Literatura

Odkazy

  Přejděte na položku Wikidata  Slovníky a encyklopedie
V bibliografických katalozích
 software pro IP telefonii
Protokoly
Klientský software
Serverový software
webové služby
srovnání