Funzionamento di header SIP: SUPPORTED & REQUIRE

Oltre alla semplice RFC3261 che disciplina i fondamentali del proticollo SIP, esistono una serie di metodi aggiuntivi, detti “estensioni”, che sono stati aggiunti al protocollo SIP di base per espandere la proprie funzionalità. Le più comuni estensioni dei metodi di base sono rappresentate da: INFO, MESSAGE, NOTIFY, PRACK e UPDATE . Nonostante questi metodi non compaiano e non siano definite nella RFC3261 sono comunque ormai tradizionalmente considerati quali “estensioni” del protocollo SIP, intese come funzionalità extra. Un client SIP può richiedere una di queste funzionalità extra ad un server (UAS). Se il server non supporta tale funzionalità, può rifiutare la sessione e inviare una risposta che indica che non sa come gestire il tipo di estensione menzionata. Un esempio piuttosto comune è costituito dalla risposta SIP 420 Bad Extension; tale risposta indica semplicemente che si sta richiedendo un’estensione SIP che non è utilizzata/compresa dal server.

Header SUPPORTED e REQUIRE

L’intestazione “Supported” viene abbozzata intorno al 2000. E’però solo nel 2002 con l’avvento della RFC3261 e del protocollo SIP v. 2 che questa intestazione (header) viene definita formalmente. Se un UAC o UAS richiede il supporto tassativo per un’estensione SIP, come ad esempio il supporto PRACK per un Media Gateway, può utilizzare l’ intestazione REQUIRE. L’utilizzo dell’intestazione REQUIRE specifica esplicitamente che la richiesta deve essere respinta se non viene fornito il supporto per le estensioni elencate. Nell’intestazione SUPPORTED l’UAC dovrebbe quindi sempre comprendere un elenco di tag di opzione indicanti le estensioni che esso è in grado di gestire. I Tag delle opzioni elencati DEVONO fare riferimento solo alle estensioni definite all’interno dello standard-track RFC. Le Estensioni definite come sperimentali e le RFC informative sono esplicitamente escluse dall’uso con le intestazioni SUPPORTED fintanto che esse non vengasno considerate definitive e approvate nell’ambito delle RFC ufficiali. E’ quindi abbastanza chiaro che l’utilizzo dell’intestazione SUPPORTED va utilizzato quando l’estensione SIP richiesta è fondamentale affinché la chiamata venga avviata correttamente. L’importanza è anche tale per cui si preferisce terminare la chimata piuttosto che rinunciare all’estensione richiesta. Le intestazioni SUPPORTED e REQUIRE appena illustrate sono generalmente presenti nei metodi INVITE, nelle risposte SIP come 200 OK ma sono comunemente utilizzate anche all’interno delle richieste di tipo SIP OPTIONS.  

 

Alcune precisazioni sull’uso dell’header REQUIRE

Nel momento in cui L’UAS ritiene che sia utile e conveniente utilizzare le estensioni elencate nell’header REQUIRE appena ricevuto, esso procede con l’esaminare il contenuto specifico della richiesta. L’intestazione  REQUIRE viene utilizzato da un UAC per informare un UAS SIP che l’UAC si aspetta che l’UAS abbia le caratteristiche necessarie per elaborare correttamente la richiesta. Se un UAS non comprende un tag di opzione elencato nel REQUIRE, DEVE rispondere generando una risposta con codice di stato 420 (estensione errata). L’UAS DEVE anche però aggiungere un ulteriore intestazione “NOT SUPPORTED” ed elencare attraverso di essa le opzioni che con vengono correttamente comprese tra quelle che erano state elencate nella richiesta REQUIRE. Esempio:

UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel

UAS->UAC: SIP/2.0 420 Estensione errata
Not Supported: 100rel

Questo comportamento assicura che l’interazione client-server proceda senza indugio quando tutte le opzioni sono comprese da entrambi i lati, e rallentare solo se le opzioni non sono comprese (come nell’esempio sopra). Se il dialogo Client-server è ben assortito, l’interazione procede rapidamente, risparmiando un viaggio di andata e ritorno ed evitando meccanismi negoziali. Inoltre sarebbe sempre meglio rimuovere tutte le ambiguità quando il client richiede funzionalità che il server non è in grado di comprendere.