Session Initiation Protocol - Session Initiation Protocol

Den Session Initiation Protocol ( SIP ) er en signaleringsprotokoll som brukes for å initiere, opprettholde og avslutte sanntidssesjoner som inneholder tale, video og meldingsprogrammer. SIP brukes for signalering og kontroll av multimedia kommunikasjonsøkter i anvendelser av Internett-telefoni for tale- og videosamtaler, i private IP-telefon systemer, direktemeldinger i løpet av Internet Protocol (IP) nettverk og mobiltelefonen ringe over LTE ( VoLTE ).

Protokollen definerer det spesifikke formatet på meldinger som utveksles og kommunikasjonsrekkefølgen for deltakernes samarbeid. SIP er en tekstbasert protokoll som inneholder mange elementer i Hypertext Transfer Protocol (HTTP) og Simple Mail Transfer Protocol (SMTP). En samtale etablert med SIP kan bestå av flere mediestrømmer , men ingen separate strømmer kreves for applikasjoner, for eksempel tekstmeldinger , som utveksler data som nyttelast i SIP -meldingen.

SIP fungerer sammen med flere andre protokoller som spesifiserer og bærer sesjonsmediene. Vanligvis utføres medietype og parameterforhandling og mediekonfigurasjon med Session Description Protocol (SDP), som bæres som nyttelast i SIP -meldinger. SIP er designet for å være uavhengig av den underliggende transportlagsprotokollen og kan brukes med User Datagram Protocol (UDP), Transmission Control Protocol (TCP) og Stream Control Transmission Protocol (SCTP). For sikre overføringer av SIP -meldinger over usikre nettverkskoblinger, kan protokollen være kryptert med Transport Layer Security (TLS). For overføring av mediestrømmer (tale, video) bruker SDP-nyttelasten som bæres i SIP-meldinger vanligvis Real-Time Transport Protocol (RTP) eller Secure Real-time Transport Protocol (SRTP).

Historie

SIP ble opprinnelig designet av Mark Handley , Henning Schulzrinne , Eve Schooler og Jonathan Rosenberg i 1996 for å lette etablering av multicast -multimediasessioner på Mbone . Protokollen ble standardisert som RFC  2543 i 1999. I november 2000 ble SIP akseptert som en 3GPP- signalprotokoll og permanent element i arkitekturen IP Multimedia Subsystem (IMS) for IP-baserte streaming multimedietjenester i mobilnett . I juni 2002 ble spesifikasjonen revidert i RFC  3261 og forskjellige utvidelser og presiseringer har blitt publisert siden.

SIP ble designet for å tilby en signal- og samtaleoppsettprotokoll for IP-basert kommunikasjon som støtter samtalebehandlingsfunksjonene og funksjonene som er tilstede i det offentlige koblede telefonnettet (PSTN) med en visjon om å støtte nye multimediaprogrammer. Den er utvidet for videokonferanser , streaming av media , direktemeldinger , informasjon om tilstedeværelse , filoverføring , internettfaks og online spill .

SIP kjennetegnes av sine talsmenn for å ha røtter i internettsamfunnet i stedet for i telekommunikasjonsindustrien . SIP har blitt standardisert hovedsakelig av Internet Engineering Task Force (IETF), mens andre protokoller, for eksempel H.323 , tradisjonelt har blitt assosiert med International Telecommunication Union (ITU).

Protokolloperasjon

SIP er bare involvert i signaloperasjonene til en mediekommunikasjonsøkt og brukes hovedsakelig til å sette opp og avslutte tale- eller videosamtaler. SIP kan brukes til å etablere to-parts ( unicast ) eller multiparty ( multicast ) økter. Det tillater også endring av eksisterende samtaler. Endringen kan innebære å endre adresser eller porter , invitere flere deltakere og legge til eller slette mediestrømmer. SIP har også funnet programmer i meldingsprogrammer, for eksempel direktemeldinger, og hendelsesabonnement og varsling.

SIP fungerer sammen med flere andre protokoller som angir medieformat og koding, og som bærer mediet når samtalen er konfigurert. For oppsett av anrop inneholder hoveddelen av en SIP -melding en Session Description Protocol (SDP) dataenhet, som angir medieformat, kodek og mediekommunikasjonsprotokoll. Tale- og videomediestrømmer transporteres vanligvis mellom terminalene ved hjelp av Real-Time Transport Protocol (RTP) eller Secure Real-time Transport Protocol (SRTP).

Hver ressurs i et SIP -nettverk, for eksempel brukeragenter, anropsrutere og telefonsvarerkasser, identifiseres av en Uniform Resource Identifier (URI). Syntaksen til URI følger den generelle standardsyntaksen som også brukes i webtjenester og e-post. URI -opplegget som brukes for SIP er sip og en typisk SIP URI har formen sip: username@domainname eller sip: username@hostport , der domenenavn krever DNS SRV -poster for å finne serverne for SIP -domenet mens hostport kan være en IP -adresse eller en fullt kvalifisert domenenavn for verten og porten. Hvis sikker overføring er nødvendig, ordningen slurker brukes.

SIP bruker designelementer som ligner på HTTP -forespørsels- og svartransaksjonsmodellen. Hver transaksjon består av en klientforespørsel som påkaller en bestemt metode eller funksjon på serveren og minst ett svar. SIP gjenbruker de fleste topptekstfeltene, kodingsregler og statuskoder for HTTP, og gir et lesbart tekstbasert format.

SIP kan bæres av flere transportlagsprotokoller, inkludert Transmission Control Protocol (TCP), User Datagram Protocol (UDP) og Stream Control Transmission Protocol (SCTP). SIP -klienter bruker vanligvis TCP eller UDP på portnummer 5060 eller 5061 for SIP -trafikk til servere og andre endepunkter. Port 5060 brukes ofte for ikke-kryptert signaltrafikk, mens port 5061 vanligvis brukes for trafikk kryptert med Transport Layer Security (TLS).

SIP-baserte telefonnettverk implementerer ofte samtalebehandlingsfunksjoner i Signalsystem 7 (SS7), som det finnes spesielle SIP-protokollutvidelser for, selv om de to protokollene i seg selv er veldig forskjellige. SS7 er en sentralisert protokoll, preget av en kompleks sentral nettverksarkitektur og stumme endepunkter (tradisjonelle telefoner). SIP er en klient-server- protokoll for ekvipotente jevnaldrende. SIP -funksjoner er implementert i de kommuniserende endepunktene, mens den tradisjonelle SS7 -arkitekturen bare er i bruk mellom byttesentre.

Nettverkselementer

Nettverkselementene som bruker Session Initiation Protocol for kommunikasjon kalles SIP -brukeragenter . Hver brukeragent (UA) utfører funksjonen til en brukeragentklient (UAC) når den ber om en servicefunksjon, og den til en brukeragentserver (UAS) når den svarer på en forespørsel. Således kan to SIP -endepunkter i prinsippet fungere uten noen inngripende SIP -infrastruktur. Av operasjonelle årsaker for nettverket, for å tilby offentlige tjenester til brukere og for katalogtjenester, definerer SIP imidlertid flere spesifikke typer nettverksserverelementer. Hver av disse tjenesteelementene kommuniserer også innenfor klient-server-modellen som er implementert i brukeragentklienter og -servere.

Bruker agent

En brukeragent er et logisk endepunkt for nettverket som sender eller mottar SIP -meldinger og administrerer SIP -økter. Brukeragenter har klient- og serverkomponenter. User agent -klienten (UAC) sender SIP -forespørsler. User agent server (UAS) mottar forespørsler og returnerer et SIP -svar. I motsetning til andre nettverksprotokoller som fikser rollene til klient og server, f.eks. I HTTP, der en nettleser bare fungerer som en klient, og aldri som en server, krever SIP at begge jevnaldrende implementerer begge rollene. Rollene til UAC og UAS varer bare i løpet av en SIP -transaksjon.

En SIP -telefon er en IP -telefon som implementerer klient- og serverfunksjoner til en SIP -brukeragent og tilbyr de tradisjonelle anropsfunksjonene til en telefon, for eksempel oppringing, svar, avvisning, samtale og samtaleoverføring. SIP -telefoner kan implementeres som en maskinvareenhet eller som en softphone . Ettersom leverandører i økende grad implementerer SIP som en standard telefoniplattform, blir skillet mellom maskinvarebaserte og programvarebaserte SIP-telefoner uskarpt, og SIP-elementer implementeres i de grunnleggende fastvarefunksjonene til mange IP-kompatible kommunikasjonsenheter som smarttelefoner .

I SIP, som i HTTP, kan brukeragenten identifisere seg ved å bruke et meldingshodefelt ( User-Agent ), som inneholder en tekstbeskrivelse av programvaren, maskinvaren eller produktnavnet. Brukeragentfeltet sendes i forespørselsmeldinger, noe som betyr at den mottakende SIP-serveren kan evaluere denne informasjonen for å utføre enhetsspesifikk konfigurasjon eller funksjonsaktivering. Operatører av SIP -nettverkselementer lagrer noen ganger denne informasjonen i kundekontoportaler, der de kan være nyttige for å diagnostisere SIP -kompatibilitetsproblemer eller vise tjenestestatus.

Proxy-server

En proxy -server er en nettverksserver med UAC- og UAS -komponenter som fungerer som en mellomliggende enhet med det formål å utføre forespørsler på vegne av andre nettverkselementer. En proxy -server spiller først og fremst rollen som samtale ruting; den sender SIP -forespørsler til en annen enhet nærmere destinasjonen. Fullmakter er også nyttige for å håndheve retningslinjer, for eksempel for å avgjøre om en bruker har lov til å ringe. En proxy tolker, og om nødvendig omskriver bestemte deler av en forespørselsmelding før den videresendes.

SIP -proxy -servere som dirigerer meldinger til mer enn én destinasjon kalles forking proxyer. Gaffelen av en SIP -forespørsel etablerer flere dialoger fra den ene forespørselen. Dermed kan et anrop besvares fra et av flere SIP -endepunkter. For identifisering av flere dialoger har hver dialog en identifikator med bidrag fra begge endepunkter.

Viderekoble server

En omdirigeringsserver er en brukeragent -server som genererer 3xx (omdirigering) svar på forespørsler den mottar, og leder klienten til å kontakte et alternativt sett med URIer. En omdirigeringsserver lar proxy -servere lede SIP -sesjonsinvitasjoner til eksterne domener.

Registrar

SIP -brukeragentregistrering til SIP -registrator med autentisering.

En registrator er et SIP -endepunkt som tilbyr en lokasjonstjeneste. Den godtar REGISTER -forespørsler, registrerer adressen og andre parametere fra brukeragenten. For påfølgende forespørsler gir det et viktig middel for å finne mulige kommunikasjonsfeller på nettverket. Plasseringstjenesten knytter en eller flere IP -adresser til SIP -URI -en til registreringsagenten. Flere brukeragenter kan registrere seg for samme URI, med det resultat at alle registrerte brukeragenter mottar samtalene til URI.

SIP-registratorer er logiske elementer og er ofte samlokalisert med SIP-proxyer. For å forbedre skalerbarheten i nettverket kan stedstjenester i stedet være lokalisert med en viderekoblingsserver.

Øktgrensekontroller

Etablering av en økt gjennom en back-to-back brukeragent .

Session border controllers (SBCs) fungerer som midtbokser mellom brukeragenter og SIP -servere for ulike typer funksjoner, inkludert skjult nettverkstopologi og bistand ved NAT -traversal . SBC er en uavhengig konstruert løsning og er ikke nevnt i SIP RFC.

Inngangsport

Gateways kan brukes til å koble et SIP -nettverk til andre nettverk, for eksempel PSTN, som bruker forskjellige protokoller eller teknologier.

SIP -meldinger

SIP er en tekstbasert protokoll med syntaks som ligner på HTTP. Det er to forskjellige typer SIP -meldinger: forespørsler og svar. Den første linjen i en forespørsel har en metode som definerer forespørselens art og en forespørsel-URI, som angir hvor forespørselen skal sendes. Den første linjen i et svar har en responskode .

Forespørsler

Forespørsler starter en funksjonalitet i protokollen. De sendes av en brukeragentklient til serveren og besvares med ett eller flere SIP -svar , som returnerer en resultatkode for transaksjonen, og generelt angir suksess, fiasko eller annen tilstand av transaksjonen.

Svar

Svar sendes av brukeragent -serveren som angir resultatet av en mottatt forespørsel. Flere klasser av svar blir gjenkjent, bestemt av det numeriske området med resultatkoder:

• 1xx: Foreløpige svar på forespørsler indikerer at forespørselen var gyldig og behandles.
• 2xx: Vellykket gjennomføring av forespørselen. Som et svar på en INVITAT, indikerer det at et anrop er opprettet. Den vanligste koden er 200, som er en ukvalifisert suksessrapport.
• 3xx: Viderekobling er nødvendig for å fullføre forespørselen. Forespørselen må fylles ut med en ny destinasjon.
• 4xx: Forespørselen kan ikke fylles ut på serveren av forskjellige årsaker, inkludert syntaks for dårlig forespørsel (kode 400).
• 5xx: Serveren klarte ikke å oppfylle en tilsynelatende gyldig forespørsel, inkludert interne serverfeil (kode 500).
• 6xx: Forespørselen kan ikke oppfylles på noen server. Det indikerer en global feil, inkludert avvisning av anrop fra destinasjonen.

Transaksjoner

Eksempel: User1s UAC bruker en invitasjonsklienttransaksjon for å sende den første INVITE (1) meldingen. Hvis det ikke mottas svar etter en tidsstyrt ventetid, kan UAC velge å avslutte transaksjonen eller sende INVITEN på nytt. Når et svar er mottatt, er User1 sikker på at INVITTEN ble levert pålitelig. Bruker1s UAC må da bekrefte svaret. Ved levering av ACK (2) er begge sider av transaksjonen fullført. I dette tilfellet kan det ha blitt opprettet en dialog.

SIP definerer en transaksjonsmekanisme for å kontrollere utvekslingene mellom deltakerne og levere meldinger pålitelig. En transaksjon er en tilstand av en økt, som kontrolleres av forskjellige tidtakere. Klienttransaksjoner sender forespørsler og servertransaksjoner svarer på disse forespørslene med ett eller flere svar. Svarene kan inneholde foreløpige svar med en svarskode i formen 1xx , og ett eller flere endelige svar (2xx - 6xx).

Transaksjoner kategoriseres videre som enten invitasjon eller ikke-invitasjon . Invitasjonstransaksjoner er forskjellige ved at de kan etablere en langvarig samtale, referert til som en dialog i SIP, og så inkludere en bekreftelse (ACK) på et ikke-sviktende endelig svar, f.eks. 200 OK .

Umiddelbare meldinger og tilstedeværelse

The Session Initiation Protocol for Instant Messaging og Presence Utnytte Extensions (enkel) er SIP-baserte suite av standarder for direktemeldinger og informasjon om tilstedeværelse . Message Session Relay Protocol (MSRP) tillater direktemeldingsøkter og filoverføring.

Samsvartesting

SIP -utviklermiljøet møtes regelmessig på konferanser organisert av SIP Forum for å teste interoperabilitet mellom SIP -implementeringer. Den TTCN-3- testspesifikasjon språk, som er utviklet av en task force ETSI (STF 196), blir brukt til å spesifisere konformitetstester for SIP-implementeringer.

Ytelsestesting

Når du utvikler SIP -programvare eller distribuerer en ny SIP -infrastruktur, er det viktig å teste evnen til servere og IP -nettverk til å håndtere viss samtalebelastning: antall samtidige samtaler og antall samtaler per sekund. SIP -ytelsestesterprogramvare brukes til å simulere SIP- og RTP -trafikk for å se om serveren og IP -nettverket er stabilt under samtalebelastningen. Programvaren måler ytelsesindikatorer som svarforsinkelse, svar/beslag-forhold , RTP- rystelser og tap av pakker , forsinkelse tur-retur .

applikasjoner

SIP -tilkobling er et markedsføringsbegrep for Voice over Internet Protocol (VoIP) -tjenester som tilbys av mange Internett -telefoni -leverandører (ITSP -er). Tjenesten gir ruting av telefonsamtaler fra en kundes private filialcentral (PBX) telefonsystem til PSTN. Slike tjenester kan forenkle infrastruktur for bedriftens informasjonssystem ved å dele Internett -tilgang for tale og data, og fjerne kostnaden for Basic Rate Interface (BRI) eller Primary Rate Interface (PRI) telefonkretser.

SIP -trunking er et lignende markedsføringsbegrep som foretrekkes når tjenesten brukes til å forenkle en telekommunikasjonsinfrastruktur ved å dele operatørtilgangskretsen for tale, data og internettrafikk mens behovet for PRI -kretser fjernes.

SIP-aktiverte videoovervåkningskameraer kan starte samtaler for å varsle operatøren om hendelser, for eksempel bevegelse av objekter i et beskyttet område.

SIP brukes i lyd over IP for kringkastingsapplikasjoner der det gir et interoperabelt middel for lydgrensesnitt fra forskjellige produsenter for å opprette forbindelser med hverandre.

Implementeringer

Det amerikanske nasjonale instituttet for standarder og teknologi (NIST), Advanced Networking Technologies Division, tilbyr en Java- implementering i allmennhet som fungerer som en referanseimplementering for standarden. Implementeringen kan fungere i proxyserver- eller brukeragentscenarier og har blitt brukt i en rekke kommersielle og forskningsprosjekter. Den støtter RFC  3261 i sin helhet og en rekke utvidelses -RFC -er inkludert RFC  6665 (hendelsesvarsel) og RFC  3262 (pålitelige foreløpige svar).

Det finnes mange andre kommersielle og åpen kildekode SIP-implementeringer. Se Liste over SIP -programvare .

SIP-ISUP fungerer

SIP-I, Session Initiation Protocol with encapsulated ISUP , er en protokoll som brukes til å opprette, endre og avslutte kommunikasjonsøkter basert på ISUP ved bruk av SIP- og IP-nettverk. Tjenester som bruker SIP-I inkluderer tale, videotelefoni, faks og data. SIP-I og SIP-T er to protokoller med lignende funksjoner, særlig for å tillate ISUP-meldinger å bli transportert over SIP-nettverk. Dette beholder alle detaljer som er tilgjengelige i ISUP -overskriften. SIP-I ble definert av ITU-T , mens SIP-T ble definert av IETF .

Kryptering

Bekymringer om sikkerheten til samtaler via det offentlige internett har blitt adressert ved kryptering av SIP -protokollen for sikker overføring . URI -ordningen SIPS brukes til å pålegge at SIP -kommunikasjon skal sikres med Transport Layer Security (TLS). SIPS URIer har skjemaet sips: user@example.com .

Ende-til-ende-kryptering av SIP er bare mulig hvis det er en direkte forbindelse mellom kommunikasjonens endepunkter. Selv om en direkte tilkobling kan opprettes via Peer-to-peer SIP eller via en VPN mellom endepunktene, involverer mest SIP-kommunikasjon flere hopp, hvor den første hoppen er fra en brukeragent til brukeragentens ITSP . For multiple-hop-saken vil SIPS bare sikre det første hoppet; de resterende humlene vil normalt ikke være sikret med TLS og SIP -kommunikasjonen vil være usikker. I kontrast gir HTTPS- protokollen ende-til-ende-sikkerhet ettersom den gjøres med en direkte tilkobling og ikke involverer begrepet humle.

Mediestrømmene (lyd og video), som er separate tilkoblinger fra SIPS -signalstrømmen, kan krypteres ved hjelp av SRTP. Nøkkelutvekslingen for SRTP utføres med SDES ( RFC  4568 ), eller med ZRTP ( RFC  6189 ). Når SDES brukes, blir tastene overført via usikker SIP med mindre SIPS brukes. Man kan også legge til en MIKEY ( RFC  3830 ) sentral i SIP for å bestemme sesjonsnøkler for bruk med SRTP.

Se også

Merknader

Referanser

Bibliografi

Eksterne linker

• IANA: SIP -parametere
• IANA: Navn på SIP -hendelsestyper