Le richieste SIP sono denominate da un metodo. RFC 3261 ne definisce sei: INVITE (avviare una sessione), ACK (confermare una risposta finale a un INVITE), BYE (terminare una sessione), CANCEL (annullare un INVITE in sospeso), REGISTER (registrare una posizione) e OPTIONS (interrogare le capacità). Gli RFC di estensione aggiungono INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE e PUBLISH.
I sei metodi di base
RFC 3261 definisce l'insieme di richieste di base che ogni implementazione SIP supporta. INVITE instaura una sessione e trasporta l'offerta SDP iniziale. ACK riscontra una risposta finale a un INVITE — è insolito nell'essere una richiesta che completa l'handshake INVITE a tre vie anziché attendere una propria risposta. BYE termina una sessione instaurata. CANCEL annulla un INVITE che non ha ancora ricevuto una risposta finale (una chiamata ancora in squillo). REGISTER comunica a un registrar dove un utente è raggiungibile. OPTIONS interroga le capacità di un peer ed è ampiamente riutilizzato come keepalive leggero.
| Metodo | Scopo | Nota |
|---|---|---|
| INVITE | Avvia una sessione | Trasporta l'offerta SDP; crea un dialogo |
| ACK | Conferma una risposta finale all'INVITE | Completa l'handshake INVITE a 3 vie |
| BYE | Terminare una sessione stabilita | Inviato da una delle due parti nel dialogo |
| CANCEL | Annulla un INVITE in sospeso | Solo prima di una risposta definitiva (squilla ancora) |
| REGISTER | Registra la posizione Contact di un utente | Aggiornato periodicamente (Expires) |
| OPTIONS | Interrogazione delle capacità | Comunemente riutilizzato come keepalive / health check |
Perché ACK e CANCEL sono speciali
Due metodi di base si comportano diversamente dagli altri. ACK non è una normale coppia richiesta/risposta: riscontra la risposta finale a un INVITE e non trasporta alcuna risposta propria. Per un 2xx viene inviato end-to-end come transazione separata; per un fallimento non-2xx è generato salto per salto all'interno della transazione INVITE. CANCEL ha significato solo mentre un INVITE è ancora in sospeso — una volta arrivata una risposta finale, usate invece BYE. Gestire correttamente questi due è il fulcro di una macchina a stati SIP corretta.
Metodi di estensione comuni
Oltre ai sei di base, un insieme di metodi di estensione gestisce messaggistica, eventi e aggiornamenti a chiamata in corso. SUBSCRIBE/NOTIFY implementano il framework degli eventi (presence, message-waiting indication, stato del dialogo). REFER innesca il trasferimento di chiamata. MESSAGE trasporta messaggi istantanei / SMS-over-SIP. UPDATE modifica una sessione prima che sia completamente instaurata (early media). PRACK riscontra in modo affidabile le risposte provvisorie. INFO trasporta informazioni a metà sessione come i DTMF. PUBLISH invia lo stato di un evento a un server.
| Metodo | RFC | Scopo |
|---|---|---|
| INFO | RFC 6086 | Informazioni a metà sessione (ad es. cifre DTMF) |
| PRACK | RFC 3262 | Conferma affidabile delle risposte provvisorie (1xx) |
| UPDATE | RFC 3311 | Modificare una sessione prima della risposta definitiva (early media) |
| SUBSCRIBE / NOTIFY | RFC 6665 | Sottoscrizione e notifica di eventi (presence, MWI) |
| REFER | RFC 3515 | Richiedi il trasferimento a un altro interlocutore |
| MESSAGE | RFC 3428 | Messaggistica istantanea / messaggistica page-mode |
| PUBLISH | RFC 3903 | Invia lo stato di un evento (ad es. presence) a un server |
Una request line sul filo
Una richiesta SIP inizia con una request line: il metodo, la Request-URI (la destinazione corrente) e la versione SIP. Seguono gli header e un body opzionale. L'esempio è l'inizio di un INVITE verso un chiamato; la Request-URI è riscritta dai proxy man mano che la richiesta è instradata, mentre l'header To resta fisso come target logico.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=1928301774
Call-ID: a84b4c76e66710@host.example.net
CSeq: 314159 INVITE
Contact: <sip:alice@host.example.net>
Content-Type: application/sdp
Content-Length: 142Domande frequenti
Quali sono i sei metodi SIP di base?
INVITE (avviare una sessione), ACK (confermare una risposta finale a un INVITE), BYE (terminare una sessione), CANCEL (annullare un INVITE in sospeso), REGISTER (registrare la posizione di un utente) e OPTIONS (interrogare le capacità). Sono definiti in RFC 3261; tutto il resto è un'estensione.
Qual è la differenza tra CANCEL e BYE?
CANCEL annulla un INVITE che non ha ancora ricevuto una risposta finale — una chiamata ancora in squillo. BYE termina una sessione già instaurata. Usate CANCEL prima che la chiamata sia risposta e BYE dopo; usare quello sbagliato lascia la macchina a stati incoerente.
Perché ACK non riceve una risposta?
ACK esiste per riscontrare la risposta finale a un INVITE e completare l'handshake a tre vie, quindi è definito per non avere una propria risposta. Per un 2xx è una transazione end-to-end separata; per un fallimento è generato salto per salto all'interno della transazione INVITE.
Come si inviano i DTMF in SIP?
Più comunemente come pacchetti RTP telephone-event (RFC 4733) nel flusso media, e in alternativa tramite messaggi SIP INFO che trasportano le cifre nel percorso di segnalazione. RTP telephone-event è preferito perché resta sincronizzato con l'audio.
Quale metodo trasferisce una chiamata?
REFER (RFC 3515). Chiede al destinatario di avviare una nuova richiesta (di norma un INVITE) verso un terzo indicato nell'header Refer-To, implementando il trasferimento di chiamata. I messaggi NOTIFY riferiscono poi al trasferente l'avanzamento della chiamata trasferita.
Specifiche della fonte
Gli standard pubblicati su cui si basa questa pagina. Si apre in una nuova scheda.