Cos'è SIP?

Sistemi telefonici di fornitori diversi hanno bisogno di un modo condiviso per concordare una chiamata.

SIP non trasporta media, e questo confine spiega perché una chiamata connessa può non avere audio.

Cosa fa effettivamente SIP?

Fa sì che due parti concordino che una sessione debba avvenire e a quali condizioni.

RFC 3261, la specifica del giugno 2002 che lo definisce, descrive SIP come "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants". I cinque compiti sono: trovare l'altro capo, decidere se accetterà la chiamata, concordare i media, far squillare e infine riagganciare o trasferire. La specifica li elenca come:

User location: determination of the end system to be used for
     communication;

User availability: determination of the willingness of the called
     party to engage in communications;

User capabilities: determination of the media and media parameters
     to be used;

Session setup: "ringing", establishment of session parameters at
     both called and calling party;

Session management: including transfer and termination of
     sessions, modifying session parameters, and invoking
     services.

Nessuno dei cinque riguarda il trasporto dell'audio. Questo è l'intero ambito.

Perché la mia chiamata è connessa ma senza audio?

Perché l'audio non è mai stato compito di SIP, e i due percorsi possono fallire indipendentemente.

La specifica è esplicita riguardo al proprio ambito:

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.

I media viaggiano su RTP, negoziato durante la configurazione e poi autonomo, spesso tra endpoint che la segnalazione non ha mai toccato. La segnalazione può completarsi e entrambe le parti possono concordare che una sessione è attiva. L'audio può comunque non arrivare perché un firewall, un traduttore di indirizzi di rete o una regola di instradamento tra gli endpoint media lo ha bloccato lasciando la segnalazione intatta.

Ecco perché audio monodirezionale e assenza di audio costituiscono una categoria diagnostica a sé anziché una variante di errore di chiamata. Il registro chiamate mostrerà una chiamata connessa, perché una chiamata connessa è esattamente ciò che la segnalazione ha ottenuto. Risoluzione problemi voce analizza i sintomi. Lo strumento di chiamata di prova di Bird stampa un riepilogo del picco audio per ciascuna direzione: uno zero su un lato è il sintomo di audio monodirezionale espresso come numero.

La stessa separazione è ciò che permette ad altri servizi di inserirsi agevolmente. RFC 3261 lo esprime come "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." Segreteria telefonica, gruppi di risposta, registrazione chiamate e agenti AI sono tutti costruiti sulle primitive anziché definiti dal protocollo.

Devo registrare un client prima che possa chiamare?

No. I trunk Bird autenticano le chiamate senza registrazione del client.

SIP definisce una funzione di registrazione, che è il modo in cui uno user agent comunica alla rete dove può essere raggiunto. È ciò che rende un telefono da scrivania raggiungibile quando qualcuno compone un interno. Ma registrarsi ed effettuare una chiamata sono atti separati, e un sistema che origina solo chiamate non ha bisogno di essere raggiungibile.

Un SIP INVITE è il metodo che richiede una chiamata. Bird autentica ciascuno rispetto alla lista di IP consentiti del trunk o tramite una sfida con password. I client non si registrano con il trunk. Configura Bird come trunk e non come account registrato: nessuna sezione type=registration in Asterisk, register=false su un gateway FreeSWITCH, registrazione impostata su none in FreePBX o 3CX. Quando un softphone non offre modo di disattivare la registrazione, il tentativo fallito è solo estetico e le chiamate funzionano comunque, perché la piattaforma agisce sull'invito e non sulla registrazione. Configurazione client SIP contiene le configurazioni complete.

Il corollario è dove vanno le credenziali. Il tuo client invia due identità diverse. Il caller ID va nell'header From e deve essere un numero che hai verificato. Il digest username è bird su ogni trunk. Inserire il caller ID nel campo di autenticazione causa un errore di autenticazione anziché un errore che menziona il caller ID.

Perché le risposte somigliano a HTTP?

Perché il protocollo è stato progettato così, fino agli intervalli numerici.

SIP è un protocollo testuale di richiesta e risposta con metodi e header. Le sue risposte rientrano nelle stesse sei classi con gli stessi numeri familiari: un 404 per una destinazione inesistente e un 486 per un sistema terminale occupato. La struttura condivisa permette di leggere una traccia SIP quasi come si leggerebbe una traccia HTTP.

Ci sono due eccezioni. Una sesta classe, 6xx, non ha equivalente HTTP e significa che nessun server può soddisfare la richiesta, non soltanto quello specifico. Un codice comune porta anche un significato su Bird che lo standard non descrive. Cosa significano i codici di risposta SIP copre entrambi i casi, incluso il motivo per cui un 503 da Bird è di solito un rifiuto che il sistema preferisce non spiegare in rete piuttosto che un sovraccarico.

Dove incontro SIP su Bird?

Al trunk, che è l'indirizzo a cui il tuo apparato invia.

Ogni trunk ha un dominio SIP fisso e accetta UDP o TCP su 5060, oppure TLS su 5061 se vuoi la segnalazione cifrata in transito. Cosa può inviare verso di esso lo decidi tu, e un nuovo trunk non accetta nulla finché non lo autorizzi. Cos'è un trunk SIP copre questa decisione e i tre meccanismi che la sostengono. Cos'è una API voce spiega come la parte SIP e la parte HTTP si dividono il lavoro.