Session Initiation Protocol - Session Initiation Protocol

Den Session Initiation Protocol ( SIP ) er en signalering protokol bruges til at indlede, vedligeholde og afslutte realtid sessioner, der omfatter telefoni, video og messaging applikationer. SIP bruges til signalering og styring af multimedie kommunikationssessioner i anvendelser af internettelefoni for tale- og videoopkald, i privat IP telefonsystemer, i instant messaging løbet Internet Protocol (IP) netværk samt mobiltelefon ringer i løbet af LTE ( VoLTE ).

Protokollen definerer det specifikke format for udvekslede meddelelser og rækkefølgen af ​​kommunikation for deltagernes samarbejde. SIP er en tekstbaseret protokol, der indeholder mange elementer i Hypertext Transfer Protocol (HTTP) og Simple Mail Transfer Protocol (SMTP). Et opkald oprettet med SIP kan bestå af flere mediestreams , men der kræves ingen separate streams til applikationer, f.eks. Tekstbeskeder , der udveksler data som nyttelast i SIP -meddelelsen.

SIP fungerer sammen med flere andre protokoller, der specificerer og bærer sessionsmedierne. Normalt udføres medietype og parameterforhandling og medieopsætning med Session Description Protocol (SDP), som transporteres som nyttelast i SIP -meddelelser. SIP er designet til at være uafhængig af den underliggende transportlagsprotokol og kan bruges med User Datagram Protocol (UDP), Transmission Control Protocol (TCP) og Stream Control Transmission Protocol (SCTP). For sikker transmission af SIP -meddelelser over usikre netværksforbindelser kan protokollen være krypteret med Transport Layer Security (TLS). Til transmission af mediestreams (stemme, video) anvender SDP-nyttelasten, der bæres i SIP-meddelelser, typisk Real-Time Transport Protocol (RTP) eller Secure Real-time Transport Protocol (SRTP).

Historie

SIP blev oprindeligt designet af Mark Handley , Henning Schulzrinne , Eve Schooler og Jonathan Rosenberg i 1996 for at lette etablering af multicast -multimediesessionerMbone . Protokollen blev standardiseret som RFC  2543 i 1999. I november 2000 blev SIP accepteret som en 3GPP- signalprotokol og permanent element i arkitekturen IP Multimedia Subsystem (IMS) til IP-baserede streaming multimedietjenester i mobilnetværk . I juni 2002 blev specifikationen revideret i RFC  3261, og forskellige udvidelser og præciseringer er blevet offentliggjort siden.

SIP blev designet til at levere en signal- og opkaldsopsætningsprotokol til IP-baseret kommunikation, der understøtter opkaldsbehandlingsfunktionerne og funktionerne i det offentlige telefonnet (PSTN) med en vision om at understøtte nye multimedieapplikationer. Det er blevet udvidet til videokonferencer , streaming af medier , instant messaging , oplysninger om tilstedeværelse , filoverførsel , internetfax og onlinespil .

SIP kendetegnes ved sine fortalere for at have rødder i internetsamfundet frem for i telekommunikationsindustrien . SIP er primært standardiseret af Internet Engineering Task Force (IETF), mens andre protokoller, såsom H.323 , traditionelt har været forbundet med International Telecommunication Union (ITU).

Protokol drift

SIP er kun involveret i signaloperationer af en mediekommunikationssession og bruges primært til at konfigurere og afslutte tale- eller videoopkald. SIP kan bruges til at etablere to-parts ( unicast ) eller multiparty ( multicast ) sessioner. Det tillader også ændring af eksisterende opkald. Ændringen kan indebære ændring af adresser eller porte , invitere flere deltagere og tilføje eller slette mediestreams. SIP har også fundet applikationer i messaging -applikationer, f.eks. Onlinemeddelelser, og abonnement og notifikationer på begivenheder.

SIP fungerer sammen med flere andre protokoller, der angiver medieformat og kodning, og som bærer mediet, når opkaldet er oprettet. Til opkaldsopsætning indeholder brødteksten i en SIP -meddelelse en SENH Description ( Session Description Protocol ) dataenhed, som angiver medieformat, codec og mediekommunikationsprotokol. Stemme- og videomediestrømme transporteres typisk mellem terminalerne ved hjælp af Real-Time Transport Protocol (RTP) eller Secure Real-time Transport Protocol (SRTP).

Hver ressource i et SIP -netværk, f.eks. Brugeragenter, opkaldsroutere og telefonsvarerkasser, identificeres af en Uniform Resource Identifier (URI). Syntaksen for URI følger den generelle standardsyntaks, der også bruges i webtjenester og e-mail. URI -skemaet, der bruges til SIP, er sip, og en typisk SIP -URI har formen sip: username@domainname eller sip: username@hostport , hvor domænenavn kræver DNS SRV -poster for at lokalisere serverne til SIP -domæne, mens hostport kan være en IP -adresse eller en fuldt kvalificeret domænenavn på værten og porten. Hvis sikker overførsel er påkrævet, ordningens slurke bruges.

SIP anvender designelementer, der ligner HTTP -anmodningen og svartransaktionsmodellen. Hver transaktion består af en klientanmodning, der påberåber sig en bestemt metode eller funktion på serveren og mindst ét ​​svar. SIP genbruger de fleste overskriftsfelter, kodningsregler og statuskoder for HTTP, hvilket giver et læsbart tekstbaseret format.

SIP kan bæres af flere transportlagsprotokoller, herunder Transmission Control Protocol (TCP), User Datagram Protocol (UDP) og Stream Control Transmission Protocol (SCTP). SIP -klienter bruger typisk TCP eller UDP på portnumre 5060 eller 5061 til SIP -trafik til servere og andre slutpunkter. Port 5060 bruges almindeligvis til ikke-krypteret signaltrafik, mens port 5061 typisk bruges til trafik, der er krypteret med Transport Layer Security (TLS).

SIP-baserede telefonnetværk implementerer ofte opkaldsbehandlingsfunktioner i Signalsystem 7 (SS7), for hvilke der findes særlige SIP-protokoludvidelser, selvom de to protokoller i sig selv er meget forskellige. SS7 er en centraliseret protokol, kendetegnet ved en kompleks central netværksarkitektur og dumme slutpunkter (traditionelle telefonrør). SIP er en klient-server- protokol for ækvipotente jævnaldrende. SIP -funktioner implementeres i de kommunikerende slutpunkter, mens den traditionelle SS7 -arkitektur kun bruges mellem switchingscentre.

Netværkselementer

Netværkselementerne, der bruger Session Initiation Protocol til kommunikation, kaldes SIP -brugeragenter . Hver brugeragent (UA) udfører funktionen af ​​en brugeragentklient (UAC), når den anmoder om en servicefunktion, og en brugeragent -server (UAS), når den svarer på en anmodning. Således kan to SIP -endepunkter i princippet fungere uden nogen mellemliggende SIP -infrastruktur. Af netoperationelle årsager, for levering af offentlige tjenester til brugere og for bibliotekstjenester definerer SIP imidlertid flere specifikke typer netværksserverelementer. Hver af disse serviceelementer kommunikerer også inden for klient-server-modellen implementeret i brugeragentklienter og -servere.

Brugeragent

En brugeragent er et logisk netværksendepunkt, der sender eller modtager SIP -meddelelser og administrerer SIP -sessioner. Brugeragenter har klient- og serverkomponenter. User agent -klienten (UAC) sender SIP -anmodninger. User agent -serveren (UAS) modtager anmodninger og returnerer et SIP -svar. I modsætning til andre netværksprotokoller, der løser klientens og serverens roller, f.eks. I HTTP, hvor en webbrowser kun fungerer som en klient og aldrig som en server, kræver SIP, at begge jævnaldrende implementerer begge roller. UAC- og UAS -rollerne varer kun i en SIP -transaktions varighed.

En SIP -telefon er en IP -telefon, der implementerer klient- og serverfunktioner i en SIP -brugeragent og leverer en telefons traditionelle opkaldsfunktioner, såsom opkald, besvar, afvis, opkaldspauser og opkaldsoverførsel. SIP -telefoner kan implementeres som en hardwareenhed eller som en softphone . Efterhånden som leverandører i stigende grad implementerer SIP som en standard telefoniplatform, er forskellen mellem hardware-baserede og software-baserede SIP-telefoner sløret, og SIP-elementer implementeres i de grundlæggende firmwarefunktioner på mange IP-kompatible kommunikationsenheder såsom smartphones .

I SIP, som i HTTP, kan brugeragenten identificere sig ved hjælp af et meddelelsesoverskriftsfelt ( User-Agent ), der indeholder en tekstbeskrivelse af softwaren, hardwaren eller produktnavnet. Brugeragentfeltet sendes i anmodningsmeddelelser, hvilket betyder, at den modtagende SIP-server kan evaluere disse oplysninger for at udføre enhedsspecifik konfiguration eller funktionsaktivering. Operatører af SIP -netværkselementer gemmer nogle gange disse oplysninger i kundekontoportaler, hvor de kan være nyttige til at diagnosticere SIP -kompatibilitetsproblemer eller i visning af servicestatus.

Proxyserver

En proxyserver er en netværksserver med UAC- og UAS -komponenter, der fungerer som en mellemliggende enhed med det formål at udføre anmodninger på vegne af andre netværkselementer. En proxyserver spiller primært rollen som opkalds routing; den sender SIP -anmodninger til en anden enhed tættere på destinationen. Fuldmagter er også nyttige til håndhævelse af politik, f.eks. Til at afgøre, om en bruger må foretage et opkald. En proxy fortolker og om nødvendigt omskriver bestemte dele af en anmodningsmeddelelse, før den videresendes.

SIP -proxyservere, der dirigerer beskeder til mere end én destination, kaldes forking proxies. Forkling af en SIP -anmodning etablerer flere dialoger fra den enkelte anmodning. Et opkald kan således besvares fra et af flere SIP -slutpunkter. Til identifikation af flere dialoger har hver dialog en identifikator med bidrag fra begge slutpunkter.

Omdiriger server

En omdirigeringsserver er en brugeragent -server, der genererer 3xx (omdirigering) svar på anmodninger, den modtager, og leder klienten til at kontakte et alternativt sæt URI'er. En omdirigeringsserver gør det muligt for proxyservere at sende invitationer til SIP -sessioner til eksterne domæner.

Registrator

SIP -brugeragentregistrering til SIP -registrator med godkendelse.

En registrator er et SIP -slutpunkt, der leverer en lokationstjeneste. Det accepterer REGISTER -anmodninger, registrerer adressen og andre parametre fra brugeragenten. For efterfølgende anmodninger giver det et vigtigt middel til at lokalisere mulige kommunikationskammerater på netværket. Placeringstjenesten forbinder en eller flere IP -adresser med registreringsagentens SIP -URI. Flere brugeragenter kan registrere sig for den samme URI med det resultat, at alle registrerede brugeragenter modtager opkaldene til URI.

SIP-registratorer er logiske elementer og er ofte samlokaliseret med SIP-proxyer. For at forbedre netværksskalerbarheden kan lokationstjenester i stedet være placeret med en omdirigeringsserver.

Session grænsekontroller

Etablering af en session gennem en back-to-back brugeragent .

Session border controllers (SBC'er) fungerer som midterkasser mellem brugeragenter og SIP -servere til forskellige typer funktioner, herunder skjult netværkstopologi og assistance i NAT -krydsning . SBC'er er en uafhængigt konstrueret løsning og nævnes ikke i SIP RFC.

Gateway

Gateways kan bruges til at forbinde et SIP -netværk med andre netværk, f.eks. PSTN, der bruger forskellige protokoller eller teknologier.

SIP -beskeder

SIP er en tekstbaseret protokol med syntaks svarende til HTTP. Der er to forskellige typer SIP -meddelelser: anmodninger og svar. Den første linje i en anmodning har en metode , der definerer anmodningens art og en Request-URI, der angiver, hvor anmodningen skal sendes. Den første linje i et svar har en svarskode .

Anmodninger

Anmodninger starter en funktionalitet af protokollen. De sendes af en brugeragentklient til serveren og besvares med et eller flere SIP -svar , som returnerer en resultatkode for transaktionen og generelt angiver transaktionens succes, fiasko eller anden tilstand.

SIP -anmodninger
Anmodningsnavn Beskrivelse Noter RFC referencer
TILMELD Registrer URI'en, der er angivet i feltet To-header med en lokationsserver, og knytter den til den netværksadresse, der er angivet i feltet Contact header. Kommandoen implementerer en placeringstjeneste. RFC  3261
INVITERE Start en dialog til oprettelse af et opkald. Anmodningen sendes af en brugeragentklient til en brugeragentserver. Når den sendes under en etableret dialog ( genbud ), ændrer den sessionerne, for eksempel at sætte et opkald i venteposition. RFC  3261
ACK Bekræft, at en enhed har modtaget et endeligt svar på en INVITE -anmodning. RFC  3261
FARVEL Signalafslutning af en dialog og afslutning af et opkald. Denne meddelelse kan blive sendt af begge endepunkter i en dialog. RFC  3261
AFBESTILLE Annuller enhver afventende anmodning. Normalt betyder det at afslutte et opkald, mens det stadig ringer, før det besvares. RFC  3261
OPDATER Rediger tilstanden for en session uden at ændre tilstanden i dialogboksen. RFC  3311
HENVISE Bed modtageren om at sende en anmodning med henblik på opkaldsoverførsel. RFC  3515
PRACK Foreløbig anerkendelse. PRACK sendes som svar på foreløbigt svar (1xx). RFC  3262
ABONNER Starter et abonnement for underretning om begivenheder fra en underretter. RFC  6665
UNDERRETTE Informer en abonnent om meddelelser om en ny begivenhed. RFC  6665
OFFENTLIGGØRE Udgiv en begivenhed til en notifikationsserver. RFC  3903
BESKED Lever en sms. Anvendes i chatprogrammer. RFC  3428
INFO Send oplysninger i midten af ​​sessionen, der ikke ændrer sessionstilstanden. Denne metode bruges ofte til DTMF -relæ. RFC  6086
MULIGHEDER Forespørg mulighederne for et slutpunkt. Det bruges ofte til NAT keepalive -formål . RFC  3261

Svar

Svar sendes af brugeragent -serveren, der angiver resultatet af en modtaget anmodning. Flere klasser af svar genkendes, bestemt af det numeriske område af resultatkoder:

  • 1xx: Foreløbige svar på anmodninger angiver, at anmodningen var gyldig og behandles.
  • 2xx: Anmodningen blev fuldført. Som et svar på en INVITERE angiver det, at et opkald er etableret. Den mest almindelige kode er 200, hvilket er en ukvalificeret succesrapport.
  • 3xx: Omdirigering af opkald er nødvendig for at afslutte anmodningen. Anmodningen skal udfyldes med en ny destination.
  • 4xx: Anmodningen kan ikke udfyldes på serveren af ​​forskellige årsager, herunder dårlig anmodningssyntaks (kode 400).
  • 5xx: Serveren opfyldte ikke en tilsyneladende gyldig anmodning, herunder interne serverfejl (kode 500).
  • 6xx: Anmodningen kan ikke opfyldes på nogen server. Det angiver en global fejl, herunder afvisning af opkald fra destinationen.

Transaktioner

Eksempel: Bruger1's UAC bruger en invitationsklientransaktion til at sende den første INVITE (1) -meddelelse. Hvis der ikke modtages noget svar efter en timerstyret ventetid, kan UAC vælge at afslutte transaktionen eller videresende INVITEN. Når et svar er modtaget, er User1 sikker på, at INVITEN blev leveret pålideligt. Bruger1's UAC skal derefter anerkende svaret. Ved levering af ACK (2) er begge sider af transaktionen komplet. I dette tilfælde kan der være etableret en dialog.

SIP definerer en transaktionsmekanisme til at kontrollere udvekslingerne mellem deltagerne og levere meddelelser pålideligt. En transaktion er en tilstand i en session, som kontrolleres af forskellige timere. Klienttransaktioner sender anmodninger, og servertransaktioner reagerer på disse anmodninger med et eller flere svar. Svarene kan omfatte foreløbige svar med en svarskode i formen 1xx og et eller flere endelige svar (2xx - 6xx).

Transaktioner kategoriseres yderligere som enten invitationer eller ikke-invitationer . Invitationstransaktioner adskiller sig ved, at de kan etablere en langvarig samtale, omtalt som en dialog i SIP, og dermed inkludere en bekræftelse (ACK) af et ikke-svigtende endeligt svar, f.eks. 200 OK .

Instant messaging og tilstedeværelse

Den Session Initiation Protocol for Instant Messaging og Presence Udnyttelse Extensions (SIMPLE) er den SIP-baserede pakke af standarder for instant messaging og oplysninger om tilstedeværelse . Message Session Relay Protocol (MSRP) tillader onlinemeddelelsessessioner og filoverførsel.

Overensstemmelsestest

SIP -udviklerfællesskabet mødes regelmæssigt på konferencer arrangeret af SIP Forum for at teste interoperabilitet mellem SIP -implementeringer. Den TTCN-3 testspecifikationen sprog, udviklet af en task force på ETSI (STF 196), der bruges til angivelse overensstemmelsesafprøvninger for SIP implementeringer.

Ydelsestest

Når man udvikler SIP -software eller implementerer en ny SIP -infrastruktur, er det vigtigt at teste serveres og IP -netværks evne til at håndtere visse opkaldsbelastninger: antal samtidige opkald og antal opkald pr. Sekund. SIP -ydelsestestersoftware bruges til at simulere SIP- og RTP -trafik for at se, om serveren og IP -netværket er stabilt under opkaldsbelastningen. Softwaren måler ydeevneindikatorer som svarforsinkelse, svar/beslaglæggelsesforhold , RTP- rystelser og tab af pakker , forsinkelse tur-retur .

Ansøgninger

SIP -forbindelse er en markedsføringsbetegnelse for voice over Internet Protocol (VoIP) -tjenester, der tilbydes af mange internettelefonitjenesteudbydere (ITSP'er). Tjenesten giver routing af telefonopkald fra en kundes private filialcentral (PBX) telefonsystem til PSTN. Sådanne tjenester kan forenkle virksomhedens informationssysteminfrastruktur ved at dele internetadgang til stemme og data og fjerne omkostningerne til Basic Rate Interface (BRI) eller Primary Rate Interface (PRI) telefonkredsløb.

SIP -trunking er et lignende marketingbegreb, der foretrækkes, når tjenesten bruges til at forenkle en telekommunikationsinfrastruktur ved at dele operatøradgangskredsløbet for stemme, data og internettrafik, samtidig med at behovet for PRI -kredsløb fjernes.

SIP-aktiverede videoovervågningskameraer kan starte opkald for at advare operatøren om begivenheder, f.eks. Bevægelse af objekter i et beskyttet område.

SIP bruges i lyd over IP til broadcast -applikationer, hvor det giver et interoperabelt middel til lydgrænseflader fra forskellige producenter til at oprette forbindelser med hinanden.

Implementeringer

US National Institute of Standards and Technology (NIST), Advanced Networking Technologies Division leverer en offentlig implementering af Java- implementering, der fungerer som referenceimplementering for standarden. Implementeringen kan fungere i scenarier for proxyserver eller brugeragent og er blevet brugt i mange kommercielle og forskningsprojekter. Det understøtter fuldt ud RFC  3261 og en række udvidelses -RFC'er, herunder RFC  6665 (hændelsesmeddelelse) og RFC  3262 (pålidelige foreløbige svar).

Der findes mange andre kommercielle og open-source SIP-implementeringer. Se Liste over SIP -software .

SIP-ISUP arbejder sammen

SIP-I, Session Initiation Protocol med indkapslet ISUP , er en protokol, der bruges til at oprette, ændre og afslutte kommunikationssessioner baseret på ISUP ved hjælp af SIP- og IP-netværk. Tjenester, der bruger SIP-I, omfatter tale, videotelefoni, fax og data. SIP-I og SIP-T er to protokoller med lignende funktioner, især for at tillade ISUP-meddelelser at blive transporteret over SIP-netværk. Dette bevarer alle de detaljer, der er tilgængelige i ISUP -overskriften. SIP-I blev defineret af ITU-T , mens SIP-T blev defineret af IETF .

Kryptering

Bekymringer om sikkerheden ved opkald via det offentlige internet er blevet behandlet ved kryptering af SIP -protokollen til sikker transmission . URI -ordningen SIPS bruges til at pålægge, at SIP -kommunikation skal sikres med Transport Layer Security (TLS). SIPS URI'er har formen sips: user@example.com .

Ende-til-ende-kryptering af SIP er kun mulig, hvis der er en direkte forbindelse mellem kommunikationens endepunkter. Mens en direkte forbindelse kan foretages via Peer-to-peer SIP eller via en VPN mellem slutpunkterne, involverer den fleste SIP-kommunikation flere humle, hvor den første hop er fra en brugeragent til brugeragentens ITSP . For multiple-hop-sagen vil SIPS kun sikre det første hop; de resterende humle vil normalt ikke være sikret med TLS, og SIP -kommunikationen vil være usikker. I modsætning hertil giver HTTPS- protokollen ende-til-ende-sikkerhed, da den gøres med en direkte forbindelse og ikke involverer begrebet humle.

Mediestreams (lyd og video), som er separate forbindelser fra SIPS -signalstrømmen, kan krypteres ved hjælp af SRTP. Nøgleudvekslingen til SRTP udføres med SDES ( RFC  4568 ) eller med ZRTP ( RFC  6189 ). Når SDES bruges, overføres nøglerne via usikker SIP, medmindre SIPS bruges. Man kan også tilføje en MIKEY ( RFC  3830 ) -central til SIP for at bestemme sessionsnøgler til brug med SRTP.

Se også

Noter

Referencer

Bibliografi

  • Brian Reid; Steve Goodman (22. januar 2015), eksamen Ref. 70-342 Advanced Solutions of Microsoft Exchange Server 2013 (MCSE) , Microsoft Press, s. 24, ISBN 978-0-73-569790-4
  • Miikka Poikselkä; Georg Mayer; Hisham Khartabil; Aki Niemi (19. november 2004), The IMS: IP Multimedia Concepts and Services in the Mobile Domain , John Wiley & Sons, s. 268, ISBN 978-0-47-087114-0

eksterne links