RFC 3261: Il DNA del VoIP – Capitolo 6
I METODI SIP, REGISTER e la raggiungibilità dell’identità

I messaggi SIP si distinguono in due grandi categorie: richieste e risposte. Le richieste contengono un’azione da eseguire e questa azione, in SIP, prende il nome di metodo. Le risposte, invece, indicano l’esito della richiesta o lo stato della sua elaborazione.

Nella RFC 3261 i metodi fondamentali sono diversi, ma il primo che analizziamo in modo dedicato nella collana è REGISTER, trattato nella Section 10 della RFC 3261. La scelta non è casuale. Prima di vedere come nasce una sessione con INVITE, conviene capire come un’identità SIP diventa raggiungibile nella rete.

Questo è uno dei capitoli che, negli anni, ho sempre affrontato con una certa attenzione anche durante i corsi che ho tenuto sul SIP e sul troubleshooting VoIP. Il motivo è semplice: REGISTER sembra spesso un passaggio preliminare, quasi amministrativo, ma in realtà tocca uno dei punti più concreti dell’intero protocollo, cioè la raggiungibilità reale dell’utente nella rete.

Molti tecnici lo associano in modo sbrigativo all’idea di registrazione del telefono. È una scorciatoia utile per capirsi al volo, ma non basta. REGISTER non serve solo a dire che un terminale è acceso. Serve a dire alla rete SIP dove deve essere raggiunto, in quel momento, un certo utente o, più precisamente, una certa identità SIP.

Questo punto è decisivo. Se non lo fissiamo bene, leggiamo male non solo i messaggi REGISTER, ma anche molti problemi successivi. Sul campo capita spesso di partire dall’INVITE quando una chiamata non arriva. In realtà, molto spesso, il problema nasce prima, cioè nel modo in cui la raggiungibilità è stata costruita, aggiornata o persa.

Nel Capitolo 3 abbiamo già introdotto il registrar come memoria della raggiungibilità. Qui facciamo il passo successivo. Vedremo insieme che cosa dice la RFC, perché questa logica esiste, come si traduce nei sistemi reali e quali segnali conviene osservare in un tracciato pcap o in Wireshark quando qualcosa non torna.

Che cosa fa davvero REGISTER

La RFC 3261 descrive la registrazione come il meccanismo con cui uno User Agent crea, aggiorna, interroga o rimuove delle associazioni tra una Address of Record e uno o più Contact. In altre parole, REGISTER non crea una chiamata, non apre un dialog e non avvia un media path. Crea invece la base informativa che permetterà, in seguito, di instradare correttamente le richieste dirette a un utente.

“Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses.”
La registrazione crea dei binding, all’interno di un location service di un determinato dominio, che associano una URI di Address of Record a uno o più indirizzi di contatto.

Questa frase spiega bene l’idea centrale. Il protocollo separa in modo rigoroso identità logica e posizione attuale. L’utente può essere noto alla rete come sip:matteo@user.voipvoice.it, ma in quel momento essere raggiungibile su un telefono IP in ufficio, su un softphone, su un client mobile oppure su più terminali insieme. REGISTER serve proprio a comunicare questa informazione alla rete.

Nel lavoro quotidiano questo si vede subito. Se un interno risulta correttamente configurato ma non squilla, il primo dubbio non è solo se l’INVITE sia stato inviato correttamente. Bisogna chiedersi se il dominio abbia un binding valido, aggiornato e coerente per quell’utente. Con binding intendiamo proprio l’associazione tra l’identità SIP pubblica dell’utente, cioè la sua Address of Record, e il recapito operativo indicato nel Contact. Senza questo passaggio, la rete non sa dove consegnare la richiesta.

Registrar e location service

La RFC distingue in modo chiaro il registrar dal location service. Il registrar è il soggetto che riceve la richiesta REGISTER e scrive o aggiorna le informazioni. Il location service è il contenitore logico da cui poi proxy e redirect server leggono i binding. Anche qui conviene essere precisi: non stiamo parlando per forza di due apparati diversi. La distinzione è logica, non fisica. Nella prassi comune, per esempio su un PBX o su una piattaforma software SIP, queste funzioni sono spesso presenti nello stesso apparato o nello stesso software, anche se dal punto di vista della RFC restano due ruoli distinti.

“Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests.”
La registrazione comporta l’invio di una richiesta REGISTER a un tipo speciale di UAS chiamato registrar. Il registrar agisce come front end del location service del dominio, leggendo e scrivendo le associazioni sulla base del contenuto delle richieste REGISTER.

Detto così può sembrare un dettaglio. In realtà non lo è. Nei sistemi reali molti tecnici osservano il server di registrazione come se fosse un semplice punto di autenticazione. In SIP il suo ruolo è più ampio. Il registrar riceve la dichiarazione di raggiungibilità e la rende disponibile agli elementi che dovranno instradare le richieste future.

Nel tracciato SIP questo passaggio non si vede solo nella richiesta REGISTER, ma anche nella conseguenza indiretta. Se il binding esiste, il proxy avrà un riferimento utile quando arriverà una richiesta diretta all’utente. Se il binding manca, è scaduto o è incoerente, il problema emergerà più avanti, spesso sotto forma di utente apparentemente irraggiungibile.

REGISTER non crea un dialog

Un altro punto da fissare bene è questo: REGISTER non stabilisce un dialog. È una richiesta SIP, segue le regole generali del comportamento UAC e del transaction layer, ma non apre quella relazione peer to peer che studieremo più avanti con INVITE e dialoghi.

“A REGISTER request does not establish a dialog.”
Una richiesta REGISTER non stabilisce un dialog.

Questo chiarisce subito perché non bisogna leggere REGISTER con la stessa mentalità con cui si legge una chiamata. Non c’è una sessione da negoziare, non c’è una conferma di media, non c’è un ACK finale come accade con le risposte 2xx a INVITE. Qui la funzione è diversa: aggiornare lo stato di raggiungibilità.

Nel lavoro pratico questa distinzione aiuta a evitare un errore frequente. Quando un tecnico vede un REGISTER riuscito, tende a considerarlo una prova generale del fatto che tutto funzioni. Non è così. Dimostra che il terminale è riuscito a registrare un binding presso il registrar. Non dimostra ancora che una chiamata verrà completata correttamente, che il routing successivo sia giusto o che il media passi senza problemi.

Non tutti i trunk SIP usano REGISTER

A questo punto conviene aprire una piccola parentesi pratica. Quando si parla di REGISTER, si potrebbe pensare che ogni collegamento SIP debba necessariamente registrarsi per poter funzionare. Nella realtà non è sempre così.

Molti interni, telefoni SIP, softphone e diversi servizi hosted usano REGISTER come meccanismo normale di raggiungibilità. Esistono però anche SIP trunk che non richiedono alcuna registrazione per instaurare o ricevere chiamate. In questi casi il rapporto tra i due lati non si basa su un binding creato tramite REGISTER, ma su una relazione di tipo peer, costruita per esempio su IP sorgente, IP destinazione, policy di instradamento, autenticazione diversa o accordi statici tra gli apparati.

In altre parole, esistono anche trunk peer in cui non c’è REGISTER. La chiamata può essere accettata perché il sistema remoto riconosce il peer autorizzato in base all’indirizzo IP, al dominio, alla porta o ad altri parametri di fiducia configurati. Questo è molto comune nelle interconnessioni tra PBX, SBC, carrier e infrastrutture di trunking professionale.

Questa precisazione è utile perché evita un errore frequente nel troubleshooting. Se stiamo analizzando un trunk SIP di tipo peer e partiamo subito a cercare un REGISTER, rischiamo di inseguire un messaggio che in quello scenario non deve proprio esistere. In quel caso il controllo corretto si sposta su altri elementi, per esempio la definizione del peer, il routing, i filtri IP, gli header attesi e il comportamento dell’INVITE.

Detto in modo semplice: REGISTER è uno dei meccanismi più importanti della raggiungibilità SIP, ma non è l’unico modello possibile. Per questo motivo conviene sempre capire prima che tipo di collegamento stiamo osservando.

Address of Record e Contact

Qui si gioca una parte importante del comportamento SIP. La RFC costruisce REGISTER attorno a due livelli che non vanno confusi: la Address of Record e il Contact.

La Address of Record, o AOR, è l’identità pubblica dell’utente nel dominio. Nel nostro contesto può essere, per esempio, sip:matteo@user.voipvoice.it. Il Contact, invece, è il recapito operativo a cui il dominio dovrà inoltrare le richieste destinate a quella identità.

La RFC è molto chiara quando descrive i campi principali della richiesta REGISTER. La Request-URI punta al dominio del location service. Il campo To contiene l’Address of Record oggetto della registrazione. Il campo From indica il soggetto responsabile della registrazione, che normalmente coincide con il To, salvo i casi di third-party registration.

“The Request-URI names the domain of the location service for which the registration is meant… The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name.”
La Request-URI identifica il dominio del location service per cui la registrazione è destinata. Il campo To contiene l’Address of Record la cui registrazione deve essere creata, interrogata o modificata. Di norma To e Request-URI differiscono, perché il primo contiene il nome utente.

Questo è il punto da fissare bene. Nel REGISTER la Request-URI non indica il singolo utente da raggiungere, ma il dominio che gestisce la registrazione. Il campo To identifica invece l’utente logico a cui i binding si riferiscono. È una distinzione semplice, ma nel tracciato pcap cambia molto il modo di leggere il messaggio.

Un errore frequente consiste nel controllare solo il Contact e trascurare la coerenza tra dominio della Request-URI, To e From. Se questi campi non raccontano la stessa logica amministrativa, la registrazione può essere rifiutata, gestita male oppure finire in un dominio che non ha responsabilità su quell’utente.

Un esempio pratico di REGISTER

Per rendere più concreta questa struttura, possiamo osservare un esempio semplice. Matteo vuole registrare il proprio endpoint sul dominio user.voipvoice.it.

REGISTER sip:user.voipvoice.it SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-76231;rport
Max-Forwards: 70
From: <sip:matteo@user.voipvoice.it>;tag=reg-001
To: <sip:matteo@user.voipvoice.it>
Call-ID: reg-847362@192.168.1.50
CSeq: 1 REGISTER
Contact: <sip:matteo@192.168.1.50:5060>;expires=300
Expires: 300
Content-Length: 0

Questo messaggio mostra già diversi punti importanti.

• La Request-URI è il dominio del registrar, non l’utente completo.
• To e From identificano l’Address of Record di Matteo.
• Il Contact indica il recapito che Matteo propone come destinazione operativa.
• Il parametro expires, qui insieme al campo Expires, suggerisce quanto a lungo il binding dovrebbe restare valido.
• Il CSeq parte da 1 e dovrà aumentare per i REGISTER successivi con lo stesso Call-ID.

In Wireshark conviene controllare subito questi elementi. Se la Request-URI punta al dominio sbagliato, il problema nasce prima ancora di qualsiasi autenticazione. Se To e Contact non sono coerenti con il contesto della registrazione, il binding risultante può essere inutile oppure indesiderato. Se CSeq non cresce correttamente o il Call-ID cambia in modo anomalo, si complica la lettura dell’ordine delle registrazioni.

Il significato operativo del Contact

La RFC spiega che il campo Contact in REGISTER contiene gli indirizzi a cui devono essere inoltrate le richieste dirette a quell’Address of Record. È una scelta architetturale molto importante, perché separa ancora una volta identità e destinazione.

“The REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the address-of-record should be forwarded.”
La richiesta REGISTER inviata a un registrar include gli indirizzi di contatto ai quali devono essere inoltrate le richieste SIP destinate all’Address of Record.

Nel mondo reale questo significa che lo stesso utente può pubblicare uno o più recapiti. Un softphone può registrare un Contact, un telefono da scrivania un altro, un client mobile un altro ancora. Il dominio manterrà queste associazioni e potrà usarle per il routing successivo.

Qui nasce anche una delle aree più delicate del troubleshooting. Molti endpoint, soprattutto in reti private, inviano nel Contact un IP privato. Questo, da solo, non significa automaticamente che la chiamata fallirà. Oggi molte centrali e molti SBC gestiscono bene questo scenario grazie a rport, received, riscritture lato server o altri meccanismi di mantenimento della raggiungibilità. Però resta un punto da osservare con attenzione, perché un Contact incoerente, scaduto o non risolvibile può creare problemi reali quando il dominio prova a usare quel binding.

Scadenza, refresh e soft state

La registrazione SIP è costruita come soft state. Questo significa che il binding non resta valido per sempre. Deve essere rinnovato periodicamente. La RFC prevede due modi con cui il client può suggerire il tempo di validità: tramite il campo Expires oppure tramite il parametro expires associato a un singolo Contact.

“When a client sends a REGISTER request, it MAY suggest an expiration interval… There are two ways… through an Expires header field or an ‘expires’ Contact header parameter.”
Quando un client invia un REGISTER può suggerire un intervallo di validità della registrazione. Ci sono due modi per farlo: con il campo Expires oppure con il parametro expires del Contact.

Questo meccanismo esiste per una ragione molto concreta. La rete non può dare per scontato che un terminale resti sempre dove si trova, acceso e raggiungibile. Il binding deve poter decadere se il terminale scompare, cambia rete, perde connettività o viene spento senza de-registrarsi.

Nel tracciato SIP questo punto si vede bene quando il terminale rinnova periodicamente la registrazione. Se il refresh non arriva in tempo, il binding scade. Da quel momento il dominio può smettere di avere una destinazione valida per l’utente, anche se dal punto di vista dell’utente il telefono sembra ancora configurato correttamente.

Un errore frequente consiste nel considerare il tempo di scadenza come un puro dettaglio amministrativo. In realtà incide direttamente sulla raggiungibilità. Se il registrar impone una policy diversa da quella proposta dal client, sarà la risposta del server a definire il tempo effettivo. Per questo conviene sempre leggere non solo il REGISTER inviato, ma anche il 200 OK di ritorno.

Timeout, re-register e un-register

Fin qui abbiamo visto che la registrazione SIP è costruita come soft state. Questo significa che non basta inviare un REGISTER una sola volta e dare per scontato che il binding resti valido per sempre. Ogni binding ha una durata limitata e deve essere mantenuto vivo con richieste successive. Proprio qui entrano in gioco tre concetti che, nella pratica, vengono citati spesso ma non sempre spiegati con precisione: timeout, re-register e un-register.

Per timeout, nel contesto del REGISTER, dobbiamo distinguere due livelli diversi. Il primo è il timeout della transazione SIP, cioè il caso in cui il terminale invia la richiesta REGISTER e non riceve una risposta finale entro i tempi previsti dal transaction layer. Il secondo è il timeout del binding, cioè la sua scadenza naturale nel location service quando il tempo di validità termina e non arriva un rinnovo in tempo.

Questa distinzione è importante perché produce sintomi diversi. Se va in timeout la transazione, il terminale non sa ancora se il registrar abbia ricevuto o meno la richiesta. Se invece scade il binding, il registrar considera semplicemente quell’associazione non più valida e il dominio può smettere di usare quel Contact per instradare richieste future.

Nel caso del timeout transazionale, la RFC specifica un comportamento prudente. Se il client non riceve alcuna risposta dal registrar, non dovrebbe continuare a ritrasmettere all’infinito o aprire nuove richieste in modo disordinato verso lo stesso server. Dal punto di vista pratico, questo significa che quando un REGISTER sembra sparire nel nulla, il tecnico deve chiedersi prima di tutto se il problema sia di rete, di routing, di risoluzione del registrar o di perdita della risposta lungo il percorso.

Il re-register è invece il rinnovo della registrazione prima che il binding scada. In pratica il terminale invia un nuovo REGISTER per confermare o aggiornare l’associazione già esistente. Normalmente mantiene lo stesso Call-ID, incrementa il CSeq e propone un nuovo intervallo di scadenza. Dal punto di vista operativo, il re-register serve a dire al dominio che quell’utente è ancora presente e ancora raggiungibile a quel Contact, oppure che il Contact è cambiato e va aggiornato.

Questo è il motivo per cui, nei sistemi reali, i terminali ben implementati non aspettano quasi mai l’ultimo secondo utile. Il rinnovo viene eseguito in anticipo rispetto alla scadenza effettiva del binding, così da evitare finestre in cui l’utente potrebbe risultare temporaneamente non raggiungibile. Se questo rinnovo non parte, parte troppo tardi o fallisce in modo ripetuto, nel tracciato pcap vedremo una sequenza tipica: ultimo REGISTER valido, assenza di refresh utile, scadenza del binding, e successiva perdita della raggiungibilità.

Il un-register, o de-registrazione, è invece la rimozione volontaria del binding. La RFC lo prevede in modo esplicito: per eliminare un singolo Contact si invia un REGISTER in cui quel Contact ha expires=0. Per eliminare tutti i binding dell’Address of Record si usa invece il valore speciale Contact: * insieme a Expires: 0. In questo modo il terminale non aspetta la scadenza naturale del binding, ma comunica direttamente al registrar che quel recapito non deve più essere considerato valido.

Dal punto di vista pratico, questo comportamento compare quando un terminale si spegne correttamente, quando un softphone esegue il logout, oppure quando un apparato cambia rete e vuole rimuovere il vecchio binding prima di registrarne uno nuovo. Non tutti i terminali però eseguono sempre un un-register pulito. Molti, nella realtà, semplicemente smettono di rinnovare il binding e lasciano che la registrazione decada da sola. Anche questo spiega perché nei sistemi reali si vedano spesso binding rimasti attivi ancora per qualche minuto dopo la chiusura del client.

Questo blocco è importante anche per il troubleshooting perché spiega tre scenari che, a prima vista, possono sembrare uguali. Un utente può risultare non raggiungibile perché non si è mai registrato correttamente, perché il re-register non è stato completato in tempo, oppure perché il terminale ha eseguito un un-register volontario. Nel tracciato SIP, però, questi tre casi lasciano segni diversi e vanno letti in modo diverso.

Più Contact, preferenze e binding multipli

La RFC prevede che uno stesso Address of Record possa essere associato a più Contact. Non è un’eccezione, è parte del modello. Un utente può voler essere raggiunto su più terminali. In questo caso il REGISTER può includere più indirizzi e la preferenza relativa può essere espressa con il parametro q.

Questo è un aspetto molto utile da ricordare quando si analizzano ambienti reali. Se Matteo è registrato contemporaneamente su un telefono fisso e su un softphone, il dominio può ricevere più binding per la stessa identità. La presenza di più Contact non indica necessariamente un errore. Va interpretata nel contesto.

Qui conviene precisare bene anche un termine che, nella pratica, viene usato spesso in modo impreciso. Non esiste un vero e proprio fork del REGISTER. Il metodo REGISTER non viene duplicato verso più terminali per cercare chi risponde, come può accadere invece con una richiesta di chiamata.

Quello che REGISTER fa è un’altra cosa: può creare o mantenere più binding per lo stesso Address of Record. In altre parole, uno stesso utente può risultare registrato con più Contact validi nello stesso momento, per esempio su un telefono fisso, su un softphone e su un client mobile.

Il forking, invece, è il comportamento che può avvenire dopo, quando arriva una richiesta successiva, per esempio un INVITE, destinata a quell’utente. In quel momento il proxy o la logica di instradamento del dominio può usare i binding presenti nel location service per tentare la consegna verso più Contact registrati, anche in parallelo.

Detto in modo molto diretto: REGISTER non fa forking, REGISTER prepara l’elenco dei recapiti validi. Il forking riguarda semmai la richiesta successiva che userà quell’elenco per cercare l’utente. Questa distinzione è importante perché evita di attribuire al metodo REGISTER un comportamento che, nella RFC, appartiene alla fase di instradamento delle richieste successive.

Sul campo questo problema compare quando si leggono come duplicati dei binding che in realtà sono legittimi. Il problema vero nasce quando un endpoint rinnova binding che non gli appartengono, quando un dispositivo lascia binding vecchi non più validi oppure quando l’ordine di preferenza non corrisponde al comportamento atteso della rete.

Rimuovere e interrogare i binding

REGISTER non serve solo ad aggiungere binding. La RFC dice in modo esplicito che può anche rimuovere o interrogare quelli esistenti. Questo amplia molto il significato operativo del metodo.

Per rimuovere un binding specifico, il client può usare un intervallo di scadenza pari a 0 per quel Contact. Per rimuovere tutti i binding associati a un Address of Record, può usare il valore speciale * nel Contact, ma solo insieme a Expires: 0. È una regola precisa e va letta bene, perché il carattere speciale non è libero: ha senso solo in quel contesto.

La RFC aggiunge anche un punto spesso poco valorizzato: una risposta di successo a REGISTER contiene l’elenco completo dei binding correnti, anche quando la richiesta non aveva un Contact. Questo rende REGISTER utile anche come meccanismo di interrogazione dello stato attuale.

“A success response to any REGISTER request contains the complete list of existing bindings… If no Contact header field is present in a REGISTER request, the list of bindings is left unchanged.”
Una risposta di successo a qualunque REGISTER contiene l’elenco completo dei binding esistenti. Se nella richiesta non è presente un campo Contact, l’elenco dei binding non viene modificato.

Nel troubleshooting questo è molto utile. Non bisogna limitarsi a guardare che il server abbia risposto 200 OK. Bisogna controllare quali binding il registrar ha effettivamente accettato e pubblicato come validi in quel momento.

Call-ID, CSeq e ordine corretto delle registrazioni

La RFC dedica attenzione anche all’ordine delle richieste REGISTER. Tutte le registrazioni inviate da uno stesso UAC verso un registrar dovrebbero usare lo stesso Call-ID durante un singolo ciclo di boot, mentre il CSeq deve aumentare di uno a ogni nuova richiesta REGISTER con quel Call-ID.

“All registrations from a UAC SHOULD use the same Call-ID… The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.”
Tutte le registrazioni provenienti da uno stesso UAC dovrebbero usare lo stesso Call-ID. Il valore di CSeq garantisce il corretto ordinamento delle richieste REGISTER e deve essere incrementato di uno a ogni nuova richiesta con lo stesso Call-ID.

Il motivo tecnico è semplice. Il registrar deve poter distinguere correttamente le richieste nuove da eventuali ritardi, ritrasmissioni o messaggi arrivati fuori ordine. Se il Call-ID cambia in modo arbitrario oppure il CSeq non cresce correttamente, la lettura dello stato diventa più fragile.

Nel tracciato pcap questo controllo è rapido e spesso molto utile. Quando una registrazione sembra andare e venire senza motivo apparente, vale la pena osservare se il terminale sta mantenendo una sequenza coerente. Il sintomo tipico è una serie di REGISTER apparentemente simili, ma con progressione errata oppure con nuovi tentativi emessi prima della risposta finale al precedente.

La RFC, infatti, vieta esplicitamente di inviare una nuova registrazione con nuovi Contact prima di aver ricevuto una risposta finale alla precedente o prima che questa sia andata in timeout. Anche questo è un modo per evitare ambiguità nello stato del registrar.

423 Interval Too Brief e altre letture utili

Tra le risposte di errore più significative per REGISTER c’è la 423 Interval Too Brief. La RFC prevede che, se il registrar considera troppo breve il tempo di registrazione richiesto, il client possa ritentare adeguando gli intervalli di scadenza almeno al valore indicato in Min-Expires.

Questo comportamento è molto istruttivo perché mostra una logica tipica del SIP: il client può proporre, ma è il server che applica la propria policy. Nel lavoro reale questo succede spesso con telefoni, ATA o softphone che chiedono refresh troppo frequenti rispetto a quanto ammesso dal dominio.

In Wireshark conviene controllare non solo il codice 423, ma anche il valore di Min-Expires e il modo in cui il terminale reagisce. Un dispositivo ben implementato ritenta con un valore coerente. Un dispositivo gestito male può continuare a ripetere richieste non accettabili, producendo un problema che sembra di autenticazione o di rete, ma che in realtà è una questione di policy sulla registrazione.

Cosa guardare nei tracciati pcap

Quando si analizza REGISTER in Wireshark, conviene seguire una sequenza mentale ordinata. Prima di tutto verificare il dominio della Request-URI. Poi controllare To, From e Contact. Dopo di questo, osservare Call-ID, CSeq, eventuale Authorization, i tempi di scadenza proposti e quelli effettivamente restituiti dal server.

Questo metodo evita una lettura troppo frettolosa. Un REGISTER riuscito non va giudicato solo dal codice finale, ma dalla qualità tecnica del binding che produce. Nel tracciato SIP questo passaggio si vede quando la risposta 200 OK restituisce i Contact correnti e i relativi tempi di validità. Lì si capisce se il registrar ha davvero recepito la raggiungibilità nel modo che il terminale si aspettava.

Un errore frequente consiste nel dire che il telefono è registrato perché ha ricevuto 200 OK. In realtà bisogna chiedersi: registrato come, con quale Contact, con quale scadenza, verso quale dominio e con quale coerenza rispetto alla topologia reale della rete.

Conclusione

A questo punto dovrebbe essere più chiaro perché REGISTER occupa una posizione così importante nella logica del SIP. Non serve a stabilire una chiamata, ma a costruire la raggiungibilità di un’identità. In altre parole, prepara il terreno su cui poi potranno viaggiare le richieste future.

La RFC 3261 tratta questo metodo con grande rigore perché da qui dipende una parte essenziale del comportamento della rete: la possibilità di associare correttamente un Address of Record a uno o più Contact, mantenerli aggiornati, rimuoverli quando serve e renderli leggibili per proxy e redirect server.

Nel lavoro quotidiano questa distinzione fa la differenza. Quando un utente non riceve chiamate, quando un interno sparisce in modo intermittente, quando un binding sembra valido ma non produce raggiungibilità reale, il punto da osservare è spesso proprio REGISTER. Ed è per questo che vale la pena studiarlo non come una formalità di avvio del terminale, ma come uno dei meccanismi più concreti e più operativi dell’intero protocollo.

Nel prossimo capitolo potremo fare il passo successivo e vedere come, una volta resa raggiungibile un’identità SIP, nasce davvero una sessione con il metodo INVITE.