SIP, il Session Initiation Protocol, è il modo in cui le chiamate telefoniche vengono aperte su internet. Quando un dispositivo vuole chiamarne un altro, SIP trasporta la negoziazione: chi chiama, dove è raggiungibile l’altra parte, quali codec audio supportano entrambi e quando qualcuno riaggancia. La voce non viaggia mai su SIP. Una volta che le due parti si sono accordate, l’audio scorre come un flusso separato, quasi sempre RTP.
Questa separazione è l’unica cosa da portarsi via da questa guida: SIP è la conversazione sulla chiamata, non la chiamata. Tutto il resto, i metodi, i codici di risposta, le porte, segue da lì. La guida spiega come funziona una chiamata SIP messaggio per messaggio, cosa significa il vocabolario e dove compare SIP quando a rispondere alle tue chiamate è un agente vocale IA.
Cos’è SIP e cosa non è
SIP è un protocollo di segnalazione a livello applicazione definito dall’IETF. È apparso la prima volta come RFC 2543 nel 1999 ed è stato revisionato come RFC 3261 nel 2002, che resta lo standard implementato da ogni telefono SIP, PBX e operatore. I suoi progettisti hanno preso in prestito il modello richiesta-risposta e la sintassi testuale di HTTP, quindi un messaggio SIP si legge in una cattura di pacchetti senza strumenti speciali.
Tre cose che SIP non è:
- Non è l’audio. SIP negozia la sessione e poi si fa da parte. Voce e video viaggiano in pacchetti RTP, descritti più sotto.
- Non è un servizio. Nessuno ti vende “SIP”. Quello che gli operatori vendono è il trunk SIP: un servizio che usa il protocollo SIP per collegare il tuo sistema telefonico alla rete telefonica pubblica.
- Non è l’unico modo di segnalare una chiamata. H.323 è più vecchio, WebRTC gestisce le chiamate dentro i browser e i protocolli proprietari girano dentro app chiuse. SIP ha vinto nel mondo della telefonia aziendale perché è aperto, basato su testo e abbastanza semplice da implementare per qualsiasi fornitore.
Come funziona una chiamata SIP
Una chiamata SIP è un breve scambio di richieste testuali e risposte numerate. Ecco una tipica chiamata in entrata, dallo squillo al riaggancio:
- INVITE. Il lato di chi chiama invia un INVITE all’indirizzo del chiamato. Il suo corpo contiene un blocco SDP (Session Description Protocol) con l’IP del chiamante, la porta dove vuole l’audio e i codec che supporta.
- 100 Trying. I proxy lungo il percorso confermano la ricezione, così chi chiama smette di ritrasmettere.
- 180 Ringing. Il dispositivo chiamato sta avvisando il suo utente. È il momento in cui chi chiama sente il tono di squillo.
- 200 OK. Il chiamato risponde. La risposta contiene il suo blocco SDP, completando la negoziazione dei codec.
- ACK. Chi chiama conferma la risposta finale. La sessione ora è stabilita e l’audio RTP inizia a fluire in entrambe le direzioni.
- BYE. Chi riaggancia invia un BYE. L’altra parte risponde 200 OK e la sessione si chiude.
A metà chiamata, ciascuna delle due parti può inviare un nuovo INVITE, chiamato re-INVITE, per modificare la sessione: metterla in attesa, aggiungere il video o cambiare codec. Una richiesta REFER chiede all’altra parte di chiamare un’altra destinazione, ed è così che funzionano i trasferimenti.
Ecco com’è fatto un INVITE sul filo, leggermente accorciato:
INVITE sip:+14155550132@sip.example.com SIP/2.0
Via: SIP/2.0/TLS client.example.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
To: <sip:+14155550132@sip.example.com>
Call-ID: 3848276298220188511@client.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.example.com;transport=tls>
Content-Type: application/sdp
Content-Length: 213
v=0
o=alice 2890844526 2890844526 IN IP4 client.example.com
s=-
c=IN IP4 client.example.com
t=0 0
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000Le ultime tre righe dell’offerta SDP sono i codec sul tavolo: il payload 0 è G.711 μ-law, il payload 8 è G.711 A-law e il payload 101 è telephone-event, la via fuori banda per inviare i tasti DTMF dentro il flusso audio. Una chiamata sulla rete pubblica si assesta quasi sempre su una delle due varianti di G.711, ed è per questo che l’audio telefonico suona come suona.
I metodi SIP da conoscere
Le richieste SIP si chiamano metodi. Questi sono quelli che incontrerai in una cattura:
| Metodo | Cosa fa |
|---|---|
| INVITE | Avvia una sessione, o la modifica a metà chiamata (re-INVITE) |
| ACK | Conferma la risposta finale a un INVITE |
| BYE | Chiude la sessione |
| CANCEL | Abbandona un INVITE a cui non è ancora stata data risposta |
| REGISTER | Dice a un registrar “sono raggiungibile a questo indirizzo” |
| OPTIONS | Chiede a un dispositivo cosa sa fare, senza chiamarlo |
| REFER | Chiede all’altra parte di chiamare un terzo: la base dei trasferimenti |
| INFO | Trasporta informazioni a metà chiamata, uno dei modi in cui possono viaggiare le cifre DTMF |
Ogni richiesta riceve risposte con codici a tre cifre, raggruppati per la prima cifra:
| Classe | Significato | Esempi |
|---|---|---|
| 1xx | Provvisoria | 100 Trying, 180 Ringing, 183 Session Progress |
| 2xx | Successo | 200 OK, 202 Accepted |
| 3xx | Reindirizzamento | 301 Moved Permanently, 302 Moved Temporarily |
| 4xx | Errore del client | 401 Unauthorized, 403 Forbidden, 404 Not Found, 486 Busy Here |
| 5xx | Errore del server | 500 Server Internal Error, 503 Service Unavailable |
| 6xx | Fallimento globale | 603 Decline, 604 Does Not Exist Anywhere |
Due di questi si rendono utili durante l’apertura. Un 401 o un 407 non è un fallimento; è una richiesta di autenticazione, e il mittente deve riprovare con le credenziali digest. Un 488 Not Acceptable Here significa che le due parti non condividono nessun codec, il modo gentile in cui una chiamata dice che non vi siete mai messi d’accordo su come codificare l’audio.
Indirizzi, registrazione e gli apparati in mezzo
Gli indirizzi SIP assomigliano agli indirizzi email: sip:alice@example.com, eventualmente con una porta o un trasporto, come in sip:alice@example.com:5061;transport=tls. Un numero di telefono diventa un URI SIP aggiungendo il dominio dell’operatore, ed è per questo che sip:+14155550132@sip.example.com è un indirizzo completo che si può chiamare.
Siccome i dispositivi si spostano e stanno dietro il NAT, un telefono SIP comunica alla rete dove si trova: invia un REGISTER al suo registrar, che annota “alice@example.com al momento è a questo IP”. Quando arriva un INVITE per Alice, un server proxy cerca quel record e inoltra la richiesta a dove Alice si trova davvero. Davanti alla maggior parte dei deployment reali c’è un session border controller (SBC), un buttafuori per il traffico SIP che termina la segnalazione, nasconde la rete interna, applica le policy di sicurezza e normalizza le stranezze degli stack SIP dei vari fornitori.
SIP vs RTP vs SDP
Tre protocolli si dividono il lavoro di ogni chiamata SIP:
| Protocollo | Ruolo |
|---|---|
| SIP | Segnalazione: trova il chiamato, negozia la sessione, la chiude |
| SDP | Descrizione: il payload nei messaggi SIP che elenca codec, IP e porte |
| RTP | Media: trasporta l’audio o il video veri, marcati con numeri di sequenza e timestamp |
Ecco perché una chiamata può squillare benissimo e consegnare solo silenzio. La metà SIP ha funzionato, quindi entrambi i telefoni concordano che una chiamata esiste, ma la metà RTP è rotta, di solito da un firewall o da un NAT che lascia passare la segnalazione e scarta i media. Quando fai il debug di una chiamata senza audio, guarda il percorso dei media, non la segnalazione. La stessa separazione è ciò che rende il jitter un problema di RTP: i campi di sequenza e timestamp di ogni pacchetto RTP, definiti dalla RFC 3550, sono esattamente ciò che un ricevitore misura per calcolarlo.
SIP vs VoIP vs trunk SIP
I tre termini vengono usati in modo intercambiabile, e non sono la stessa cosa:
| Termine | Cos’è |
|---|---|
| VoIP | L’idea generale: la voce trasportata su reti IP |
| SIP | Un protocollo di segnalazione usato per aprire chiamate VoIP |
| Trunk SIP | Un servizio dell’operatore che usa SIP per collegare il tuo sistema telefonico alla PSTN |
Se il VoIP è l’idea di chiamare via internet, SIP è la grammatica che parlano i due capi, e un trunk SIP è l’abbonamento che porta la tua chiamata sulla rete telefonica pubblica. La guida ai trunk SIP copre il lato del servizio: fornitori, canali e configurazione.
Trasporti, porte e crittografia
La segnalazione SIP viaggia su UDP o TCP sulla porta 5060, oppure su TLS sulla porta 5061. UDP è il default tradizionale ed evita il blocco head-of-line, ma i messaggi grandi si frammentano, quindi TCP è comune per qualsiasi cosa di dimensioni consistenti. TLS crittografa la segnalazione e autentica l’altro capo, ed è ciò che gli operatori si aspettano per qualsiasi cosa in produzione.
Il SIP in chiaro non crittografa nulla: chiunque sul percorso può leggere la segnalazione, e i media viaggiano su RTP non crittografato. La soluzione standard è TLS per la segnalazione più SRTP, definito dalla RFC 3711, per i media. I due capi devono mettersi d’accordo, perché attivare la crittografia da una parte sola è un modo affidabile di produrre chiamate che si connettono e non portano audio.
Un avvertimento sopravvissuto a ogni decennio di SIP: non esporre un endpoint SIP aperto. Gli scanner perlustrano internet in cerca della porta 5060 pochi minuti dopo la sua comparsa, a caccia di trunk che facciano chiamate gratis. Autentica i mittenti con credenziali digest, autorizza gli IP di segnalazione del tuo operatore, o entrambe le cose.
Dove SIP incontra un agente vocale
Se metti un agente vocale IA sulla rete telefonica, SIP è il protocollo che lavora ai due estremi della chiamata: l’operatore consegna le chiamate in entrata alla piattaforma di agenti come INVITE SIP, e la piattaforma rimanda indietro chiamate in uscita e trasferimenti allo stesso modo. Alcuni dettagli del protocollo smettono di essere curiosità nel momento in cui quello stack è tuo:
- I trasferimenti sono REFER. Quando l’agente passa un chiamante a una persona, la piattaforma invia un SIP REFER che chiede all’operatore di far squillare una nuova destinazione. Un REFER semplice è un trasferimento a freddo; renderlo a caldo, dove la persona sente prima il contesto, è compito dell’agente prima che il REFER parta.
- I tasti premuti hanno tre trasporti. Le cifre DTMF possono viaggiare in banda come audio, fuori banda come eventi telephone-event RFC 4733 (il payload 101 nell’INVITE qui sopra) o dentro messaggi SIP INFO. Un disallineamento tra ciò che il telefono invia e ciò che l’agente ascolta è il motivo per cui i menu “premi 1” ingoiano cifre in silenzio.
- I media sono a 8 kHz. Le chiamate telefoniche negoziano G.711, quindi il riconoscimento vocale dell’agente vede audio a banda stretta che gli piaccia o no. Fai i test su audio telefonico reale prima di regolare qualsiasi altra cosa; la guida al G.711 spiega cosa taglia il codec.
- Le chiamate dal browser sono un altro mondo. WebRTC ha un modello proprio, agnostico rispetto alla segnalazione, crittografia obbligatoria e jitter buffer adattivi. La guida WebRTC vs WebSocket mappa le differenze per gli agenti vocali che vivono in un browser invece che sulla rete telefonica.
Su Cartesia, i Managed Agents accettano chiamate dal tuo trunk SIP via TCP o TLS, con la crittografia dei media SRTP impostata su disabled, allowed o required, e autenticano le chiamate in entrata con credenziali digest o un elenco di IP autorizzati. I trasferimenti partono come REFER SIP verso numeri di telefono o URI SIP. L’integrazione trunk SIP (Inglese) spiega come puntare un operatore verso l’endpoint SIP di Cartesia, e la guida ai trunk SIP copre la configurazione completa, inclusi i campi API e la tabella dei fallimenti.
Guide correlate
- Cos’è un trunk SIP e come usarlo con l’IA vocale
- Codec G.711: μ-law, A-law e audio telefonico a 8 kHz
- Cos’è il DTMF? Toni, frequenze e agenti vocali
- Cos’è il jitter in VoIP? Come misurarlo e correggerlo
- WebRTC vs WebSocket per l’IA vocale in tempo reale
- Trasferimento a caldo e a freddo: le differenze