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 BW bwcli
Requisiti
- Possibilità di utilizzare AS bwcli e un utente admin
- Essere in grado di rivedere gli AS XSLogs
Eseguire un ottenere per controllare i valori correnti di entrambi i parametri.
Per impostazione predefinita abilitaRitardoRiavvioRapido è disabilitato (false) e il valore predefinito di ritardoQuickReInviteMillisecondi è 1000 (1000 ms o 1 secondo).
Parte dell'output del comando get viene omessa per migliorare la leggibilità.
AS_CLI/Interface/SIP> get
...
enableDelayQuickReInvite = false
delayQuickReInviteMilliseconds = 1000
...
Configurare il parametro delayQuickReInviteMilliseconds.
Accettate il valore di default o utilizzate quello più adatto al vostro ambiente.
Utilizzare il valore più basso possibile. Iniziare con il valore di 100 ms e aumentarlo abbastanza da consentire la risoluzione del problema.
AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100
...Done
Dopo aver configurato il valore di delayQuickReInviteMilliseconds, 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, il ritardo deve essere almeno 100 ms o superiore.
100 ms sono in genere sufficienti per evitare che l'ACK e la richiesta di nuovo siano ricevuti in modo non corretto.
Il valore è probabilmente più alto, in base all'ambiente di rete e alle entità SIP coinvolte nel percorso del segnale.
Risoluzione dei problemi
Se il dispositivo risponde ancora con un codice di errore 500 e l'ACK e il RE-INVITE sono stati consegnati nell'ordine corretto, sono necessarie ulteriori indagini sul dispositivo.
Utilizzare gli XSLogs sull'AS per verificare che l'AS abbia aggiunto il ritardo come configurato.
Utilizzare l'acquisizione dei pacchetti o i registri del dispositivo per verificare 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 INVITE subito dopo l'invio di un ACK.
Non funziona nel caso in cui il SA riceva un ACK e ciò induca il SA a inviare un nuovo INVITE.
Feedback