10. Registrations
10 Registrazioni (Registrations)
10.1 Panoramica (Overview)
SIP fornisce una funzione di scoperta. Quando un utente desidera avviare una sessione con un altro utente, SIP deve individuare l'host attualmente raggiungibile per l'utente destinatario. Questo processo di scoperta è spesso svolto da elementi di rete SIP come server proxy o di reindirizzamento, che ricevono la richiesta, decidono dove inviarla in base alla conoscenza della posizione dell'utente e la inoltrano. A tal fine, questi elementi fanno riferimento a un servizio astratto chiamato servizio di localizzazione, che fornisce associazioni di indirizzi per un particolare dominio. Queste associazioni mappano un URI SIP o SIPS in ingresso (es. sip:[email protected]) in uno o più URI «più vicini» all'utente desiderato (es. sip:[email protected]). In definitiva, il proxy fa riferimento a un servizio di localizzazione per l'URI passato nella Request-URI, che corrisponde all'utente destinatario.
La registrazione crea un'associazione nel servizio di localizzazione di un particolare dominio, associando un URI di indirizzo di riferimento (address-of-record) a uno o più indirizzi di contatto. Così, quando un proxy di quel dominio riceve una richiesta la cui Request-URI corrisponde all'indirizzo di riferimento, inoltra la richiesta all'indirizzo di contatto registrato. In genere, ha senso registrare un indirizzo di riferimento nel servizio di localizzazione di un dominio solo se le richieste per quell'indirizzo sono instradate verso quel dominio. Nella maggior parte dei casi, ciò significa che il dominio della registrazione deve corrispondere al dominio nell'URI di indirizzo di riferimento.
Esistono molti modi per stabilire il contenuto del servizio di localizzazione. Uno è amministrativo. Inoltre, SIP fornisce un meccanismo che consente agli UA di creare esplicitamente associazioni. Tale meccanismo è noto come registrazione.
La registrazione comporta l'invio di una richiesta REGISTER a un tipo particolare di UAS chiamato registrar. Il registrar funge da front-end per il servizio di localizzazione del dominio, leggendo e scrivendo corrispondenze in base al contenuto delle richieste REGISTER. Il servizio di localizzazione è quindi consultato dai server proxy responsabili dell'instradamento delle richieste verso quel dominio.
La figura 2 mostra uno schema dell'intero processo di registrazione. Si noti che registrar e server proxy sono ruoli logici che possono essere svolti da un singolo dispositivo di rete. Per chiarezza, la figura li separa. Inoltre, gli UA possono inviare richieste tramite un server proxy per raggiungere il registrar se sono elementi distinti.
SIP non impone un meccanismo specifico per implementare il servizio di localizzazione. L'unico requisito è che il registrar di un dominio DEVE poter leggere e scrivere dati nel servizio di localizzazione, e che il proxy o il server di reindirizzamento di quel dominio DEVE poter leggere gli stessi dati.
10.2 Costruzione della richiesta REGISTER (Constructing the REGISTER Request)
Una richiesta REGISTER aggiunge, rimuove e interroga associazioni. Può aggiungere una nuova associazione tra un indirizzo di riferimento e uno o più indirizzi di contatto. Gli indirizzi di contatto possono essere registrati per conto di terzi debitamente autorizzati. Un client può anche rimuovere associazioni precedenti o interrogare quali associazioni sono attualmente presenti per l'indirizzo di riferimento.
Salvo diversa indicazione, la costruzione della richiesta REGISTER e il comportamento del client che la invia sono identici al comportamento generale dell'UAC descritto nelle sezioni 8.1 e 17.1.
Una richiesta REGISTER non stabilisce un dialogo. Un UAC PUÒ includere un campo di intestazione Route in una richiesta REGISTER basata su un insieme di route preesistente. Il campo di intestazione Record-Route non ha significato in una richiesta o risposta REGISTER e DEVE essere ignorato se presente.
I seguenti campi di intestazione, eccetto Contact, DEVONO essere inclusi in una richiesta REGISTER. Il campo Contact PUÒ essere incluso.
Request-URI: specifica il dominio del servizio di localizzazione oggetto della registrazione. I componenti «userinfo» e «@» dell'URI SIP NON DEVONO essere presenti.
To: contiene l'indirizzo di riferimento per cui la registrazione è creata, interrogata o modificata. DEVE essere un URI SIP o SIPS.
From: contiene l'indirizzo di riferimento della persona responsabile della registrazione.
Call-ID: per tutte le registrazioni inviate a un registrar particolare, DOVREBBE usare lo stesso valore Call-ID.
CSeq: il client DEVE incrementare di 1 il valore CSeq per ogni richiesta REGISTER con stesso Call-ID.
Contact: la richiesta PUÒ contenere un campo Contact con zero o più valori.
Gli UA NON DEVONO inviare una nuova registrazione prima di ricevere la risposta finale del registrar per la precedente, o prima della scadenza della precedente.
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| [email protected]
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+ [email protected]
carol
Figure 2: REGISTER example
I seguenti parametri Contact hanno significato speciale.
action: il parametro «action» di RFC 2543 è obsoleto. Un UAC NON DOVREBBE usarlo.
expires: indica la durata di validità dell'associazione. Se assente, si usa il campo Expires. Valori > 2**32-1 sono trattati come 2**32-1; un valore mal formato DOVREBBE essere trattato come 3600.
10.2.1 Aggiunta di associazioni (Adding Bindings)
Una richiesta REGISTER inviata a un registrar contiene un indirizzo di contatto verso cui inoltrare le richieste SIP per l'indirizzo di riferimento. L'indirizzo di riferimento è nel campo To. Il valore Contact è generalmente un URI SIP o SIPS, ma PUÒ usare qualsiasi schema. Se l'indirizzo di riferimento nel To è un URI SIPS, il valore Contact DOVREBBE essere SIPS. La registrazione non aggiorna tutte le associazioni; tipicamente un UA aggiorna solo il proprio indirizzo di contatto.
10.2.1.1 Impostazione dell'intervallo di scadenza (Setting the Expiration Interval of Contact Addresses)
Un client PUÒ proporre un intervallo di scadenza tramite il campo Expires o il parametro «expires» del Contact. Quest'ultimo consente un intervallo per associazione quando più associazioni sono in un'unica richiesta.
10.2.1.2 Preferenze tra indirizzi di contatto (Preferences among Contact Addresses)
Se più contatti sono inviati, il UA che registra intende associarli tutti all'indirizzo di riferimento. La lista PUÒ essere prioritizzata col parametro «q».
10.2.2 Rimozione di associazioni (Removing Bindings)
Sebbene la registrazione sia soft state e scada se non aggiornata, PUÒ essere rimossa esplicitamente. Un client PUÒ richiedere la cancellazione immediata specificando scadenza «0». Il valore speciale «*» si applica a tutte le registrazioni ma NON DEVE essere usato senza un campo Expires con valore «0».
10.2.3 Recupero di associazioni (Fetching Bindings)
Ogni risposta con successo a una REGISTER contiene l'elenco completo delle associazioni esistenti, che la richiesta abbia o meno un campo Contact. Una REGISTER senza Contact non modifica l'elenco.
10.2.4 Aggiornamento di associazioni (Refreshing Bindings)
Ogni UA è responsabile dell'aggiornamento delle associazioni precedentemente stabilite. La risposta 200 (OK) contiene l'elenco dei contatti; il UA esamina ciascuno e aggiorna la scadenza, emettendo una nuova REGISTER per ciascuno prima della scadenza.
10.2.5 Impostazione dell'orologio interno (Setting the Internal Clock)
Se la risposta contiene un campo Date, il client PUÒ usarlo per regolare l'orologio interno.
10.2.6 Individuazione di un registrar (Discovering a Registrar)
Gli UA possono usare tre metodi per determinare l'indirizzo di invio: configurazione, uso dell'indirizzo di riferimento, e multicast. Se nessun indirizzo è configurato, il UA DOVREBBE usare la parte host dell'indirizzo di riferimento come Request-URI.
10.2.7 Trasmissione di una richiesta (Transmitting a Request)
Dopo aver costruito la REGISTER, il UAC segue le procedure della sezione 8.1.2. Se la transazione restituisce timeout, il UAC NON DOVREBBE ritentare subito con lo stesso registrar.
10.2.8 Risposte di errore (Error Responses)
Se un UA riceve 423 (Interval Too Brief), PUÒ riprovare dopo aver reso l'intervallo di scadenza pari al valore Min-Expires della risposta.
10.3 Elaborazione delle richieste REGISTER (Processing REGISTER Requests)
Un registrar è un UAS speciale che risponde a REGISTER e mantiene un elenco di associazioni. DEVE processare le REGISTER in ordine di ricezione e atomicamente. Alla ricezione di una REGISTER esegue: verifica Request-URI e responsabilità; verifica Require; autentica il UAC; verifica autorizzazione (403 se negata); estrae e canonizza l'indirizzo di riferimento dal To (404 se non valido); gestisce Contact (caso «*» con Expires 0); per ciascun contatto determina l'intervallo richiesto, PUÒ accorciarlo, PUÒ rifiutare con 423 se troppo breve (con Min-Expires); confronta e aggiorna le associazioni esistenti per Call-ID e CSeq; infine restituisce 200 (OK) con tutte le associazioni e il parametro «expires» (e campo Date).