SIP - Guida rapida

Session Initiation Protocol (SIP) è uno dei protocolli più comuni utilizzati nella tecnologia VoIP. È un protocollo a livello di applicazione che funziona insieme ad altri protocolli a livello di applicazione per controllare le sessioni di comunicazione multimediale su Internet.

Tecnologia VoIP

Prima di andare oltre, dobbiamo prima comprendere alcuni punti sul VoIP.

  • VOIP è una tecnologia che consente di fornire contenuti vocali e multimediali (video, immagini) su Internet. È uno dei modi più economici per comunicare sempre e ovunque con la disponibilità di Internet.

  • Alcuni vantaggi di VOIP includono:

    • A basso costo

    • Portability

    • Nessun cavo aggiuntivo

    • Flexibility

    • Videoconferenze

  • Per una chiamata VOIP, tutto ciò di cui hai bisogno è un computer / laptop / cellulare con connettività Internet. La figura seguente mostra come avviene una chiamata VoIP.

Con questo fondamentale, torniamo a SIP.

SIP - Panoramica

Di seguito sono riportati alcuni punti da notare su SIP:

  • SIP è un protocollo di segnalazione utilizzato per creare, modificare e terminare una sessione multimediale tramite il protocollo Internet. Una sessione non è altro che una semplice chiamata tra due endpoint. Un endpoint può essere uno smartphone, un laptop o qualsiasi dispositivo in grado di ricevere e inviare contenuti multimediali su Internet.

  • SIP è un protocollo a livello di applicazione definito dallo standard IETF (Internet Engineering Task Force). È definito inRFC 3261.

  • SIP incarna l'architettura client-server e l'uso di URL e URI da HTTP e uno schema di codifica del testo e uno stile di intestazione da SMTP.

  • SIP si avvale dell'aiuto di SDP (Session Description Protocol) che descrive una sessione e RTP (Real Time Transport Protocol) utilizzato per fornire voce e video su rete IP.

  • SIP può essere utilizzato per sessioni a due (unicast) o multiparty (multicast).

  • Altre applicazioni SIP includono trasferimento di file, messaggistica istantanea, videoconferenze, giochi online e distribuzione multimediale.

Dove si inserisce SIP?

Fondamentalmente SIP è un protocollo a livello di applicazione. Si tratta di un semplice protocollo di segnalazione di rete per creare e terminare sessioni con uno o più partecipanti. Il protocollo SIP è progettato per essere indipendente dal protocollo di trasporto sottostante, quindi le applicazioni SIP possono essere eseguite su TCP, UDP o altri protocolli di rete di livello inferiore.

La seguente illustrazione mostra dove SIP si inserisce nello schema generale delle cose:

In genere, il protocollo SIP viene utilizzato per la telefonia via Internet e la distribuzione multimediale tra due o più endpoint. Ad esempio, una persona può avviare una chiamata telefonica a un'altra persona utilizzando SIP oppure qualcuno può creare una chiamata in conferenza con molti partecipanti.

Il protocollo SIP è stato progettato per essere molto semplice, con un insieme limitato di comandi. È anche basato su testo, quindi chiunque può leggere un messaggio SIP passato tra gli endpoint in una sessione SIP.

Ci sono alcune entità che aiutano SIP nella creazione della sua rete. In SIP, ogni elemento di rete è identificato da un fileSIP URI(Uniform Resource Identifier) ​​che è come un indirizzo. Di seguito sono riportati gli elementi di rete:

  • Agente utente
  • Server proxy
  • Server di registrazione
  • Reindirizza server
  • Location Server

Agente utente

È l'endpoint e uno degli elementi di rete più importanti di una rete SIP. Un endpoint può avviare, modificare o terminare una sessione. I programmi utente sono il dispositivo o l'elemento di rete più intelligente di una rete SIP. Potrebbe essere un softphone, un cellulare o un laptop.

I programmi utente sono logicamente divisi in due parti:

  • User Agent Client (UAC) - L'entità che invia una richiesta e riceve una risposta.

  • User Agent Server (UAS) - L'entità che riceve una richiesta e invia una risposta.

SIP si basa su un'architettura client-server in cui il telefono del chiamante funge da client che avvia una chiamata e il telefono del chiamato funge da server che risponde alla chiamata.

Server proxy

È l'elemento di rete che prende una richiesta da un programma utente e la inoltra a un altro utente.

  • Fondamentalmente il ruolo di un server proxy è molto simile a un router.

  • Ha una certa intelligenza per capire una richiesta SIP e inviarla avanti con l'aiuto di URI.

  • Un server proxy si trova tra due agenti utente.

  • Possono esserci un massimo di 70 server proxy tra un'origine e una destinazione.

Esistono due tipi di server proxy:

  • Stateless Proxy Server- Inoltra semplicemente il messaggio ricevuto. Questo tipo di server non memorizza alcuna informazione di una chiamata o di una transazione.

  • Stateful Proxy Server- Questo tipo di server proxy tiene traccia di ogni richiesta e risposta ricevuta e può utilizzarlo in futuro se necessario. Può ritrasmettere la richiesta, se non c'è risposta dall'altra parte in tempo.

Server di registrazione

Il server di registrazione accetta le richieste di registrazione dagli agenti utente. Aiuta gli utenti ad autenticarsi all'interno della rete. Memorizza l'URI e la posizione degli utenti in un database per aiutare altri server SIP all'interno dello stesso dominio.

Dai un'occhiata al seguente esempio che mostra il processo di una registrazione SIP.

Qui il chiamante vuole registrarsi con il dominio TMC. Quindi invia una richiesta di REGISTRAZIONE al server di registrazione di TMC e il server restituisce una risposta 200 OK poiché ha autorizzato il client.

Reindirizza server

Il server di reindirizzamento riceve le richieste e cerca il destinatario previsto della richiesta nel database delle posizioni creato dal registrar.

Il server di reindirizzamento utilizza il database per ottenere informazioni sulla posizione e risponde con 3xx (risposta di reindirizzamento) all'utente. Discuteremo i codici di risposta più avanti in questo tutorial.

Location Server

Il server di localizzazione fornisce informazioni sulle possibili posizioni di un chiamante ai server di reindirizzamento e proxy.

Solo un server proxy o un server di reindirizzamento può contattare un server di posizione.

La figura seguente illustra i ruoli svolti da ciascuno degli elementi di rete nello stabilire una sessione.

SIP - Architettura di sistema

SIP è strutturato come un protocollo a strati, il che significa che il suo comportamento è descritto in termini di una serie di fasi di elaborazione abbastanza indipendenti con solo un accoppiamento libero tra ciascuna fase.

  • Lo strato più basso di SIP è il suo syntax and encoding. La sua codifica è specificata usando un augmentedBackus-Naur Form grammar (BNF).

  • Al secondo livello c'è il transport layer. Definisce come un client invia richieste e riceve risposte e come un server riceve richieste e invia risposte sulla rete. Tutti gli elementi SIP contengono un livello di trasporto.

  • Poi arriva il file transaction layer. Una transazione è una richiesta inviata da una transazione client (utilizzando il livello di trasporto) a una transazione server, insieme a tutte le risposte a tale richiesta inviate dalla transazione server al client. Qualsiasi attività eseguita da un client agente utente (UAC) viene eseguita utilizzando una serie di transazioni.Stateless proxies non contengono un livello di transazione.

  • Lo strato sopra transaction layerè chiamato utente della transazione. Ciascuna delle entità SIP, ad eccezione diStateless proxies, è un utente di transazione.

L'immagine seguente mostra il flusso di chiamate di base di una sessione SIP.

Di seguito viene fornita una spiegazione dettagliata del flusso di chiamate di cui sopra:

  • Una richiesta INVITE inviata a un server proxy è responsabile dell'avvio di una sessione.

  • Il server proxy invia a 100 Trying risposta immediata al chiamante (Alice) per interrompere le ritrasmissioni della richiesta INVITE.

  • Il server proxy cerca l'indirizzo di Bob nel server di posizione. Dopo aver ottenuto l'indirizzo, inoltra ulteriormente la richiesta INVITE.

  • Successivamente, 180 Ringing (Risposte provvisorie) generate da Bob vengono restituite ad Alice.

  • UN 200 OK la risposta viene generata subito dopo che Bob prende il telefono.

  • Bob riceve un ACK dall'Alice, una volta ottenuto 200 OK.

  • Allo stesso tempo, la sessione viene stabilita ei pacchetti RTP (conversazioni) iniziano a fluire da entrambe le estremità.

  • Dopo la conversazione, qualsiasi partecipante (Alice o Bob) può inviare un file BYE richiesta di terminare la sessione.

  • BYE raggiunge direttamente da Alice a Bob bypassando il server proxy.

  • Alla fine, Bob invia un file 200 OK risposta per confermare il BYE e la sessione viene terminata.

  • Nel flusso delle chiamate di base sopra, tre transactions sono (contrassegnati come 1, 2, 3) disponibili.

La chiamata completa (da INVITE a 200 OK) è nota come a Dialog.

SIP Trapezoid

In che modo un proxy aiuta a connettere un utente con un altro? Cerchiamo di scoprirlo con l'aiuto del diagramma seguente.

La topologia mostrata nel diagramma è nota come trapezio SIP. Il processo si svolge come segue:

  • Quando un chiamante avvia una chiamata, viene inviato un messaggio INVITE al server proxy. Dopo aver ricevuto l'invito, il server proxy tenta di risolvere l'indirizzo del chiamato con l'aiuto del server DNS.

  • Dopo aver ottenuto il percorso successivo, il server proxy del chiamante (Proxy 1, noto anche come server proxy in uscita) inoltra la richiesta INVITE al server proxy del chiamato che funge da server proxy in entrata (Proxy 2) per il chiamato.

  • Il server proxy in entrata contatta il server di posizione per ottenere informazioni sull'indirizzo del chiamato in cui si è registrato l'utente.

  • Dopo aver ottenuto le informazioni dal server di localizzazione, inoltra la chiamata alla sua destinazione.

  • Una volta che i programmi utente conoscono il loro indirizzo, possono ignorare la chiamata, ovvero le conversazioni passano direttamente.

I messaggi SIP sono di due tipi: requests e responses.

  • La riga di apertura di una richiesta contiene un metodo che definisce la richiesta e un Request-URI che definisce dove deve essere inviata la richiesta.

  • Allo stesso modo, la riga di apertura di una risposta contiene un codice di risposta.

Metodi di richiesta

SIP requestssono i codici utilizzati per stabilire una comunicazione. Per completarli, ci sonoSIP responses che generalmente indicano se una richiesta è riuscita o meno.

Queste richieste SIP, note come METODI, rendono utilizzabile il messaggio SIP.

  • I METODI possono essere considerati richieste SIP, poiché richiedono un'azione specifica che deve essere intrapresa da un altro agente utente o server.

  • I METODI si distinguono in due tipi:

    • Metodi fondamentali

    • Metodi di estensione

Metodi fondamentali

Esistono sei metodi principali come discusso di seguito.

INVITARE

INVITE viene utilizzato per avviare una sessione con un programma utente. In altre parole, un metodo INVITE viene utilizzato per stabilire una sessione multimediale tra i programmi utente.

  • INVITE può contenere le informazioni multimediali del chiamante nel corpo del messaggio.

  • Una sessione è considerata stabilita se un INVITO ha ricevuto una risposta positiva (2xx) o è stato inviato un ACK.

  • Una richiesta INVITE riuscita stabilisce un file dialog tra i due programmi utente che continua fino a quando non viene inviato un BYE per terminare la sessione.

  • Un INVITO inviato all'interno di una finestra di dialogo stabilita è noto come re-INVITE.

  • Re-INVITE viene utilizzato per modificare le caratteristiche della sessione o aggiornare lo stato di una finestra di dialogo.

INVITE Esempio

Il codice seguente mostra come viene utilizzato INVITE.

INVITE sips:[email protected] SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:[email protected]>;tag = 1234567 
   To: Bob<sips:[email protected]>
   Call-ID: [email protected]  
   CSeq: 1 INVITE 
   Contact: <sips:[email protected]> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  
   
   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

ADDIO

BYE è il metodo utilizzato per terminare una sessione stabilita. Questa è una richiesta SIP che può essere inviata dal chiamante o dal chiamato per terminare una sessione.

  • Non può essere inviato da un server proxy.

  • La richiesta BYE normalmente instrada end-to-end, bypassando il server proxy.

  • BYE non può essere inviato a un INVITO in attesa o a una sessione non stabilita.

REGISTRATI

La richiesta REGISTER esegue la registrazione di un agente utente. Questa richiesta viene inviata da un agente utente a un server di registrazione.

  • La richiesta di REGISTRAZIONE può essere inoltrata o inoltrata fino a quando non raggiunge un registrar autorevole del dominio specificato.

  • Porta l'AOR (Address of Record) in To intestazione dell'utente che si sta registrando.

  • La richiesta REGISTER contiene il periodo di tempo (3600sec).

  • Un agente utente può inviare una richiesta di REGISTRAZIONE per conto di un altro agente utente. Questo è noto comethird-party registration. Qui, ilFrom il tag contiene l'URI della parte che presenta la registrazione per conto della parte identificata nel file To intestazione.

ANNULLA

CANCEL viene utilizzato per terminare una sessione non stabilita. I programmi utente utilizzano questa richiesta per annullare un tentativo di chiamata in sospeso avviato in precedenza.

  • Può essere inviato da un agente utente o da un server proxy.

  • ANNULLA è un file hop by hop request, cioè passa attraverso gli elementi tra il programma utente e riceve la risposta generata dal successivo elemento stateful.

ACK

ACK viene utilizzato per riconoscere le risposte finali a un metodo INVITE. Un ACK va sempre nella direzione di INVITE.ACK può contenere SDP body (caratteristiche dei media), se non è disponibile in INVITE.

  • ACK non può essere utilizzato per modificare la descrizione del supporto che è già stata inviata nell'INVITO iniziale.

  • Un proxy con stato che riceve un ACK deve determinare se l'ACK deve essere inoltrato o meno a valle a un altro proxy o agente utente.

  • Per le risposte 2xx, ACK è end-to-end, ma per tutte le altre risposte finali funziona hop per hop quando sono coinvolti proxy stateful.

OPZIONI

Il metodo OPTIONS viene utilizzato per interrogare un agente utente o un server proxy sulle sue capacità e scoprire la sua disponibilità attuale. La risposta a una richiesta elenca le capacità dell'agente utente o del server. Un proxy non genera mai una richiesta OPTIONS.

Metodi di estensione

sottoscrivi

SUBSCRIBE viene utilizzato dagli interpreti per stabilire un abbonamento allo scopo di ricevere notifiche su un particolare evento.

  • Contiene un file Expires campo di intestazione che indica la durata di un abbonamento.

  • Al termine del periodo di tempo, l'abbonamento terminerà automaticamente.

  • La sottoscrizione stabilisce un dialogo tra i programmi utente.

  • Puoi iscriverti nuovamente inviando un altro SUBSCRIBE all'interno della finestra di dialogo prima della scadenza.

  • Verrà ricevuto 200 OK per un abbonamento dall'Utente.

  • Gli utenti possono annullare l'iscrizione inviando un altro metodo SUBSCRIBE con valore Expires 0 (zero).

NOTIFICARE

NOTIFY viene utilizzato dai programmi utente per ottenere il verificarsi di un particolare evento. Di solito una NOTIFICA si attiverà all'interno di una finestra di dialogo quando esiste una sottoscrizione tra l'abbonato e il notificatore.

  • Ogni NOTIFICA riceverà 200 risposte OK se viene ricevuto dal notificatore.

  • NOTIFY contiene un file Event campo di intestazione che indica l'evento e un file subscriptionstate campo di intestazione che indica lo stato corrente della sottoscrizione.

  • Una NOTIFICA viene sempre inviata all'inizio e alla fine di un abbonamento.

PUBBLICARE

PUBLISH viene utilizzato da un programma utente per inviare informazioni sullo stato dell'evento a un server.

  • PUBBLICA è utile soprattutto quando ci sono più fonti di informazioni sugli eventi.

  • Una richiesta PUBBLICA è simile a una NOTIFICA, tranne per il fatto che non viene inviata in una finestra di dialogo.

  • Una richiesta PUBLISH deve contenere un file Expires campo di intestazione e un file Min-Expires campo di intestazione.

FARE RIFERIMENTO

REFER è usato da un programma utente per indicare a un altro programma utente di accedere a un URI per la finestra di dialogo.

  • REFER deve contenere un file Refer-Tointestazione. Questa è un'intestazione obbligatoria per REFER.

  • REFER può essere inviato all'interno o all'esterno di una finestra di dialogo.

  • UN 202 Accepted attiverà una richiesta REFER che indica che un altro programma utente ha accettato il riferimento.

INFORMAZIONI

INFO viene utilizzato da un programma utente per inviare informazioni di segnalazione della chiamata a un altro agente utente con il quale ha stabilito una sessione multimediale.

  • Questa è una richiesta end-to-end.

  • Un proxy inoltrerà sempre una richiesta INFO.

AGGIORNARE

UPDATE viene utilizzato per modificare lo stato di una sessione se non viene stabilita una sessione. L'utente può modificare il codec con UPDATE.

SE viene stabilita una sessione, viene utilizzato un nuovo invito per modificare / aggiornare la sessione.

PRACK

PRACK viene utilizzato per confermare la ricezione di un trasferimento affidabile di risposta provvisoria (1XX).

  • Generalmente PRACK viene generato da un client quando riceve una risposta provvisoria contenente un file RSeq numero di sequenza affidabile e a supported:100rel intestazione.

  • PRACK contiene il valore (RSeq + CSeq) nel file rack intestazione.

  • Il metodo PRACK si applica a tutte le risposte provvisorie tranne la risposta 100 tentativi, che non viene mai trasportata in modo affidabile.

  • Un PRACK può contenere un corpo del messaggio; può essere utilizzato per lo scambio di offerte / risposte.

MESSAGGIO

Viene utilizzato per inviare un messaggio istantaneo tramite SIP. Un IM di solito consiste in brevi messaggi scambiati in tempo reale dai partecipanti impegnati in una conversazione di testo.

  • Il MESSAGGIO può essere inviato all'interno o all'esterno di una finestra di dialogo.

  • Il contenuto di un MESSAGGIO viene trasportato nel corpo del messaggio come un file MIME attaccamento.

  • UN 200 OK normalmente si riceve una risposta per indicare che il messaggio è stato recapitato a destinazione.

Una risposta SIP è un messaggio generato da un server UAS (user agent server) o da un server SIP per rispondere a una richiesta generata da un client. Potrebbe essere un riconoscimento formale per impedire la ritrasmissione delle richieste da parte di un UAC.

  • Una risposta può contenere alcuni campi di intestazione aggiuntivi di informazioni necessarie per un controllo dell'account utente.

  • SIP ha sei risposte.

  • Da 1xx a 5xx è stato preso in prestito da HTTP e 6xx è stato introdotto in SIP.

  • 1xx è considerato come un provisional risposta e il resto lo sono final risposte.

S.No. Descrizione della funzione
1 1xx: Risposte provvisorie / informative

Le risposte informative vengono utilizzate per indicare call progress. Normalmente le risposte sono end-to-end (tranne 100 tentativi).
2 2xx: risposte di successo

Questa classe di risposte ha lo scopo di indicare che una richiesta è stata accettata.
3 3xx: Risposte di reindirizzamento

Generalmente queste risposte di classe vengono inviate dai server di reindirizzamento in risposta a INVITE. Sono anche noti come risposte di classe di reindirizzamento.
4 4xx: risposte in caso di errore del client

Le risposte agli errori del client indicano che la richiesta non può essere soddisfatta poiché alcuni errori vengono identificati dal lato UAC.
5 5xx: risposta in caso di errore del server

Questa risposta di classe viene utilizzata per indicare che la richiesta non può essere elaborata a causa di un errore con il server.
6 6xx: risposta globale in caso di errore

Questa classe di risposta indica che il server sa che la richiesta fallirà ovunque venga provata. Di conseguenza, la richiesta non deve essere inviata ad altre posizioni.

Un'intestazione è un componente di un messaggio SIP che trasmette informazioni sul messaggio. È strutturato come una sequenza di campi di intestazione.

I campi di intestazione SIP nella maggior parte dei casi seguono le stesse regole dei campi di intestazione HTTP. I campi di intestazione sono definiti comeHeader: field, dove Header viene utilizzato per rappresentare il nome del campo dell'intestazione e field è l'insieme di token che contiene le informazioni. Ogni campo è costituito da un nome di campo seguito da due punti (":") e dal valore del campo (ad es.field-name: field-value).

Intestazioni SIP - Forma compatta

Molti campi di intestazione SIP comuni hanno una forma compatta in cui il nome del campo di intestazione è indicato da un singolo carattere minuscolo. Di seguito vengono forniti alcuni esempi:

Intestazione Forma compatta
Per T
attraverso V
Call-ID io
Contatto M
A partire dal F
Soggetto S
Lunghezza del contenuto io

Formato intestazione SIP

L'immagine seguente mostra la struttura di una tipica intestazione SIP.

Le intestazioni sono classificate come segue a seconda del loro utilizzo in SIP:

SDP è l'acronimo di Session Description Protocol. Viene utilizzato per descrivere sessioni multimediali in un formato compreso dai partecipanti su una rete. A seconda di questa descrizione, una parte decide se partecipare a una conferenza o quando o come partecipare a una conferenza.

  • Il proprietario di una conferenza la pubblicizza sulla rete inviando messaggi multicast che contengono la descrizione della sessione, ad esempio il nome del proprietario, il nome della sessione, la codifica, i tempi, ecc. A seconda di queste informazioni, i destinatari dell'annuncio prendere una decisione sulla partecipazione alla sessione.

  • SDP è generalmente contenuto nella parte del corpo del protocollo di avvio della sessione popolarmente chiamato SIP.

  • SDP è definito nella RFC 2327. Un messaggio SDP è composto da una serie di righe, chiamate campi, i cui nomi sono abbreviati da una singola lettera minuscola e sono nell'ordine richiesto per semplificare l'analisi.

Scopo dell'SDP

Lo scopo di SDP è trasmettere informazioni sui flussi multimediali in sessioni multimediali per aiutare i partecipanti a partecipare o raccogliere informazioni su una particolare sessione.

  • SDP è una breve descrizione testuale strutturata.

  • Trasmette il nome e lo scopo della sessione, i media, i protocolli, i formati dei codec, i tempi e le informazioni sul trasporto.

  • Un partecipante provvisorio controlla queste informazioni e decide se partecipare a una sessione e come e quando partecipare a una sessione se decide di farlo.

  • Il formato ha voci nella forma di <type> = <value>, dove <type> definisce un parametro di sessione univoco e <value> fornisce un valore specifico per quel parametro.

  • La forma generale di un messaggio SDP è:

    x = parameter1 parameter2 ... parameterN

  • La riga inizia con una singola lettera minuscola, ad esempio x. Non ci sono mai spazi tra la lettera e il = e c'è esattamente uno spazio tra ogni parametro. Ogni campo ha un numero definito di parametri.

Parametri di descrizione della sessione

Descrizione della sessione (* denota facoltativo)

  • v = (versione protocollo)
  • o = (proprietario / creatore e identificatore di sessione)
  • s = (nome sessione)
  • i = * (informazioni sulla sessione)
  • u = * (URI della descrizione)
  • e = * (indirizzo e-mail)
  • p = * (numero di telefono)
  • c = * (informazioni sulla connessione - non richieste se incluse in tutti i media)
  • b = * (informazioni sulla larghezza di banda)
  • z = * (aggiustamenti del fuso orario)
  • k = * (chiave di crittografia)
  • a = * (zero o più righe di attributi di sessione)

Versione protocollo

Il campo v = contiene il numero di versione dell'SDP. Poiché la versione corrente di SDP è 0, un messaggio SDP valido inizierà sempre con v = 0.

Origine

Il campo o = contiene informazioni sul mittente della sessione e gli identificatori di sessione. Questo campo viene utilizzato per identificare in modo univoco la sessione.

  • Il campo contiene:

    o = <username> <session-id> <version> <network-type> <address-type>

  • Il username Il parametro contiene il login o l'host del mittente.

  • Il session-id è un timestamp NTP (Network Time Protocol) o un numero casuale utilizzato per garantire l'unicità.

  • Il version è un campo numerico che viene aumentato per ogni modifica alla sessione, consigliato anche come timestamp NTP.

  • Il network-typeè sempre IN per Internet. Il parametro del tipo di indirizzo è IP4 o IP6 per l'indirizzo IPv4 o IPv6 in formato decimale puntato o un nome host completo.

Nome e informazioni della sessione

Il campo s = contiene un nome per la sessione. Può contenere qualsiasi numero di caratteri diverso da zero. Il campo i = facoltativo contiene informazioni sulla sessione. Può contenere un numero qualsiasi di caratteri.

URI

Il campo u = facoltativo contiene un URI (Uniform Resource Indicator) con ulteriori informazioni sulla sessione

Indirizzo e-mail e numero di telefono

Il campo e = facoltativo contiene un indirizzo e-mail dell'ospite della sessione. Il campo p = facoltativo contiene un numero di telefono.

Dati di connessione

Il campo c = contiene informazioni sulla connessione multimediale.

  • Il campo contiene:

    c = <network-type> <address-type> <connection-address>

  • Il network-type parametro è definito come IN per Internet.

  • Il address-type è definito come IP4 per gli indirizzi IPv4 e IP6 per gli indirizzi IPv6.

  • Il connection-address è l'indirizzo IP o l'host che invierà i pacchetti multimediali, che potrebbero essere multicast o unicast.

  • Se multicast, il campo dell'indirizzo di connessione contiene -

    indirizzo-connessione = indirizzo-multicast di base / ttl / numero-di-indirizzi

    • dove ttl è il valore del time-to-live e il numero di indirizzi indica il numero di indirizzi multicast contigui inclusi a partire dall'indirizzo multicast di base.

Larghezza di banda

Il campo b = facoltativo contiene informazioni sulla larghezza di banda richiesta. È della forma -

b = modificatore: larghezza di banda - valore

Ora, orari di ripetizione e fusi orari

Il campo t = contiene l'ora di inizio e l'ora di fine della sessione.

t = ora di inizio ora di fine

Il campo facoltativo r = contiene informazioni sui tempi di ripetizione che possono essere specificati in NTP o in giorni ( d ), ore ( h ) o minuti ( m ).

Il campo z = facoltativo contiene informazioni sugli offset del fuso orario. Questo campo viene utilizzato se si verificano sessioni che coprono un cambiamento dall'ora legale all'ora solare o viceversa.

Annunci dei media

Il campo m = facoltativo contiene informazioni sul tipo di sessione multimediale. Il campo contiene:

m = elenco dei formati di trasporto della porta multimediale

  • Il parametro multimediale è audio, video, testo, applicazione, messaggio, immagine o controllo. Il parametro port contiene il numero di porta.

  • Il parametro di trasporto contiene il protocollo di trasporto o il profilo RTP utilizzato.

  • L'elenco dei formati contiene ulteriori informazioni sui media. Di solito, contiene i tipi di payload multimediali definiti nei profili video audio RTP.

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Uno di questi tre codec può essere utilizzato per la sessione multimediale audio. Se l'intenzione è di stabilire tre canali audio, verranno utilizzati tre campi multimediali separati.

Attributi

Il campo a = facoltativo contiene gli attributi della sessione multimediale precedente. Questo campo può essere utilizzato perextend SDP to provide more information about the media. Se non completamente compreso da un utente SDP, il campo dell'attributo può essere ignorato. Possono esserci uno o più campi attributo per ogni tipo di payload multimediale elencato nel campo media.

Gli attributi in SDP possono essere entrambi

  • livello di sessione, o
  • livello dei media.

Livello di sessione significa che l'attributo è elencato prima della prima riga multimediale nell'SDP. In questo caso, l'attributo si applica a tutte le linee multimediali sottostanti.

Livello supporto significa che è elencato dopo una riga multimediale. In questo caso, l'attributo si applica solo a questo particolare flusso multimediale.

SDP può includere attributi sia a livello di sessione che a livello di supporto. Se lo stesso attributo appare come entrambi, l'attributo del livello multimediale sostituisce l'attributo del livello della sessione per quel particolare flusso multimediale. Si noti che il campo dei dati di connessione può anche essere a livello di sessione o a livello di supporto.

Un esempio di SDP

Di seguito è riportata una descrizione della sessione di esempio, presa da RFC 2327 -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

L'uso di SDP con SIP è indicato nella risposta all'offerta SDP RFC 3264. Il tipo di corpo del messaggio predefinito in SIP è application/sdp.

  • Il chiamante elenca le funzionalità multimediali che desidera ricevere in SDP, di solito in un INVITO o in un ACK.

  • La parte chiamata elenca le proprie capacità multimediali nella risposta 200 OK a INVITE.

Un tipico utilizzo SIP di SDP include i seguenti campi: versione, origine, oggetto, ora, connessione e uno o più supporti e attributi.

  • I campi oggetto e ora non vengono utilizzati da SIP ma sono inclusi per compatibilità.

  • Nello standard SDP, il campo oggetto è un campo obbligatorio e deve contenere almeno un carattere, suggerito come s = - se non c'è soggetto.

  • Il campo ora è generalmente impostato su t = 00. SIP utilizza i campi connessione, media e attributi per impostare le sessioni tra gli UA.

  • Il campo origine ha un uso limitato con SIP.

  • L'id di sessione viene solitamente mantenuto costante durante una sessione SIP.

  • La versione viene incrementata ogni volta che si modifica l'SDP. Se l'SDP inviato è invariato rispetto a quello inviato in precedenza, la versione rimane la stessa.

  • Poiché il tipo di sessione multimediale e il codec da utilizzare fanno parte della negoziazione della connessione, SIP può utilizzare SDP per specificare più tipi di media alternativi e per accettare o rifiutare selettivamente tali tipi di media.

La specifica offerta / risposta, RFC 3264, consiglia di utilizzare un attributo contenente a = rtpmap: per ogni campo media. Un flusso multimediale viene rifiutato impostando il numero di porta su zero per il campo multimediale corrispondente nella risposta SDP.

Esempio

Nell'esempio seguente, il chiamante Tesla vuole impostare una chiamata audio e video con due possibili codec audio e un codec video nell'SDP trasportato nell'INVITO iniziale -

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

I codec sono referenziati dai numeri di profilo RTP / AVP 97, 98.

La parte chiamata Marry risponde alla chiamata, sceglie il secondo codec per il primo campo multimediale e rifiuta il secondo campo multimediale, desiderando solo la sessione AMR.

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Se questa chiamata solo audio non è accettabile, Tom invierà un ACK e poi un BYE per annullare la chiamata. Altrimenti, la sessione audio verrebbe stabilita e i pacchetti RTP scambiati.

Come illustra questo esempio, a meno che il numero e l'ordine dei campi multimediali non vengano mantenuti, la parte chiamante non saprebbe con certezza quali sessioni multimediali sono state accettate e rifiutate dalla parte chiamata.

Le regole di offerta / risposta sono riassunte nelle sezioni seguenti.

Regole per la generazione di un'offerta

Un'offerta SDP deve includere tutti i campi SDP obbligatori (questo include v =, o =, s =, c = e t =). Questi sono campi obbligatori in SDP.

Di solito include un campo media ( m = ) ma non è necessario. Le righe multimediali contengono tutti i codec elencati in ordine di preferenza. L'unica eccezione è che se l'endpoint supporta un numero enorme di codec, dovrebbe essere elencato il più probabile o il più preferito. Diversi tipi di media includono audio, video, testo, MSRP, BFCP e così via.

Regole per la generazione di una risposta

Una risposta SDP a un'offerta deve essere costruita secondo le seguenti regole:

  • La risposta deve avere lo stesso numero di m = righe nello stesso ordine della risposta.

  • I singoli flussi multimediali possono essere rifiutati impostando il numero di porta su 0.

  • Gli stream vengono accettati inviando un numero di porta diverso da zero.

  • I payload elencati per ogni tipo di supporto devono essere un sottoinsieme dei payload elencati nell'offerta.

  • Per i payload dinamici, non è necessario utilizzare lo stesso numero di payload dinamico in ciascuna direzione. Di solito, viene selezionato un solo payload.

Regole per la modifica di una sessione

Entrambe le parti possono avviare un altro scambio di offerte / risposte per modificare una sessione. Quando una sessione viene modificata, è necessario seguire le seguenti regole:

  • Il numero di versione della riga di origine ( o = ) deve essere lo stesso dell'ultimo inviato, il che indica che questo SDP è identico allo scambio precedente, oppure può essere incrementato di uno, che indica un nuovo SDP che deve essere analizzato.

  • L'offerta deve includere tutte le linee multimediali esistenti e devono essere inviate nello stesso ordine.

  • È possibile aggiungere ulteriori flussi multimediali alla fine dell'elenco di m = line.

  • Un flusso multimediale esistente può essere eliminato impostando il numero di porta su 0. Questa linea multimediale deve rimanere nell'SDP e in tutti i futuri scambi di offerte / risposte per questa sessione.

Chiamata in attesa

Un partecipante in una chiamata può mettere temporaneamente in attesa l'altro. Questo viene fatto inviando un INVITE con un SDP identico a quello dell'INVITO originale ma cona = sendonly attributo presente.

La chiamata viene resa nuovamente attiva inviando un altro INVITO con il a = sendrecvattributo presente. La figura seguente mostra il flusso di una chiamata in attesa.

Personal mobilityè la capacità di avere un identificatore costante su un numero di dispositivi. SIP supporta la mobilità personale di base utilizzando il metodo REGISTER, che consente a un dispositivo mobile di modificare il proprio indirizzo IP e il punto di connessione a Internet ed essere ancora in grado di ricevere le chiamate in arrivo.

SIP può anche supportare service mobility - la capacità di un utente di mantenere gli stessi servizi quando è mobile

Mobilità SIP durante la consegna (pre-chiamata)

Un dispositivo associa il proprio URI di contatto con l'indirizzo del record mediante una semplice registrazione SIP. In base all'indirizzo IP del dispositivo, la registrazione autorizza l'aggiornamento automatico di queste informazioni nella rete SIP.

Durante la consegna, lo User-agent si instrada tra diversi operatori, dove deve registrarsi nuovamente con un contatto come AOR con un altro fornitore di servizi.

Ad esempio, prendiamo l'esempio del seguente flusso di chiamate. UA che ha temporaneamente ricevuto un nuovo URI SIP con un nuovo fornitore di servizi. L'UA esegue quindi una doppia registrazione:

  • La prima registrazione è con il nuovo operatore di servizi, che lega l'URI di contatto del dispositivo con l'URI AOR del nuovo provider di servizi.

  • La seconda richiesta REGISTER viene reindirizzata al fornitore di servizi originale e fornisce l'AOR del nuovo fornitore di servizi come URI di contatto.

Come mostrato più avanti nel flusso della chiamata, quando arriva una richiesta alla rete del fornitore di servizi originale, INVITE viene reindirizzato al nuovo fornitore di servizi che quindi instrada la chiamata all'utente.

Per la prima registrazione, il messaggio contenente l'URI del dispositivo sarebbe:

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0

Il secondo messaggio di registrazione con l'URI di roaming sarebbe:

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

Il primo INVITE rappresentato nella figura sopra verrebbe inviato a sip: registrar2.in; il secondo INVITE verrebbe inviato a sip: sip: [email protected], che verrebbe inoltrato asip:[email protected]. Raggiunge Tom e consente di stabilire la sessione. Periodicamente è necessario aggiornare entrambe le registrazioni.

Mobilità durante una chiamata (re-invito)

L'agente utente può cambiare il suo indirizzo IP durante la sessione mentre passa da una rete all'altra. Il SIP di base supporta questo scenario, poiché è possibile utilizzare un re-INVITO in una finestra di dialogo per aggiornare l'URI del contatto e modificare le informazioni sui media nell'SDP.

Dai un'occhiata al flusso delle chiamate menzionato nella figura sottostante.

  • Qui, Tom rileva una nuova rete,

  • Utilizza DHCP per acquisire un nuovo indirizzo IP e

  • Esegue un re-INVITE per consentire la segnalazione e il flusso multimediale al nuovo indirizzo IP.

Se l'UA può ricevere i media da entrambe le reti, l'interruzione è trascurabile. In caso contrario, alcuni pacchetti multimediali potrebbero andare persi, provocando una leggera interruzione della chiamata.

Il re-INVITE apparirà come segue:

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

Il re-INVITE contiene il nuovo indirizzo IP di Bowditch nei campi dell'intestazione Via e Contatto e le informazioni sui media SDP.

Mobilità in Midcall (con sostituzione intestazione)

Nella mobilità midcall, il set di route effettivo (set di proxy SIP che i messaggi SIP devono attraversare) deve cambiare. Non possiamo utilizzare un re-INVITE nella mobilità a metà chiamata

Ad esempio, se è necessario un proxy per l'attraversamento NAT, è necessario modificare l'URI del contatto: è necessario creare una nuova finestra di dialogo. Quindi, deve inviare un nuovo INVITO con un'intestazione Sostituisce, che identifica la sessione esistente.

Note - Supponiamo che A e B siano entrambi in una chiamata e se A ottiene un altro INVITE (diciamo da C) con un'intestazione di sostituzione (dovrebbe corrispondere alla finestra di dialogo esistente), allora A deve accettare l'invito e terminare la sessione con B e trasferire tutte le risorse a dialogo appena formato.

Il flusso delle chiamate è mostrato nella figura seguente. È simile al flusso di chiamate precedente utilizzando re-INVITE tranne per il fatto che viene generato automaticamente un BYE per terminare la finestra di dialogo esistente quando viene accettato l'invito con i sostituti.

Di seguito sono riportati i punti da notare in questo scenario:

  • La finestra di dialogo esistente tra Tom e Jerry include il vecchio server proxy visitato.

  • La nuova finestra di dialogo che utilizza la nuova rete wireless richiede l'inclusione del nuovo server proxy visitato.

  • Di conseguenza, Tom invia un INVITO con sostituzioni, che crea una nuova finestra di dialogo che include il nuovo server proxy visitato ma non il vecchio server proxy visitato.

  • Quando Jerry accetta l'invito, viene automaticamente inviato un BYE per terminare la vecchia finestra di dialogo che passa attraverso il vecchio server proxy visitato che ora non è più coinvolto nella sessione.

  • La sessione multimediale risultante viene stabilita utilizzando il nuovo indirizzo IP di Tom dall'SDP in INVITE.

Mobilità dei servizi

I servizi in SIP possono essere forniti in proxy o in UA. Fornire mobilità ai servizi insieme alla mobilità personale può essere difficile a meno che i dispositivi dell'utente non siano configurati in modo identico con gli stessi servizi.

SIP può supportare facilmente la mobilità dei servizi su Internet. Quando è connesso a Internet, un UA configurato per utilizzare un set di proxy in India può ancora utilizzare tali proxy durante il roaming in Europa. Non ha alcun impatto sulla qualità della sessione multimediale poiché il supporto scorre sempre direttamente tra i due UA e non attraversa i server proxy SIP.

I servizi residenti nell'endpoint sono disponibili solo quando l'endpoint è connesso a Internet. Un servizio di terminazione come un servizio di inoltro di chiamata implementato in un endpoint avrà esito negativo se l'endpoint ha temporaneamente perso la connessione Internet. Quindi alcuni servizi vengono implementati nella rete utilizzando server proxy SIP.

A volte un server proxy inoltra una singola chiamata SIP a più endpoint SIP. Questo processo è noto come fork. In questo caso, una singola chiamata può far squillare più endpoint contemporaneamente.

Con il fork SIP, puoi far squillare il tuo telefono fisso contemporaneamente al tuo softphone o un telefono SIP sul tuo cellulare, permettendoti di rispondere facilmente alla chiamata da entrambi i dispositivi.

In genere, in un ufficio, si supponga che il capo non sia in grado di rispondere alla chiamata o di allontanarsi, il fork SIP consente alla segretaria di rispondere alle chiamate del suo interno.

Il fork sarà possibile se è disponibile un proxy stateful in quanto deve funzionare e rispondere tra i tanti che riceve.

Abbiamo due tipi di biforcazione:

  • Forking parallelo
  • Forking sequenziale

Forking parallelo

In questo scenario, il server proxy eseguirà il fork di INVITE, ad esempio, su due dispositivi (UA2, UA3) alla volta. Entrambi i dispositivi genereranno 180 Squilli e chi riceve la chiamata genererà 200 OK. La risposta (supponiamo UA2) che raggiunge per prima l'Originator stabilirà una sessione con UA2. Per l'altra risposta, verrà attivato un CANCEL.

Se l'originatore riceve entrambe le risposte contemporaneamente, in base al valore q, inoltrerà la risposta.

Forking sequenziale

In questo scenario, il server proxy eseguirà il fork di INVITE su un dispositivo (UA2). Se UA2 non è disponibile o è occupato in quel momento, il proxy lo invierà a un altro dispositivo (UA3).

Ramo: ID e tag

Gli ID filiale aiutano i proxy a far corrispondere le risposte alle richieste forkate. Senza gli ID filiale, un server proxy non sarebbe in grado di comprendere la risposta biforcuta. Branch-id sarà disponibile nell'intestazione Via.

I tag vengono utilizzati dall'UAC per distinguere più risposte finali da diversi UAS. Un UAS non può risolvere se la richiesta è stata forkata o meno. Pertanto, è necessario aggiungere un tag.

I proxy possono anche aggiungere tag se genera una risposta finale, non inseriscono mai tag nelle richieste o nelle risposte che inoltrano.

È possibile che una singola richiesta possa essere forkata anche da più server proxy. Quindi il proxy che eseguirà il fork aggiungerà i propri ID univoci ai rami che ha creato.

Call leg e Call ID

Un segmento di chiamata si riferisce a una relazione di segnalazione uno a uno tra due programmi utente. L'ID chiamata è un identificatore univoco contenuto nel messaggio SIP che fa riferimento alla chiamata. Una chiamata è una raccolta di gambe di chiamata.

Un UAC inizia inviando un INVITO. A causa del fork, potrebbe ricevere più 200 OK da diversi UA. Ciascuno corrisponde a un segmento di chiamata diverso all'interno della stessa chiamata.

Una chiamata è quindi un gruppo di gambe di chiamata. Un segmento di chiamata si riferisce alla connessione end-to-end tra UA.

Gli spazi CSeq nelle due direzioni di un segmento di chiamata sono indipendenti. All'interno di una singola direzione, il numero di sequenza viene incrementato per ogni transazione.

Segreteria telefonica

La posta vocale è molto comune oggigiorno per gli utenti aziendali. È un'applicazione telefonica. Viene visualizzata l'immagine quando la parte chiamata non è disponibile o non è in grado di ricevere la chiamata, il PBX annuncia alla parte chiamante di lasciare un messaggio vocale.

L'agente utente riceverà una risposta 3xx o reindirizzerà al server di posta vocale se il numero della parte chiamata non è raggiungibile. Tuttavia, è necessario un qualche tipo di interno SIP per indicare al sistema di posta vocale quale casella vocale utilizzare, ovvero quale annuncio riprodurre e dove memorizzare il messaggio registrato. Ci sono due modi per ottenere questo risultato:

  • Utilizzando un'estensione del campo dell'intestazione SIP

  • Utilizzando l'URI della richiesta per segnalare queste informazioni

Supponiamo per l'utente sip:[email protected] ha un sistema di posta vocale su sip: voicemail.tutorialspoint.com che fornisce la posta vocale, l'URI di richiesta di INVITE quando viene inoltrato al server di posta vocale potrebbe essere simile a:

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

La figura seguente mostra come l'URI della richiesta trasporta l'identificatore della cassetta postale e il motivo (qui 486).

Come sappiamo, un server proxy può essere stateless o stateful. Qui, in questo capitolo, discuteremo di più sui server proxy e sul routing SIP.

Server proxy senza stato

Un server proxy senza stato inoltra semplicemente il messaggio che riceve. Questo tipo di server non memorizza alcuna informazione della chiamata o della transazione.

  • I proxy senza stato dimenticano la richiesta SIP una volta che è stata inoltrata.
  • La transazione sarà veloce tramite proxy senza stato.

Stateful Proxy Server

Un server proxy con stato tiene traccia di ogni richiesta e risposta che riceve. Può utilizzare le informazioni memorizzate in futuro, se necessario. Può ritrasmettere la richiesta se non riceve una risposta dall'altra parte.

  • I proxy con stato ricordano la richiesta dopo che è stata inoltrata, quindi possono usarla per il routing anticipato. I proxy con stato mantengono lo stato della transazione . La transazione implica lo stato della transazione,notchiama stato .

  • La transazione non è veloce con i proxy con stato come senza stato.

  • I proxy con stato possono eseguire il fork e ritrasmettere se necessario (ad esempio: deviazione di chiamata occupata, ad esempio).

Via e Record-route

Record-Route

L'intestazione Record-Route viene inserita nelle richieste dei proxy che volevano essere nel percorso delle richieste successive per lo stesso call-id. Viene quindi utilizzato dall'agente utente per instradare le richieste successive.

attraverso

Le intestazioni tramite vengono inserite dai server nelle richieste per rilevare i loop e per aiutare le risposte a ritrovare la strada per il client. Ciò è utile affinché solo le risposte raggiungano la destinazione.

  • Un UA stesso genera e aggiunge il proprio indirizzo in un campo di intestazione Via durante l'invio della richiesta.

  • Un proxy che inoltra la richiesta aggiunge un campo di intestazione Via contenente il proprio indirizzo all'inizio dell'elenco dei campi di intestazione Via.

  • Un proxy o UA che genera una risposta a una richiesta copia tutti i campi dell'intestazione Via dalla richiesta in ordine nella risposta, quindi invia la risposta all'indirizzo specificato nel campo dell'intestazione Via superiore.

  • Un proxy che riceve una risposta controlla il campo dell'intestazione Via superiore e corrisponde al proprio indirizzo. Se non corrisponde, la risposta è stata scartata.

  • Il campo di intestazione Via superiore viene quindi rimosso e la risposta inoltrata all'indirizzo specificato nel campo di intestazione Via successivo.

I campi di intestazione Via contengono nome protocollo, numero versione e trasporto (SIP / 2.0 / UDP, SIP / 2.0 / TCP, ecc.) E contengono numeri di porta e parametri come ricevuto, rport, ramo.

  • Un tag ricevuto viene aggiunto a un campo di intestazione Via se un UA o un proxy riceve la richiesta da un indirizzo diverso da quello specificato nel campo di intestazione Via superiore.

  • Un parametro di diramazione viene aggiunto ai campi di intestazione Via da UAs e proxy, che viene calcolato come una funzione hash dell'URI di richiesta e del numero A, Da, ID chiamata e CSeq.

SIP (Softphone) e PSTN (Vecchio telefono) sono entrambi reti diverse e parlano lingue diverse. Quindi abbiamo bisogno di un traduttore (Gateway qui) per comunicare tra queste due reti.

Facciamo un esempio per mostrare come un telefono SIP effettua una chiamata telefonica a un PSTN attraverso il gateway PSTN.

In questo esempio, Tom (sip:[email protected]) è un telefono SIP e Jerry utilizza un numero di telefono globale +91401234567.

SIP a PSTN tramite gateway

La figura seguente mostra un flusso di chiamate da SIP a PSTN tramite gateway.

Di seguito viene fornita una spiegazione dettagliata di tutto il processo che ha luogo durante una chiamata da un telefono SIP a PSTN.

  • Prima di tutto, il telefono (Tom) SIP compone il numero globale +91401234567 per raggiungere Jerry. L'agente utente SIP lo interpreta come un numero globale e lo converte in request-uri usando DNS e attiva la richiesta.

  • Il telefono SIP invia l'INVITO direttamente al gateway.

  • Il gateway avvia la chiamata nella PSTN selezionando un trunk ISUP SS7 per il successivo switch telefonico nella PSTN.

  • Le cifre composte da INVITE vengono mappate in ISUP IAM. Il messaggio di indirizzo completo (ACM) ISUP viene restituito dalla rete PSTN per indicare che il trunk è stato creato.

  • Il telefono genera la suoneria e va al centralino telefonico. Il gateway mappa l'ACM alla risposta 183 Session Progress contenente un SDP che indica la porta RTP che il gateway utilizzerà per collegare l'audio dalla PSTN.

  • Alla ricezione del 183, l'UAC del chiamante inizia a ricevere i pacchetti RTP inviati dal gateway e presenta l'audio al chiamante in modo che sappia che il chiamato sta procedendo nella PSTN.

  • La chiamata viene completata quando la parte chiamata risponde al telefono, il che fa sì che la centrale telefonica invii un messaggio di risposta (ANM) al gateway.

  • Il gateway quindi interrompe la connessione audio PSTN in entrambe le direzioni e invia una risposta 200 OK al chiamante. Poiché il percorso multimediale RTP è già stabilito, il gateway risponde all'SDP nel 183 ma non provoca modifiche alla connessione RTP.

  • L'UAC invia un ACK per completare lo scambio di segnalazione SIP. Poiché non esiste un messaggio equivalente in ISUP, il gateway assorbe l'ACK.

  • Il chiamante invia BYE al gateway per terminare. Il gateway mappa il BYE nel messaggio di rilascio ISUP (REL).

  • Il gateway invia il 200OK al BYE e riceve un RLC dalla PSTN.

Un codec, abbreviazione di coder-decoder, esegue due operazioni di base:

  • Innanzitutto, converte un segnale vocale analogico nella sua forma digitale equivalente in modo che possa essere facilmente trasmesso.

  • Successivamente, converte il segnale digitale compresso nella sua forma analogica originale in modo che possa essere riprodotto.

Ci sono molti codec disponibili sul mercato, alcuni sono gratuiti mentre altri richiedono una licenza. I codec variano nella qualità del suono e variano di conseguenza nella larghezza di banda.

I dispositivi hardware come telefoni e gateway supportano diversi codec. Mentre parlano tra loro, negoziano quale codec useranno.

Qui, in questo capitolo, discuteremo alcuni popolari codec audio SIP ampiamente utilizzati.

G.711

G.711 è un codec introdotto dall'ITU nel 1972 per l'utilizzo nella telefonia digitale. Il codec ha due varianti:A-Law viene utilizzato in Europa e nei collegamenti telefonici internazionali, uLaw è utilizzato negli Stati Uniti e in Giappone.

  • G.711 utilizza una compressione logaritmica. Comprime ogni campione a 16 bit a 8 bit, quindi raggiunge un rapporto di compressione di 1: 2.

  • Il bitrate è 64 kbit / s per una direzione, quindi una chiamata consuma 128 kbit / s.

  • G.711 è lo stesso codec utilizzato dalla rete PSTN, quindi fornisce la migliore qualità vocale. Tuttavia consuma più larghezza di banda rispetto ad altri codec.

  • Funziona meglio nelle reti locali in cui abbiamo molta larghezza di banda disponibile.

G.729

G.729 è un codec con requisiti di larghezza di banda ridotta; fornisce una buona qualità audio.

  • Il codec codifica l'audio in frame di 10 ms. Data una frequenza di campionamento di 8 kHz, un frame da 10 ms contiene 80 campioni audio.

  • L'algoritmo codec codifica ogni frame in 10 byte, quindi il bitrate risultante è di 8 kbit / s in una direzione.

  • G.729 è un codec con licenza. Gli utenti finali che desiderano utilizzare questo codec dovrebbero acquistare un hardware che lo implementa (sia esso un telefono VoIP o un gateway).

  • Una variante utilizzata di frequente di G.729 è G.729a. È compatibile via cavo con il codec originale ma ha requisiti di CPU inferiori.

G.723.1

G.723.1 è il risultato di una competizione che ITU ha annunciato con l'obiettivo di progettare un codec che consentirebbe chiamate oltre 28,8 e collegamenti modem a 33 kbit / s.

  • Abbiamo due varianti di G.723.1. Entrambi operano su frame audio di 30 ms (cioè 240 campioni), ma gli algoritmi differiscono.

  • Il bitrate della prima variante è di 6,4 kbit / s, mentre per la seconda variante è di 5,3 kbit / s.

  • I frame codificati per le due varianti sono lunghi rispettivamente 24 e 20 byte.

GSM 06.10

GSM 06.10 è un codec progettato per reti mobili GSM. È anche noto come GSM Full Rate.

  • Questa variante del codec GSM può essere utilizzata liberamente, quindi la troverai spesso nelle applicazioni VoIP open source.

  • Il codec opera su frame audio lunghi 20 ms (cioè 160 campioni) e comprime ogni frame a 33 byte, quindi il bitrate risultante è di 13 kbit /.

Un agente utente back-to-back (B2BUA) è un elemento di rete logico nelle applicazioni SIP. È un tipo di SIP UA che riceve una richiesta SIP, quindi riformula la richiesta e la invia come nuova richiesta.

A differenza di un server proxy, mantiene lo stato del dialogo e deve partecipare a tutte le richieste inviate sui dialoghi che ha stabilito. Un B2BUA rompe la natura end-to-end di SIP.

B2BUA - Come funziona?

Un agente B2BUA opera tra due endpoint di una telefonata e divide il canale di comunicazione in due call legs. B2BUA è una concatenazione di UAC e UAS. Ha stabilito che partecipa a tutte le segnalazioni SIP tra le due estremità della chiamata. Poiché B2BUA disponibile in un fornitore di servizi di dialogo può implementare alcune funzionalità a valore aggiunto.

Nella parte della chiamata di origine, B2BUA agisce come un server agente utente (UAS) ed elabora la richiesta come un client agente utente (UAC) all'estremità di destinazione, gestendo la segnalazione tra i punti finali uno dopo l'altro.

Un B2BUA mantiene lo stato completo delle chiamate che gestisce. Ogni lato di un B2BUA funziona come un elemento di rete SIP standard come specificato in RFC 3261.

Funzioni di B2BUA

Un B2BUA fornisce le seguenti funzioni:

  • Gestione delle chiamate (fatturazione, disconnessione automatica delle chiamate, trasferimento delle chiamate, ecc.)

  • Interworking di rete (forse con adattamento del protocollo)

  • Nascondere gli interni di rete (indirizzi privati, topologia di rete, ecc.)

Spesso, i B2BUA vengono implementati anche nei gateway multimediali per collegare i flussi multimediali per il pieno controllo della sessione.

Esempio di B2BUA

Molti sistemi telefonici aziendali PBX (Private Branch Exchange) incorporano la logica B2BUA.

Alcuni firewall sono dotati della funzionalità ALG (Application Layer Gateway), che consente a un firewall di autorizzare il traffico SIP e multimediale pur mantenendo un alto livello di sicurezza.

Un altro tipo comune di B2BUA è noto come Session Border Controller (SBC).