RFC 3261: Il DNA del VoIP – Capitolo 10
OPTIONS, capability e disponibilità nel SIP

Apriamo un tracciato SIP e troviamo una richiesta OPTIONS seguita, pochi millisecondi dopo, da un 200 OK. Nessuno ha sollevato la cornetta. Nessun telefono ha squillato. Eppure due elementi della rete si sono cercati, si sono riconosciuti e si sono scambiati informazioni utili.

Durante i corsi della VoIP Academy mi piace partire da questa scena, perché mostra bene un aspetto del SIP che spesso passa inosservato: non tutti i messaggi servono ad avviare o terminare una chiamata. Alcuni servono a capire con chi stiamo comunicando, quali funzioni sono disponibili e se il percorso di segnalazione risponde.

Nel capitolo precedente abbiamo visto come CANCEL interrompe un tentativo di chiamata e come BYE termina una sessione. Ora incontriamo OPTIONS. Non crea una sessione e non modifica quella esistente. Interroga uno User Agent o un server SIP e ci restituisce informazioni che, se lette correttamente, diventano molto utili anche nel troubleshooting.

La sezione 11 della RFC 3261 lo definisce così:

“The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities.”
Il metodo SIP OPTIONS permette a uno User Agent di interrogare un altro User Agent o un proxy server per conoscerne le capacità.

La RFC comprende tra queste capacità i metodi, i tipi di contenuto, le estensioni e i codec supportati. Tutti gli User Agent conformi alla RFC devono gestire OPTIONS. Nelle reti reali il metodo viene usato anche come controllo periodico di raggiungibilità. Una risposta conferma che un elemento SIP ha risposto in quel momento, ma non garantisce che la chiamata successiva andrà a buon fine.

Il ruolo di OPTIONS

Un UAC invia una richiesta OPTIONS per conoscere le capacità del destinatario. Il destinatario assume il ruolo di UAS e genera una risposta finale. Non viene creata una sessione, non squilla un telefono e non nasce automaticamente un dialogo.

Le informazioni restituite possono riguardare:

• i metodi SIP supportati;
• le estensioni SIP riconosciute;
• i tipi di contenuto accettati;
• le lingue e le codifiche gestite;
• le capacità multimediali, se la risposta contiene un corpo SDP;
• lo stato di base del destinatario.

Il metodo può quindi servire per una richiesta di capability oppure per un controllo operativo. I due usi partono dallo stesso messaggio, ma non hanno lo stesso obiettivo.

Per cosa viene usato OPTIONS in un comune PBX?

Immaginiamo di aprire la pagina di stato di un PBX. Accanto agli interni e ai trunk troviamo indicazioni come raggiungibile, disponibile, OK oppure unreachable. Dietro molte di queste informazioni lavora proprio OPTIONS. Il centralino invia periodicamente una richiesta al telefono IP, al gateway, al Session Border Controller o al server del provider e attende una risposta entro il tempo configurato.

Se osserviamo il traffico con Wireshark, vediamo una sequenza regolare: OPTIONS parte dal PBX e il dispositivo risponde, spesso con 200 OK. Questa coppia di messaggi permette al centralino di verificare che il peer sia raggiungibile a livello SIP e di misurare il tempo di risposta. Diversi produttori chiamano la funzione SIP ping, OPTIONS ping, qualify o keepalive.

Può accadere anche il contrario. Un telefono IP o un PBX remoto invia OPTIONS verso il proprio server SIP per controllare che il percorso di segnalazione sia ancora attivo. Quando il traffico attraversa un NAT, lo scambio periodico può inoltre contribuire a mantenere aperta la relativa mappatura UDP. Non va però confuso con il rinnovo della registrazione: è il REGISTER, con la sua scadenza, a mantenere aggiornato il binding tra l’identità SIP e il Contact del dispositivo.

Ora mettiamoci nei panni del tecnico che vede il trunk marcato come disponibile. Possiamo concludere che il server ha risposto al controllo previsto dal PBX. Non possiamo ancora affermare che una chiamata completa funzionerà. OPTIONS non prova da solo il routing del numero chiamato, l’autenticazione dell’INVITE, la disponibilità dei canali, la negoziazione dei codec o il passaggio dell’RTP.

Anche la definizione di risposta valida dipende dall’apparato. Alcuni PBX richiedono 200 OK. Altri considerano il peer raggiungibile quando ricevono una qualsiasi risposta SIP finale, perché anche un 401 Unauthorized, un 403 Forbidden o un 486 Busy Here dimostra che un elemento SIP ha ricevuto e processato la richiesta. Per leggere correttamente lo stato mostrato dal centralino dobbiamo quindi conoscere la sua configurazione: intervallo tra i controlli, timeout, numero di tentativi e codici accettati.

Capability e raggiungibilità

Quando OPTIONS viene usato secondo la logica descritta dalla RFC, il client vuole conoscere le funzioni disponibili prima di inviare una richiesta più impegnativa. Per esempio, può controllare se il destinatario dichiara una determinata estensione nell’header Supported oppure se accetta application/sdp.

Nelle piattaforme VoIP il metodo viene spesso inviato a intervalli regolari per verificare se un trunk, un gateway, un PBX o un altro peer risponde. Questo meccanismo viene chiamato spesso SIP OPTIONS ping, qualify o keepalive. I nomi cambiano secondo il prodotto.

Questa pratica è utile, ma va interpretata correttamente. Un 200 OK conferma che la richiesta ha raggiunto un elemento capace di rispondere. Non controlla da solo:

• la disponibilità di canali o risorse per una chiamata;
• la correttezza del routing applicato a uno specifico numero;
• l’autenticazione richiesta da un INVITE;
• la negoziazione SDP completa;
• il passaggio effettivo dei flussi RTP;
• la raggiungibilità di tutte le destinazioni dietro un proxy.

Un peer può quindi rispondere regolarmente a OPTIONS e rifiutare l’INVITE successivo. Può anche rispondere a OPTIONS mentre una parte diversa del servizio è in errore. Il controllo conferma la vita del punto SIP interrogato, non l’intera catena della chiamata.

Fuori o dentro un dialogo

OPTIONS può essere inviato fuori da un dialogo. È il caso più comune nei controlli periodici tra apparati. Gli header From, To, Call-ID e CSeq identificano la transazione, ma non indicano da soli l’esistenza di una sessione.

La RFC consente anche di inviarlo all’interno di un dialogo già stabilito. In questo caso il messaggio usa le informazioni del dialogo e interroga il peer sulle capacità utilizzabili in seguito. La risposta a OPTIONS non modifica il dialogo e non cambia la sessione in corso.

Nel lavoro quotidiano è utile controllare i tag di From e To, il Call-ID, il route set e il valore di CSeq. Questi elementi aiutano a capire se il messaggio è autonomo o se appartiene a una relazione SIP già esistente. I dialoghi verranno trattati in modo completo più avanti nella collana.

Costruzione della richiesta

La sezione 11.1 della RFC 3261 applica a OPTIONS le regole generali già viste per la costruzione di una richiesta SIP. La Request-URI identifica il bersaglio operativo. Può indicare uno User Agent oppure un server SIP.

Se la richiesta è indirizzata a un proxy, la Request-URI può contenere solo il dominio, senza la parte utente. La differenza tra To e Request-URI resta la stessa: To dichiara il destinatario logico, mentre la Request-URI guida l’instradamento della richiesta.

OPTIONS sip:daniele@voip.example SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-opt-001;rport
Max-Forwards: 70
To: <sip:daniele@voip.example>
From: Matteo <sip:matteo@lab.example>;tag=4f91a2
Call-ID: options-001@192.0.2.10
CSeq: 101 OPTIONS
Contact: <sip:matteo@192.0.2.10:5060>
Accept: application/sdp
Content-Length: 0

La prima riga contiene il metodo, la Request-URI e la versione del protocollo. L’header Via identifica il percorso usato dalla risposta e contiene un branch univoco per la transazione. Max-Forwards limita il numero di passaggi tra elementi SIP.

Call-ID, i tag e CSeq consentono di correlare messaggi e risposte. Nel CSeq il nome del metodo deve essere OPTIONS. L’header Contact è facoltativo. Anche Accept non è obbligatorio, ma la RFC raccomanda di inserirlo per indicare il tipo di corpo che il client desidera ricevere. Nell’esempio viene richiesto SDP.

Content-Length: 0 indica che la richiesta non contiene un corpo. Una richiesta OPTIONS può comunque avere un corpo, purché il destinatario sappia interpretarlo.

La risposta del destinatario

La gestione della risposta è definita nella sezione 11.2 della RFC 3261. Il destinatario la costruisce secondo le regole generali previste per un UAS. Il codice dovrebbe corrispondere a quello che sarebbe stato scelto per un INVITE ricevuto nello stesso stato. Un apparato pronto ad accettare una chiamata può restituire 200 OK; un apparato occupato può restituire 486 Busy Here.

Questa equivalenza descrive lo stato di base del UAS. Non trasforma OPTIONS in una simulazione completa dell’INVITE. Proxy, regole di instradamento, autenticazione e forking possono produrre comportamenti diversi quando arriva una vera chiamata.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-opt-001;rport=5060;received=192.0.2.10
To: <sip:daniele@voip.example>;tag=9bc721
From: Matteo <sip:matteo@lab.example>;tag=4f91a2
Call-ID: options-001@192.0.2.10
CSeq: 101 OPTIONS
Contact: <sip:daniele@198.51.100.25:5060>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Accept: application/sdp
Supported: replaces, timer
User-Agent: PBX-Lab
Content-Length: 0

La risposta riporta gli stessi valori di Via, From, Call-ID e CSeq necessari alla correlazione. Il UAS aggiunge il proprio tag nel campo To. Gli header successivi descrivono alcune capacità dichiarate.

Leggere gli header

Allow elenca i metodi che il destinatario dichiara di supportare. La presenza di un metodo indica una capacità del UAS, ma non garantisce che quel metodo sia consentito in ogni stato o per ogni utente.

Supported elenca le option tag comprese dal destinatario. Non va confuso con Allow: il primo riguarda estensioni e funzioni opzionali, il secondo riguarda i metodi SIP.

Accept indica i tipi di contenuto accettati. La risposta può riportare anche Accept-Encoding e Accept-Language. La RFC raccomanda la presenza di questi header, insieme ad Allow e Supported, in una risposta 200 OK a OPTIONS.

Contact può indicare nomi o modalità alternative per raggiungere l’utente. In una risposta OPTIONS ha un significato simile a quello previsto nelle risposte 3xx. Non deve essere interpretato automaticamente come un aggiornamento permanente del routing.

Se OPTIONS è indirizzato a un proxy e la risposta viene generata dal proxy stesso, il 200 OK descrive le capacità del server. In questo caso Allow dovrebbe essere omesso, perché un proxy inoltra richieste e non coincide con uno User Agent sul quale valutare tutti i metodi.

Il corpo SDP

Una risposta OPTIONS può contenere un corpo. Se la richiesta accetta application/sdp, il UAS può usare SDP per descrivere le proprie capacità multimediali. Se l’header Accept manca, la RFC assume application/sdp come valore predefinito per questo uso.

Il corpo SDP presente in una risposta OPTIONS non crea una sessione e non avvia un flusso RTP. Descrive ciò che il destinatario può gestire. La negoziazione effettiva avverrà nel contesto di una richiesta capace di creare o modificare una sessione.

Molti apparati usano OPTIONS solo come controllo di raggiungibilità e rispondono senza SDP. Un Content-Length: 0 non rende la risposta incompleta: significa semplicemente che il server ha scelto di non allegare una descrizione multimediale.

OPTIONS come controllo periodico

Un PBX può inviare OPTIONS ogni 30 o 60 secondi verso il Session Border Controller o il proxy del provider. Se riceve una risposta valida entro il tempo previsto, mantiene il peer nello stato raggiungibile. Se le risposte mancano per più tentativi, può dichiararlo non disponibile e cambiare il routing.

Questo comportamento dipende dal prodotto. La RFC definisce il metodo e il trattamento della richiesta, ma non impone la frequenza dei controlli, il numero di errori tollerati o la logica con cui un trunk viene marcato come disponibile o non disponibile.

Anche il codice considerato valido può cambiare. Alcuni sistemi richiedono 200 OK. Altri considerano sufficiente una risposta SIP finale, perché dimostra che il peer e il percorso di segnalazione sono attivi. Durante il troubleshooting bisogna quindi conoscere la politica locale, non limitarsi a osservare la presenza di una risposta.

Il timeout

Se la richiesta non riceve risposta, la transazione termina con un timeout. Questo può indicare che il bersaglio non è raggiungibile, ma il silenzio non identifica da solo la causa.

Le cause più comuni comprendono:

• indirizzo o porta errati;
• problemi DNS;
• routing IP non disponibile;
• firewall che blocca la richiesta o la risposta;
• NAT non coerente;
• servizio SIP fermo;
• ACL che scarta il mittente;
• trasporto diverso da quello atteso;
• risposta inviata a un indirizzo ricavato in modo errato dal Via.

Con UDP, una richiesta può essere ritrasmessa secondo i timer della transazione non-INVITE. Nel tracciato pcap possiamo quindi trovare più OPTIONS identici con la stessa branch. Non sono controlli distinti: possono essere ritrasmissioni della stessa richiesta in assenza di risposta.

Max-Forwards uguale a zero

La RFC prevede un uso diagnostico di Max-Forwards. Un server che riceve OPTIONS con valore zero può rispondere indipendentemente dalla Request-URI. Inviando richieste con valori progressivi si possono interrogare i singoli passaggi, con una logica simile a traceroute.

Questa funzione dipende dal comportamento degli elementi attraversati e non sostituisce gli strumenti di rete. Può però aiutare a capire quale server risponde e quali capacità dichiara lungo il percorso SIP.

Limiti con proxy e forking

Un INVITE diretto a un utente può essere inoltrato verso più contatti. In caso di forking possono tornare più risposte finali positive. OPTIONS è trattato come richiesta non-INVITE e produce una sola risposta finale verso il client. La differenza deriva dalle regole di elaborazione delle risposte da parte del proxy, descritte nella sezione 16.7 della RFC 3261.

Una risposta positiva a OPTIONS non descrive quindi necessariamente tutti i dispositivi registrati per un utente. Può provenire da un solo ramo oppure dal proxy. Per sapere chi ha risposto conviene osservare Server, User-Agent, Contact, i Via presenti e gli indirizzi IP del pacchetto, sapendo che questi elementi possono essere modificati o omessi.

Lettura in Wireshark

Quando guardiamo un tracciato, una sequenza regolare di OPTIONS e 200 OK mostra il controllo periodico tra due elementi. Richieste ripetute senza risposta indicano un timeout in formazione. Una risposta 401 Unauthorized o 407 Proxy Authentication Required mostra invece che il server è raggiungibile, ma richiede credenziali secondo la propria configurazione.

Un 404 Not Found, 403 Forbidden o 486 Busy Here non equivale al silenzio. La segnalazione ha percorso la rete e un elemento SIP ha elaborato la richiesta. Il codice va poi interpretato rispetto alla Request-URI, al server che lo ha generato e alle regole del servizio.

Errori di interpretazione

Il primo errore consiste nel considerare il 200 OK come prova completa del funzionamento del trunk. OPTIONS non verifica automaticamente audio, codec realmente negoziati, instradamento di ogni numerazione o policy applicate all’INVITE.

Il secondo errore è scambiare OPTIONS per una chiamata. Il metodo non fa squillare il destinatario e non crea una sessione. La presenza di header già noti non cambia questa funzione.

Il terzo errore è attribuire la risposta all’utente indicato nel To senza controllare la Request-URI e il percorso. La risposta può essere stata generata da un proxy o da un altro elemento intermedio.

Il quarto errore è leggere ogni OPTIONS ripetuto come un nuovo controllo. Se branch, Call-ID e CSeq coincidono, può trattarsi della ritrasmissione della stessa transazione. Se cambiano, è più probabile che sia iniziato un nuovo ciclo di verifica.

Una verifica ordinata

Per analizzare un problema legato a OPTIONS possiamo seguire una sequenza semplice:

1. identificare chi invia la richiesta e chi dovrebbe rispondere;
2. controllare Request-URI, indirizzi IP, porte e trasporto;
3. cercare la risposta con branch, Call-ID e CSeq;
4. misurare il tempo di risposta;
5. distinguere nuovi controlli e ritrasmissioni;
6. interpretare il codice finale;
7. leggere gli header di capability;
8. confrontare il risultato con le soglie configurate sull’apparato.

Questa procedura evita di confondere la disponibilità della rete con quella del servizio. Un pacchetto può arrivare a destinazione senza soddisfare la politica del PBX. Al contrario, una risposta di errore può essere utile perché conferma che il percorso SIP è attivo.

Conclusioni

OPTIONS è una richiesta SIP non-INVITE usata per interrogare capacità e stato di base di uno User Agent o di un server. Può essere inviata fuori da un dialogo oppure all’interno di un dialogo esistente, senza modificarlo. La risposta può dichiarare metodi, estensioni, tipi di contenuto e capacità multimediali.

Nelle reti VoIP il metodo è diventato anche uno strumento di controllo periodico. È efficace per verificare che un peer risponda, ma il risultato va letto entro i suoi limiti. Un 200 OK non sostituisce una chiamata di prova; un timeout non spiega da solo dove si trovi il guasto.

Nel prossimo capitolo vedremo il re-INVITE, usato per modificare una sessione già esistente. In quel caso la richiesta non si limita a interrogare il peer: può cambiare i parametri della comunicazione in corso.