Introduzione
In questo documento viene descritto come configurare enableDelayQuickReinvita per impedire al server applicazioni (AS) di inviare un nuovo invito troppo rapidamente dopo un ACK.
Prerequisiti
- Conoscenze base del protocollo SIP (Session Initiation Protocol)
- Conoscenze base di AS
- Conoscenze base di BroadWorks bwcli
Requisiti
- Possibilità di utilizzare AS bwcli e un utente admin
- Essere in grado di rivedere gli AS XSLogs
Componenti usati
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
In alcuni scenari di chiamata, l'AS deve avviare una riconnessione e a tale scopo invia un nuovo invito a entrambe le estremità. Questo si verifica quando l'AS deve avviare una riconnessione dopo che è stata stabilita una sessione, ad esempio per le chiamate ai Call Center, ai gruppi di ricerca o a quelli che implicano la funzione Click to Dial o Registrazione di chiamata.
Quando il SA deve inviare il comando re-INVITE dopo l'invio dell'ACK nella stessa finestra di dialogo, normalmente il SA invia il comando re-INVITE nello stesso momento dell'ACK e ciò può causare la ricezione non corretta dell'ACK e del comando re-INVITE da parte del dispositivo remoto.
In questo caso, il dispositivo che riceve il comando re-INVITE prima dell'ACK in sospeso può rifiutare il comando re-INVITE, in genere con un codice di errore 500 (che può tuttavia variare in base all'implementazione del dispositivo remoto).
Configurazione
Per configurare questa funzione, sono disponibili due parametri, entrambi posizionati nella bwcli in corrispondenza di AS_CLI/Interface/SIP>.
- enableDelayQuickReInvite è lo switch principale per attivare o disattivare la funzionalità. I valori accettati sono true e false.
- delayQuickReInviteMilliseconds è il valore in millisecondi (ms) del ritardo aggiunto dopo l'ACK. L'intervallo di valori è compreso tra 100 ms e 10000 ms.
Per configurare questa funzione, aprire AS bwcli, accedere come utente Admin, quindi selezionare AS_CLI/Interface/SIP>:
AS_CLI> cd /Interface/SIP
AS_CLI/Interface/SIP>
Eseguire prima un comando get per controllare i valori correnti di entrambi i parametri. Per impostazione predefinita, enableDelayQuickReInvite è disabilitato (false) e il valore predefinito di delayQuickReInviteMilliseconds è 1000 (1000 ms o 1 secondo).
Parte dell'output del comando get è omessa per migliorare la leggibilità.
AS_CLI/Interface/SIP> get
...
enableDelayQuickReInvite = false
delayQuickReInviteMilliseconds = 1000
...
Configurare quindi il parametro delayQuickReInviteMilliseconds. È possibile accettare il valore predefinito o utilizzare quello più adatto al proprio ambiente. Si consiglia di utilizzare il valore più basso possibile, quindi si consiglia di iniziare con il valore di 100ms e di aumentarlo nel caso in cui non sia sufficiente per consentire la risoluzione del problema.
AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100
...Done
Dopo aver configurato il valore di delayQuickReInviteMilliseconds, è possibile abilitare enableDelayQuickReInvite.
AS_CLI/Interface/SIP> set enableDelayQuickReInvite true
...Done
Verifica
Al termine della configurazione, eseguire di nuovo lo scenario di chiamata per verificare che l'ASA aggiunga il ritardo tra l'ACK e il re-INVITE. Ad esempio, se l'appliance ASA è stata configurata per aggiungere 100 ms, è possibile prevedere un ritardo di almeno 100 ms, ma potrebbe essere superiore di alcuni ms.
100 ms sono in genere sufficienti per impedire la ricezione di ACK e RE-INVITE in modo non corretto, ma il valore potrebbe essere superiore, in base all'ambiente di rete e alle entità SIP coinvolte nel percorso di segnalazione.
Risoluzione dei problemi
Se il dispositivo continua a rispondere con un codice di errore 500 e l'ACK e il RE-INVITE sono stati consegnati nell'ordine corretto, è necessario eseguire ulteriori indagini sul dispositivo.
Utilizzare gli XSLog sull'AS per verificare che l'AS abbia aggiunto il ritardo come configurato e utilizzare un'acquisizione pacchetti o i registri del dispositivo per assicurarsi che il ritardo sia stato sufficiente per il recapito dei messaggi nell'ordine corretto.
Si noti che questa procedura funziona solo quando l'AS invia un nuovo INVITO subito dopo l'invio di un ACK, ma non nel caso in cui l'AS riceva un ACK e ciò induca l'AS a inviare un nuovo INVITO.
Feedback