Einleitung
In diesem Dokument wird beschrieben, wie enableDelayQuickReinvite konfiguriert wird, um zu verhindern, dass der Anwendungsserver (AS) nach einer ACK zu schnell eine Re-INVITE sendet.
Voraussetzungen
- Grundlegendes SIP-Wissen (Session Initiation Protocol)
- Grundlegendes AS-Wissen
- Grundlegende Kenntnisse über BW bwcli
Anforderungen
- die AS bwcli und einen Administrator-Benutzer verwenden können.
- Überprüfen der AS XSLogs
Ausführen eines erhalten , um die aktuellen Werte beider Parameter zu überprüfen.
Standardmäßig enableDelayQuickReInvite ist deaktiviert (false), und der Standardwert von VerzögerungQuickReInviteMilliseconds ist 1000 (1000 ms oder 1 Sekunde).
Ein Teil der Ausgabe des Befehls get wird weggelassen, um die Lesbarkeit zu verbessern.
AS_CLI/Interface/SIP> get
...
enableDelayQuickReInvite = false
delayQuickReInviteMilliseconds = 1000
...
Konfigurieren Sie den delayQuickReInviteMilliseconds-Parameter.
Akzeptieren Sie den Standardwert, oder verwenden Sie den für Ihre Umgebung am besten geeigneten.
Verwenden Sie den niedrigstmöglichen Wert. Beginnen Sie mit einem Wert von 100 ms, und erhöhen Sie diesen so weit, dass das Problem gelöst werden kann.
AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100
...Done
Aktivieren Sie enableDelayQuickReInviteMilliseconds, nachdem der Wert für delayQuickReInviteMilliseconds konfiguriert wurde.
AS_CLI/Interface/SIP> set enableDelayQuickReInvite true
...Done
Überprüfung
Wenn die Konfiguration abgeschlossen ist, führen Sie das Anrufszenario erneut aus, um sicherzustellen, dass das AS die Verzögerung zwischen ACK und Re-INVITE hinzufügt.
Wenn das AS beispielsweise so konfiguriert wurde, dass 100 ms hinzugefügt werden, sollte die Verzögerung mindestens 100 ms oder etwas höher sein.
100 ms sind normalerweise ausreichend, um zu verhindern, dass ACK und Re-INVITE außer Betrieb genommen werden.
Je nach Netzwerkumgebung und den beteiligten SIP-Einheiten im Signalpfad ist der Wert möglicherweise höher.
Fehlerbehebung
Wenn das Gerät weiterhin mit einem Fehlercode von 500 antwortet und ACK und Re-INVITE in der richtigen Reihenfolge zugestellt wurden, ist eine weitere Untersuchung auf dem Gerät erforderlich.
Verwenden Sie die XSLogs auf dem AS, um zu überprüfen, ob das AS die Verzögerung wie konfiguriert hinzugefügt hat.
Verwenden Sie eine Paketerfassung oder die Geräteprotokolle, um sicherzustellen, dass die Verzögerung ausreicht, damit die Nachrichten in der richtigen Reihenfolge zugestellt werden.
Beachten Sie, dass dies nur funktioniert, wenn der AS eine Re-INVITE direkt nach dem Senden einer ACK sendet.
Dies ist nicht möglich, wenn das AS eine ACK empfängt und das AS veranlasst, eine Re-INVITE-Nachricht zu senden.
Feedback