Session Etablering Protocol

sip , eng.  Session Initiation Protocol , Session Initiation Protocol  - en dataoverførselsprotokol, der beskriver en metode til at etablere og afslutte en brugerkommunikationssession, herunder udveksling af multimedieindhold ( IP-telefoni , video- og lydkonferencer , instant messages , onlinespil ) [1] .

Denne protokol beskriver, hvordan en klientapplikation (f.eks. en softphone ) kan anmode om at starte en forbindelse fra en anden, muligvis fysisk fjern, klient på det samme netværk ved hjælp af dets unikke navn. Protokollen definerer en måde at skabe en kommunikationskanal på og forhandle protokoller til udveksling af information mellem klienter (for eksempel bruges RTP -protokollen til taledataudveksling ). Det er tilladt at tilføje eller fjerne sådanne kanaler under den etablerede session, samt tilslutte og afbryde yderligere klienter (det vil sige, at der er et konferenceopkald, når mere end to parter har tilladelse til at deltage i udvekslingen). SIP bestemmer også den rækkefølge, som sessionen slutter i [2] .

Udviklere af SIP-protokollen

SIP blev udviklet af IETF MMUSIC Working Group [3] . Protokollen begyndte at blive udviklet i 1996 af Henning Schulzrinne ( Columbia University ) og Mark Handley ( University College London ). I november 2000 blev SIP godkendt som en 3GPP -signaleringsprotokol og en kerneprotokol for IMS-arkitekturen ( modifikation 3GPP TS.24.229 [4] ) [5] . SIP  er en af ​​de protokoller, der aktivt bruges til stemmetransmission over internettet ( Voice over IP ), sammen med H.323 .

Protokolprincipper

MMUSIC-arbejdsgruppen baserede protokollen på følgende principper:

Protokoldesign

SIP-klienter bruger traditionelt TCP- eller UDP -port 5060 til at forbinde SIP-netværkselementer. Grundlæggende bruges SIP til at etablere og afbryde tale- og videoopkald. Samtidig kan den bruges i alle andre applikationer, hvor en forbindelse er påkrævet, såsom højttaleranlæg, mobilterminaler og så videre. Der er et stort antal SIP-relaterede RFC'er , der definerer adfærden af ​​sådanne applikationer. For selv at overføre tale- og videodataene bruges andre transportprotokoller, oftest RTP .

Hovedmålet i udviklingen af ​​SIP var at skabe en IP- baseret signaleringsprotokol, der kunne understøtte det udvidede sæt af opkaldsbehandlingsfunktioner og -tjenester leveret af det eksisterende PSTN . SIP-protokollen definerer ikke selv disse funktioner, men fokuserer kun på brugerregistrering, opsætning og afslutning af opkald og tilhørende signalering. Samtidig blev den designet til at understøtte sådanne funktionelle elementer af netværket som proxyservere (proxyservere) og brugeragenter (brugeragenter). Disse elementer giver et grundlæggende sæt tjenester: opkald, opkald til et telefonapparat, lydmeddelelse til abonnenten om opkaldsstatus.

SIP-baserede telefonnetværk kan også understøtte de mere avancerede tjenester, der typisk leveres af SS-7 , på trods af de betydelige forskelle mellem de to protokoller. SS-7 er kendetegnet ved et komplekst, centraliseret intelligent netværk og enkle, ikke-intelligente terminaler (traditionelle telefoner). SIP kræver tværtimod et meget simpelt (og derfor meget skalerbart) netværk med intelligens indbygget i endeelementerne ved kanten (terminaler bygget som fysiske enheder eller programmer).

SIP bruges sammen med flere andre protokoller og deltager kun i signaleringsdelen af ​​en kommunikationssession. SIP fungerer som en bærer for SDP , som beskriver parametrene for medietransmission inden for en session, såsom de anvendte IP- porte og codecs . I en typisk applikation er SIP-sessioner simpelthen strømme af RTP -pakker . RTP er den direkte transportør af tale- og videodata.

Den første foreslåede version af standarden (SIP 2.0) blev defineret i RFC 2543 . Protokollen blev yderligere forfinet i RFC 3261 , selvom mange implementeringer stadig er baseret på mellemversioner af standarden. Bemærk, at versionsnummeret forbliver 2.0.

Adressering

For at interagere med eksisterende IP-netværksapplikationer og for at give brugermobilitet, bruger SIP en adresse, der ligner en e-mail-adresse . Opkaldte og opkaldsadresser er Uniform Resource Pointers URI'er , såkaldte SIP URI'er , normalt i formatet sip:идентификатор@домен, hvor "identifier" er abonnentens navn eller telefonnummer, og "domæne" angiver serveren eller IP-PBX, som kan angives af domænenavnet eller IP-adressen.
Eksempler:

URI-standarden er specificeret i RFC 3986 .

Adressen består af to dele. Den første del er navnet på den bruger, der er registreret i domænet eller arbejdsstationen. Den anden del af adressen angiver netværkets domænenavn, vært eller IP-adresse. Hvis den anden del identificerer telefongatewayen, så angiver den første del abonnentens telefonnummer.

Brugernavne er simpelthen alfanumeriske identifikatorer. I IP-telefoni bruges som regel rent digitale identifikatorer ("numre") for at gøre det lettere at udvide/erstatte klassiske telefonnet. Lokale telefonnumre er normalt 2-3-4 cifre.

Telefonnummeret, der sendes til gatewayen, er tilgængeligt gennem det, det kan enten være et lokalt forbindelsesnummer eller et mobil- eller fastnettelefonnummer. Gateway-adressen (IP-adresse eller domænenavn) indstilles i indstillingerne for telefonen eller klientprogrammet, og brugeren behøver kun at ringe til et nummer for at foretage et opkald.

Netværksarkitektur

SIP-protokollen har en klient-server-arkitektur.

Klienten udsteder anmodninger, der angiver, hvad den ønsker at modtage fra serveren. Serveren modtager og behandler anmodninger og udsteder svar, der indeholder en meddelelse om succesen af ​​anmodningen, en fejlmeddelelse eller information anmodet af klienten.

Opkaldstjenesten er fordelt på forskellige elementer i SIP-netværket. Det vigtigste funktionelle element, der implementerer forbindelsesstyringsfunktionerne, er brugerterminalen. Andre elementer af netværket kan være ansvarlige for at dirigere opkald og tjener nogle gange til at levere yderligere tjenester.

Terminal

Når klienten og serveren er implementeret i terminaludstyret og interagerer direkte med brugeren, kaldes de User Agent Client ( engelsk  UAC , user agent client) - og User Agent Server ( engelsk  UAS , user agent server). Hvis både UAC og UAS er til stede på en enhed, kaldes den en brugeragent ( UA , brugeragent) og er i det væsentlige en SIP -terminal .

Serveren ( UAS ) og klienten ( UAC ) har mulighed for at interagere direkte med brugeren. Andre SIP- klienter og -servere kan ikke gøre dette.

Proxyserver

En proxyserver (fra den engelske  proxy  - "representative") repræsenterer brugerens interesser i netværket. Den accepterer anmodninger, behandler dem og udfører de relevante handlinger. Proxyserveren består af en klient- og en serverdel, så den kan modtage opkald, indlede anmodninger og returnere svar.
Proxyserveren må ikke ændre strukturen og indholdet af transmitterede meddelelser, kun tilføje sine adresseoplysninger til det særlige Via-felt.

Der er to typer proxy-servere

Proxyen kan indikere over for brugeren, som svar på den første anmodning, behovet for yderligere autentificering - mindst et login (svar 407 Proxy-autentificering påkrævet ), inkl. digital autentificering for sikkerhed.

Server B2BUA

B2BUA - ( engelsk  back-to-back user agent , bogstaveligt talt: "back-to-back user agent") - en variant af serverens logiske element i applikationer, der arbejder med SIP-protokollen. B2BUA ligner i konceptet en SIP-proxyserver , men der er grundlæggende forskelle. B2BUA-serveren arbejder samtidigt med flere (normalt to) slutenheder - terminaler, der deler opkaldet eller sessionen op i forskellige sektioner. B2BUA arbejder med hvert sted individuelt, som UAS - i forhold til initiativtager og som UAC - i forhold til den terminal, der modtager opkaldet. I dette tilfælde transmitteres signaleringsmeddelelser inden for sessionen i begge retninger synkront, selvom beslutningen om behovet for at transmittere en meddelelse og dens format træffes af B2BUA for hver sektion individuelt. Hver af deltagerne i forbindelsen (kommunikationssessionen) på signallaget interagerer med B2BUA som med en slutenhed, selvom serveren i virkeligheden er en mellemmand. Dette afspejles i adressefelterne (såsom Fra, Til og Kontakt) for meddelelser sendt af B2BUA-serveren. Den vigtigste forskel mellem B2BUA er således den fuldstændig uafhængige signalering af alle opkaldsben. Dette betyder især, at unikke identifikatorer bruges til at interagere med hver enkelt bruger i en kommunikationssession, og indholdet af de samme meddelelser for forskellige websteder vil være forskelligt. Brugeragenter af slutterminaler kan interagere med B2BUA og med deltagelse af proxyservere.

B2BUA-serveren kan give følgende funktioner:

Ganske ofte er B2BUA en del af en mediegateway for fuldt ud at kunne administrere mediestrømmene i en session. Signaling Gateway, der er en del af forbindelses-/sessionsgrænsekontrolenheden  , er et godt eksempel på en B2BUA-applikation.

Omdiriger server

Omdirigeringsserveren bruges til at omdirigere opkaldet til brugerens aktuelle placering . Omdirigeringsserveren afslutter ikke opkald og initierer ikke sine egne anmodninger, men rapporterer kun adressen på den påkrævede terminal eller proxyserver ved hjælp af 3XX klassesvar ( 301 flyttet permanent eller 302 flyttet midlertidigt ). Til disse formål kan omdirigeringsserveren interagere med en SIP-registrator eller en lokationsserver.

Brugeren må dog ikke bruge omdirigeringsserveren til at oprette forbindelsen, hvis han selv kender den aktuelle adresse på den ønskede bruger.

Registreringsserver (registrator)

SIP-protokollen indebærer brugermobilitet, det vil sige, at brugeren kan bevæge sig inden for netværket ved at få en ny adresse. Derfor har SIP en registreringsmekanisme - besked om en ny adresse fra brugeragenten. Registreringsserveren eller registratoren ( registrator ) tjener til at rette og gemme brugerens aktuelle adresse og er en regelmæssigt opdateret database med adresseoplysninger. Generelt giver brugeren registreringsserveren deres adresseoplysninger, såsom en IP-adresse eller domænenavn og en abonnents telefonnummer, ved hjælp af en anmodning REGISTER. Serveren kan bekræfte vellykket registrering ( 200 OK) eller afvise, hvis der er et datatjek, og brugerkontoen ikke findes ( 404 Not found), eller registrering for brugeren i øjeblikket er forbudt ( 403 Forbidden). Registratoren kan angive behovet for et brugerlogin til verifikation ( 401 Unauthorized), mens den kan tilbyde klienten at autentificere baseret på en krypteret adgangskode. En enhed eller software, der ikke bruger SIP-protokollen (f.eks . DBMS , MS Exchange , RADIUS-server osv.) kan fungere som en informationskilde til brugergodkendelse. Registrering af brugerens terminal på serveren har en vis "levetid" og skal bekræftes af en ny anmodning REGISTERfra klienten, ellers kan adresseoplysningerne blive slettet. Klienten kan også sende en anmodning med en registreringstid på nul - en anmodning om at tvinge fjernelse af adresseoplysninger fra serveren (afslutning af registrering).

I forskellige implementeringer af SIP-netværk kan der være en kombination af en registreringsserver og andre servere i en enkelt applikation eller enhed, der fungerer gennem en enkelt socket på en enkelt port (normalt UDP / 5060) - det vil sige et enkelt punkt til modtagelse og behandling af anmodninger. Så ofte kombineres registratorer med en omdirigeringsserver, B2BUA eller SIP proxy. For eksempel indeholder mange software-PBX'er (for eksempel Asterisk , Yate , RTU ) funktionaliteten af ​​en SIP-registrator med verifikation af hver brugers registreringsdata. Oplysninger om brugerens mulighed for at registrere og etablere forbindelser bestemmes i dette tilfælde af hans enkelte konto. Til gengæld kræver IP-telefoni abonnentudstyr ( telefoner , abonnent-gateways ) i de fleste tilfælde obligatorisk forhåndsregistrering på serveren for yderligere arbejde i telefonnettet.

Som et resultat kan et IP-telefonisystem ligne et mobilkommunikationssystem - når det er tændt, registrerer alt abonnentudstyr sig på switchen (PBX) og kan derefter foretage og modtage opkald gennem det, som enten omdirigerer anmodningen til en anden ende bruger eller videresender anmodningen til en anden switch.

Brugerplaceringsserver

Brugeren kan bevæge sig inden for forskellige netværk, desuden kan den rigtige adresse på brugeren være ukendt, selvom hans nummer er kendt. Dette er især relevant for nummerportabilitetstjenesten (LNP/MNP) . For at løse sådanne problemer er der en mekanisme til at bestemme brugerens placering ved hjælp af tredjepartsværktøjer, der ikke er direkte relateret til SIP - Location Server , som gemmer brugerens aktuelle adresse og er en regelmæssigt opdateret database med adresseoplysninger.  

En bruger, der har brug for en anden brugers adresseoplysninger for at etablere en forbindelse, kontakter ikke lokationsserveren direkte. Denne funktion udføres af andre SIP-servere, der bruger LDAP , R WHOIS , ENUM , RADIUS eller andre protokoller.

SIP-protokolmeddelelser

SIP -protokolmeddelelser (anmodninger og svar) er sekvenser af tekststrenge kodet i overensstemmelse med RFC 2279 . Strukturen og syntaksen af ​​SIP-meddelelser er identiske med dem, der bruges i HTTP-protokollen .

SIP-meddelelsesstruktur
Startlinje
Titler
Tom linje
Meddelelsestekst

Eksempel på INVITE- anmodning :

INVITER 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 Fra: "78128210000" <sip:[email protected]>;tag=as149b2d97 Til: <sip:[email protected]> Kontakt: <sip:[email protected]> Opkalds-id: [email protected] CSeq: 103 INVITER Max Forwards: 16 Dato: ons, 10. januar 2001 13:16:23 GMT Tillad: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Understøttet: erstatter Indholdstype: applikation/sdp Indholdslængde: 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=lyd 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:off - - - - a=sendecv

Forespørgsler

Den originale version af SIP-protokollen (i RFC 3261 ) definerede seks typer anmodninger. Ved hjælp af anmodninger rapporterer klienten den aktuelle placering, inviterer brugere til at deltage i kommunikationssessioner, ændrer allerede etablerede sessioner, afslutter dem osv. Anmodningstypen er angivet i startlinjen.

  1. INVITE  - Inviterer brugeren til en kommunikationssession. Indeholder normalt en SDP-beskrivelse af sessionen.
  2. ACK  - Bekræfter modtagelse af et svar på en INVITE -anmodning .
  3. BYE  - afslutter sessionen. Kan sendes af enhver af de parter, der deltager i sessionen.
  4. ANNULLER  - annullerer behandlingen af ​​tidligere indsendte anmodninger, men påvirker ikke anmodninger, der allerede er afsluttet.
  5. REGISTER  - bærer adresseoplysninger til registrering af en bruger på en lokationsserver.
  6. OPTIONS  - Anmoder om oplysninger om serverens funktionalitet.

I fremtiden blev protokollen udvidet, flere flere typer anmodninger blev tilføjet til den:

  1. PRACK  er en midlertidig bekræftelse ( RFC 3262 ).
  2. ABONNER  - Abonner for at modtage begivenhedsmeddelelser ( RFC 3265 ).
  3. NOTIFY  - meddelelse til abonnenten om begivenheden ( RFC 3265 ).
  4. PUBLISH  - Offentliggørelse af en hændelse på serveren ( RFC 3903 ).
  5. INFO  - informationsoverførsel, der ikke ændrer sessionens tilstand ( RFC 2976 ).
  6. REFER  - Modtagerens anmodning om at sende en SIP-anmodning ( RFC 3515 ).
  7. MESSAGE  - instant messaging ved hjælp af SIP ( RFC 3428 ).
  8. OPDATERING  - Ændring af sessionstilstand uden at ændre dialogtilstand ( RFC 3311 ).

Svar på forespørgsler

Svar på anmodninger rapporterer resultatet af behandlingen af ​​anmodningen eller formidler de ønskede oplysninger. SIP-protokollen arvede strukturen af ​​svar og deres typer fra HTTP-protokollen . Der er defineret seks typer af svar, som bærer forskellige funktionelle belastninger. Svartypen er kodet som et trecifret tal, hvor det vigtigste er det første ciffer, som definerer svarklassen:

  1. 1XX  - informationssvar; angive, at anmodningen er under behandling. De mest almindelige svar af denne type er 100 forsøger , 180 ringer , 183 sessionsfremskridt .
  2. 2XX  - endelige svar, der angiver, at anmodningen blev behandlet. I øjeblikket er kun to svar defineret i denne type - 200 OK og 202 Accepteret (bemærk 202-koden er ikke i RFC 3261 ).
  3. 3XX  er endelige svar, der informerer den opkaldende brugers udstyr om den kaldte brugers nye placering, såsom et 302 Flyttet Midlertidigt svar .
  4. 4XX  - endelige svar, der informerer om en afvisning eller fejl under behandling eller udførelse af en anmodning, for eksempel 403 Forbidden eller det klassiske HTTP - svar 404 Not Found . Andre eksempler: 406 Ikke acceptabel  - uacceptabel (efter indhold) anmodning, 486 Optaget Her  - abonnenten er optaget, eller 487 Forespørgsel afsluttet  - den opkaldende bruger afsluttede forbindelsen uden at vente på svar (anmodning om annullering).
  5. 5XX  - endelige svar, der informerer om, at anmodningen ikke kan behandles på grund af en serverfejl, 500 Intern serverfejl .
  6. 6XX  - endelige svar, der informerer om, at forbindelsen med den kaldte bruger ikke kan etableres, for eksempel betyder svaret 603 Afvisning , at den kaldte bruger afviste det indgående opkald.

Forbindelsesetableringsalgoritmer

SIP-protokollen er en kontrolprotokol til etablering, ændring og afslutning af en streamingdataforbindelse. Transmissionsparametrene for mediestrømme er beskrevet i SIP-protokollen ved hjælp af SDP (Session Description Protocol). Streamingmedier kan transmitteres på forskellige måder, blandt hvilke RTP- og RTCP -transportprotokollerne er de mest populære .

SIP-protokollen definerer 3 hovedscenarier for etablering af en forbindelse: med deltagelse af en proxyserver, med deltagelse af en videresendelsesserver og direkte mellem brugere. Scenarier er forskellige i, hvordan den kaldte bruger findes og inviteres. De grundlæggende forbindelsesetableringsalgoritmer er beskrevet i RFC 3665 .

Et eksempel på et forbindelsesopsætningsscenarie, der involverer en SIP-omdirigeringsserver og en SIP-proxy

Et eksempel på forbindelsesopsætningsscript, der involverer en B2BUA-server

I eksemplet nedenfor bliver medietrafik proxyet gennem serveren. Signaleringsmeddelelser for Alice - B2BUA og B2BUA - Boris-segmenter er fuldstændig uafhængige og udføres inden for forskellige sessioner (i det mindste vil destinations- og afsenderadresserne samt opkalds-id'et for sessionerne ændres). Alices terminal kender ikke den rigtige placering af Boris terminal og omvendt. Dette kan ligne interaktion gennem nogle softswitches eller session border-controllere (SBC'er) .

SIP-T og SIP-I

For at interagere med traditionelle telefonnetværk ved hjælp af SS-7- signalering blev der udviklet ændringer af SIP-protokollen for telefoni: Session Initiation Protocol for Telephones (SIP-T) og Session Initiation Protocol Internetworking (SIP-I). SIP-I-protokollen blev udviklet af ITU-T , anbefaling Q.1912.5 [6] , og SIP-T blev udviklet af IETF og beskrevet i RFC 3372. Hovedopgaven med disse ændringer af SIP-protokollen er at overføre transparent ISUP -meddelelser over et IP-netværk. Denne opgave udføres ved at indkapsle SS -signaleringsenheder i SIP-meddelelser. Alle de nødvendige opgaver til interaktionen mellem protokollerne blev løst baseret på SIP-protokollen:

Interoperabilitetskrav SIP-T funktion
ISUP-signalgennemsigtighed ISUP-indkapsling i SIP-meddelelsestekst
Mulighed for at dirigere SIP-meddelelser afhængigt af ISUP-parametre Oversættelse af ISUP-parametre i SIP-meddelelseshovedet
Oversættelse af adresseoplysninger under en etableret forbindelse Brug af INFO-metoden

Sammenligning med H.323

SIP er menneskelig læsbar og struktureret med hensyn til anmodninger og svar. Tilhængere af SIP hævder også, at det er enklere end H.323 [7] . Dog nogle[ hvem? ] har en tendens til at tro, at selvom SIP's oprindelige mål var enkelhed, er det i sin nuværende form blevet lige så komplekst som H.323. Andet[ hvem? ] mener, at SIP er en tilstandsløs protokol, som dermed gør det nemt at implementere failover og andre funktioner, der er vanskelige i stateful protokoller som H.323. SIP og H.323 er ikke begrænset til stemmekommunikation, de kan betjene enhver kommunikationssession, fra stemme til video eller fremtidige applikationer.

Sammenlign parameter nippe til H.323
Yderligere tjenester Sættet af tjenester, der understøttes af begge protokoller, er omtrent det samme.
Brugernes personlige mobilitet Har et godt sæt mobilitetsstøtteværktøjer Personlig mobilitet understøttet, men mindre fleksibel
Protokoludvidelsesmuligheder Praktisk udvidelsesmuligheder, nem kompatibilitet med tidligere versioner Udvidelsesmuligheder er understøttet, men der er en række kompleksiteter
Netværks skalerbarhed Begge protokoller giver god netværksskalerbarhed
Tidspunkt for etablering af forbindelse En transaktion er nok Flere transaktioner påkrævet
Protokol kompleksitet Enkelt, få anmodninger, tekstbeskedformat Komplekse, mange anmodninger og protokoller, binær repræsentation af meddelelser
Hardwarekompatibilitet Stort set ingen. Hver producent af SIP-enheder følger kun det sæt af anbefalinger (RFC), som han kan lide, fordi sættet af disse anbefalinger er meget stort. Faktisk er det kun basisopkaldet, der er kompatibelt Næsten færdig. Standarder er veletablerede og har et klart sæt specifikationer

Sikkerhed

En separat sektion af RFC 3261 er viet til sikkerhedsproblemer ved brug af SIP-protokollen . Kryptering af signaltrafik er mulig på transportniveau ved brug af TLS over TCP/UDP. Derudover er der udviklet SIPS -standarden ( engelsk  SIPS ), som pålægger yderligere aftaler om sikker datatransmission via SIP. SRTP -protokollen bruges til at kryptere multimedieindhold .

Se også

Noter

  1. ↑ Hygiejnisk centrifugalpumpe med CIP- og SIP-kapacitet  // Verdenspumper. - 2004-05. - T. 2004 , nej. 452 . - S. 8 . — ISSN 0262-1762 . - doi : 10.1016/s0262-1762(04)00189-0 .
  2. ↑ Alan B. Johnston. SIP: forståelse af Session Initiation Protocol . - Boston: Artech House, 2001. - 1 online ressource (xxi, 201 sider) s. - ISBN 1-58053-413-9 , 978-1-58053-413-0.
  3. ↑ Multimediesessionskontrol med flere partier (musik) - Charter Arkiveret 6. december 2005.
  4. ↑ 3GPP-specifikation: 24.229 . Hentet 3. april 2008. Arkiveret fra originalen 22. marts 2008.
  5. ↑ Artikel "Forudsætninger for fremkomsten af ​​NGN" (utilgængeligt link) . Hentet 3. april 2008. Arkiveret fra originalen 13. april 2008. 
  6. ↑ Anbefaling ITU-T Q.1912.5: Samarbejde mellem session initiation protocol (SIP) og bæreruafhængig opkaldskontrolprotokol eller ISDN-brugerdel. . Hentet 11. april 2021. Arkiveret fra originalen 11. april 2021.
  7. ↑ Jim Van Meggelen, Leif Madsen, Jared Smith. Asterisk er fremtiden for IP-telefoni. - Symbol-Plus, St. Petersborg-Moskva, 2009. - 656 s. - 2000 eksemplarer.  — ISBN 978-5-93286-128-8 .

Litteratur

Links

  Gå til Wikidata-elementet  Ordbøger og encyklopædier
I bibliografiske kataloger
 Software til IP- telefoni
Protokoller
Klientsoftware
Server software
Webtjenester
sammenligning