SIP 302 Moved Temporarily

SIP 302 Moved Temporarily

Un PBX può gestire la chiamata creando una seconda chiamata verso il numero di destinazione, oppure può utilizzare un meccanismo di redirection SIP, lasciando al dispositivo o al sistema remoto il compito di instaurare la nuova chiamata.

Il codice SIP 302 Moved Temporarily appartiene proprio a questa seconda categoria.

Questa distinzione diventa particolarmente importante quando si vuole inoltrare una chiamata proveniente dall’esterno verso un altro numero esterno mantenendo, sul telefono del destinatario finale, il numero originale del chiamante.

È proprio in questo scenario che possono emergere differenze significative tra un normale telefono IP e un IP-PBX.

1. Il problema in uno scenario reale

Consideriamo un esempio semplice:

• A = 02 55555 → numero del chiamante originale
• B = 02 4444444 → numero della linea SIP / DID che riceve la chiamata
• C = 02 6666666 → numero esterno verso cui effettuare l’inoltro

Il flusso desiderato è:

A → B → C

con una condizione precisa: C deve visualizzare A come numero chiamante.

Quindi, se 02 55555 chiama 02 4444444 e quest’ultimo è configurato per inoltrare la chiamata a 02 6666666, il telefono C dovrebbe vedere:

02 55555

e non:

02 4444444

Questo dettaglio è tutt’altro che secondario.

Se il PBX genera una nuova chiamata verso C utilizzando come Caller ID il numero della propria linea B, il destinatario finale vedrà il numero del centralino o della linea aziendale anziché quello della persona che ha originato la chiamata.

2. Che cosa fa realmente un SIP 302

Il codice 302 Moved Temporarily è definito dallo standard SIP RFC 3261. In caso di risposta 302, il sistema che ha ricevuto la risposta può utilizzare l’indirizzo contenuto nell’header Contact per effettuare una nuova richiesta verso la destinazione indicata.

In termini semplificati:

Chiamante A
     |
     | INVITE B
     v
Sistema B
     |
     | 302 Moved Temporarily
     | Contact: C
     v
Il sistema originatore
     |
     | nuovo INVITE verso C
     v
Destinazione C

Il punto fondamentale è che il dispositivo che riceve il 302 non deve necessariamente mantenere la chiamata attraverso il PBX.

La risposta 302 comunica sostanzialmente:

“La destinazione richiesta è temporaneamente raggiungibile a questo altro indirizzo.”

Il nuovo INVITE viene quindi costruito dal dispositivo o dal sistema che elabora la risposta di redirection.

RFC 3261 descrive il 302 come una risposta di redirection nella quale il client dovrebbe riprovare la richiesta utilizzando l’indirizzo indicato nell’header Contact.

3. Redirection e call forwarding non sono la stessa cosa

Questo è probabilmente il punto più importante dell’intera questione.

Un utente può configurare:

Call Forward → numero esterno

ma non significa necessariamente che il PBX stia utilizzando SIP 302.

Esistono almeno due approcci concettualmente differenti.

Approccio A – SIP 302

Il PBX risponde alla chiamata con una redirection:

A → B
B → 302 Contact: C
A / sistema originatore → C

Il PBX comunica la nuova destinazione e può uscire dal percorso della chiamata.

Approccio B – nuovo INVITE generato dal PBX

Il PBX mantiene la gestione della chiamata e genera una nuova chiamata:

A → B
      |
      | nuova chiamata
      v
      C

In questo caso l’UCM deve costruire un nuovo INVITE verso C.

Ed è proprio qui che nasce il problema del Caller ID.

Il nuovo INVITE deve contenere, secondo quanto consentito dal provider e dalla configurazione, l’identità originale di A oppure le informazioni necessarie affinché il provider possa ricostruirla.

4. Perché il Caller ID può cambiare

Quando l’UCM genera un nuovo INVITE verso il provider, non sta semplicemente “prolungando” il primo INVITE. Sta effettuando una nuova richiesta SIP.

Di conseguenza devono essere determinati diversi parametri:

• numero chiamante;
• Caller ID;
• From;
• P-Asserted-Identity;
• Remote-Party-ID, se utilizzato;
• eventuale Diversion;
• eventuale DOD;
• regole della outbound route;
• Caller ID globale;
• impostazioni del trunk.

La documentazione Grandstream descrive infatti una precisa gerarchia utilizzata dall’UCM per determinare il Caller ID in uscita, nella quale rientra anche il mantenimento del Caller ID originale per le chiamate inoltrate.

Questo spiega perché il semplice fatto che:

“il forwarding funziona”

non significa automaticamente che:

“il Caller ID originale viene mantenuto”.

Sono due problemi differenti.

5. Il ruolo del “Keep Original CID”

Negli UCM630X esiste una funzione specifica per mantenere il Caller ID originale nelle chiamate inoltrate.

La documentazione Grandstream indica infatti Keep Original CID come uno degli elementi che determinano la scelta del Caller ID in uscita.

La logica generale può essere rappresentata così:

Chiamata originale
        |
        v
Caller ID A
        |
        v
      UCM
        |
        | Keep Original CID
        v
   Nuovo INVITE
        |
        v
    Provider
        |
        v
        C

Ma il fatto che l’UCM conservi internamente il Caller ID originale non significa necessariamente che il provider lo accetti.

Il provider può infatti applicare proprie regole sull’identità del chiamante.

6. Il ruolo del Diversion Header

Un altro elemento importante è il Diversion Header.

Il Diversion Header viene utilizzato per comunicare che una chiamata è stata deviata e può contenere informazioni relative alla chiamata prima del forwarding.

La documentazione ufficiale Grandstream specifica che il Diversion Header può essere utilizzato proprio nelle chiamate inoltrate verso un numero esterno.

Nel caso di un inoltro:

A → B → C

il SIP INVITE verso C può quindi contenere informazioni che descrivono la deviazione.

Un esempio concettuale potrebbe essere:

Diversion: <sip:B@provider>

mentre l’identità del chiamante potrebbe essere rappresentata separatamente attraverso:

From:
P-Asserted-Identity:
Remote-Party-ID:

Questi header non sono intercambiabili.

È quindi importante non considerare il Diversion Header come una semplice “sostituzione” del Caller ID.

7. From, P-Asserted-Identity e Remote-Party-ID

Quando si analizza un problema di Caller ID in VoIP, guardare soltanto il display del telefono non è sufficiente.

Bisogna analizzare il SIP. In particolare:

From

È uno degli elementi fondamentali dell’identità SIP della richiesta.

From: <sip:0255555@provider>

P-Asserted-Identity

Può essere utilizzato per comunicare l’identità del chiamante all’interno di una rete SIP che considera attendibile tale informazione.

P-Asserted-Identity: <sip:0255555@provider>

Remote-Party-ID

È un ulteriore meccanismo utilizzato da molti apparati e provider per il Caller ID.

Remote-Party-ID: <sip:0255555@provider>

Diversion

Descrive invece il fatto che la chiamata è stata deviata e può fornire informazioni sulla destinazione o sul percorso precedente.

Per questo motivo, durante un troubleshooting serio, è molto più utile catturare il traffico SIP e confrontare gli header del nuovo INVITE.

8. Un confronto particolarmente interessante: telefono IP contro UCM

Nel caso analizzato è stato effettuato un confronto utilizzando lo stesso trunk SIP.

Prima:

SIP trunk
    |
    v
UCM6304
    |
    v
numero esterno C

Il forwarding non produceva il risultato desiderato relativamente al Caller ID.

Successivamente lo stesso trunk è stato registrato direttamente su un telefono IP Grandstream, configurando il forwarding verso lo stesso numero C.

In questo caso il forwarding funzionava correttamente e il destinatario riceveva il Caller ID originale.

Questo confronto è importante perché elimina diverse possibili variabili:

• stesso provider;
• stesso trunk;
• stessa numerazione;
• stessa destinazione;
• stesso concetto di forwarding;
• apparato Grandstream anche nel secondo test.

La differenza sostanziale diventa quindi il modo in cui il dispositivo realizza il forwarding SIP.

Il confronto è stato inoltre documentato tramite catture SIP dei due scenari, proprio per poter analizzare la segnalazione anziché basarsi esclusivamente sul comportamento percepito dall’utente.

9. Il chiarimento decisivo: UCM630X e SIP 302

Nel corso del troubleshooting è stata posta una domanda molto precisa a Grandstream:

Gli UCM630X supportano SIP 302 Moved Temporarily per questo tipo di inoltro?

La risposta fornita dal supporto Grandstream è stata:

Questo chiarimento è importante perché consente di separare due questioni che inizialmente possono sembrare la stessa cosa:

• l’UCM630X può effettuare un forwarding verso un numero esterno;
• l’UCM630X può utilizzare SIP 302 per realizzare quel forwarding.

La prima funzionalità esiste. La seconda, secondo la risposta ufficiale ricevuta da Grandstream, non è supportata.

Questo significa che non è corretto continuare a cercare una combinazione di impostazioni che “attivi” SIP 302 sull’UCM630X.

Il problema non è una voce nascosta nel menu. È una limitazione della funzionalità.

10. Questo non significa che il Caller ID originale non possa essere mantenuto

La mancata disponibilità del SIP 302 non significa necessariamente che sia impossibile ottenere:

A → B → C

con:

Caller ID su C = A

Significa semplicemente che bisogna utilizzare un meccanismo differente.

L’UCM può infatti generare un nuovo INVITE verso il numero C e tentare di mantenere l’identità originale attraverso le proprie impostazioni di Caller ID e gli header SIP.

La documentazione Grandstream descrive esplicitamente funzioni relative a:

• Keep Original CID;
• Caller ID;
• PAI;
• PPI;
• Diversion;
• Caller ID Manipulation;
• Outbound Route CID.

Sono tutti elementi che possono influire sulla presentazione dell’identità nella nuova chiamata.

11. Il caso del Global Outbound CID

Durante l’analisi è emerso anche un parametro particolarmente interessante:

Global Outbound CID Number

Nel caso esaminato questo campo risultava vuoto.

È importante però non considerarlo automaticamente la soluzione.

La documentazione Grandstream indica il Global Outbound CID come uno degli elementi della gerarchia utilizzata dall’UCM per determinare il Caller ID in uscita.

Per questo motivo può essere utilizzato come parametro di test, ma non dovrebbe essere modificato “a caso”.

La metodologia corretta è:

1. documentare la configurazione originale;
2. modificare un parametro;
3. effettuare la chiamata;
4. verificare il Caller ID;
5. acquisire eventualmente il SIP;
6. confrontare il risultato con il test precedente.

In questo modo è possibile capire quale parametro abbia realmente effetto.

12. Una configurazione da verificare

Quando si cerca di ottenere il mantenimento del Caller ID originale senza SIP 302, le impostazioni da verificare sono principalmente queste.

SIP Trunk

• Keep Original CID → verificare che sia abilitato;
• Send Diversion Header → verificare che sia abilitato;
• DOD → verificare che non sostituisca il Caller ID desiderato;
• eventuali impostazioni PAI/PPI → verificare quale identità viene inviata.

SIP Settings

Verificare:

• Enable Diversion Header
• Send Deflection Diversion

La documentazione attuale Grandstream specifica che l’opzione relativa alla deflection può determinare l’inserimento del Diversion con motivo deflection quando una chiamata viene instradata verso un numero esterno.

Outbound Route

Verificare:

• Caller ID;
• eventuale Outbound Route CID;
• Caller ID Manipulation;
• eventuale DOD;
• trunk utilizzato.

La documentazione Grandstream conferma che l’Outbound Route CID può determinare il Caller ID utilizzato nel From dell’INVITE quando non intervengono valori con priorità superiore.

Global Outbound CID

Nel caso in esame:

Global Outbound CID Number = vuoto

Questo valore deve essere considerato come una delle variabili da testare, non come una soluzione certa.

13. Il test realmente utile: guardare il SIP

Il modo più efficace per verificare il comportamento non è chiedere semplicemente:

“Sul telefono C cosa compare?”

La domanda tecnica corretta è:

“Che cosa sta realmente inviando l’UCM nel nuovo INVITE verso il provider?”

Bisogna quindi confrontare almeno:

INVITE
From:
P-Asserted-Identity:
Remote-Party-ID:
Diversion:

tra:

Scenario funzionante

Telefono Grandstream
        ↓
     Forward
        ↓
     Provider
        ↓
        C

e:

Scenario UCM

UCM6304
   ↓
 Forward
   ↓
 Provider
   ↓
   C

Il confronto diretto dei due INVITE può evidenziare immediatamente quale informazione viene persa o sostituita.

14. Un dettaglio spesso sottovalutato: il provider

Anche quando l’UCM invia correttamente l’identità originale, non è detto che il provider la accetti.

Questo è un punto fondamentale.

Il provider può applicare policy che impediscono di presentare come Caller ID un numero che non appartiene alla numerazione autorizzata del cliente.

In altre parole:

UCM → Provider

non significa automaticamente:

Provider → C

con gli stessi header ricevuti dall’UCM.

Il provider può:

• accettare il Caller ID originale;
• sostituirlo con il numero del trunk;
• utilizzare PAI;
• utilizzare From;
• utilizzare una propria logica di validazione;
• rifiutare la chiamata;
• utilizzare il Diversion Header per determinare il trattamento della deviazione.

Per questo il fatto che il forwarding effettuato direttamente dal telefono funzioni correttamente costituisce una prova molto utile sul comportamento del trunk, ma non dimostra da solo quale specifico header sia determinante.

15. Un problema che può sembrare banale, ma non lo è

A prima vista la richiesta può sembrare semplicemente:

“Quando arriva una chiamata, girala a un cellulare.”

Dal punto di vista SIP, invece, la domanda corretta è:

Chi deve effettuare la nuova chiamata e quale identità deve essere presentata su quella nuova sessione?

Questa differenza cambia completamente il troubleshooting.

Con SIP 302:

Redirection
    ↓
nuova richiesta verso C

Con forwarding gestito dal PBX:

UCM
 ↓
nuovo INVITE
 ↓
Provider
 ↓
C

Nel secondo caso l’UCM deve decidere quale Caller ID utilizzare e il provider deve accettarlo.

16. Conclusioni

L’esperienza sul campo mostra ancora una volta quanto sia importante distinguere il comportamento percepito dall’utente dalla reale segnalazione SIP.

Un:

“il centralino inoltra la chiamata”

non è una descrizione tecnica sufficiente.

Bisogna capire se il sistema:

• effettua una redirection SIP;
• mantiene la sessione;
• crea una nuova chiamata;
• modifica il Caller ID;
• utilizza Diversion;
• utilizza PAI/PPI/RPID;
• oppure lascia al dispositivo originatore il compito di effettuare la nuova richiesta.

Nel caso degli UCM630X, la verifica effettuata con Grandstream ha portato a una risposta precisa:

Questo chiude definitivamente la ricerca di una presunta impostazione nascosta per abilitare il 302.

Resta invece tecnicamente interessante la possibilità di ottenere lo stesso risultato funzionale attraverso il normale meccanismo di forwarding dell’UCM, lavorando sulla conservazione del Caller ID originale e sulla corretta costruzione del nuovo INVITE.

Ed è proprio qui che un’analisi SIP con Wireshark diventa molto più utile di una lunga sequenza di prove “a tentativi”: non bisogna limitarsi a verificare se il telefono squilla.