Session Etablering Protocol

sip , eng.  Session Initiation Protocol , Session Initiation Protocol  - ett dataöverföringsprotokoll som beskriver en metod för att upprätta och avsluta en användarkommunikationssession, inklusive utbyte av multimediainnehåll ( IP-telefoni , video- och ljudkonferenser , snabbmeddelanden , onlinespel ) [1] .

Detta protokoll beskriver hur en klientapplikation (till exempel en datortelefon ) kan begära att en anslutning startas från en annan, möjligen fysiskt avlägsen, klient på samma nätverk med sitt unika namn. Protokollet definierar ett sätt att skapa en kommunikationskanal och förhandla om protokoll för utbyte av information mellan klienter (till exempel används RTP - protokollet för röstdatautbyte ). Det är tillåtet att lägga till eller ta bort sådana kanaler under den etablerade sessionen, samt ansluta och koppla bort ytterligare klienter (det vill säga ett konferenssamtal tillhandahålls när fler än två parter tillåts delta i utbytet). SIP bestämmer också i vilken ordning sessionen slutar [2] .

Utvecklare av SIP-protokollet

SIP utvecklades av IETF MMUSIC Working Group [3] . Protokollet började utvecklas 1996 av Henning Schulzrinne ( Columbia University ) och Mark Handley ( University College London ). I november 2000 godkändes SIP som ett 3GPP -signaleringsprotokoll och ett kärnprotokoll för IMS-arkitekturen ( modifiering 3GPP TS.24.229 [4] ) [5] . SIP  är ett av de protokoll som aktivt används för röstöverföring över Internet ( Voice over IP ) tillsammans med H.323 .

Protokollprinciper

MMUSIC-arbetsgruppen baserade protokollet på följande principer:

Protokolldesign

SIP-klienter använder traditionellt TCP- eller UDP -port 5060 för att ansluta SIP-nätverkselement. I grund och botten används SIP för att upprätta och koppla bort röst- och videosamtal. Samtidigt kan den användas i alla andra applikationer där en anslutning krävs, såsom högtalarsystem, mobilterminaler och så vidare. Det finns ett stort antal SIP-relaterade RFC :er som definierar beteendet hos sådana applikationer. För att själva överföra röst- och videodata används andra transportprotokoll, oftast RTP .

Huvudmålet med utvecklingen av SIP var att skapa ett IP- baserat signaleringsprotokoll som kunde stödja den utökade uppsättningen av samtalsbehandlingsfunktioner och tjänster som tillhandahålls av det befintliga PSTN . SIP-protokollet i sig definierar inte dessa funktioner, utan fokuserar endast på användarregistrering, samtalsuppkoppling och avslutning samt tillhörande signalering. Samtidigt utformades den för att stödja sådana funktionella delar av nätverket som proxyservrar (proxyservrar) och användaragenter (användaragenter). Dessa element tillhandahåller en grundläggande uppsättning tjänster: uppringning, uppringning av en telefon, ljudavisering till abonnenten om samtalsstatus.

SIP-baserade telefonnät kan också stödja de mer avancerade tjänsterna som vanligtvis tillhandahålls av SS-7 , trots de betydande skillnaderna mellan de två protokollen. SS-7 kännetecknas av ett komplext, centraliserat intelligent nätverk och enkla, icke-intelligenta terminaler (traditionella telefoner). SIP, tvärtom, kräver ett mycket enkelt (och därför mycket skalbart) nätverk med intelligens inbyggd i ändelementen vid kanten (terminaler byggda som fysiska enheter eller program).

SIP används tillsammans med flera andra protokoll och deltar endast i signaleringsdelen av en kommunikationssession. SIP fungerar som bärare för SDP , som beskriver parametrarna för mediaöverföring inom en session, såsom IP- portar och codecs som används . I en typisk applikation är SIP-sessioner helt enkelt strömmar av RTP- paket . RTP är den direkta bäraren av röst- och videodata.

Den första föreslagna versionen av standarden (SIP 2.0) definierades i RFC 2543 . Protokollet förfinades ytterligare i RFC 3261 , även om många implementeringar fortfarande är baserade på mellanversioner av standarden. Observera att versionsnumret förblir 2.0.

Adressering

För att interagera med befintliga IP-nätverksapplikationer och för att ge användarrörlighet, använder SIP en adress som liknar en e-postadress . Uppringda och anropande adresser är Uniform Resource Pointers URI , så kallade SIP URI , vanligtvis i formatet sip:идентификатор@домен, där "identifier" är abonnentens namn eller telefonnummer, och "domän" anger servern eller IP-PBX, som kan anges av domännamnet eller IP-adressen.
Exempel:

URI-standarden specificeras i RFC 3986 .

Adressen består av två delar. Den första delen är namnet på användaren som är registrerad på domänen eller arbetsstationen. Den andra delen av adressen anger nätverkets domännamn, värd eller IP-adress. Om den andra delen identifierar telefongatewayen, anger den första delen abonnentens telefonnummer.

Användarnamn är helt enkelt alfanumeriska identifierare. Inom IP-telefoni används som regel rent digitala identifierare (”nummer”) för att underlätta utbyggnad/ersättning av klassiska telefonnät. Lokala telefonnummer är vanligtvis 2-3-4 siffror.

Telefonnumret som överförs till gatewayen är vilket som helst tillgängligt via den, det kan antingen vara ett lokalt anslutningsnummer eller ett mobil- eller fasttelefonnummer. Gateway-adressen (IP-adress eller domännamn) ställs in i telefonens eller klientprogrammets inställningar, och användaren behöver bara slå ett nummer för att ringa ett samtal.

Nätverksarkitektur

SIP-protokollet har en klient-server-arkitektur.

Klienten utfärdar förfrågningar som anger vad den vill ta emot från servern. Servern tar emot och bearbetar förfrågningar och utfärdar svar som innehåller ett meddelande om att begäran lyckades, ett felmeddelande eller information som begärs av klienten.

Samtalstjänsten är fördelad mellan olika delar av SIP-nätet. Det huvudsakliga funktionella elementet som implementerar anslutningshanteringsfunktionerna är användarterminalen. Andra delar av nätverket kan vara ansvariga för att dirigera samtal och ibland tjäna till att tillhandahålla ytterligare tjänster.

Terminal

När klienten och servern är implementerade i terminalutrustningen och interagerar direkt med användaren kallas de User Agent Client ( Engelska  UAC , användaragentklient) - och User Agent Server ( Engelska  UAS , användaragentserver). Om både UAC och UAS finns på en enhet kallas den för en användaragent ( UA , användaragent) och är i huvudsak en SIP- terminal .

Servern ( UAS ) och klienten ( UAC ) har förmågan att interagera direkt med användaren. Andra SIP- klienter och servrar kan inte göra detta.

Proxyserver

En proxyserver (från engelska  proxy  - "representative") representerar användarens intressen i nätverket. Den accepterar förfrågningar, bearbetar dem och utför lämpliga åtgärder. Proxyservern består av en klient och en serverdel, så den kan ta emot samtal, initiera förfrågningar och returnera svar.
Proxyservern får inte ändra strukturen och innehållet i överförda meddelanden, utan bara lägga till sin adressinformation i det speciella Via-fältet.

Det finns två typer av proxyservrar

Proxyn kan indikera för användaren, som svar på den första begäran, behovet av ytterligare autentisering - åtminstone en inloggning (svar 407 Proxy-autentisering krävs ), inkl. digital autentisering för säkerhet.

Server B2BUA

B2BUA - ( engelska  back-to-back user agent , bokstavligen: "back-to-back user agent") - en variant av serverns logiska element i applikationer som arbetar med SIP-protokollet. B2BUA liknar konceptet en SIP-proxyserver , men det finns grundläggande skillnader. B2BUA-servern fungerar samtidigt med flera (vanligtvis två) slutenheter - terminaler, som delar upp samtalet eller sessionen i olika sektioner. B2BUA arbetar med varje plats individuellt, som UAS - i förhållande till initiatorn och som UAC - i förhållande till den terminal som tar emot samtalet. I detta fall sänds signaleringsmeddelanden inom sessionen i båda riktningarna synkront, även om beslutet om behovet av att sända ett meddelande och dess format tas av B2BUA för varje sektion individuellt. Var och en av deltagarna i anslutningen (kommunikationssessionen) vid signallagret interagerar med B2BUA som med en slutenhet, även om servern i verkligheten är en mellanhand. Detta återspeglas i adressfälten (som Från, Till och Kontakt) för meddelanden som skickas av B2BUA-servern. Den viktigaste skillnaden mellan B2BUA är alltså den helt oberoende signaleringen av alla samtalsben. Detta innebär i synnerhet att unika identifierare används för att interagera med varje enskild användare under en kommunikationssession, och innehållet i samma meddelanden för olika webbplatser kommer att vara olika. Användaragenter för slutterminaler kan interagera med B2BUA och med deltagande av proxyservrar.

B2BUA-servern kan tillhandahålla följande funktioner:

Ganska ofta är B2BUA en del av en mediagateway för att helt och hållet kunna hantera mediaströmmarna inom en session. Signaling Gateway som är en del av Connection/Session Border Controller  är ett utmärkt exempel på en B2BUA-applikation.

Omdirigera server

Omdirigeringsservern används för att omdirigera samtalet till användarens nuvarande plats. Omdirigeringsservern avslutar inte samtal och initierar inte sina egna förfrågningar, utan rapporterar endast adressen till den nödvändiga terminalen eller proxyservern med hjälp av 3XX-klasssvar ( 301 flyttade permanent eller 302 flyttade tillfälligt ). För dessa ändamål kan omdirigeringsservern interagera med en SIP-registrator eller en platsserver.

Användaren får dock inte använda omdirigeringsservern för att upprätta anslutningen om han själv känner till den aktuella adressen till den önskade användaren.

Registreringsserver (registrator)

SIP -protokollet innebär användarmobilitet, det vill säga att användaren kan röra sig inom nätverket genom att erhålla en ny adress. Därför har SIP en registreringsmekanism - meddelande om en ny adress från användaragenten. Registreringsservern eller registraren ( registratorn ) tjänar till att fixa och lagra användarens aktuella adress och är en regelbundet uppdaterad databas med adressinformation. I allmänhet förser användaren registreringsservern med sin adressinformation, såsom en IP-adress eller domännamn och en abonnents telefonnummer, med hjälp av en begäran REGISTER. Servern kan bekräfta framgångsrik registrering ( 200 OK) eller avvisa om det finns en datakontroll och användarkontot inte hittas ( 404 Not found) eller om registrering för användaren för närvarande är förbjuden ( 403 Forbidden). Registraren kan indikera behovet av en användarinloggning för verifiering ( 401 Unauthorized), medan den kan erbjuda klienten att autentisera baserat på ett krypterat lösenord. En enhet eller programvara som inte använder SIP-protokollet (till exempel DBMS , MS Exchange , RADIUS-server , etc.) kan fungera som en informationskälla för användarautentisering. Registrering av användarens terminal på servern har en viss "livstid" och måste bekräftas av en ny begäran REGISTERfrån klienten, annars kan adressinformationen raderas. Klienten kan också skicka en begäran med noll registreringslivslängd - en begäran om att tvinga bort adressinformation från servern (slutförande av registrering).

I olika implementeringar av SIP-nätverk kan det finnas en kombination av en registreringsserver och andra servrar i en enda applikation eller enhet som fungerar via ett enda uttag på en enda port (vanligtvis UDP / 5060) - det vill säga en enda punkt för mottagning och behandla förfrågningar. Så ofta kombineras registrarer med en omdirigeringsserver, B2BUA eller SIP-proxy. Till exempel innehåller många mjukvaruväxelsystem (till exempel Asterisk , Yate , RTU ) funktionaliteten hos en SIP-registrator med verifiering av registreringsdata för varje användare. Information om användarens förmåga att registrera och upprätta anslutningar bestäms i detta fall av hans enda konto. I sin tur kräver abonnentutrustning för IP-telefoni ( telefoner , abonnentgateways ) i de flesta fall obligatorisk förregistrering på servern för vidare arbete i telefonnätet.

Som ett resultat kan ett IP-telefonisystem se ut som ett cellulärt kommunikationssystem - när den är påslagen registreras all abonnentutrustning på switchen (PBX) och kan därefter ringa och ta emot samtal genom den, vilket antingen omdirigerar förfrågan till en annan ände användare eller vidarebefordrar begäran till en annan switch.

Användarplatsserver

Användaren kan röra sig inom olika nätverk, dessutom kan användarens verkliga adress vara okänd, även om hans nummer är känt. Detta är särskilt relevant för nummerportabilitetstjänsten (LNP/MNP) . För att lösa sådana problem finns det en mekanism för att bestämma användarens plats med hjälp av tredjepartsverktyg som inte är direkt relaterade till SIP - Location Server , som lagrar användarens aktuella adress och är en regelbundet uppdaterad databas med adressinformation.  

En användare som behöver en annan användares adressinformation för att upprätta en anslutning kontaktar inte platsservern direkt. Denna funktion utförs av andra SIP-servrar som använder LDAP , R WHOIS , ENUM , RADIUS eller andra protokoll.

SIP-protokollmeddelanden

SIP- protokollmeddelanden (förfrågningar och svar) är sekvenser av textsträngar kodade i enlighet med RFC 2279 . Strukturen och syntaxen för SIP - meddelanden är identiska med de som används i HTTP - protokollet .

SIP-meddelandestruktur
Startlinje
Titlar
Tom linje
Meddelandetext

INVITE- förfrågan exempel :

BJUD IN 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 Från: "78128210000" <sip:[email protected]>;tag=as149b2d97 Till: <sip:[email protected]> Kontakt: <sip:[email protected]> Samtals-ID: [email protected] CSeq: 103 INBJUD Max forwards: 16 Datum: ons, 10 januari 2001 13:16:23 GMT Tillåt: BJUD IN, ACK, AVBRYT, ALTERNATIV, BYE, REFER, SUBSCRIBE, NOTIFY Stöds: ersätter Innehållstyp: applikation/sdp Innehållslängd: 394 v=0 o=root 3303 3304 IN IP4 10.0.0.10 s=session c=IN IP4 10.0.0.10 t=0 0 m=ljud 40358 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telefon-event/8000 a=fmtp:101 0-16 a=silenceSupp:av - - - - a=sendrecv

Förfrågningar

Den ursprungliga versionen av SIP-protokollet (i RFC 3261 ) definierade sex typer av förfrågningar. Med hjälp av förfrågningar rapporterar klienten den aktuella platsen, bjuder in användare att delta i kommunikationssessioner, modifierar redan etablerade sessioner, avslutar dem, etc. Typen av begäran anges i startraden.

  1. BJUD IN  - Bjuder in användaren till en kommunikationssession. Innehåller vanligtvis en SDP-beskrivning av sessionen.
  2. ACK  - Bekräftar mottagandet av ett svar på en INVITE- förfrågan .
  3. BYE  - avslutar sessionen. Kan sändas av någon av parterna som deltar i sessionen.
  4. AVBRYT  – avbryter behandlingen av tidigare inlämnade förfrågningar, men påverkar inte förfrågningar som redan har avslutats.
  5. REGISTER  - bär adressinformation för registrering av en användare på en platsserver.
  6. ALTERNATIV  - Begär information om serverns funktionalitet.

I framtiden utökades protokollet, flera fler typer av förfrågningar lades till:

  1. PRACK  är en tillfällig bekräftelse ( RFC 3262 ).
  2. PRENUMERERA  - Prenumerera för att få händelseaviseringar ( RFC 3265 ).
  3. MEDDELA  - meddelande till abonnenten om händelsen ( RFC 3265 ).
  4. PUBLISH  - Publicering av en händelse på servern ( RFC 3903 ).
  5. INFO  - informationsöverföring som inte ändrar tillståndet för sessionen ( RFC 2976 ).
  6. REFERERA  - Mottagarens begäran att skicka en SIP-förfrågan ( RFC 3515 ).
  7. MESSAGE  - snabbmeddelanden med hjälp av SIP ( RFC 3428 ).
  8. UPPDATERING  - Ändra sessionstillstånd utan att ändra dialogstatus ( RFC 3311 ).

Svar på förfrågningar

Svar på förfrågningar rapporterar resultatet av behandlingen av begäran eller förmedlar den begärda informationen. SIP-protokollet ärvde strukturen av svar och deras typer från HTTP-protokollet . Sex typer av svar definieras som bär olika funktionella belastningar. Svarstypen är kodad som ett tresiffrigt nummer, den viktigaste är den första siffran, som definierar svarsklassen:

  1. 1XX  - informationssvar; ange att begäran behandlas. De vanligaste svaren av denna typ är 100 försöker , 180 ringningar , 183 sessionsförlopp .
  2. 2XX  - slutliga svar, som indikerar att begäran behandlades framgångsrikt. För närvarande är endast två svar definierade i denna typ - 200 OK och 202 accepterade (not 202-koden finns inte i RFC 3261 ).
  3. 3XX  är slutliga svar som informerar den uppringande användarens utrustning om den uppringda användarens nya plats, såsom ett 302 Moved Temporary Response .
  4. 4XX  - sista svar som informerar om ett avslag eller ett fel under bearbetning eller exekvering av en begäran, till exempel 403 Förbjudet eller det klassiska HTTP- svaret 404 Hittade inte . Andra exempel: 406 Ej acceptabel  - oacceptabel (efter innehåll) begäran, 486 Upptagen Här  - abonnenten är upptagen, eller 487 Begäran  avslutad - den uppringande användaren avslutade anslutningen utan att vänta på ett svar (begäran avbrytning).
  5. 5XX  - slutliga svar som informerar om att begäran inte kan behandlas på grund av ett serverfel, 500 Server Internt fel .
  6. 6XX  - slutliga svar som informerar om att förbindelsen med den uppringda användaren inte kan upprättas, till exempel betyder svaret 603 Avvisa att den uppringda användaren avvisade det inkommande samtalet.

Algoritmer för upprättande av anslutning

SIP-protokollet är ett kontrollprotokoll för att upprätta, modifiera och avsluta en strömmande dataanslutning. Överföringsparametrarna för mediaströmmar beskrivs i SIP-protokollet med hjälp av SDP (Session Description Protocol). Strömmande media kan överföras på olika sätt, bland vilka RTP- och RTCP- transportprotokollen är de mest populära .

SIP-protokollet definierar tre huvudscenarier för att upprätta en anslutning: med deltagande av en proxyserver, med deltagande av en vidarekopplingsserver och direkt mellan användare. Scenarierna skiljer sig åt i hur den anropade användaren hittas och bjuds in. De grundläggande anslutningsetableringsalgoritmerna beskrivs i RFC 3665 .

Ett exempel på ett anslutningsscenario som involverar en SIP-omdirigeringsserver och en SIP-proxy

Ett exempel på anslutningsinstallationsskript som involverar en B2BUA-server

I exemplet nedan proxias mediatrafik via servern. Signaleringsmeddelanden för Alice - B2BUA och B2BUA - Boris-segment är helt oberoende och exekveras inom olika sessioner (åtminstone destinations- och sändningsadresserna, samt sessionernas samtals-ID kommer att ändras). Alices terminal känner inte till den verkliga platsen för Boris terminal och vice versa. Detta kan se ut som interaktion genom vissa mjukvaruväxlar eller sessionsgränskontroller (SBC) .

SIP-T och SIP-I

För att interagera med traditionella telefonnät som använder SS-7- signalering utvecklades modifieringar av SIP-protokollet för telefoni: Session Initiation Protocol for Telephones (SIP-T) och Session Initiation Protocol Internetworking (SIP-I). SIP-I-protokollet utvecklades av ITU-T , rekommendation Q.1912.5 [6] , och SIP-T utvecklades av IETF och beskrivs i RFC 3372. Huvuduppgiften för dessa modifieringar av SIP-protokollet är att transparent överföra ISUP- meddelanden över ett IP-nätverk. Denna uppgift åstadkommes genom att kapsla in SS -signaleringsenheter i SIP-meddelanden. Alla nödvändiga uppgifter för interaktionen mellan protokollen löstes baserat på SIP-protokollet:

Krav på interoperabilitet SIP-T funktion
ISUP-signaltransparens ISUP Inkapsling i SIP Message Body
Möjlighet att dirigera SIP-meddelanden beroende på ISUP-parametrar Översättning av ISUP-parametrar i SIP-meddelandehuvudet
Översättning av adressinformation under en etablerad anslutning Använder INFO-metoden

Jämförelse med H.323

SIP är mänskligt läsbar och strukturerad när det gäller förfrågningar och svar. Förespråkare av SIP hävdar också att det är enklare än H.323 [7] . Dock några[ vem? ] tenderar att tro att även om SIP:s ursprungliga mål var enkelhet, har det i sin nuvarande form blivit lika komplext som H.323. Övrig[ vem? ] anser att SIP är ett tillståndslöst protokoll, vilket därmed gör det enkelt att implementera failover och andra funktioner som är svåra i tillståndsprotokoll som H.323. SIP och H.323 är inte begränsade till röstkommunikation, de kan tjäna alla kommunikationssessioner, från röst till video eller framtida applikationer.

Jämför parameter SMUTTA H.323
Ytterligare tjänster Uppsättningen tjänster som stöds av båda protokollen är ungefär densamma.
Användarnas personliga rörlighet Har en bra uppsättning verktyg för mobilitetsstöd Personlig rörlighet stöds men mindre flexibel
Protokollförlängbarhet Bekväm utdragbarhet, enkel kompatibilitet med tidigare versioner Utökningsbarhet stöds, men det finns ett antal komplexiteter
Nätverksskalbarhet Båda protokollen ger bra nätverksskalbarhet
Tid för etablering av anslutning En transaktion räcker Flera transaktioner krävs
Protokollkomplexitet Enkelt, få förfrågningar, textmeddelandeformat Komplexa, många förfrågningar och protokoll, binär representation av meddelanden
Hårdvarukompatibilitet Praktiskt taget ingen. Varje tillverkare av SIP-enheter följer endast den uppsättning rekommendationer (RFC) som han gillar, eftersom uppsättningen av dessa rekommendationer är mycket stor. Egentligen är bara basanropet kompatibelt Nästan komplett. Standarder är väletablerade och har en tydlig uppsättning specifikationer

Säkerhet

En separat del av RFC 3261 ägnas åt säkerhetsfrågor som använder SIP-protokollet . Kryptering av signaltrafik är möjlig på transportnivå genom användning av TLS över TCP/UDP. Dessutom har SIPS- standarden ( engelska  SIPS ) utvecklats, som medför ytterligare avtal om säker dataöverföring via SIP. SRTP- protokollet används för att kryptera multimediainnehåll .

Se även

Anteckningar

  1. ↑ Hygienisk centrifugalpump med CIP- och SIP-kapacitet  // Världspumpar. — 2004-05. - T. 2004 , nej. 452 . - S. 8 . — ISSN 0262-1762 . - doi : 10.1016/s0262-1762(04)00189-0 .
  2. ↑ Alan B. Johnston. SIP: förstå Session Initiation Protocol . - Boston: Artech House, 2001. - 1 onlineresurs (xxi, 201 sidor) sid. - ISBN 1-58053-413-9 , 978-1-58053-413-0.
  3. ↑ Multimediasessionskontroll för flera partier (musik) - Charter Arkiverad 6 december 2005.
  4. ↑ 3GPP-specifikation: 24.229 . Hämtad 3 april 2008. Arkiverad från originalet 22 mars 2008.
  5. ↑ Artikel "Förutsättningar för uppkomsten av NGN" (otillgänglig länk) . Hämtad 3 april 2008. Arkiverad från originalet 13 april 2008. 
  6. ↑ Rekommendation ITU-T Q.1912.5: Samverkan mellan sessionsinitieringsprotokoll (SIP) och bäraroberoende samtalskontrollprotokoll eller ISDN-användardel. . Hämtad 11 april 2021. Arkiverad från originalet 11 april 2021.
  7. ↑ Jim Van Meggelen, Leif Madsen, Jared Smith. Asterisk är framtiden för IP-telefoni. - Symbol-Plus, St Petersburg-Moskva, 2009. - 656 s. - 2000 exemplar.  — ISBN 978-5-93286-128-8 .

Litteratur

Länkar

  Gå till Wikidata-objektet  Ordböcker och uppslagsverk
I bibliografiska kataloger
 Programvara för IP- telefoni
Protokoll
Klientprogramvara
Serverprogramvara
Webbservice
jämförelse