Protocolul de stabilire a sesiunii

sorbi , ing.  Session Initiation Protocol , Session Initiation Protocol  - un protocol de transfer de date care descrie o metodă pentru stabilirea și terminarea unei sesiuni de comunicare cu utilizatorul, inclusiv schimbul de conținut multimedia ( telefonie IP , conferințe video și, mesaje instantanee , jocuri online ) [1] .

Acest protocol descrie modul în care o aplicație client (de exemplu, un softphone ) poate solicita începerea unei conexiuni de la un alt client, eventual la distanță fizică, din aceeași rețea folosind numele său unic. Protocolul definește o modalitate de a crea un canal de comunicare și de a negocia protocoale pentru schimbul de informații între clienți (de exemplu, protocolul RTP este utilizat pentru schimbul de date vocale ). Este permisă adăugarea sau eliminarea unor astfel de canale în timpul sesiunii stabilite, precum și conectarea și deconectarea clienților suplimentari (adică, un apel conferință este oferit atunci când mai mult de două părți au permisiunea de a participa la schimb). SIP determină și ordinea în care se încheie sesiunea [2] .

Dezvoltatorii protocolului SIP

SIP a fost dezvoltat de IETF MMUSIC Working Group [3] . Protocolul a început să fie dezvoltat în 1996 de Henning Schulzrinne ( Universitatea Columbia ) și Mark Handley ( Colegiul Universității din Londra ). În noiembrie 2000, SIP a fost aprobat ca protocol de semnalizare 3GPP și protocol de bază pentru arhitectura IMS ( modificarea 3GPP TS.24.229 [4] ) [5] . SIP  este unul dintre protocoalele utilizate în mod activ pentru transmiterea vocii prin Internet ( Voice over IP ), împreună cu H.323 .

Principiile protocolului

Grupul de lucru MMUSIC a bazat protocolul pe următoarele principii:

Proiectare protocol

Clienții SIP folosesc în mod tradițional portul TCP sau UDP 5060 pentru a conecta elementele de rețea SIP. Practic, SIP este folosit pentru a stabili și a deconecta apelurile vocale și video. În același timp, poate fi utilizat în orice alte aplicații în care este necesară o conexiune, cum ar fi sisteme de adresare publică, terminale mobile și așa mai departe. Există un număr mare de RFC -uri legate de SIP care definesc comportamentul unor astfel de aplicații. Pentru a transfera datele de voce și video în sine, sunt utilizate alte protocoale de transport, cel mai adesea RTP .

Scopul principal în dezvoltarea SIP a fost acela de a crea un protocol de semnalizare bazat pe IP care ar putea suporta setul extins de caracteristici și servicii de procesare a apelurilor furnizate de PSTN -ul existent . Protocolul SIP în sine nu definește aceste funcții, ci se concentrează doar pe înregistrarea utilizatorilor, setarea și terminarea apelurilor și semnalizarea asociată. În același timp, a fost conceput pentru a susține astfel de elemente funcționale ale rețelei, cum ar fi servere proxy (servere proxy) și agenți de utilizator (agenți de utilizator). Aceste elemente oferă un set de bază de servicii: apelare, apelare la un telefon, notificare sonoră a abonatului despre starea apelului.

Rețelele de telefonie bazate pe SIP pot suporta și serviciile mai avansate furnizate de obicei de SS-7 , în ciuda diferențelor semnificative dintre cele două protocoale. SS-7 se caracterizează printr-o rețea inteligentă complexă, centralizată și terminale simple, neinteligente (telefoane tradiționale). SIP, dimpotrivă, necesită o rețea foarte simplă (și, prin urmare, foarte scalabilă) cu inteligență încorporată în elementele finale de la margine (terminale construite ca dispozitive fizice sau programe).

SIP este utilizat împreună cu alte câteva protocoale și participă numai la partea de semnalizare a unei sesiuni de comunicare. SIP acționează ca purtător pentru SDP , care descrie parametrii transmisiei media într-o sesiune, cum ar fi porturile IP și codecurile utilizate . Într-o aplicație tipică, sesiunile SIP sunt pur și simplu fluxuri de pachete RTP . RTP este purtătorul direct de date de voce și video.

Prima versiune propusă a standardului (SIP 2.0) a fost definită în RFC 2543 . Protocolul a fost rafinat în continuare în RFC 3261 , deși multe implementări se bazează încă pe versiuni intermediare ale standardului. Rețineți că numărul versiunii rămâne 2.0.

Adresare

Pentru a interacționa cu aplicațiile de rețea IP existente și pentru a oferi mobilitate utilizatorilor, SIP folosește o adresă similară cu o adresă de e-mail . Adresele de apelat și de apelare sunt URI Uniform Resource Pointers , așa-numitele URI SIP , de obicei în format sip:идентификатор@домен, unde „identificator” este numele sau numărul de telefon al abonatului, iar „domeniul” specifică serverul sau IP-PBX, care poate fi specificat prin numele domeniului sau adresa IP.
Exemple:

Standardul URI este specificat în RFC 3986 .

Adresa are două părți. Prima parte este numele utilizatorului înregistrat în domeniu sau stație de lucru. A doua parte a adresei specifică numele domeniului rețelei, gazda sau adresa IP. Dacă a doua parte identifică gateway-ul telefonic, atunci prima parte indică numărul de telefon al abonatului.

Numele de utilizator sunt pur și simplu identificatori alfanumerici. În telefonia IP, de regulă, identificatorii pur digitali („numerele”) sunt utilizați pentru confortul extinderii / înlocuirii rețelelor de telefonie clasice. Numerele de telefon locale au de obicei 2-3-4 cifre.

Numărul de telefon transmis către gateway este orice disponibil prin intermediul acestuia, poate fi fie un număr de conexiune locală, fie un număr de telefon mobil sau fix. Adresa gateway-ului (adresa IP sau numele domeniului) este setată în setările telefonului sau programului client, iar utilizatorul trebuie doar să formeze un număr pentru a efectua un apel.

Arhitectura de rețea

Protocolul SIP are o arhitectură client-server.

Clientul emite cereri indicând ceea ce dorește să primească de la server. Serverul primește și procesează cereri și emite răspunsuri care conțin o notificare cu privire la succesul cererii, o notificare de eroare sau informații solicitate de client.

Serviciul de apel este distribuit între diferite elemente ale rețelei SIP. Principalul element funcțional care implementează funcțiile de gestionare a conexiunii este terminalul utilizatorului. Alte elemente ale rețelei pot fi responsabile pentru rutarea apelurilor și uneori servesc la furnizarea de servicii suplimentare.

Terminal

Când clientul și serverul sunt implementate în echipamentul terminal și interacționează direct cu utilizatorul, ele se numesc User Agent Client ( în engleză  UAC , user agent client) - și User Agent Server ( în engleză  UAS , user agent server). Dacă atât UAC, cât și UAS sunt prezente pe un dispozitiv, atunci acesta se numește User Agent ( UA , user agent) și este în esență un terminal SIP .

Serverul ( UAS ) și clientul ( UAC ) au capacitatea de a interacționa direct cu utilizatorul. Alți clienți și servere SIP nu pot face acest lucru.

Server proxy

Un server proxy (din limba engleză  proxy  - „reprezentant”) reprezintă interesele utilizatorului în rețea. Acceptă cereri, le procesează și efectuează acțiunile corespunzătoare. Serverul proxy constă dintr-o parte client și o parte server, astfel încât poate primi apeluri, iniția cereri și returna răspunsuri.
Serverul proxy nu poate modifica structura și conținutul mesajelor transmise, adăugând doar informațiile despre adresa sa în câmpul special Via.

Există două tipuri de servere proxy

Proxy-ul poate indica utilizatorului, ca răspuns la prima solicitare, necesitatea unei autentificări suplimentare - cel puțin o autentificare (răspunsul 407 Este necesară autentificarea proxy ), incl. autentificare digitală pentru securitate.

Server B2BUA

B2BUA - ( în engleză  back-to-back user agent , literal: "back-to-back user agent") - o variantă a elementului logic de server în aplicațiile care lucrează cu protocolul SIP. B2BUA este similar în concept cu un server proxy SIP , dar există diferențe fundamentale. Serverul B2BUA funcționează simultan cu mai multe (de obicei două) dispozitive finale - terminale, împărțind apelul sau sesiunea în secțiuni diferite. B2BUA lucrează cu fiecare site individual, ca UAS - în raport cu inițiatorul și ca UAC - în raport cu terminalul care primește apelul. În acest caz, mesajele de semnalizare sunt transmise în cadrul sesiunii în ambele sensuri sincron, deși decizia privind necesitatea transmiterii unui mesaj și formatul acestuia este luată de B2BUA pentru fiecare secțiune în mod individual. Fiecare dintre participanții la conexiune (sesiunea de comunicare) la nivelul de semnalizare interacționează cu B2BUA ca și cu un dispozitiv final, deși în realitate serverul este un intermediar. Acest lucru se reflectă în câmpurile de adresă (cum ar fi De la, Către și Contact) ale mesajelor trimise de serverul B2BUA. Astfel, diferența cheie dintre B2BUA este semnalizarea complet independentă a tuturor segmentelor de apel. Aceasta înseamnă, în special, că identificatorii unici sunt utilizați pentru a interacționa cu fiecare utilizator individual în cadrul unei sesiuni de comunicare, iar conținutul acelorași mesaje pentru site-uri diferite va fi diferit. Agenții utilizatori ai terminalelor finale pot interacționa cu B2BUA și cu participarea serverelor proxy.

Serverul B2BUA poate oferi următoarele caracteristici:

Destul de des, B2BUA face parte dintr-un gateway media pentru a gestiona pe deplin fluxurile media dintr-o sesiune. Gateway-ul de semnalizare care face parte din controlerul de frontieră de conexiune/sesiune  este un exemplu excelent de aplicație B2BUA.

Server de redirecționare

Serverul de redirecționare este folosit pentru a redirecționa apelul către locația curentă a utilizatorului. Serverul de redirecționare nu termină apelurile și nu inițiază propriile cereri, ci doar raportează adresa terminalului sau serverului proxy necesar folosind răspunsuri de clasă 3XX ( 301 Mutat permanent sau 302 Mutat temporar ). În aceste scopuri, serverul de redirecționare poate interacționa cu un registrator SIP sau cu un server de locație.

Cu toate acestea, utilizatorul nu poate utiliza serverul de redirecționare pentru a realiza conexiunea dacă el însuși știe adresa curentă a utilizatorului solicitat.

Server de înregistrare (registrar)

Protocolul SIP presupune mobilitatea utilizatorului , adică utilizatorul se poate deplasa în cadrul rețelei obținând o nouă adresă. Prin urmare, SIP are un mecanism de înregistrare - notificarea unei noi adrese de la agentul utilizator. Serverul de înregistrare sau registratorul ( registrare ) servește pentru a fixa și stoca adresa curentă a utilizatorului și este o bază de date actualizată în mod regulat cu informații despre adrese. În general, utilizatorul furnizează serverului de înregistrare informații despre adresa sa, cum ar fi o adresă IP sau un nume de domeniu și numărul de telefon al abonatului, folosind o solicitare REGISTER. Serverul poate confirma înregistrarea cu succes ( 200 OK) sau respinge dacă există o verificare a datelor și contul de utilizator nu este găsit ( 404 Not found) sau înregistrarea utilizatorului este interzisă în prezent ( 403 Forbidden). Registratorul poate indica necesitatea unei autentificare a utilizatorului pentru verificare ( 401 Unauthorized), în timp ce poate oferi clientului să se autentifice pe baza unei parole criptate. Un dispozitiv sau software care nu utilizează protocolul SIP (de exemplu , DBMS , MS Exchange , server RADIUS etc.) poate acționa ca o sursă de informații pentru autentificarea utilizatorului. Înregistrarea terminalului utilizatorului pe server are o anumită „durată de viață” și trebuie confirmată printr-o nouă solicitare REGISTERdin partea clientului, în caz contrar informațiile despre adresă pot fi șterse. Clientul poate trimite, de asemenea, o solicitare cu o durată de viață de înregistrare zero - o solicitare de a forța ștergerea informațiilor despre adresă de pe server (finalizarea înregistrării).

În diferite implementări ale rețelelor SIP, poate exista o combinație de server de înregistrare și alte servere într-o singură aplicație sau dispozitiv care funcționează printr-un singur socket pe un singur port (de obicei UDP / 5060) - adică un singur punct pentru recepție și procesarea cererilor. Așadar, registratorii sunt combinați cu un server de redirecționare, un proxy B2BUA sau SIP. De exemplu, multe PBX software (de exemplu, Asterisk , Yate , RTU ) conțin funcționalitatea unui registrator SIP cu verificarea datelor de înregistrare ale fiecărui utilizator. Informațiile despre capacitatea utilizatorului de a se înregistra și de a stabili conexiuni sunt determinate în acest caz de contul său unic. La rândul lor, echipamentele de abonat de telefonie IP ( telefoane , gateway-uri de abonat ) necesită în cele mai multe cazuri preînregistrare obligatorie pe server pentru continuarea lucrărilor în rețeaua de telefonie.

Ca urmare, un sistem de telefonie IP poate arăta similar cu un sistem de comunicații celulare - atunci când este pornit, toate echipamentele abonaților se înregistrează pe comutator (PBX) și după aceea pot efectua și primi apeluri prin intermediul acestuia, care fie redirecționează cererea către un alt capăt. utilizator sau trimite cererea către un alt comutator.

Server de locație a utilizatorului

Utilizatorul se poate deplasa în cadrul diferitelor rețele, în plus, adresa reală a utilizatorului poate fi necunoscută, chiar dacă numărul acestuia este cunoscut. Acest lucru este relevant, în special, pentru serviciul de portabilitate a numerelor (LNP/MNP) . Pentru a rezolva astfel de probleme, există un mecanism pentru determinarea locației utilizatorului folosind instrumente terțe care nu au legătură directă cu SIP - Location Server , care stochează adresa curentă a utilizatorului și este o bază de date actualizată în mod regulat cu informații despre adrese.  

Un utilizator care are nevoie de informații despre adresa altui utilizator pentru a stabili o conexiune nu contactează direct serverul de locație. Această funcție este realizată de alte servere SIP folosind LDAP , R WHOIS , ENUM , RADIUS sau alte protocoale.

Mesaje protocol SIP

Mesajele de protocol SIP (cereri și răspunsuri) sunt secvențe de șiruri de text codificate în conformitate cu RFC 2279 . Structura și sintaxa mesajelor SIP sunt identice cu cele utilizate în protocolul HTTP .

Structura mesajului SIP
Linia de start
Titluri
Linie goală
Conținutul mesajului

Exemplu de solicitare INVITE :

INVITE sip:[email protected] SIP/2.0 Rută de înregistrare: <sip:[email protected];lr> Prin: SIP/2.0/UDP 10.0.0.10;branch=z9hG4bK3af7.0a6e92f4.0 Prin: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK12ee92cb;rport=5060 De la: "78128210000" <sip:[email protected]>;tag=as149b2d97 Către: <sip:[email protected]> Contact: <sip:[email protected]> ID de apel: [email protected] CSeq: 103 INVITARE Max atacanți: 16 Data: miercuri, 10 ianuarie 2001 13:16:23 GMT Permite: INVITARE, ACK, ANULARE, OPȚIUNI, BYE, REFER, ABONAȚI-VĂ, NOTIFICAȚI Suportat: înlocuiește Tip de conținut: aplicație/sdp Lungimea conținutului: 394 v=0 o=root 3303 3304 IN IP4 10.0.0.10 s=sesiune 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 telefon-eveniment/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=sendrecv

Cereri

Versiunea originală a protocolului SIP (în RFC 3261 ) a definit șase tipuri de solicitări. Cu ajutorul cererilor, clientul raportează locația curentă, invită utilizatorii să participe la sesiuni de comunicare, modifică sesiunile deja stabilite, le încheie etc. Tipul cererii este indicat în linia de start.

  1. INVITE  - Invită utilizatorul la o sesiune de comunicare. Conține de obicei o descriere SDP a sesiunii.
  2. ACK  - Confirmă primirea unui răspuns la o solicitare INVITE .
  3. BYE  - încheie sesiunea. Poate fi transmis de oricare dintre părțile participante la ședință.
  4. ANULARE  - anulează procesarea cererilor depuse anterior, dar nu afectează cererile care au finalizat deja procesarea.
  5. ÎNREGISTRARE  - conține informații despre adresă pentru înregistrarea unui utilizator pe un server de locație.
  6. OPȚIUNI  - Solicită informații despre funcționalitatea serverului.

În viitor, protocolul a fost extins, i s-au adăugat mai multe tipuri de solicitări:

  1. PRACK  este o confirmare temporară ( RFC 3262 ).
  2. SUBSCRIBE  - Abonați-vă pentru a primi notificări de evenimente ( RFC 3265 ).
  3. NOTIFY  - notificarea abonatului despre eveniment ( RFC 3265 ).
  4. PUBLICARE  - Publicarea unui eveniment pe server ( RFC 3903 ).
  5. INFO  - transfer de informații care nu modifică starea sesiunii ( RFC 2976 ).
  6. REFER  - Solicitarea destinatarului de a trimite o cerere SIP ( RFC 3515 ).
  7. MESAJ  - mesagerie instantanee folosind SIP ( RFC 3428 ).
  8. UPDATE  - Modificarea stării sesiunii fără modificarea stării dialogului ( RFC 3311 ).

Răspunsuri la întrebări

Răspunsurile la solicitări raportează rezultatul procesării cererii sau transmit informațiile solicitate. Protocolul SIP a moștenit structura răspunsurilor și tipurile acestora din protocolul HTTP . Sunt definite șase tipuri de răspunsuri, purtând sarcini funcționale diferite. Tipul de răspuns este codificat ca un număr din trei cifre, cea mai importantă fiind prima cifră, care definește clasa de răspuns:

  1. 1XX  - răspunsuri informaționale; indică faptul că cererea este în curs de procesare. Cele mai frecvente răspunsuri de acest tip sunt 100 Încercare , 180 Sonerie , 183 Progres sesiune .
  2. 2XX  - răspunsuri finale, care indică faptul că cererea a fost procesată cu succes. În prezent, doar două răspunsuri sunt definite în acest tip - 200 OK și 202 Acceptat (nota 202 codul nu este în RFC 3261 ).
  3. 3XX  sunt răspunsuri finale care informează echipamentul utilizatorului apelant despre noua locație a utilizatorului apelat, cum ar fi un răspuns 302 Moved Temporary .
  4. 4XX  - răspunsuri finale care informează despre o respingere sau o eroare în timpul procesării sau executării unei cereri, de exemplu, 403 Interzis sau răspunsul HTTP clasic 404 Not Found . Alte exemple: 406 Not Acceptable  - cerere inacceptabilă (după conținut), 486 Busy Here  - abonatul este ocupat sau 487 Request Terminated  - utilizatorul care a apelat a încheiat conexiunea fără a aștepta un răspuns (cerere de anulare).
  5. 5XX  - răspunsuri finale care informează că cererea nu poate fi procesată din cauza unei erori de server, 500 Server Internal Error .
  6. 6XX  - răspunsuri finale care informează că conexiunea cu utilizatorul apelat nu poate fi stabilită, de exemplu, răspunsul 603 Refuzare înseamnă că utilizatorul apelat a respins apelul primit.

Algoritmi de stabilire a conexiunii

Protocolul SIP este un protocol de control pentru stabilirea, modificarea și terminarea unei conexiuni de date în flux. Parametrii de transmisie ai fluxurilor media sunt descriși în protocolul SIP prin intermediul SDP (Session Description Protocol). Media de streaming poate fi transmisă prin diferite mijloace, printre care protocoalele de transport RTP și RTCP sunt cele mai populare .

Protocolul SIP definește 3 scenarii principale pentru stabilirea unei conexiuni: cu participarea unui server proxy, cu participarea unui server de redirecționare și direct între utilizatori. Scenariile diferă în ceea ce privește modul în care utilizatorul apelat este găsit și invitat. Algoritmii de bază de stabilire a conexiunii sunt descriși în RFC 3665 .

Un exemplu de scenariu de configurare a conexiunii care implică un server de redirecționare SIP și un proxy SIP

Un exemplu de script de configurare a conexiunii care implică un server B2BUA

În exemplul de mai jos, traficul media este transmis prin proxy prin server. Mesajele de semnalizare pentru segmentele Alice - B2BUA și B2BUA - Boris sunt complet independente și sunt executate în cadrul diferitelor sesiuni (cel puțin adresele de destinație și de expediere, precum și Call ID-ul sesiunilor se vor modifica). Terminalul lui Alice nu cunoaște locația reală a terminalului lui Boris și invers. Aceasta poate arăta ca o interacțiune prin unele softswitch -uri sau controlere de frontieră de sesiune (SBC) .

SIP-T și SIP-I

Pentru a interacționa cu rețelele telefonice tradiționale utilizând semnalizarea SS-7 , au fost dezvoltate modificări ale protocolului SIP pentru telefonie: Protocolul de inițiere a sesiunii pentru telefoane (SIP-T) și Protocolul de inițiere a sesiunii de internetworking (SIP-I). Protocolul SIP-I a fost dezvoltat de ITU-T , recomandarea Q.1912.5 [6] , iar SIP-T a fost dezvoltat de IETF și descris în RFC 3372. Sarcina principală a acestor modificări ale protocolului SIP este de a transfera în mod transparent Mesaje ISUP printr-o rețea IP. Această sarcină este îndeplinită prin încapsularea unităților de semnalizare SS în mesaje SIP. Toate sarcinile necesare pentru interacțiunea dintre protocoale au fost rezolvate pe baza protocolului SIP:

Cerință de interoperabilitate Funcția SIP-T
Transparența semnalizării ISUP Încapsularea ISUP în corpul mesajului SIP
Posibilitatea de a ruta mesaje SIP în funcție de parametrii ISUP Traducerea parametrilor ISUP în antetul mesajului SIP
Traducerea informațiilor despre adresă în timpul unei conexiuni stabilite Folosind metoda INFO

Comparație cu H.323

SIP este ușor de citit și structurat în termeni de solicitări și răspunsuri. Susținătorii SIP susțin, de asemenea, că este mai simplu decât H.323 [7] . Cu toate acestea, unii[ cine? ] tind să creadă că, în timp ce scopul inițial al SIP a fost simplitatea, în forma sa actuală a devenit la fel de complex ca H.323. Alte[ cine? ] cred că SIP este un protocol fără stat, ceea ce face astfel ușoară implementarea failover-ului și a altor caracteristici care sunt dificile în protocoalele cu state, cum ar fi H.323. SIP și H.323 nu se limitează la comunicarea vocală, ele pot servi orice sesiune de comunicare, de la voce la video sau aplicații viitoare.

Compara parametrul ÎNGHIŢITURĂ H.323
Servicii aditionale Setul de servicii suportate de ambele protocoale este aproximativ același.
Mobilitatea personală a utilizatorilor Are un set bun de instrumente de sprijin pentru mobilitate Mobilitatea personală susținută, dar mai puțin flexibilă
Extensibilitatea protocolului Extensibilitate convenabilă, compatibilitate ușoară cu versiunile anterioare Extensibilitatea este acceptată, dar există o serie de complexități
Scalabilitatea rețelei Ambele protocoale oferă o scalabilitate bună a rețelei
Ora stabilirii conexiunii O singură tranzacție este suficientă Sunt necesare tranzacții multiple
Complexitatea protocolului Simplu, puține solicitări, format mesaj text Complex, multe cereri și protocoale, reprezentare binară a mesajelor
Compatibilitate hardware Practic nici unul. Fiecare producător de dispozitive SIP urmează doar setul de recomandări (RFC) care îi place, deoarece setul acestor recomandări este foarte mare. De fapt, doar apelul de bază este compatibil Aproape complet. Standardele sunt bine stabilite și au un set clar de specificații

Securitate

O secțiune separată a RFC 3261 este dedicată problemelor de securitate folosind protocolul SIP . Criptarea traficului de semnalizare este posibilă la nivel de transport prin utilizarea TLS peste TCP/UDP. În plus, a fost dezvoltat standardul SIPS ( English  SIPS ), care impune acorduri suplimentare privind transmiterea securizată a datelor prin SIP. Protocolul SRTP este utilizat pentru a cripta conținutul multimedia .

Vezi și

Note

  1. Pompă centrifugă igienă cu capacitate CIP și SIP  // World Pumps. — 2004-05. - T. 2004 , nr. 452 . - S. 8 . — ISSN 0262-1762 . - doi : 10.1016/s0262-1762(04)00189-0 .
  2. Alan B. Johnston. SIP: înțelegerea protocolului de inițiere a sesiunii . - Boston: Artech House, 2001. - 1 resursă online (xxi, 201 pagini) p. - ISBN 1-58053-413-9 , 978-1-58053-413-0.
  3. Multiparty Multimedia Session Control (mmusic) - Charter Arhivat 6 decembrie 2005.
  4. Specificația 3GPP: 24.229 . Consultat la 3 aprilie 2008. Arhivat din original pe 22 martie 2008.
  5. Articolul „Precondiții pentru apariția NGN” (link inaccesibil) . Consultat la 3 aprilie 2008. Arhivat din original pe 13 aprilie 2008. 
  6. Recomandarea ITU-T Q.1912.5: Interfuncționare între protocolul de inițiere a sesiunii (SIP) și protocolul de control al apelurilor independent de purtător sau partea utilizator ISDN. . Preluat la 11 aprilie 2021. Arhivat din original la 11 aprilie 2021.
  7. Jim Van Meggelen, Leif Madsen, Jared Smith. Asterisk este viitorul telefoniei IP. - Simbol-Plus, Sankt Petersburg-Moscova, 2009. - 656 p. - 2000 de exemplare.  — ISBN 978-5-93286-128-8 .

Literatură

Link -uri