I messaggi SIP di richiesta e di risposta: i metodi e i codici di risposta

Per comprendere il Protocollo SIP è fondamentale partire dalle basi. Quando parliamo di Session Initiation Protocol (SIP) facciamo riferimento al protocollo di segnalazione utilizzato per controllare le sessioni di comunicazione di una chiamata VoIP.

Il Protocollo SIP è fondato sui messaggi SIP di richiesta e di risposta che sono descritti alla pagina 26 della RFC3261.

Il protocollo SIP è un protocollo basato su testo e utilizza il set di caratteri UTF-8. Un messaggio SIP può essere sia un messaggio di richiesta da un client verso un server che una risposta da un server verso il client stesso.

I messaggi SIP, sia di richiesta che di risposta, utilizzano uno schema comune di base anche se la sintassi può differire per i caratteri e per alcune specifiche. Tralasciando la codifica dei caratteri, la sintassi dei protocollo SIP è molto simile a quella dell’HTML/1.1, anche se il SIP non costituisce un’estensione del protocollo HTML.

Sia le richieste che le risposte SIP presentano una struttura di base comune, composta da:

1. Start-Line: la linea iniziale di un messaggio SIP può essere una Request-Line o una Status-Line, a seconda che si tratti di un messaggio di richiesta o di risposta.
2. Message-Header: è l’intestazione del messaggio che può essere composta da una o più campi/linee.
3. Linea-Vuota: è sempre prevista, anche se il message-body non è presente oppure è vuoto.
4. Message Body: è il corpo del messaggio. Può essere vuoto, contenere informazioni oppure contenere il protocollo SDP.

Sia la Start-Line che ogni linea di message-header, nonché la linea vuota, devono terminare con una sequenza CRLF (carriage-return line-feed sequence).

Nei prossimi paragrafi descriverò la classificazione dei messaggi di richiesta e di risposta SIP. Per agevolare gli eventuali approfondimenti, per ogni messaggio analizzato verranno indicati gli specifici link alle RFC di riferimento. Le specifiche del protocollo SIP coinvolgono numerosi documenti RFC di riferimento creati nel corso del tempo e la loro gerarchia non è sempre facile da ricostruire.

LE RICHIESTE SIP (Metodi)

I messaggi di richiesta SIP sono caratterizzati dal fatto di avere come linea iniziale una “Request-Line”.

La Request-Line contiene il nome del metodo, la Request-URI e la versione del protocollo. Ad esempio:

Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:123456@trunk.voipvoice.it:5060 SIP/2.0
        Method: INVITE
        Request-URI: sip:123456@trunk.voipvoice.it:5060

I metodi di richiesta SIP sono definiti dalle RFC SIP. I metodi fondamentali sono definiti direttamente all’interno della RFC3261 mentre altri medodi sono disciplinati come “estensioni” all’interno di altri specifici documenti RFC.

I 6 Metodi SIP fondamentali (RFC3261)

Questi 6 metodi di base sono previsti direttamente all’interno della RFC3261.

REGISTER

La registrazione comporta l’invio di una richiesta di registrazione verso un tipo speciale di User Agent Server (UAS) chiamato Registrar Server.
Un registrar funge da front-end al servizio di localizzazione per un dominio, leggendo e scrivendo mappature in base ai contenuti delle richieste di REGISTRAZIONE. Questo servizio di localizzazione viene quindi generalmente consultato da un server proxy responsabile dell’instradamento delle richieste per quel dominio.

INVITE e RE-INVITE

Quando uno User Agent Client (UAC) desidera avviare una sessione audio o audio/video, formula una richiesta INVITE. La richiesta di INVITE, domanda ad un server (UAS) di stabilire una sessione. Tale richiesta può essere inoltrata tramite deleghe , giungendo eventualmente ad uno o più UAS che potenzialmente possono accettare l’invito. Questi UAS dovranno spesso chiedere all’utente se accettare l’invito. Trascorso un certo lasso di tempo, gli UAS possono accettare l’invito (nel senso che accettano che la sessione possa essere stabilitala) attraverso un messaggio di risposta di tipo 2xx.

Se l’invito non viene accettato, viene inviata una risposta 3xx, 4xx, 5xx o 6xx, a seconda del motivo del rifiuto. Prima di inviare una risposta definitiva, l’UAS può anche inviare risposte provvisorie (1xx) per avvisare l’ UAC dell’andamento del contatto con l’utente chiamato.

Il Re-Invite corrisponde semplicemente ad una richiesta di modifica di un invite precedentemente trasmesso. Il Re-Invite non rappresenta quindi in metodo indipendente ma è un semplice invite di modifica. Questa modifica può comportare la modifica di indirizzi o porte oppure l’aggiunta di un flusso multimediale, l’eliminazione di un flusso multimediale e così via. Ciò si ottiene inviando una nuova richiesta INVITE all’interno della stessa finestra di dialogo che ha stabilito la sessione. Una richiesta INVITE inviata all’interno di una finestra di dialogo esistente è nota come re-INVITE.

Un esempio tipico di re-invite si presenta durante la trasmissione di un FAX in T38. In questo caso viene modificato l’attributo media da “audio” a “image” e contemporaneamente viene modificata la porte e l’indirizzo IP di trasmissione del flusso RTP.

ACK

Il protocollo SIP implementa un handshake a tre vie.

•  Il chiamante invia un INVITE
•  Il chiamato invia un 200 OK per accettare la chiamata
•  Il chiamante invia un ACK per indicare che l’handshake è stato eseguita e che verrà quindi configurata una chiamata.

Se il primo messaggio INVITE include una descrizione della chiamata SDP (con le informazioni multimediali per avviare la sessione di chiamata audio) , il 200 OK conterrà anch’esso l’SDP del chiamato.

BYE

CANCEL

La richiesta CANCEL, come suggerisce il nome, viene utilizzata per cancellare una precedente richiesta inviata da un client. In particolare lo UAC, chiede all’UAS di cessare l’elaborazione della richiesta e di generare una risposta di errore a tale richiesta. CANCEL non ha effetto su una richiesta alla quale un UAS ha già dato una risposta definitiva.

Per questo motivo, è molto utile annullare le richieste alle quali un server può impiegare molto tempo per rispondere. Il metodo CANCEL rappresenta la soluzione migliore per le richieste di INVITE, che possono richiedere molto tempo per generare una risposta. In tale utilizzo, un UAS che riceve una richiesta CANCEL per un INVITE, ma non ha ancora inviato una risposta finale, “smetterà di squillare” e quindi risponderà all’INVITE con una risposta di errore specifica (487).

OPTIONS

Il metodo SIP OPTIONS consente a un UA di interrogare un altro UA o un server proxy in merito alle sue capacità. Ciò consente ad un client di scoprire informazioni sui metodi supportati, i tipi di contenuto, le estensioni, i codec e così via senza “squillare” l’altra parte.

Ad esempio, prima che un client inserisca un campo di intestazione Require in un INVITE che elenca un’opzione che non è certo che l’UAS di destinazione supporti, il client può interrogare l’UAS di destinazione con OPTIONS per vedere se questa opzione viene restituita in un campo di intestazione Supported.

Tutti gli UA devono supportare il metodo OPTIONS.

I Metodi SIP previsti come estensioni da altre specifiche RFC

Di seguito elenco i metodi SIP che non sono direttamente previsti all’interno della RFC3261 ma che sono stati introdotti come estensioni all’interno di successive RFC. Per ognuno di questi metodi è indicata la specirti

INFO (RFC2927)

L’intento del metodo INFO è di consentire il trasporto di informazioni di controllo relative alla sessione generate durante la sessione stessa. Un esempio di tali informazioni di controllo della sessione sono i messaggi di segnalazione ISUP e ISDN utilizzati per controllare i servizi di chiamata telefonica.

Il metodo INFO è anche stato utilizzato per la trasmissione dei toni DTMF anche se tale sistema è ormai sconsigliato dalle RFC stesse.

MESSAGE (RFC3428)

La messaggistica istantanea (IM) si riferisce al trasferimento di messaggi tra utenti in tempo quasi-reale. Questi messaggi sono generalmente, ma non necessariamente, brevi. I messaggi istantanei vengono spesso utilizzati in modalità conversazionale, ovvero il trasferimento dei messaggi avanti e indietro è sufficientemente veloce da consentire ai partecipanti di mantenere una conversazione interattiva.

Il metodo MESSAGE è un’estensione del Session Initiation Protocol (SIP) che consente il trasferimento di messaggi istantanei. Poiché la richiesta MESSAGE è un’estensione di SIP, eredita tutte le funzionalità di routing e sicurezza delle richieste di quel protocollo. Le richieste MESSAGE trasportano il contenuto sotto forma di parti del corpo MIME. Le richieste MESSAGE non avviano esse stesse un dialogo SIP. In condizioni di utilizzo normale, ogni messaggio istantaneo è autonomo, proprio come i messaggi cercapersone. Le richieste di MESSAGGE possono essere inviate nel contesto di un dialogo avviato da qualche altra richiesta SIP.

NOTIFY (RFC2848)

Durante il periodo di sottoscrizione, il Gateway può, di volta in volta, inviare una richiesta di NOTIFY spontanea al soggetto indicato nell’header “Contact”. Normalmente ciò avverrà a seguito di qualsiasi modifica dello stato della sessione di servizio per la quale il richiedente si è iscritto. NOTIFY in genere funziona in abbinamento alla richiesta di SUBSCRIVE (vedi sotto).

Lo UAS ricevente deve riconoscere questo restituendo una risposta finale (normalmente un “200 OK”). In questa versione delle estensioni PINT, il gateway non è tenuto a supportare le risposte di reindirizzamento (codici 3xx) e potrebbe quindi trattarli come un errore.

Pertanto, se la classe del codice di risposta è superiore a 2xx, ciò può essere considerato dal gateway come un errore della sessione di monitoraggio e, in tale situazione, tenterà immediatamente di chiudere la sessione (vedere di seguito).

PRACK (RFC3262)

Il metodo PRACK è definito nella RFC 3262: “Affidabilità delle risposte provvisorie nel protocollo SIP (Session Initiation Protocol)”

L’implementazione del PRACK presenta ancora oggi numerosi problemi di compatibilità

PUBLISH (RFC3903)

REFER (RFC3515)

Il metodo SIP REFER è principalmente impiegato per i trasferimenti di chiamata ma può essere impiegato per molte altre applicazioni. Il soggetto che invisa il refer deve essere informato circa l’esito della richiesta di riferimento.

SUBSCRIBE (RFC2848)

Quando una richiesta SUBSCRIBE viene inviata a un server PINT, indica che un utente desidera ricevere informazioni sullo stato di una sessione di servizio. La richiesta identifica la sessione di interesse includendo la descrizione della sessione originale insieme alla richiesta, utilizzando l’ ID di sessione globale SDP che fa parte del campo origine per identificare in modo univoco la sessione di servizio.

La richiesta SUBSCRIBE (come qualsiasi altra richiesta SIP su una sessione in corso) viene inviata allo stesso server in cui è stato inviato l’ INVITE originale , o ad un server  che è stato specificato nel campo Contact all’interno di una risposta successiva (questo potrebbe essere il PINT gateway per la sessione).

UNSUBSCRIVE (RFC2848)

Questo metodo consente di terminare una sessione di monitoraggio. Ciò si ottiene inviando una richiesta UNSUBSCRIBE al server corrispondente. Tale richiesta indica che il mittente intende chiudere immediatamente la sessione di monitoraggio e, al ricevimento della risposta finale dal server ricevente, la sessione si considera conclusa.

UPDATE (RFC3311)

UPDATE consente a un client di aggiornare i parametri di una sessione (come l’insieme di flussi multimediali e i relativi codec) ma non ha alcun impatto sullo stato di una finestra di dialogo. In questo senso, è come un re-INVITE , ma a differenza di re-INVITE, può essere inviato prima che l’ INVITE iniziale sia stato completato. Ciò lo rende molto utile per l’aggiornamento dei parametri di sessione all’interno delle prime finestre di dialogo.

LE RISPOSTE SIP (Codici)

I messaggi di risposta SIP sono caratterizzati dal fatto di avere come linea iniziale una “Status-Line”.

Una Status-Line contiene la Versione del protocollo seguita da uno Status-Code numerico e dalla frase testuale associata (Reason-Phrase). Ad esempio:

Session Initiation Protocol (200)
    Status-Line: SIP/2.0 200 OK
        Status-Code: 200

Lo Status-Code è un codice risultato intero a 3 cifre che indica il risultato di un tentativo di comprendere e soddisfare una richiesta. La frase di motivazione (reason-phrase) ha lo scopo di fornire una breve descrizione testuale del Codice di stato. Lo Status-Code è destinato all’uso da parte di sistemi automatici, mentre la frase di motivazione è destinata all’utente umano. Per un client non è quindi necessario visualizzare la frase di motivazione.

La prima cifra dello Status-Code definisce la classe di risposta. Le ultime due cifre non hanno alcun ruolo di categorizzazione. Per questo motivo, qualsiasi risposta con un codice di stato compreso tra 100 e 199 è indicata come “risposta 1xx”, qualsiasi risposta con un codice di stato tra 200 e 299 come “risposta 2xx” e così via. Il protocollo SIP/2.0 consente sei valori per la prima cifra:

1xx: Risposte Provvisorie e Informative — conferma della richiesta ricevuta, richiesta in elaborazione.

2xx: Risposte Definitive, di Successo: l’azione è stata ricevuta con successo, è stata compresa, e accettata.

3xx: Risposte di Reindirizzamento — è necessario intraprendere ulteriori azioni per completare la richiesta;

4xx: Errori o segnalazioni del Client — la richiesta contiene una sintassi errata o non può essere soddisfatte su questo server;

5xx: Errori o segnalazioni del Server — il server non è riuscito a soddisfare un apparentemente richiesta valida;

6xx: Errori globali: la richiesta non può essere soddisfatta in nessun caso server.

Elenco dei Codici di Risposta SIP conosciuti (per classi)

1xx Risposte Provvisorie e Informative

• 100 Trying – La ricerca estesa è in corso, quindi un forking proxy deve inviare una 100 risposte.
• 180 Ringing – L’User Agent di destinazione ha ricevuto il messaggio d’INVITO e sta avvisando l’utente della chiamata.
• 181 Call Is Being Forwarded – Opzionale, inviato dal Server per indicare che una chiamata è in corso di inoltro.
• 182 Queued – La destinazione non era temporaneamente disponibile, il server ha messo in coda la chiamata fino a quando la destinazione non è disponibile.
• 183 Session Progress – Questa risposta può essere utilizzata per inviare informazioni aggiuntive per una chiamata che è ancora in fase di set up.
• 199 Early Dialog Terminated – Invio da parte del server User Agent per indicare che un dialogo precedente è stato interrotto.

2xx Risposte Definitive, di Successo

• 200 OK – Mostra che la richiesta ha avuto successo.
• 202 accepted – Indica che la richiesta è stata accettata. Principalmente usato per referenze
• 204 No Notification – Indica che la richiesta è stata accolta ma che non verrà ricevuta alcuna risposta.

3xx: Risposte di Reindirizzamento

• 300 Multiple Choices – L’indirizzo risolto a una delle diverse opzioni tra cui l’utente o il cliente può scegliere.
• 301 Moved Permanently – L’URI della Richiesta originale non è più valido, il nuovo indirizzo viene indicato nell’intestazione del Contatto.
• 302 Moved Temporarily – Il cliente deve provare l’indirizzo nel campo Contatto.
• 305 Use Proxy – Il campo Contatto indica un proxy che deve essere utilizzato per accedere alla destinazione richiesta.
• 380 Alternative Service – La chiamata non è riuscita, ma le alternative sono dettagliate nel corpo del messaggio.

4xx: Errori o segnalazioni del Client

• 400 Bad Request – La richiesta non è stata interpretata a causa della sintassi malformata.401 Unauthorized – La richiesta richiede l’autenticazione dell’utente. Questa risposta è emessa da UAS e registrars.
• 402 Payment Required – (Riservato per uso futuro).
• 403 Forbidden – Il server ha compreso la richiesta, ma si rifiuta di svolgerla.
• 404 Not Found – Il server ha informazioni definitive che l’utente non esiste presso il (User not found).
• 405 Method Not Allowed – Il metodo specificato nella Request-Line è compreso, ma non è consentito.
• 406 Not Acceptable – La risorsa è in grado di generare solo risposte con contenuto inaccettabile.
• 407 Proxy Authentication Required – La richiesta richiede l’autenticazione dell’utente.
• 408 Request Timeout – Non è stato possibile trovare l’utente in tempo.
• 409 Conflict – Utente già registrato (decaduto).
• 410 Gone – L’utente esisteva una volta, ma non è più disponibile.
• 411 Length Required – Il server non accetterà la richiesta senza una lunghezza di contenuto valida (decaduto).
• 412 Conditional Request Failed – Il prerequisito dato non è stato trovato.
• 413 Request Entity Too Large – Richiesta corpo troppo grande.
• 414 Request URI Too Long – Il server rifiuta il servizio della richiesta, il Req-URI è più lungo di quanto il server possa interpretare.
• 415 Unsupported Media Type – Il corpo della richiesta è in un formato non supportato.
• 416 Unsupported URI Scheme – Il Request-URI è sconosciuto al server.
• 417 Unknown Resource-Priority – C’era un tag di opzione Resource-Priority, ma nessuna intestazione Resource-Priority.
• 420 Bad Extension – Cattiva estensione del protocollo SIP utilizzato, non compreso dal server.
• 421 Extension Required – Il server necessita di una specifica estensione non elencata nell’intestazione Supportata.
• 422 Session Interval Too Small – La richiesta contiene un campo di intestazione Session-Expires con una durata inferiore al minimo.
• 423 Interval Too Brief – Il tempo di scadenza della risorsa è troppo breve.
• 424 Bad Location Information – Il contenuto della richiesta è stato malformato o comunque insoddisfacente.
• 428 Use Identity Header – Il criterio del server richiede un’intestazione di Identità e non è stato fornito.
• 429 Provide Referrer Identity – Il server non ha ricevuto un token Referred-By valido sulla richiesta.
• 430 Flow Failed – Un flusso specifico verso un agente utente non è riuscito, anche se altri flussi possono avere successo.
• 433 Anonymity Disallowed – La richiesta è stata respinta perché anonima.
• 436 Bad Identity Info – La richiesta ha un’intestazione Identity-Info e lo schema URI contenuto non può essere deselezionato.
• 437 Unsupported Certificate – Il server non è stato in grado di convalidare un certificato per il dominio che ha firmato la richiesta.
• 438 Invalid Identity Header – Il server ha ottenuto un certificato valido utilizzato per firmare una richiesta, non è stato in grado di verificare la firma.
• 439 First Hop Lacks Outbound Support – Il primo proxy in uscita non supporta la funzione “outbound”.
• 440 Max-Breadth Exceeded – Se un proxy SIP ha determinato un contesto di risposta non aveva un Max-Breadth in entrata sufficiente per effettuare un fork parallelo desiderato, e il proxy non è in grado di compensare biforcando in serie o inviando un redirect, quel proxy DEVE restituire una risposta 440. Un cliente che riceve una risposta 440 può dedurre che la sua richiesta non ha raggiunto tutte le destinazioni possibili.
• 469 Bad Info Package – Se un SIP UA riceve una richiesta INFO associata a un Info Package che l’UA non ha indicato la volontà di ricevere, l’UA DEVE inviare una risposta 469, che contiene un campo di intestazione Recv-Info con i Pacchetti Info per i quali l’UA è disposta a ricevere richieste INFO.
• 470 Consent Needed – La fonte della richiesta non aveva il permesso del destinatario per effettuare tale richiesta.
• 480 Temporarily Unavailable – Chiamata attualmente non disponibile.
• 481 Call/Transaction Does Not Exist – Il server ha ricevuto una richiesta che non corrisponde a nessun dialogo o transazione.
• 482 Loop Detected – Il server ha rilevato un loop.
• 483 Too Many Hops – L’intestazione Max-Forwards ha raggiunto il valore ‘0’.
• 484 Address Incomplete – Richiesta-URI incompleta.
• 485 Ambiguous – Request-URI è incompleto.
• 486 Busy Here – La linea è occupata.
• 487 Request Terminated – La richiesta è terminata per bye o cancella.
• 488 Not Acceptable Here – Alcuni aspetti della descrizione della sessione del Request-URI non sono accettabili.
• 489 Bad Event – Il server non ha compreso un pacchetto di eventi specificato in un campo di intestazione dell’evento.
• 491 Request Pending – Il server ha qualche richiesta in sospeso dalla stessa finestra di dialogo.
• 493 Undecipherable – La richiesta non decifrabile contiene un corpo MIME criptato, che il destinatario non può decifrare.
• 494 Security Agreement Required – Il server ha ricevuto una richiesta che richiede un meccanismo di sicurezza negoziato.

5xx: Errori o segnalazioni del Server

• 500 Server Internal Error – Il server non ha potuto soddisfare la richiesta a causa di alcune condizioni impreviste.
• 501 Not Implemented – Il metodo di richiesta SIP non è implementato qui.
• 502 Bad Gateway – Il server, ha ricevuto una risposta non valida da un server a valle mentre cercava di soddisfare una richiesta.
• 503 Service Unavailable – Il server è in manutenzione o è temporaneamente sovraccaricato e non può elaborare la richiesta.
• 504 Server Time-out – Il server ha tentato di accedere ad un altro server mentre cercava di elaborare una richiesta, nessuna risposta tempestiva.
• 505 Version Not Supported – La versione del protocollo SIP nella richiesta non è supportata dal server.
• 513 Message Too Large – La lunghezza del messaggio della richiesta è più lunga di quanto il server possa elaborare.
• 555 Push Notification Service Not Supported – Il server non supporta il servizio di notifica push specificato nel parametro pn-provider SIP URI.
• 580 Precondition Failure – Il server non è in grado o non vuole rispettare alcuni vincoli specificati nell’offerta.

6xx: Errori globali

• 600 Busy Everywhere – Tutte le destinazioni possibili sono occupate.
• 603 Decline – La destinazione non può/non vuole partecipare alla chiamata, non ci sono destinazioni alternative.
• 604 Does Not Exist Anywhere – Il server ha l’informazione ufficiale che l’utente richiesto non esiste da nessuna parte.
• 606 Not Acceptable – L’agente dell’utente è stato contattato con successo, ma alcuni aspetti della descrizione della sessione non erano accettabili.
• 607 Unwanted – La parte chiamata non voleva che la sua chiamata venisse effettuata dalla parte chiamante. I futuri tentativi da parte del chiamante saranno probabilmente respinti in modo analogo.