- Startseite
- /
- Artikel
Danke für Ihr Feedback.
Bereitstellungsparameter für Telefone in Cisco BroadWorks
In diesem Artikel
Feedback?Dieser Hilfeartikel bezieht sich auf Cisco Telefone, die in Cisco BroadWorks registriert sind. Die Informationen auf dieser Seite umfassen die Bereitstellungsparameter und ihre Syntax.
Typen von Bereitstellungsparametern
In diesem Abschnitt werden die Bereitstellungsparameter grob nach Funktion sortiert beschrieben.
Allgemeine Parameter
Die allgemeinen Parameter GPP_* () werden als freie Zeichenfolgen verwendet, die registriert werden, wenn das Telefon für die Interaktion mit einer bestimmten Bereitstellungsserverlösung konfiguriert wird. Die GPP_*-Parameter sind standardmäßig leer. Sie können so konfiguriert werden, dass sie verschiedene Werte enthalten, einschließlich der folgenden:
-
Verschlüsselungsschlüssel
-
URLs
-
Statusinformationen zur mehrstufigen Bereitstellung.
-
Vorlagen für Post-Anfragen
-
Zuordnungen von Parameternamensaliasen
-
Teilweise Zeichenfolgenwerte, die schließlich zu vollständigen Parameterwerten kombiniert werden.
Die GPP_*-Parameter stehen für eine Makroerweiterung innerhalb anderer Bereitstellungsparameter zur Verfügung. Zu diesem Zweck sind Makronamen mit einem Großbuchstaben (A bis P) ausreichend, um den Inhalt von GPP_A bis GPP_P zu identifizieren. Außerdem identifizieren die Makronamen mit zwei Großbuchstaben SA bis SD GPP_SA bis GPP_SD als Sonderfall, wenn sie als Argumente der folgenden URL-Optionen verwendet werden:
key, uid und pwd
Diese Parameter können als Variablen in Bereitstellungs- und Upgrade-Regeln verwendet werden. Sie werden referenziert, indem dem Variablennamen das Zeichen „$“ vorangestellt wird, z. B. $GPP_A.
Parameter aktivieren
Die Parameter „Provision_Enable“ und „Upgrade_Enable“ steuern alle Profilresynchronisierungs- und Firmware-Upgrade-Vorgänge. Diese Parameter steuern Resynchronisierungen und Upgrades unabhängig voneinander. Diese Parameter steuern auch die Resynchronisierungs- und Upgrade-URL-Befehle, die über den Verwaltungswebserver ausgegeben werden. Beide Parameter sind standardmäßig auf Ja festgelegt.
Der Resync_From_SIP-Parameter steuert Anforderungen für Resynchronisierungsvorgänge. Ein SIP NOTIFY-Ereignis wird vom Proxyserver des Serviceanbieters an das Telefon gesendet. Wenn diese Option aktiviert ist, kann der Proxy eine erneute Synchronisierung anfordern. Dazu sendet der Proxy eine SIP NOTIFY-Nachricht, die das Ereignis enthält: Resynchronisierungskopfzeile mit dem Gerät.
Das Gerät fordert die Anforderung mit einer 401-Antwort an (Autorisierung für verwendete Anmeldeinformationen abgelehnt). Das Gerät erwartet eine authentifizierte nachfolgende Anforderung, bevor es die Resynchronisierungsanforderung vom Proxy akzeptiert. Das Event: reboot_now und Event: restart_now Header führen kalte bzw. warme Neustarts durch, die ebenfalls in Frage gestellt werden.
Die beiden verbleibenden Funktionen sind Resync_On_Reset und Resync_After_Upgrade_Attempt. Diese Parameter bestimmen, ob das Gerät nach dem Neustart der Hochladesoftware und nach jedem Upgrade-Versuch eine Resynchronisierung durchführt.
Wenn das Resync_On_Reset aktiviert ist, führt das Gerät eine zufällige Verzögerung ein, die der Startsequenz folgt, bevor das Zurücksetzen durchgeführt wird. Die Verzögerung ist eine zufällige Zeit bis zu dem Wert, den die Resync_Random_-Verzögerung (in Sekunden) angibt. In einem Pool von Telefonen, die gleichzeitig eingeschaltet werden, werden durch diese Verzögerung die Startzeiten der Resynchronisierungsanforderungen der einzelnen Geräte verteilt. Diese Funktion kann bei einer großen lokalen Bereitstellung nützlich sein, wenn ein Stromausfall auftritt.
Auslöser
Das Telefon ermöglicht Ihnen die Resynchronisierung in bestimmten Intervallen oder zu einem bestimmten Zeitpunkt.
In bestimmten Intervallen resynchronisieren
Das Telefon ist so konzipiert, dass es regelmäßig eine Resynchronisierung mit dem Bereitstellungsserver durchführt. Das Intervall für die Resynchronisierung wird in Resync_Periodisch (Sekunden) konfiguriert. Wenn dieser Wert leer gelassen wird, führt das Gerät keine regelmäßigen Resynchronisierungen durch.
Die erneute Synchronisierung erfolgt normalerweise, wenn die Sprachleitungen inaktiv sind. Wenn eine Sprachleitung aktiv ist, wenn eine Resynchronisierung fällig ist, verzögert das Telefon die Resynchronisierung, bis die Leitung wieder inaktiv ist. Eine Resynchronisierung kann dazu führen, dass sich die Konfigurationsparameterwerte ändern.
Eine Resynchronisierung kann fehlschlagen, weil das Telefon kein Profil vom Server abrufen kann, die heruntergeladene Datei beschädigt ist oder ein interner Fehler aufgetreten ist. Das Gerät versucht, die Resynchronisierung nach einer in „Resync_Error_Retry_-Verzögerung“ angegebenen Zeit (in Sekunden) erneut durchzuführen. Wenn die Resync_Error_Retry_Verzögerung auf 0 festgelegt ist, versucht das Gerät nach einer fehlgeschlagenen Resynchronisierung nicht erneut, eine erneute Synchronisierung durchzuführen.
Wenn ein Upgrade fehlschlägt, wird nach Upgrade_Error_Retry_-Verzögerungssekunden ein erneuter Versuch durchgeführt.
Es sind zwei konfigurierbare Parameter verfügbar, um eine Resynchronisierung bedingt auszulösen: Resync_Trigger_1 und Resync_Trigger_2. Jeder Parameter kann mit einem bedingten Ausdruck programmiert werden, der einer Makroerweiterung unterliegt. Wenn das Intervall für die Resynchronisierung abläuft (Zeit für die nächste Resynchronisierung), verhindern die Auslöser (sofern festgelegt) die Resynchronisierung, es sei denn, mindestens ein Auslöser wird mit „true“ bewertet.
Die folgende Beispielbedingung löst eine Resynchronisierung aus. Im Beispiel ist der letzte Versuch des Telefon-Upgrades mehr als 5 Minuten (300 Sekunden) und mindestens 10 Minuten (600 Sekunden) seit dem letzten Resynchronisierungsversuch vergangen.
$UPGTMR gt 300 und $PRVTMR ge 600Resynchronisierung zu einem bestimmten Zeitpunkt
Mit dem Resync_At-Parameter kann sich das Telefon zu einem bestimmten Zeitpunkt erneut synchronisieren. Dieser Parameter verwendet das 24-Stunden-Format (hhmm), um die Zeit festzulegen.
Der Parameter „Resync_At_Random_Delay“ ermöglicht es dem Telefon, sich mit einer nicht angegebenen Verzögerung erneut zu synchronisieren. Dieser Parameter verwendet ein positives Ganzzahl-Format, um die Zeit anzugeben.
Das Überfluten des Servers mit Resynchronisierungsanforderungen von mehreren Telefonen, die auf die gleichzeitige Resynchronisierung eingestellt sind, sollte vermieden werden. Dazu löst das Telefon die Resynchronisierung bis zu 10 Minuten nach der angegebenen Zeit aus.
Wenn Sie die Resynchronisierungszeit beispielsweise auf 1000 (10:00 Uhr) festlegen, löst das Telefon die Resynchronisierung jederzeit zwischen 10:00 Uhr und 10:10 Uhr aus.
Standardmäßig ist diese Funktion deaktiviert. Wenn der Parameter Resync_At bereitgestellt wird, wird der Parameter Resync_Periodic ignoriert.
Konfigurierbare Zeitpläne
Mithilfe der folgenden Bereitstellungsparameter können Sie Zeitpläne für regelmäßige Resynchronisierungen konfigurieren und die Wiederholungsintervalle für Resynchronisierungs- und Upgrade-Fehler angeben:
-
Resync_periodisch
-
Resync_Error_Retry_-Verzögerung
-
Upgrade_Error_Retry_-Verzögerung
Jeder Parameter akzeptiert einen einzelnen Verzögerungswert (in Sekunden). Die neue erweiterte Syntax ermöglicht eine durch Komma getrennte Liste von aufeinanderfolgenden Verzögerungselementen. Das letzte Element der Sequenz wird implizit für immer wiederholt.
Optional können Sie ein Pluszeichen verwenden, um einen anderen numerischen Wert anzugeben, der eine zusätzliche zufällige Verzögerung festlegt.
Beispiel 1
In diesem Beispiel erfolgt die Resynchronisierung des Telefons in regelmäßigen Abständen alle 2 Stunden. Wenn ein Resynchronisierungsfehler auftritt, wiederholt das Gerät Versuche in den folgenden Intervallen: 30 Minuten, 1 Stunde, 2 Stunden, 4 Stunden. Das Gerät führt weitere Versuche in 4-Stunden-Intervallen durch, bis die Resynchronisierung erfolgreich ist.
Resync_Periodisch=7200 Resync_Error_Retry_Verzögerung=1800,3600,7200,14400 Beispiel 2
In diesem Beispiel erfolgt die Resynchronisierung des Geräts in regelmäßigen Abständen jede Stunde (plus eine zusätzliche zufällige Verzögerung von bis zu 10 Minuten). Bei einem Resynchronisierungsfehler werden die Versuche des Geräts in den folgenden Intervallen wiederholt: 30 Minuten (plus bis zu 5 Minuten). 1 Stunde (plus bis zu 10 Minuten), 2 Stunden (plus bis zu 15 Minuten). Das Gerät versucht es weiterhin in 2-Stunden-Intervallen (plus bis zu 15 Minuten), bis die Resynchronisierung erfolgreich ist.
Resync_Periodisch=3600+600 Resync_Error_Retry_Verzögerung=1800+300,3600+600,7200+900 Beispiel 3
Wenn in diesem Beispiel ein Remote-Upgrade-Versuch fehlschlägt, versucht das Gerät das Upgrade nach 30 Minuten, dann erneut nach einer weiteren Stunde und dann nach zwei Stunden. Wenn das Upgrade weiterhin fehlschlägt, versucht das Gerät alle vier bis fünf Stunden erneut, bis das Upgrade erfolgreich war.
Upgrade_Error_Retry_Verzögerung = 1800,3600,7200,14400+3600 Profilregeln
Das Telefon stellt mehrere Remote-Konfigurationsprofilparameter bereit (Profile_Rule*). Somit kann jeder Resynchronisierungsvorgang mehrere Dateien abrufen, die von verschiedenen Servern verwaltet werden.
Im einfachsten Szenario erfolgt die Resynchronisierung des Geräts in regelmäßigen Abständen mit einem einzelnen Profil auf einem zentralen Server, der alle relevanten internen Parameter aktualisiert. Alternativ kann das Profil auf verschiedene Dateien aufgeteilt werden. Eine Datei gilt für alle Telefone in einer Bereitstellung. Für jedes Konto wird eine separate, eindeutige Datei bereitgestellt. Verschlüsselungsschlüssel und Zertifikatinformationen können von einem weiteren Profil bereitgestellt werden, das auf einem separaten Server gespeichert ist.
Wenn eine Resynchronisierung fällig ist, wertet das Telefon die vier Profile_Rule*-Parameter nacheinander aus:
-
Profile_Regel
-
rofile_Rule_B
-
rofile_Rule_Ü
-
rofile_Rule_D
Jede Auswertung kann dazu führen, dass ein Profil von einem Remote-Bereitstellungsserver abgerufen wird und einige interne Parameter möglicherweise aktualisiert werden. Wenn eine Auswertung fehlschlägt, wird die Resynchronisierungssequenz unterbrochen und von dem im Parameter Resync_Error_Retry_Delay (Sekunden) angegebenen Beginn erneut versucht. Wenn alle Auswertungen erfolgreich sind, wartet das Gerät auf die im Parameter Resync_Periodic angegebene Sekunde und führt dann eine weitere Resynchronisierung durch.
Der Inhalt jedes Profile_Rule*-Parameters besteht aus einer Reihe von Alternativen. Die Alternativen werden durch das Zeichen | (pipe) getrennt. Jede Alternative besteht aus einem Bedingungsausdruck, einem Zuweisungsausdruck, einer Profil-URL und allen zugehörigen URL-Optionen. Alle diese Komponenten sind in jeder Alternative optional. Im Folgenden sind die gültigen Kombinationen und die Reihenfolge aufgeführt, in der sie, falls vorhanden, angezeigt werden müssen:
[ conditional-expr ] [ assignment-expr ] [[ options ] URL ] Innerhalb jedes Profile_Rule*-Parameters müssen alle Alternativen mit Ausnahme der letzten einen Bedingungsausdruck bereitstellen. Dieser Ausdruck wird ausgewertet und wie folgt verarbeitet:
-
Bedingungen werden von links nach rechts ausgewertet, bis eine gefunden wird, die als wahr ausgewertet wird (oder bis eine Alternative ohne Bedingungsausdruck gefunden wird).
-
Alle zugehörigen Zuweisungsausdrücke werden, sofern vorhanden, ausgewertet.
-
Wenn eine URL als Teil dieser Alternative angegeben wird, wird versucht, das Profil herunterzuladen, das sich unter der angegebenen URL befindet. Das System versucht, die internen Parameter entsprechend zu aktualisieren.
Wenn alle Alternativen über Bedingungsausdrücke verfügen und keine Auswertung „true“ ergibt (oder wenn die gesamte Profilregel leer ist), wird der gesamte Profile_Rule*-Parameter übersprungen. Der nächste Profilregelparameter in der Sequenz wird ausgewertet.
Beispiel 1
Dieses Beispiel führt eine bedingungslose Resynchronisierung mit dem Profil unter der angegebenen URL durch und führt eine HTTP GET-Anforderung an den Remote-Bereitstellungsserver durch:
http://remote.server.com/cisco/$MA.cfg
Beispiel 2
In diesem Beispiel erfolgt die Resynchronisierung des Geräts mit zwei verschiedenen URLs, je nach Registrierungsstatus von Leitung 1. Bei verlorener Registrierung führt das Gerät einen HTTP POST für ein CGI-Skript durch. Das Gerät sendet den Inhalt des makroerweiterten GPP_A, der zusätzliche Informationen zum Gerätestatus enthalten kann:
($PRVTMR ge 600)? http://p.tel.com/has-reg.cfg | [--posten a] http://p.tel.com/lost-reg? Beispiel 3
In diesem Beispiel erfolgt die Resynchronisierung des Geräts mit demselben Server. Das Gerät stellt zusätzliche Informationen bereit, wenn kein Zertifikat auf der Einheit installiert ist (für ältere Einheiten vor 2.0):
(„$CCERT“ eq „installiert“)? https://p.tel.com/config? | https://p.tel.com/config?cisco$MAU Beispiel 4
In diesem Beispiel ist Leitung 1 deaktiviert, bis GPP_A über die erste URL auf den Wert „Provisioned“ gesetzt wird. Anschließend erfolgt die Resynchronisierung mit der zweiten URL:
(„$A“ oder „Bereitgestellt“)? (Line_Enable_1_ = „Nein“;)! https://p.tel.com/init-prov | https://p.tel.com/configs Beispiel 5
In diesem Beispiel wird angenommen, dass das Profil, das der Server zurückgibt, XML-Element-Tags enthält. Diese Tags müssen mithilfe der in GPP_B gespeicherten Aliase-Zuordnung wieder den entsprechenden Parameternamen zugeordnet werden:
[--alias b] https://p.tel.com/account/$PN$MA.xml Eine Resynchronisierung gilt normalerweise als nicht erfolgreich, wenn ein angefordertes Profil vom Server nicht empfangen wird. Der Parameter Resync_Fails_On_FNF kann dieses Standardverhalten überschreiben. Wenn Resync_Fails_On_FNF auf „Nein“ festgelegt ist, akzeptiert das Gerät eine „Datei nicht gefunden“-Antwort vom Server als erfolgreiche Resynchronisierung. Der Standardwert für Resync_Fails_On_FNF ist „Yes“ (Ja).
Upgrade-Regel
Mit der Upgrade-Regel wird das Gerät angewiesen, eine neue Software zu aktivieren und ggf. von wo aus die Software abgerufen werden kann. Wenn sich die Software bereits auf dem Gerät befindet, wird nicht versucht, die Software abzurufen. Die Gültigkeit des Software-Standorts spielt also keine Rolle, wenn sich die gewünschte Software in der inaktiven Partition befindet.
Die Upgrade_Regel gibt eine Firmware-Version an, die, wenn sie sich von der aktuellen Version unterscheidet, heruntergeladen und angewendet wird, sofern sie nicht durch einen Bedingungsausdruck eingeschränkt ist oder Upgrade_Aktivieren auf Nein gesetzt ist.
Das Telefon stellt einen konfigurierbaren Remote-Upgrade-Parameter bereit: Upgrade_Rule. Dieser Parameter akzeptiert eine ähnliche Syntax wie die Profilregelparameter. URL-Optionen werden für Upgrades nicht unterstützt, aber Bedingungsausdrücke und Zuweisungsausdrücke können verwendet werden. Wenn Bedingungsausdrücke verwendet werden, können für den Parameter mehrere durch das | Zeichen getrennte Alternativen angegeben werden. Die Syntax für jede Alternative lautet wie folgt:
[ conditional-expr ] [ assignment-expr ] URL Wie bei den Profile_Rule*-Parametern wertet der Upgrade_Rule-Parameter jede Alternative aus, bis ein Bedingungsausdruck erfüllt ist oder eine Alternative keinen Bedingungsausdruck aufweist. Der zugehörige Zuweisungsausdruck wird ausgewertet, falls angegeben. Anschließend wird versucht, ein Upgrade auf die angegebene URL durchzuführen.
Wenn die Upgrade_Regel eine URL ohne Bedingungsausdruck enthält, wird das Gerät auf das in der URL angegebene Firmware-Image aktualisiert. Nach der Makroerweiterung und Auswertung der Regel versucht das Gerät erst dann erneut, ein Upgrade durchzuführen, wenn die Regel oder die effektive Kombination aus scheme + server + port + filepath geändert wurde.
Um zu versuchen, ein Firmware-Upgrade durchzuführen, deaktiviert das Gerät die Audiofunktion zu Beginn des Vorgangs und wird am Ende des Vorgangs neu gestartet. Das Gerät startet nur dann automatisch ein Upgrade, das durch den Inhalt von Upgrade_Rule gesteuert wird, wenn alle Sprachleitungen derzeit inaktiv sind.
Beispiel:
https://10.73.10.223/firmware/PHONEOS-8875.1-0-1-0001-1.loadsIn diesem Beispiel aktualisiert die Upgrade_Regel die Firmware auf das Image, das unter der angegebenen URL gespeichert ist.
Ein weiteres Beispiel:
(„$F“ oder „Beta-Kunde“)? http://p.tel.com/firmware/PHONEOS-8875.1-0-1-0001-1.loads | http://p.tel.com/firmware/PHONEOS-8875.1-0-1-0001-1.loads In diesem Beispiel wird das Gerät angewiesen, basierend auf dem Inhalt des allgemeinen Parameters GPP_F eines von zwei Bildern zu laden.
Bereitstellungsparameter
Die Bereitstellungsparameter finden Sie auf der Registerkarte Bereitstellung auf der Telefon-Webseite.
Konfigurationsprofilparameter
In der folgenden Tabelle werden die Funktionen und die Verwendung der einzelnen Parameter im Abschnitt Konfigurationsprofilparameter auf der Registerkarte Bereitstellung definiert.
|
Parametername |
Beschreibung und Standardwert |
|---|---|
|
Bereitstellung aktivieren |
Steuert alle Resynchronisierungsaktionen unabhängig von Firmware-Upgrade-Aktionen. Legen Sie Ja fest, um die Remotebereitstellung zu aktivieren. Der Standardwert ist „Ja“. |
|
Erneute Synchronisierung Beim Zurücksetzen |
Nach jedem Neustart wird eine Resynchronisierung ausgelöst, mit Ausnahme von Neustarts, die durch Parameteraktualisierungen und Firmware-Upgrades verursacht werden. Der Standardwert ist „Ja“. |
|
Zufällige Verzögerung bei der Resynchronisierung |
Eine zufällige Verzögerung nach der Startsequenz vor dem Zurücksetzen, die in Sekunden angegeben ist. In einem Pool von IP-Telefoniegeräten, die planmäßig gleichzeitig eingeschaltet werden, werden die Zeiten verteilt, zu denen jede Einheit eine Resynchronisierungsanforderung an den Bereitstellungsserver sendet. Diese Funktion kann bei einer großen lokalen Bereitstellung nützlich sein, wenn ein Stromausfall auftritt. Der Wert für dieses Feld muss eine Ganzzahl zwischen 0 und 65535 sein. Der Standardwert ist 2. |
|
Erneute Synchronisierung um (HHmm) |
Die Zeit (HHmm), in der sich das Gerät mit dem Bereitstellungsserver neu synchronisiert. Der Wert für dieses Feld muss eine vierstellige Zahl im Bereich von 0000 bis 2400 sein, um die Zeit im Format HHmm anzugeben. Beispielsweise steht 0959 für 09:59. Der Standardwert ist leer. Wenn der Wert ungültig ist, wird der Parameter ignoriert. Wenn dieser Parameter auf einen gültigen Wert festgelegt ist, wird der Parameter „Periodische Neusynchronisierung“ ignoriert. |
|
Erneute Synchronisierung mit zufälliger Verzögerung |
Verhindert eine Überlastung des Bereitstellungsservers, wenn eine große Anzahl von Geräten gleichzeitig eingeschaltet wird. Um zu vermeiden, dass Resynchronisierungsanforderungen von mehreren Telefonen an den Server überflutet werden, führt das Telefon die Resynchronisierung im Bereich zwischen den Stunden und Minuten sowie den Stunden und Minuten plus der zufälligen Verzögerung durch (hhmm, hhmm+random_delay). Beispiel: Wenn die zufällige Verzögerung = (Erneute Synchronisierung bei zufälliger Verzögerung + 30)/60 Minuten ist, wird der Eingabewert in Sekunden in Minuten umgewandelt und auf die nächste Minute aufgerundet, um das endgültige random_delay Intervall zu berechnen. Der gültige Wert liegt zwischen 600 und 65535. Wenn der Wert kleiner als 600 ist, liegt die zufällige interne Verzögerung zwischen 0 und 600. Der Standardwert ist 600 Sekunden (10 Minuten). |
|
Periodische Resynchronisierung |
Das Zeitintervall zwischen regelmäßigen Resynchronisierungen mit dem Bereitstellungsserver. Der zugehörige Timer für die Resynchronisierung ist erst nach der ersten erfolgreichen Synchronisierung mit dem Server aktiv. Die gültigen Formate sind wie folgt:
Legen Sie diesen Parameter auf Null fest, um die periodische Resynchronisierung zu deaktivieren. Der Standardwert ist 3600 Sekunden. |
|
Wiederholungsverzögerung für Resynchronisierungsfehler |
Wenn eine erneute Synchronisierung fehlschlägt, weil das IP-Telefoniegerät kein Profil vom Server abrufen konnte, die heruntergeladene Datei beschädigt ist oder ein interner Fehler auftritt, versucht das Gerät, die erneute Synchronisierung nach der in Sekunden festgelegten Zeitdauer durchzuführen. Die gültigen Formate sind wie folgt:
Wenn die Verzögerung auf 0 festgelegt ist, versucht das Gerät nicht, sich nach einem fehlgeschlagenen Resynchronisierungsversuch erneut zu synchronisieren. |
|
Erzwungene Resynchronisierungsverzögerung |
Maximale Verzögerung (in Sekunden), die das Telefon wartet, bevor eine erneute Synchronisierung durchgeführt wird. Das Gerät führt keine Resynchronisierung durch, während eine der Telefonleitungen aktiv ist. Da eine Resynchronisierung mehrere Sekunden dauern kann, sollte das Gerät vor der Resynchronisierung längere Zeit inaktiv gewesen sein. Auf diese Weise können Benutzer Anrufe nacheinander tätigen, ohne unterbrochen zu werden. Das Gerät verfügt über einen Timer, der rückwärts läuft, wenn alle Leitungen inaktiv sind. Dieser Parameter ist der Anfangswert des Zählers. Resynchronisierungsereignisse werden verzögert, bis dieser Zähler auf Null reduziert wird. Der gültige Wert liegt zwischen 0 und 65535. Der Standardwert ist 14.400 Sekunden. |
|
Erneute Synchronisierung von SIP |
Ermöglicht, dass eine Resynchronisierung über eine SIP NOTIFY-Nachricht ausgelöst wird. Der Standardwert ist „Ja“. |
|
Erneute Synchronisierung nach dem Upgrade-Versuch |
Aktiviert oder deaktiviert den Resynchronisierungsvorgang nach einem Upgrade. Wenn „Ja“ ausgewählt ist, wird die Synchronisierung ausgelöst. Der Standardwert ist „Ja“. |
|
Resynchronisierungsauslöser 1, Resynchronisierungsauslöser 2 |
Konfigurierbare Bedingungen für den Resynchronisierungsauslöser. Eine Resynchronisierung wird ausgelöst, wenn die logische Gleichung in diesen Parametern TRUE ergibt. Der Standardwert ist (leer). |
|
Resynchronisierung schlägt bei FNF fehl |
Eine Resynchronisierung gilt als nicht erfolgreich, wenn ein angefordertes Profil vom Server nicht empfangen wird. Dies kann durch diesen Parameter überschrieben werden. Wenn die Einstellung auf Nein festgelegt ist, akzeptiert das Gerät die Antwort Der Standardwert ist „Ja“. |
|
Profilregel Profilregel B Profilregel C Profilregel D |
Jede Profilregel informiert das Telefon über eine Quelle, von der aus ein Profil (Konfigurationsdatei) abgerufen werden kann. Bei jeder erneuten Synchronisierung wendet das Telefon alle Profile nacheinander an. Standard: Wenn Sie die AES-256-CBC-Verschlüsselung auf die Konfigurationsdateien anwenden, geben Sie den Verschlüsselungsschlüssel mit dem Schlüsselwort Sie können den Verschlüsselungscode optional in Anführungszeichen (") einschließen. |
|
Zu verwendende DHCP-Option |
Durch Komma getrennte DHCP-Optionen, die zum Abrufen von Firmware und Profilen verwendet werden. Der Standardwert ist 66,160,159,150,60,43,125. |
|
Protokollmeldung über Anforderung |
Dieser Parameter enthält die Nachricht, die zu Beginn eines Resynchronisierungsversuchs an den Syslog-Server gesendet wird. Der Standardwert ist |
|
Protokollmeldung über erfolgreiche Aufzeichnungen |
Die Syslog-Meldung, die nach dem erfolgreichen Abschluss eines Resynchronisierungsversuchs ausgegeben wird. Der Standardwert ist |
|
Protokollmeldung über fehlgeschlagene Protokolle |
Die Syslog-Meldung, die nach einem fehlgeschlagenen Resynchronisierungsversuch ausgegeben wird. Der Standardwert ist |
|
Vom Benutzer konfigurierbare Resynchronisierung |
Ermöglicht einem Benutzer, das Telefon über den IP-Telefonbildschirm erneut zu synchronisieren. Der Standardwert ist „Ja“. |
Firmware-Upgrade-Parameter
In der folgenden Tabelle werden die Funktionen und die Verwendung der einzelnen Parameter im Abschnitt Firmware-Upgrade der Registerkarte Bereitstellung definiert.
|
Parametername |
Beschreibung und Standardwert |
|---|---|
|
Upgrade aktivieren |
Aktiviert Firmware-Upgrade-Vorgänge unabhängig von Resynchronisierungsaktionen. Der Standardwert ist „Ja“. Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
|
Wiederholungsverzögerung für Upgrade-Fehler |
Das Upgrade-Wiederholungsintervall (in Sekunden), das bei einem fehlgeschlagenen Upgrade angewendet wird. Das Gerät verfügt über einen Timer für Fehler beim Firmware-Upgrade, der nach einem fehlgeschlagenen Firmware-Upgrade-Versuch aktiviert wird. Der Timer wird mit dem Wert in diesem Parameter initialisiert. Der nächste Firmware-Update wird durchgeführt, wenn dieser Timer auf Null fällt. Der Standardwert ist 3600 Sekunden. Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
|
Upgrade-Regel |
Ein Skript für das Firmware-Upgrade, das die Upgrade-Bedingungen und die zugehörigen Firmware-URLs definiert. Sie verwendet dieselbe Syntax wie die Profilregel. Geben Sie die Upgrade-Regel im folgenden Format ein:
Beispiel: Wenn kein Protokoll angegeben ist, wird TFTP angenommen. Wenn kein Servername angegeben wird, wird der Host, der die URL anfordert, als Servername verwendet. Wenn kein Port angegeben ist, wird der Standardport verwendet (69 für TFTP, 80 für HTTP oder 443 für HTTPS). Der Standardwert ist leer. Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
|
Protokollmeldung über Upgrade-Anfrage |
Syslog Nachricht wurde am Beginn eines Firmware Upgradungsversuchs veröffentlicht. Standard: Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
|
Protokollmeldung über erfolgreiche Aktualisierung |
Die nach Abschluss eines Firmware-Update ausgegebene syslog Nachricht wird erfolgreich abgeschlossen. Der Standardwert ist Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
|
Protokollmeldung über fehlgeschlagene Aktualisierung |
Syslog Nachricht wird nach einem fehlgeschlagenen Firmware-Update veröffentlicht. Der Standardwert ist Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
|
Peer-Firmware-Freigabe |
Aktiviert oder deaktiviert die PFS-Funktion (Peer Firmware Sharing). Wählen Sie Ja oder Nein aus, um die Funktion zu aktivieren bzw. zu deaktivieren. Standard: Ja Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
|
Peer-Firmware-Freigabe-Protokollserver |
Gibt die IP-Adresse und den Port an, an den die UDP-Nachricht gesendet wird. Beispiel: 10.98.76.123:514, wobei 10.98.76.123 die IP-Adresse und 514 die Portnummer ist. Konfigurieren Sie diesen Parameter mit einer der folgenden Methoden:
|
Allgemeine Parameter
In der folgenden Tabelle werden die Funktionen und die Verwendung der einzelnen Parameter im Abschnitt Allgemeine Parameter der Registerkarte Bereitstellung definiert.
|
Parametername |
Beschreibung und Standardwert |
|---|---|
|
gpp a – gpp p |
Die allgemeinen GPP_*-Parameter werden als freie Zeichenfolgen verwendet, die registriert werden, wenn die Telefone für die Interaktion mit einer bestimmten Bereitstellungsserverlösung konfiguriert werden. Sie können so konfiguriert werden, dass sie verschiedene Werte enthalten, einschließlich der folgenden:
Der Standardwert ist leer. |
Makroerweiterungsvariablen
Bestimmte Makrovariablen werden in den folgenden Bereitstellungsparametern erkannt:
-
Profile_Regel
-
rofile_Rule_*
-
Resync_Trigger_*
-
Upgrade_Regel
-
Log_*
-
GPP_* (unter bestimmten Bedingungen)
Innerhalb dieser Parameter werden Syntaxtypen wie $NAME oder $(NAME) erkannt und erweitert.
Unterzeichenfolgen von Makrovariablen können mit der Schreibweise $(NAME:p) und $(NAME:p:q) angegeben werden, wobei p und q nicht negative Ganzzahlen sind (ab Version 2.0.11 verfügbar). Die resultierende Makroerweiterung beginnt bei der Zeichenverschiebung p mit der Länge q (oder bis zum Ende der Zeichenfolge, wenn q nicht angegeben ist). Wenn GPP_A beispielsweise ABCDEF enthält, wird $(A:2) zu CDEF und $(A:2:3) zu CDE erweitert.
Ein nicht erkannter Name wird nicht übersetzt, und die Form $NAME oder $(NAME) bleibt nach der Erweiterung unverändert im Parameterwert.
|
Parametername |
Beschreibung und Standardwert |
|---|---|
|
$ |
Das Formular $$ wird auf ein einzelnes $ Zeichen erweitert. |
|
A bis P |
Ersetzt durch den Inhalt der allgemeinen Parameter GPP_A bis GPP_P. |
|
SA bis SD |
Ersetzt durch spezielle Parameter GPP_SA bis GPP_SD. Diese Parameter enthalten Schlüssel oder Kennwörter, die in der Bereitstellung verwendet werden. $SA bis $SD werden als Argumente für den optionalen URL-Qualifizierer für die Resynchronisierung erkannt, --Schlüssel. |
|
MA |
MAC-Adresse mit Hexadezimalzeichen in Kleinbuchstaben, z. B. 000e08aabbcc. |
|
MAU |
MAC-Adresse mit Hexadezimalzeichen in Großbuchstaben, z. B. 000E08AABBCC. |
|
MAC |
MAC-Adresse mit Hexadezimalzeichen in Kleinbuchstaben und Doppelpunkten, um die Hexadezimalzeichenpaare zu trennen. Beispiel: 00:0e:08:aa:bb:cc. |
|
PN |
Produktname. Beispiel: CP-8875-CC-C-9K. |
|
PSN | Produktseriennummer. Beispiel: V03. |
|
SN |
Zeichenfolge der Seriennummer. beispielsweise 88012BA01234. |
|
CCERT |
Status des SSL-Clientzertifikats: Installiert oder nicht installiert. |
|
IP |
IP-Adresse des Telefons innerhalb des lokalen Subnetzes. Beispiel: 192.168.1.100. |
|
Extip |
Externe IP-Adresse des Telefons, wie im Internet dargestellt. Beispiel: 66.43.16.52. |
|
schwingen |
Zeichenfolge der Softwareversion. Beispiel: Telefon-8875.1-0-1-0001-1 |
|
hwver |
Zeichenfolge der Hardware-Version. Beispiel: 2.0.1 |
|
prvst |
Bereitstellungsstatus (numerische Zeichenfolge): -1 = explizite Anfrage zur erneuten Synchronisierung 0 = Resynchronisierung einschalten 1 = regelmäßige Neusynchronisierung 2 = Resynchronisierung fehlgeschlagen, Wiederholungsversuch |
|
upgst |
Upgrade-Status (numerische Zeichenfolge): 1 = erster Upgrade-Versuch 2 = Upgrade fehlgeschlagen, Wiederholungsversuch |
|
aktualisieren |
Ergebnismeldung (ERR) des vorherigen Upgrade-Versuchs; beispielsweise http_get fehlgeschlagen. |
|
prvtmr |
Sekunden seit dem letzten Resynchronisierungsversuch. |
|
UPGTMR |
Sekunden seit dem letzten Upgrade-Versuch. |
|
REGTMR1 |
Sekunden, die vergangen sind, seit die Registrierung von Leitung 1 beim SIP-Server verloren ging. |
|
REGTMR2 |
Sekunden, die vergangen sind, seit die Registrierung von Leitung 2 beim SIP-Server verloren ging. |
|
upgcond |
Name des älteren Makros. |
|
Schema |
Dateizugriffsschema (TFTP, HTTP oder HTTPS), ermittelt nach der Analyse der URL für die Resynchronisierung oder das Upgrade. |
|
Serv |
Hostname des Anforderungszielservers, ermittelt nach der Analyse der URL für die Resynchronisierung oder das Upgrade. |
|
Servip |
IP-Adresse des Anforderungszielservers, ermittelt nach der Analyse der URL für die Resynchronisierung oder das Upgrade, möglicherweise nach der DNS-Suche. |
|
Port |
UDP-/TCP-Port des Anforderungsziels, ermittelt nach der Analyse der URL für die Resynchronisierung oder das Upgrade. |
|
Pfad |
Dateipfad des Anforderungsziels, ermittelt nach der Analyse der URL für die Resynchronisierung oder das Upgrade. |
|
Fehler |
Ergebnismeldung des Resynchronisierungs- oder Upgrade-Versuchs. Nur nützlich beim Generieren von Ergebnis-Syslog-Meldungen. Der Wert wird bei Upgrade-Versuchen in der UPGERR-Variablen beibehalten. |
|
UID |
Der Inhalt des Benutzer-ID-Konfigurationsparameters für Leitung n. |
|
Ems |
Extension-Mobility-Status |
|
MUID |
Extension Mobility-Benutzer-ID |
|
mpwd |
Extension Mobility-Passwort |
Interne Fehlercodes
Das Telefon definiert eine Reihe interner Fehlercodes (X00–X99), um die Konfiguration zu erleichtern, um unter bestimmten Fehlerbedingungen eine genauere Kontrolle über das Verhalten des Geräts zu ermöglichen.
|
Parametername |
Beschreibung und Standardwert |
|---|---|
|
X00 |
Transport Layer- (oder ICMP-)Fehler beim Senden einer SIP-Anforderung. |
|
X20 |
Zeitüberschreitung bei der SIP-Anforderung, während auf eine Antwort gewartet wird. |
|
X40 |
Allgemeiner SIP-Protokollfehler (z. B. inakzeptabler Codec in SDP in 200- und ACK-Nachrichten oder Zeitüberschreitung beim Warten auf ACK). |
|
X60 |
Gewählte Nummer gemäß gegebenem Wählplan ungültig. |
