Session Establishment Protocol

korty , eng.  Session Initiation Protocol , Session Initiation Protocol  - olyan adatátviteli protokoll , amely egy felhasználói kommunikációs munkamenet létrehozásának és befejezésének módszerét írja le, beleértve a multimédiás tartalom cseréjét ( IP-telefónia , video- és audiokonferenciák , azonnali üzenetek , online játékok ) [1] .

Ez a protokoll leírja, hogy egy ügyfélalkalmazás (például egy softphone ) hogyan kérheti a kapcsolat indítását egy másik, esetleg fizikailag távoli klienstől ugyanazon a hálózaton az egyedi név használatával. A protokoll meghatározza a kommunikációs csatorna létrehozásának és protokollok egyeztetésének módját az ügyfelek közötti információcseréhez (például az RTP protokollt hangadatcserére használják ). Lehetőség van ilyen csatornák hozzáadására vagy eltávolítására a létrehozott munkamenet során, valamint további ügyfelek csatlakoztatása és leválasztása (vagyis konferenciahívást biztosítunk, ha kettőnél több fél vehet részt a központban). A SIP meghatározza a munkamenet befejezésének sorrendjét is [2] .

A SIP protokoll fejlesztői

A SIP -t az IETF MMUSIC Working Group fejlesztette ki [3] . A protokoll fejlesztését 1996-ban Henning Schulzrinne ( Columbia Egyetem ) és Mark Handley ( University College London ) kezdte. 2000 novemberében a SIP-t 3GPP jelzési protokollként és az IMS architektúra alapprotokolljaként hagyták jóvá ( 3GPP TS.24.229 [4] módosítás ) [5] . A SIP  az egyik aktívan használt protokoll az interneten keresztüli hangátvitelhez ( Voice over IP ), valamint a H.323 .

Protokoll alapelvek

Az MMUSIC munkacsoport a protokollt a következő elvekre alapozta:

Protokoll tervezés

A SIP kliensek hagyományosan TCP vagy UDP 5060 portot használnak a SIP hálózati elemek összekapcsolására. Alapvetően a SIP hang- és videohívások létrehozására és leválasztására szolgál. Ugyanakkor bármilyen más alkalmazásban is használható, ahol kapcsolatra van szükség, mint például hangosító rendszerek, mobil terminálok stb. Számos SIP-hez kapcsolódó RFC létezik, amelyek meghatározzák az ilyen alkalmazások viselkedését. Maguk a hang- és videoadatok átviteléhez más szállítási protokollokat használnak, leggyakrabban RTP -t .

A SIP fejlesztésének fő célja egy olyan IP -alapú jelzési protokoll létrehozása volt, amely képes támogatni a meglévő PSTN által nyújtott hívásfeldolgozási funkciók és szolgáltatások kiterjesztett készletét . Maga a SIP protokoll nem határozza meg ezeket a funkciókat, csak a felhasználói regisztrációra, a hívások beállítására és befejezésére, valamint a kapcsolódó jelzésekre összpontosít. Ugyanakkor úgy tervezték, hogy támogassa a hálózat olyan funkcionális elemeit, mint a proxy szerverek (proxy szerverek) és a felhasználói ügynökök (felhasználói ügynökök). Ezek az elemek egy alapszolgáltatást biztosítanak: tárcsázás, telefonhívás, az előfizető hangos értesítése a hívás állapotáról.

A SIP alapú telefonhálózatok az SS-7 által jellemzően nyújtott fejlettebb szolgáltatásokat is támogatni tudják , a két protokoll közötti jelentős különbségek ellenére. Az SS-7-et komplex, központosított intelligens hálózat és egyszerű, nem intelligens terminálok (hagyományos telefonok) jellemzik. Ezzel szemben a SIP egy nagyon egyszerű (és ezért nagymértékben skálázható) hálózatot igényel, amelynek a szélén lévő végelemekbe (fizikai eszközként vagy programként épített terminálok) beépített intelligencia.

A SIP-t számos más protokollal együtt használják, és csak a kommunikációs munkamenet jelzési részében vesz részt. A SIP az SDP hordozójaként működik , amely leírja a munkameneten belüli médiaátvitel paramétereit, például a használt IP - portokat és kodekeket . Egy tipikus alkalmazásban a SIP-munkamenetek egyszerűen RTP -csomagok folyamai . Az RTP a hang- és videoadatok közvetlen hordozója.

A szabvány első javasolt változata (SIP 2.0) az RFC 2543 -ban került meghatározásra . A protokollt tovább finomították az RFC 3261 -ben, bár sok megvalósítás még mindig a szabvány köztes verzióin alapul. Vegye figyelembe, hogy a verziószám továbbra is 2.0.

Megszólítás

A meglévő IP-hálózati alkalmazásokkal való interakcióhoz és a felhasználói mobilitás biztosításához a SIP egy e-mail címhez hasonló címet használ . A hívott és hívó címek egységes erőforrás-mutató URI -k , úgynevezett SIP URI -k , általában olyan formátumban sip:идентификатор@домен, ahol az "azonosító" az előfizető neve vagy telefonszáma, a "tartomány" pedig a szervert vagy IP-alközpontot határozza meg, amelyet a domain név vagy IP-cím.
Példák:

Az URI szabványt az RFC 3986 határozza meg .

A cím két részből áll. Az első rész a domainben vagy munkaállomáson regisztrált felhasználó neve. A cím második része a hálózati tartomány nevét, gazdagépét vagy IP-címét határozza meg. Ha a második rész a telefonos átjárót jelöli, akkor az első rész az előfizető telefonszámát.

A felhasználónevek egyszerűen alfanumerikus azonosítók. Az IP-telefóniában általában tisztán digitális azonosítókat („számokat”) használnak a klasszikus telefonhálózatok bővítésének/leváltásának kényelme érdekében. A helyi telefonszámok általában 2-3-4 számjegyből állnak.

Az átjárónak továbbított telefonszám bármely elérhető rajta keresztül, lehet helyi csatlakozási szám vagy mobil vagy vezetékes telefonszám. Az átjáró címe (IP-cím vagy tartománynév) a telefon vagy a kliensprogram beállításaiban van beállítva, és a felhasználónak csak egy számot kell tárcsáznia a hívás kezdeményezéséhez.

Hálózati architektúra

A SIP protokoll kliens-szerver architektúrával rendelkezik.

Az ügyfél kéréseket ad ki, jelezve, hogy mit szeretne kapni a szervertől. A szerver fogadja és feldolgozza a kéréseket, és válaszokat ad ki, amelyek a kérelem sikerességéről szóló értesítést, hibaértesítést vagy az ügyfél által kért információkat tartalmaznak.

A hívásszolgáltatás a SIP hálózat különböző elemei között oszlik meg. A kapcsolatkezelési funkciókat megvalósító fő funkcionális elem a felhasználói terminál. A hálózat más elemei is felelősek lehetnek a hívások irányításáért, és néha további szolgáltatások nyújtására szolgálnak.

Terminál

Amikor a kliens és a szerver a végberendezésben implementálva van, és közvetlenül interakcióba lépnek a felhasználóval, akkor ezeket User Agent Clientnek ( angolul  UAC , user agent client) és User Agent Servernek ( angol  UAS , user agent server) nevezik. Ha az UAC és az UAS is jelen van egy eszközön, akkor azt User Agentnek ( UA , user agent) hívják, és lényegében egy SIP terminál .

A szerver ( UAS ) és a kliens ( UAC ) képes közvetlenül kapcsolatba lépni a felhasználóval. Más SIP kliensek és szerverek ezt nem tudják megtenni.

Proxy szerver

Egy proxy szerver (az angol  proxyból  - "representative") képviseli a felhasználó érdekeit a hálózatban. Elfogadja a kéréseket, feldolgozza azokat, és elvégzi a megfelelő műveleteket. A proxyszerver egy kliensből és egy szerverrészből áll, így képes hívásokat fogadni, kéréseket kezdeményezni és válaszokat adni.
A proxyszerver nem változtathatja meg a továbbított üzenetek szerkezetét és tartalmát, csak a címinformációit adja hozzá a speciális Via mezőhöz.

Kétféle proxyszerver létezik

A proxy az első kérésre válaszolva jelezheti a felhasználó felé további hitelesítés szükségességét - legalább egy bejelentkezést (válasz 407 Proxy hitelesítés szükséges ), beleértve. digitális hitelesítés a biztonság érdekében.

Szerver B2BUA

B2BUA - ( angol  back-to-back user agent , szó szerint: "back-to-back user agent") - a szerver logikai elemének egy változata a SIP protokollal működő alkalmazásokban. A B2BUA koncepciója hasonló a SIP proxyszerverhez , de vannak alapvető különbségek. A B2BUA szerver egyidejűleg több (általában két) végeszközzel – terminállal – működik, a hívást vagy a munkamenetet különböző részekre osztva. A B2BUA minden telephellyel külön-külön, UAS-ként - a kezdeményezőhöz viszonyítva és UAC-ként - a hívást fogadó terminálhoz viszonyítva működik. Ebben az esetben a jelzőüzenetek továbbítása a munkameneten belül mindkét irányban szinkronban történik, bár az üzenet továbbításának szükségességéről és formátumáról a B2BUA dönt az egyes szakaszokra külön-külön. A jelzőrétegben a kapcsolat (kommunikációs munkamenet) minden résztvevője úgy kommunikál a B2BUA-val, mint egy végeszközzel, bár a valóságban a szerver közvetítő. Ez megjelenik a B2BUA szerver által küldött üzenetek címmezőiben (például Feladó, Címzett és Kapcsolatfelvétel). Így a legfontosabb különbség a B2BUA között az összes híváság teljesen független jelzése. Ez különösen azt jelenti, hogy egyedi azonosítókat használnak az egyes felhasználókkal való interakcióhoz egy kommunikációs munkameneten belül, és a különböző webhelyeken ugyanazon üzenetek tartalma eltérő lesz. A végterminálok felhasználói ügynökei interakcióba léphetnek a B2BUA-val és proxyszerverek részvételével.

A B2BUA szerver a következő szolgáltatásokat nyújtja:

A B2BUA gyakran egy médiaátjáró része annak érdekében, hogy egy munkameneten belül teljes mértékben kezelje a médiafolyamokat. A Connection/Session Border Controller részét képező Signaling Gateway  a B2BUA alkalmazások kiváló példája.

Szerver átirányítása

Az átirányítási szerver a hívás átirányítására szolgál a felhasználó aktuális helyére. Az átirányító szerver nem fejezi be a hívásokat, és nem kezdeményez saját kéréseket, hanem csak a szükséges terminál vagy proxyszerver címét jelenti 3XX osztályválaszok segítségével ( 301 véglegesen áthelyezve vagy 302 ideiglenesen áthelyezve ). Ebből a célból az átirányító szerver kölcsönhatásba léphet egy SIP regisztrátorral vagy egy helykiszolgálóval.

A felhasználó azonban nem használhatja az átirányító szervert a kapcsolat létrehozásához, ha ő maga ismeri a keresett felhasználó aktuális címét.

Regisztrációs szerver (regisztrátor)

A SIP protokoll a felhasználói mobilitást jelenti, azaz a felhasználó egy új cím megszerzésével mozoghat a hálózaton belül. Ezért a SIP-nek van egy regisztrációs mechanizmusa - értesítés egy új címről a felhasználói ügynöktől. A regisztrációs szerver vagy regisztrátor ( regisztrátor ) a felhasználó aktuális címének rögzítésére és tárolására szolgál, és a címinformációk rendszeresen frissített adatbázisa. Általában a felhasználó egy kéréssel megadja a regisztrációs szervernek címinformációit, például egy IP-címet vagy domain nevet és egy előfizető telefonszámát REGISTER. A szerver megerősítheti a sikeres regisztrációt ( 200 OK) vagy elutasíthatja, ha adatellenőrzés történik, és a felhasználói fiók nem található ( 404 Not found), vagy a felhasználó regisztrációja jelenleg le van tiltva ( 403 Forbidden). A regisztrátor az ellenőrzéshez felhasználói bejelentkezés szükségességét jelezheti ( 401 Unauthorized), míg a kliensnek felajánlhatja a titkosított jelszó alapján történő hitelesítést . A SIP protokollt nem használó eszközök vagy szoftverek (például DBMS , MS Exchange , RADIUS szerver stb.) információforrásként szolgálhatnak a felhasználói hitelesítéshez. A felhasználói terminál szerveren való regisztrációja bizonyos "élettartamú", és azt a kliens új kérésével kell megerősíteni REGISTER, ellenkező esetben a címadatok törlődnek. Az ügyfél nulla regisztrációs élettartammal is küldhet kérelmet - kérést a címadatok szerverről való eltávolítására (a regisztráció befejezésére).

A SIP-hálózatok különböző megvalósításaiban előfordulhat egy regisztrációs kiszolgáló és más szerverek kombinációja egyetlen alkalmazásban vagy eszközben, amely egyetlen porton (általában UDP / 5060) egyetlen foglalaton keresztül működik – azaz egyetlen vételi pont. és a kérések feldolgozása. A regisztrátorokat gyakran egy átirányítási szerverrel, B2BUA -val vagy SIP-proxyval kombinálják. Például sok szoftveres alközpont (például Asterisk , Yate , RTU ) tartalmazza a SIP regisztrátor funkcióit az egyes felhasználók regisztrációs adatainak ellenőrzésével. A felhasználó regisztrációs és kapcsolatépítési képességére vonatkozó információkat ebben az esetben az egyetlen fiókja határozza meg. Az IP-telefon előfizetői berendezések ( telefonok , előfizetői átjárók ) viszont a legtöbb esetben kötelező előzetes regisztrációt igényelnek a szerveren a telefonhálózatban történő további munkához.

Ennek eredményeként az IP-telefónia rendszer hasonlíthat egy cellás kommunikációs rendszerhez - bekapcsolt állapotban minden előfizetői berendezés regisztrál a kapcsolón (PBX), majd ezen keresztül tud hívásokat kezdeményezni és fogadni, ami vagy átirányítja a kérést egy másik végre. felhasználót, vagy továbbítja a kérést egy másik kapcsolónak.

Felhasználói helykiszolgáló

A felhasználó különböző hálózatokon belül mozoghat, ráadásul a felhasználó valós címe ismeretlen lehet, még akkor is, ha ismert a száma. Ez különösen a számhordozhatósági szolgáltatásra (LNP/MNP) vonatkozik . Az ilyen problémák megoldására létezik egy olyan mechanizmus, amely meghatározza a felhasználó tartózkodási helyét olyan harmadik féltől származó eszközök segítségével, amelyek nem kapcsolódnak közvetlenül a SIP-hez - Location Server , amely tárolja a felhasználó aktuális címét, és egy rendszeresen frissített címadatok adatbázisa.  

Az a felhasználó, akinek egy másik felhasználó címére van szüksége a kapcsolat létrehozásához, nem lép kapcsolatba közvetlenül a helykiszolgálóval. Ezt a funkciót más SIP szerverek hajtják végre LDAP , R WHOIS , ENUM , RADIUS vagy más protokollok használatával.

SIP protokoll üzenetek

A SIP protokoll üzenetei (kérések és válaszok) az RFC 2279 szerint kódolt szövegsorozatok . A SIP üzenetek szerkezete és szintaxisa megegyezik a HTTP protokollban használtakkal .

SIP üzenet struktúra
Start vonal
Címek
Üres sor
Üzenet törzse

Példa INVITE kérésre :

MEGHÍVÁS sip:[email protected] SIP/2.0 Record-Route: <sip:[email protected];lr> Via: SIP/2.0/UDP 10.0.0.10;branch=z9hG4bK3af7.0a6e92f4.0 Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK12ee92cb;rport=5060 Feladó: "78128210000" <sip:[email protected]>;tag=as149b2d97 Címzett: <sip:[email protected]> Kapcsolatfelvétel: <sip:[email protected]> Hívásazonosító: [email protected] CSeq: 103 MEGHÍVÁS Max előre: 16 Dátum: 2001. január 10., szerda, 13:16:23 GMT Engedélyezés: MEGHÍVÁS, VISSZA, TÖRLÉS, OPCIÓK, BYE, REFEER, ELŐFIZETÉS, ÉRTESÍTÉS Támogatott: helyettesíti Tartalom típusa: Application/sdp Tartalom hossza: 394 v=0 o=root 3303 3304 IN IP4 10.0.0.10 s=munkamenet c=IN IP4 10.0.0.10 t=0 0 m = audio 40358 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 phone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=sendrecv

Kérések

A SIP-protokoll eredeti verziója ( RFC 3261 -ben ) hatféle kérelmet határozott meg. A kérések segítségével a kliens jelenti az aktuális tartózkodási helyét, meghívja a felhasználókat kommunikációs munkamenetekben való részvételre, módosítja a már létrejött munkameneteket, leállítja, stb. A kérés típusát a startsorban jelzi.

  1. INVITE  – Meghívja a felhasználót egy kommunikációs munkamenetre. Általában a munkamenet SDP-leírását tartalmazza.
  2. ACK – Nyugtázza a MEGHÍVÁS kérésre  adott válasz beérkezését .
  3. BYE  – befejezi a munkamenetet. Az ülésen részt vevő bármelyik fél továbbíthatja.
  4. MÉGSEM  - megszakítja a korábban benyújtott kérelmek feldolgozását, de nem érinti azokat a kéréseket, amelyek feldolgozása már befejeződött.
  5. REGISZTRÁCIÓ  – címadatokat tartalmaz a felhasználó regisztrálásához a helykiszolgálón.
  6. OPCIÓK  – Információt kér a szerver működéséről.

A jövőben a protokoll kibővült, számos további kéréstípus került hozzá:

  1. A PRACK  egy ideiglenes nyugtázás ( RFC 3262 ).
  2. ELŐFIZETÉS  – Iratkozzon fel az eseményértesítések fogadására ( RFC 3265 ).
  3. ÉRTESÍTÉS  - az előfizető értesítése az eseményről ( RFC 3265 ).
  4. PUBLISH  – Esemény közzététele a szerveren ( RFC 3903 ).
  5. INFO  - információátvitel, amely nem változtatja meg a munkamenet állapotát ( RFC 2976 ).
  6. REFER  – A címzett kérése SIP-kérés küldésére ( RFC 3515 ).
  7. MESSAGE  - azonnali üzenetküldés SIP használatával ( RFC 3428 ).
  8. FRISSÍTÉS  – A munkamenet állapotának módosítása a párbeszédpanel állapotának megváltoztatása nélkül ( RFC 3311 ).

Megkeresésekre adott válaszok

A megkeresésekre adott válaszok beszámolnak a kérelem feldolgozásának eredményéről, vagy továbbítják a kért információkat. A SIP protokoll a válaszok szerkezetét és típusait a HTTP protokolltól örökölte . Hat típusú válasz van meghatározva, amelyek különböző funkcionális terheléseket hordoznak. A válasz típusa háromjegyű számként van kódolva, a legfontosabb az első számjegy, amely meghatározza a válaszosztályt:

  1. 1XX  - információs válaszok; jelzi, hogy a kérelem feldolgozás alatt áll. A leggyakoribb ilyen típusú válaszok a következők: 100 próbálkozás , 180 csengetés , 183 munkamenet folyamata .
  2. 2XX  - végső válaszok, jelezve, hogy a kérés sikeresen feldolgozva. Jelenleg csak két válasz van definiálva ebben a típusban - 200 OK és 202 Accepted (megjegyzés: a 202-es kód nem szerepel az RFC 3261 -ben ).
  3. A 3XX  végső válasz, amely tájékoztatja a hívó felhasználó berendezését a hívott felhasználó új helyéről, például egy 302 Áthelyezett ideiglenes válasz .
  4. 4XX  - végső válaszok, amelyek egy kérés feldolgozása vagy végrehajtása során történt elutasításról vagy hibáról tájékoztatnak, például 403 Tiltott vagy a klasszikus HTTP - válasz 404 Nem található . További példák: 406 Nem elfogadható  - elfogadhatatlan (tartalom szerint) kérés, 486 Foglalt itt  - az előfizető foglalt, vagy 487 Kérelem  megszűnt - a hívó felhasználó válasz megvárása nélkül bontotta a kapcsolatot (megszakítási kérelem).
  5. 5XX  - végső válaszok, amelyek arról tájékoztatnak, hogy a kérést szerverhiba miatt nem lehet feldolgozni, 500 Szerver belső hiba .
  6. 6XX  - végső válaszok, amelyek arról tájékoztatnak, hogy a hívott felhasználóval nem lehet kapcsolatot létesíteni, például a 603 Elutasítás válasz azt jelenti, hogy a hívott felhasználó elutasította a bejövő hívást.

Kapcsolatlétesítési algoritmusok

A SIP protokoll egy vezérlőprotokoll adatfolyam-kapcsolat létrehozására, módosítására és befejezésére. A médiafolyamok átviteli paramétereit a SIP protokoll írja le az SDP (Session Description Protocol) segítségével. A streaming média többféle módon továbbítható, ezek közül a legnépszerűbbek az RTP és az RTCP szállítási protokollok .

A SIP protokoll 3 fő forgatókönyvet határoz meg a kapcsolat létrehozására: proxyszerver részvételével, továbbítószerver részvételével és közvetlenül a felhasználók között. A forgatókönyvek különböznek a hívott felhasználó megtalálásának és meghívásának módjában. Az alapvető kapcsolatlétrehozási algoritmusokat az RFC 3665 írja le .

Példa egy kapcsolatbeállítási forgatókönyvre, amely egy SIP-átirányítási kiszolgálót és egy SIP-proxyt tartalmaz

Példa kapcsolat-beállító parancsfájlra, amely egy B2BUA-kiszolgálót tartalmaz

Az alábbi példában a médiaforgalom a szerveren keresztül történik. Az Alice - B2BUA és B2BUA - Boris szegmensek jelzési üzenetei teljesen függetlenek, és különböző munkameneteken belül futnak le (legalább a munkamenetek cél- és küldési címe, valamint hívásazonosítója megváltozik). Alice terminálja nem ismeri Borisz termináljának valós helyét és fordítva. Ez úgy tűnhet, mint egyes softswitcheken vagy session border controllereken (SBC) keresztül történő interakció .

SIP-T és SIP-I

Az SS-7 jelzést használó hagyományos telefonhálózatokkal való interakció érdekében a telefonálás SIP protokolljának módosításait fejlesztették ki: Session Initiation Protocol for Telephones (SIP-T) és Session Initiation Protocol Internetworking (SIP-I). A SIP-I protokollt az ITU-T fejlesztette ki, a Q.1912.5 ajánlás [6] , a SIP-T protokollt pedig az IETF fejlesztette ki, és az RFC 3372 leírása. A SIP protokoll ezen módosításainak fő feladata az átlátható átvitel ISUP üzenetek IP hálózaton keresztül. Ezt a feladatot az SS jelzőegységek SIP üzenetekbe való beágyazásával valósítják meg. A protokollok közötti interakcióhoz szükséges összes feladatot a SIP protokoll alapján oldottuk meg:

Átjárhatósági követelmény SIP-T funkció
ISUP jelzési átlátszóság ISUP tokozás a SIP üzenettörzsben
A SIP üzenetek továbbítása az ISUP paramétereitől függően ISUP paraméterek fordítása a SIP üzenet fejlécében
Címadatok fordítása létrejött kapcsolat során Az INFO módszer használata

Összehasonlítás a H.323-mal

A SIP ember által olvasható, és a kérések és válaszok szempontjából strukturált. A SIP támogatói azt is állítják, hogy egyszerűbb, mint a H.323 [7] . Azonban néhány[ ki? ] hajlamosak azt gondolni, hogy míg a SIP eredeti célja az egyszerűség volt, jelenlegi formájában olyan összetett lett, mint a H.323. Egyéb[ ki? ] úgy vélik, hogy a SIP egy állapot nélküli protokoll, ami megkönnyíti a feladatátvételi és egyéb olyan funkciók megvalósítását, amelyek az állapotalapú protokollokban, például a H.323-ban, nehézkesek. A SIP és a H.323 nem korlátozódik a hangkommunikációra, bármilyen kommunikációs munkamenetet kiszolgálhatnak, a hangtól a videóig vagy a jövőbeni alkalmazásokig.

Hasonlítsa össze a paramétert KORTY H.323
További szolgáltatások A mindkét protokoll által támogatott szolgáltatások köre megközelítőleg azonos.
A felhasználók személyes mobilitása Jó mobilitástámogató eszközkészlettel rendelkezik Személyes mobilitás támogatott, de kevésbé rugalmas
Protokoll bővíthetőség Kényelmes bővíthetőség, egyszerű kompatibilitás a korábbi verziókkal A bővíthetőség támogatott, de ennek számos bonyolultsága van
Hálózati méretezhetőség Mindkét protokoll jó hálózati skálázhatóságot biztosít
A kapcsolat létrehozásának ideje Egy tranzakció elég Több tranzakció szükséges
Protokoll összetettsége Egyszerű, kevés kérés, szöveges üzenet formátum Összetett, sok kérés és protokoll, üzenetek bináris megjelenítése
Hardver kompatibilitás Gyakorlatilag egyik sem. A SIP-eszközök minden gyártója csak a neki tetsző ajánláskészletet (RFC) követi, mivel ezeknek az ajánlásoknak a halmaza nagyon nagy. Valójában csak az alaphívás kompatibilis Majdnem kész. A szabványok jól megalapozottak, és világos előírásokkal rendelkeznek

Biztonság

Az RFC 3261 külön fejezete a SIP protokoll használatával kapcsolatos biztonsági kérdéseknek szól . A jelzési forgalom titkosítása szállítási szinten lehetséges a TCP/UDP -n keresztüli TLS használatával. Emellett kidolgozásra került a SIPS szabvány ( angol  SIPS ), amely további megállapodásokat ír elő a biztonságos SIP-en keresztüli adatátvitelről. Az SRTP protokoll a multimédiás tartalom titkosítására szolgál .

Lásd még

Jegyzetek

  1. ↑ Higiénikus centrifugálszivattyú CIP és SIP képességgel  // World Pumps. — 2004-05. - T. 2004 , sz. 452 . - S. 8 . — ISSN 0262-1762 . - doi : 10.1016/s0262-1762(04)00189-0 .
  2. ↑ Alan B. Johnston. SIP: a Session Initiation Protocol megértése . - Boston: Artech House, 2001. - 1 online forrás (xxi, 201 oldal) p. - ISBN 1-58053-413-9 , 978-1-58053-413-0.
  3. ↑ Multiparty Multimedia Session Control (mmusic) – Charta archiválva : 2005. december 6.
  4. ↑ 3GPP specifikáció: 24.229 . Letöltve: 2008. április 3. Az eredetiből archiválva : 2008. március 22..
  5. ↑ "Az NGN megjelenésének előfeltételei" cikk (elérhetetlen link) . Letöltve: 2008. április 3. Az eredetiből archiválva : 2008. április 13.. 
  6. ↑ ITU-T Q.1912.5 ajánlás: Együttműködés a munkamenet-kezdeményezési protokoll (SIP) és a hordozófüggetlen hívásvezérlő protokoll vagy ISDN felhasználói rész között. . Letöltve: 2021. április 11. Az eredetiből archiválva : 2021. április 11.
  7. ↑ Jim Van Meggelen, Leif Madsen, Jared Smith. Az Asterisk az IP-telefónia jövője. - Symbol-Plus, Szentpétervár-Moszkva, 2009. - 656 p. - 2000 példányban.  — ISBN 978-5-93286-128-8 .

Irodalom

Linkek

  Ugrás a Wikidata elemre  Szótárak és enciklopédiák
Bibliográfiai katalógusokban
 IP -telefon szoftver
Protokollok
Kliens szoftver
Szerver szoftver
Webszolgáltatások
összehasonlítás