> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/de/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md). # Überlegungen zur Hardware-Bereitstellung Diese Seite beschreibt die Bereitstellung des Zoom Node ZPLS-Moduls auf einer virtuellen Maschine mithilfe unterstützter Hypervisoren. Sie bietet detaillierte Konfigurationsoptionen, die auf unterschiedliche Hardwarekapazitäten zugeschnitten sind, um eine optimale Leistung für verschiedene betriebliche Anforderungen zu gewährleisten. ### Unterstützte Hypervisoren #### Kunden müssen die Zoom Node-Software auf einer virtuellen Maschine installieren, die auf einem unterstützten Hypervisor ausgeführt wird Als Zoom Node-Workload muss das ZPLS-Modul auf einer virtuellen Maschine installiert werden, auf der die Zoom Node-Plattform ausgeführt wird, auf einem [unterstützten Hypervisor](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Weitere Informationen über Zoom Node als Produkt finden Sie [im Anhang](#_a2lvsihjp0ek). #### Kunden können je nach Hardwarekapazitäten eine von zwei Konfigurationsoptionen Wählen Das ZPLS-Modul unterstützt zwei Konfigurationen, abhängig von den Hardwarekapazitäten der virtuellen Maschine. Diese Kapazitäten sind unten aufgeführt: | | Konfigurationsoption 1 | Konfigurationsoption 2 | | --------------------------------- | -------------------------------------------- | --------------------------------------------- | | **Hardware-Spezifikationen** |

8 CPU

16 GB RAM

80 GB HDD

|

16 CPU

16 GB RAM

80 GB HDD

| | **Gesamtregistrierungen** | 2000 | 5000 | | **Maximale gleichzeitige Anrufe** | 240 | 480 | | **Anrufe pro Sekunde** | 2 | 4 | | **Registrierungen pro Sekunde** | 60 | 400 | {% hint style="info" %} Wenn die Anzahl der Endpunkte innerhalb eines für Ausfallsicherheit aktivierten Standorts die Bereitstellungskapazitäten eines Standorts überschreitet, verarbeitet das ZPLS-Modul Registrierungen nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“. Kunden wird geraten, zusätzliche Module Hinzufügen oder die Zoom Phone-Policyeinstellung zu verwenden [**den Lokalen Survivability-Modus**](#_ah8xua8wdq10) um zu priorisieren, welche Benutzer den Ausfallsicherheits-Failover unterstützen. {% endhint %} ### Modulskalierung und Resilienz #### ZPLS-Module unterstützen Clustering für zusätzliche Skalierung und/oder Resilienz Kunden können ZPLS-Module zu Gruppen zusammenfassen, mit bis zu 20 Modulen pro Standort (oder 100 Node-Geräten insgesamt pro Konto) für zusätzliche Redundanz oder Skalierung. {% hint style="info" %} Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert zum Aktivieren ein technisches Support-Ticket. {% endhint %} #### Skalierung erhöht die unterstützten Gerätekapazitäten eines Standorts Die Erhöhung der Anzahl von ZPLS-Modulen verbessert die Kapazitäten jedes Standorts linear mit jedem zusätzlichen Modul. Wenn ein Modul beispielsweise insgesamt 5.000 Registrierungen unterstützt, erhöht die Bereitstellung von fünf Modulen die Unterstützung auf 25.000 Registrierungen. #### Redundanz fügt zusätzliche Module für die Resilienz hinzu, skaliert jedoch die Gerätekapazitäten eines Standorts nicht Wenn ein ZPLS-Modul zu Redundanzzwecken verwendet wird, tragen die redundanten Module nicht zur Gesamtzahl der unterstützten Nebenstellen bei. Stattdessen befinden sich die Module im „Hot-Standby“ und werden nur aktiviert, wenn primäre Module ausfallen. Beispielsweise unterstützen ein primäres und ein redundantes Modul zusammen insgesamt 5.000 Registrierungen, sodass im Falle eines Ausfalls eines primären Moduls das redundante Modul nicht mit mehr Geräten als seinem unterstützten Limit überlastet wird. #### Beispiel für die Bereitstellung von ZPLS mit Skalierung und Redundanz Der Einfachheit halber zeigt das folgende Beispiel eine Bereitstellung mit zusätzlicher Skalierung und Redundanz. {% hint style="success" %} **Beispiel**: Ein Krankenhaus muss für die Ausfallsicherheit bis zu 10.000 registrierte Nebenstellen unterstützen. Um dies zu erreichen, setzt das Krankenhaus vier ZPLS-Module ein. Die ersten beiden Module können jeweils 5.000 Registrierungen unterstützen, wodurch sich eine Gesamtkapazität von bis zu 10.000 Registrierungen ergibt. In Anerkennung der Bedeutung von Resilienz setzt das Krankenhaus jedoch zusätzlich zwei weitere Module als redundante Backups für die primären Module ein. In diesem Szenario hat das Krankenhaus nun primäre und sekundäre Hardware für die Ausfallsicherheit bereitgestellt. Falls jetzt ein primäres Modul ausfällt, werden die redundanten Module Übernehmen, um einen unterbrechungsfreien Dienst aufrechtzuerhalten, während sie weiterhin bis zu 10.000 registrierte Geräte unterstützen. {% endhint %} ### Überlegungen zum Standortdesign #### Standorte gruppieren Zoom Phone-Benutzer nach Standort für gemeinsame Telefonie-Einstellungen und -Richtlinien A **Standort** ist ein spezifischer Begriff, der in Zoom Phone verwendet wird und Benutzer mit gemeinsamen Merkmalen — wie einem gemeinsamen Access-Code, einer Adresse, einer SIP-Zone, einer Abteilung oder Richtlinien — zu einer einzigen, verwaltbaren Gruppe im Zoom-Webportal zusammenfasst. Für einige Kunden kann ein einzelner Standort alle Benutzer innerhalb ihres Business repräsentieren und sich über mehrere Gebäude innerhalb eines Campus oder Standorts erstrecken; für andere können je nach Ihren Geschäftsanforderungen mehrere Standorte erforderlich sein. Für weitere Informationen zu Standorten oder zur Standortverwaltung, [siehe das Support-Center von Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### Zoom Phone unterstützt Einzelstandort- und Mehrere Standorte-Designs Für die Konfiguration von Zoom Phone-Standorten innerhalb eines Kontos gibt es zwei grundlegende Designs: 1. **Einzelstandort**: Repräsentiert alle Benutzer innerhalb eines Kontos, möglicherweise über mehrere Gebäude oder Standorte hinweg, innerhalb eines einzigen Zoom Phone-Standorts. 2. **Mehrere Standorte**: Repräsentiert Benutzersegmente getrennt nach Standort, Gebäude, Abteilung oder Funktion, jeweils mit einem eigenen Standort.
{% hint style="info" %} Kontoadministratoren der aktuellen Zoom-Kunden können ihr aktuelles Standortdesign über die [**Unternehmensinformationen**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) Seite, Verfügbar im **Telefonsystem-Verwaltung** Menü im Webportal. {% endhint %} #### Jedes ZPLS-Modul kann jeweils nur einem Standort zugeordnet werden Wie bereits erwähnt, ist ein ZPLS-Modul der [Registrar mit dritthöchster Priorität](#_7itj40mx1dut) für unterstützte Geräte, hinter primären und sekundären SIP-Zonen. Da Geräte ihre SRV-Listen während des Startvorgangs erhalten und diese Listen an die Einstellungen ihres Standorts gebunden sind, **jedes ZPLS-Modul kann jeweils nur einem Standort zugeordnet werden**. #### Jeder Standort kann gleichzeitig bis zu 20 ZPLS-Module unterstützen Obwohl jedes ZPLS-Modul jeweils nur einem Standort zugeordnet werden kann, kann ein Standort bis zu 20 ZPLS-Module in einer Gruppe unterstützen und so die Ausfallsicherheitsfunktionen jedes Standorts erweitern. {% hint style="info" %} Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert zum Aktivieren ein technisches Support-Ticket. {% endhint %} #### ZPLS-Module unterstützen standortübergreifende Anrufe, wenn die Module mit einem gemeinsamen Netzwerk verbunden sind ZPLS-Module aus verschiedenen Standorten unterstützen standortübergreifende Anrufe während eines Ausfallsicherheits-Events, solange die Geräte im lokalen Netzwerk auffindbar sind. Wenn ein Unternehmenscampus beispielsweise drei Gebäude mit jeweils eigenem Telefonstandort hat, können die ZPLS-Module jedes Standorts Standort-zu-Standort-Anrufe über das Campusnetzwerk herstellen. {% hint style="info" %} Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert zum Aktivieren ein technisches Support-Ticket. {% endhint %} #### Vor der Bereitstellung von ZPLS sollten Konten verstehen, welche Standortkonfiguration für ihre Bedürfnisse am besten geeignet ist Da jedes ZPLS-Modul jeweils nur einem Standort zugeordnet werden kann, ist das Standortdesign einer der wichtigsten Faktoren bei der Bereitstellung des ZPLS-Dienstes innerhalb eines Kontos. Aus diesem Grund sollten Kunden verstehen, welche Standortkonfiguration am besten geeignet ist, um ihre praktischen Business- und Ausfallsicherheitsanforderungen zu erfüllen, da jeder zusätzliche für Ausfallsicherheit aktivierte Standort mindestens ein zusätzliches ZPLS-Modul erfordert. #### Ein Einzelstandort-Design ist einfacher zu verwalten und bietet Ausfallsicherheit mit einem einzigen ZPLS-Modul, bietet jedoch weniger Flexibilität für Benutzereinstellungen und Richtlinien Ein Einzelstandort-Design hilft, die Verwaltung von Zoom Phone-Einstellungen und -Richtlinien zu optimieren, indem alle Benutzer innerhalb eines Kontos in einer einzigen, einheitlichen Gruppe zusammengefasst werden. Diese einzelne Benutzergruppe bietet Unternehmen eine unkomplizierte Verwaltung und geringere Komplexität, wodurch der Verwaltungsprozess vereinfacht wird. Zusätzlich kann ein Einzelstandort-Design lokale Telefon-Ausfallsicherheit mit einem einzigen ZPLS-Modul bieten, solange die Benutzer des Standorts die [Kapazitäten eines Einzelmoduls](#_rx0i1j9xofnc). Allerdings bringt die Einfachheit eines Einzelstandort-Designs naturgemäß auch Einschränkungen mit sich. Insbesondere bieten Einzelstandort-Designs weniger Flexibilität aufgrund ihres „one size fits all“-Ansatzes, der möglicherweise nicht für alle Bereitstellungsszenarien über mehrere Abteilungen mit unterschiedlichen Anforderungen geeignet ist. Darüber hinaus können Einzelstandort-Bereitstellungen in bestimmten Ausfallsicherheitsszenarien anfällig sein, wenn das [lokale Netzwerk ausfällt](#_gzpf5m70jl3i). #### Ein Design mit mehreren Standorten bietet mehr Flexibilität für Benutzereinstellungen und Richtlinien, erfordert jedoch ein ZPLS-Modul für jeden für Ausfallsicherheit aktivierten Standort und ist komplexer zu verwalten Ein Design mit mehreren Standorten bietet Unternehmen zusätzliche Flexibilität bei Benutzereinstellungen und Richtlinien, indem Benutzer in verschiedene Gruppen mit granularen Einstellungssteuerungen aufgeteilt werden. Dieses Design ermöglicht es Organisationen, Kommunikationskonfigurationen detailliert anzupassen, um spezifische Anforderungen an verschiedenen Standorten zu erfüllen, was zu einer feineren und anpassungsfähigeren Benutzererfahrung für verschiedene Abteilungen, Szenarien oder Anforderungen führt. Zusätzlich können Bereitstellungen mit mehreren Standorten [standortübergreifende Kommunikation](#_a42hwaw1pfmx) wenn die Standorte über ein gemeinsames Netzwerk verbunden sind. Die Verwaltung eines Designs mit mehreren Standorten erfordert jedoch sorgfältige Aufmerksamkeit für die Feinheiten der einzigartigen Anforderungen jedes Standorts, was einen höheren administrativen Aufwand erfordern kann. Da jedem ZPLS-Modul jeweils nur ein Standort zugewiesen werden kann, benötigt jeder für Ausfallsicherheit aktivierte Standort zudem ein ZPLS-Modul und eine Lizenz, was zu einem ressourcenintensiveren Setup beitragen kann. {% hint style="info" %} In einem Design mit mehreren Standorten haben Kunden die Flexibilität zu wählen, welche Standorte für Ausfallsicherheit konfiguriert werden. Standorte *ohne* ein ZPLS-Modul bleibt weiterhin nicht in der Lage, Anrufe zu tätigen oder zu empfangen, bis die Standard-Konnektivität wiederhergestellt ist. {% endhint %} ### Netzwerkausfälle #### Die Ausfallsicherheit kann beeinträchtigt werden, wenn das lokale Netzwerk eines Standorts ausfällt Obwohl ZPLS-Module darauf ausgelegt sind, während dienstbeeinträchtigender Events lokale Telefon-Ausfallsicherheit bereitzustellen, kann die Ausfallsicherheit beeinträchtigt werden, wenn das lokale Netzwerk eines Standorts ausfällt. Diese Szenarien werden in den folgenden beiden Abschnitten beschrieben. #### Ausfall des lokalen Netzwerks an einem Einzelstandort In einem Einzelstandort-Design sind ein oder mehrere Gebäude über ein lokales oder Campusnetzwerk verbunden und werden innerhalb von Zoom Phone durch einen einzigen Standort repräsentiert. Diese Konfiguration geht von einem gemeinsamen Netzwerk zwischen allen Benutzern und Gebäuden innerhalb eines Standorts aus, ohne externe Netzwerkabhängigkeiten (z. B. das Internet) für die Kommunikation zwischen Gebäuden. Mit diesem Standortdesign kann ein Unternehmen allen Benutzern innerhalb eines einzelnen Standorts oder einer einzelnen Standort-Umgebung lokale Ausfallsicherheit mit nur einem ZPLS-Modul bieten; jedoch ist dieses Design im Falle eines Ausfalls des lokalen oder Campusnetzwerks anfällig, der die Kommunikation zwischen Gebäuden beeinträchtigt. Das folgende Beispiel beschreibt, wie ein Ausfall des lokalen Netzwerks eine Bereitstellung an einem Einzelstandort beeinflussen kann.
{% hint style="success" %} **Beispiel:** Ein Unternehmen setzt das ZPLS-Modul für einen einzelnen Zoom Phone-Standort ein, der aus den Gebäuden A, B und C besteht, die über ein Campusnetzwerk verbunden sind. Das ZPLS-Modul läuft in Gebäude A und ist **nicht** mit einem SBC für externe Anrufe über das PSTN verbunden. Im Falle eines Ausfalls des externen Internetdienstes oder eines dienstbeeinträchtigenden Events kann jeder Benutzer innerhalb des Standorts einen anderen Benutzer innerhalb des *gleichen* Standorts anrufen, solange beide Benutzer über das Campusnetzwerk die Verbindung zum ZPLS-Modul aufrechterhalten. Im Falle eines Ausfalls des Campusnetzwerks können Benutzer in den Gebäuden B und C jedoch keine Anrufe tätigen, solange das ZPLS-Modul in Gebäude A nicht erreichbar ist. Folglich müssen Benutzer in den Gebäuden B und C warten, bis das Campusnetzwerk wiederhergestellt ist, um Ausfallsicherheitsanrufe zu tätigen. {% endhint %} Die folgende Tabelle zeigt die Zoom Phone-Ausfallsicherheit in einem Einzelstandort-Design mit mehreren Gebäuden: | Anrufe ausgehend von Gebäude | Kann diese Standorte bei einem Ausfall des externen Internets erreichen | Kann diese Standorte bei einem Ausfall des Campusnetzwerks erreichen | | ---------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------- | | Gebäude A (ZPLS-Host) | ☑️Gebäude A, B und C | ☑️ Gebäude A *nur* | | Gebäude B | ☑️Gebäude A, B und C | ✖️ | | Gebäude C | ☑️Gebäude A, B und C | ✖️ | #### Ausfall des lokalen Netzwerks bei mehreren Standorten ohne SBC In einem Design mit mehreren Standorten wird jedes Gebäude oder jeder Standort (z. B. Etage, Außenbüro usw.) innerhalb von Zoom Phone unabhängig durch einen eindeutigen Standort repräsentiert. Diese Konfiguration setzt voraus, dass jeder Standort ein ZPLS-Modul hat und dass die Standorte über ein gemeinsames Campusnetzwerk verbunden sind. Mit diesem Standortdesign unterstützt jeder Standort sein eigenes ZPLS-Modul, sodass Benutzer innerhalb desselben Gebäudes einander anrufen können, wenn der Ausfallsicherheitsmodus aktiviert ist. Wenn mehrere Standorte mit einem ZPLS-Modul über ein gemeinsames Netzwerk verbunden sind, können Benutzer außerdem Benutzer an \_anderen Standorten\_ anrufen, solange das lokale Netzwerk betriebsbereit bleibt. Dieses Design ist jedoch im Falle eines Ausfalls des Campusnetzwerks anfällig, der die Kommunikation zwischen Gebäuden beeinträchtigt. Das folgende Beispiel beschreibt, wie ein Ausfall des Campusnetzwerks eine Bereitstellung mit mehreren Standorten beeinflussen kann.
{% hint style="success" %} **Beispiel:** Ein Unternehmen setzt das ZPLS-Modul innerhalb seines Campus mit mehreren Gebäuden ein, der aus den Gebäuden A, B und C besteht. Jedes Gebäude ist ein eindeutiger Standort innerhalb von Zoom Phone und verfügt über ein standortspezifisches ZPLS-Modul. Alle Gebäude innerhalb des Campus sind über ein Campusnetzwerk verbunden, das für die Kommunikation zwischen Gebäuden nicht von externen Internetdiensten abhängt. In diesem Beispiel kann im Falle eines Ausfalls des externen Internetdienstes, eines Ausfalls des Campusnetzwerks oder eines dienstbeeinträchtigenden Events jeder Benutzer innerhalb eines Standorts einen anderen Benutzer innerhalb desselben Standorts anrufen. Da jedoch jedes Gebäude ein eindeutiger Standort ist und sich Benutzer bei ihren standortspezifischen Modulen registrieren, können die ZPLS-Module bei einem Ausfall des Campusnetzwerks keine standortübergreifenden Anrufe übertragen. Stattdessen sind Benutzer darauf beschränkt, Anrufe zu anderen Benutzern innerhalb ihres lokalen Standorts zu tätigen. {% endhint %} Die folgende Tabelle zeigt die Zoom Phone-Ausfallsicherheit aus dem obigen Beispiel in einem Design mit mehreren Standorten und einem miteinander verbundenen Campusnetzwerk: | Anrufe ausgehend von Gebäude | Kann diese Standorte bei einem Ausfall des externen Internets erreichen | Kann diese Standorte bei einem Ausfall des Campusnetzwerks erreichen | | ---------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------- | | Gebäude A (ZPLS-Host) | ☑️ Gebäude A, B und C | ☑️ Gebäude A | | Gebäude B (ZPLS-Host) | ☑️ Gebäude A, B und C | ☑️ Gebäude B | | Gebäude C (ZPLS-Host) | ☑️ Gebäude A, B und C | ☑️ Gebäude C | #### Wenn ein lokales Netzwerk ausfällt, werden standortübergreifende Anrufe auch über das PSTN unterstützt, sofern jeder Standort mit einem SBC verbunden ist und die Anrufweiterleitung aktiviert ist Im Falle eines Ausfalls des lokalen Netzwerks können Kunden mit einem Design mit mehreren Standorten, das das ZPLS-Modul mit einem SBC und PSTN-Konnektivität an jedem Standort integriert, Standort-zu-Standort-Anrufe durch Aktivieren der Anrufweiterleitung ermöglichen, wenn [die Anrufweiterleitung aktiviert ist](#_2v7qst7vxwaa). Wenn dies konfiguriert ist, werden Telefonanrufe, die während des Ausfallsicherheitsmodus getätigt werden, vom Client des Benutzers zum PSTN, zum SBC und ZPLS-Modul des zweiten Standorts weitergeleitet und gelangen schließlich zum Gerät des Angerufenen. Das folgende Diagramm bietet einen Überblick über diese Konfiguration:
{% hint style="danger" %} Diese Konfiguration **erfordert** Verarbeitung von E.164-Telefonnummern auf den konfigurierten SBCs. {% endhint %} Die folgende Tabelle zeigt ebenfalls die Zoom Phone-Ausfallsicherheit in einem Design mit mehreren Standorten und unabhängigen SBCs: | Anrufe ausgehend von Gebäude | Kann diese Standorte bei einem Ausfall des externen Internets erreichen | Kann diese Standorte bei einem Ausfall des Campusnetzwerks erreichen | | ---------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------- | | Gebäude A (ZPLS-Host) | ☑️Gebäude A, B und C | ☑️Gebäude A, B und C | | Gebäude B (ZPLS-Host) | ☑️Gebäude A, B und C | ☑️Gebäude A, B und C | | Gebäude C (ZPLS-Host) | ☑️Gebäude A, B und C | ☑️Gebäude A, B und C | #### Nomadische Benutzer registrieren sich immer beim ZPLS-Modul, das ihrem Heimatstandort zugeordnet ist Wenn Benutzer oder Geräte zu Zoom Phone hinzugefügt werden, wird einem Benutzer oder Gerät statisch ein „Heimat“-Standort zugeordnet, bis dies von einem Kontoadministrator anders aktualisiert wird. Das bedeutet, dass Zoom den an den Benutzer gebundenen Standort nicht dynamisch anpasst, wenn ein Benutzer sich an einen physischen Standort außerhalb seines zugeordneten Heimatstandorts begibt, wie etwa ein Bürogebäude, das einem anderen Standort zugeordnet ist. Folglich versucht der Benutzer, wenn die Verbindung zu den Zoom Phone-Datenzentren verloren geht, sich beim ZPLS-Modul zu registrieren, das seinem Heimatstandort zugeordnet ist, selbst wenn er sich an einem anderen Standort befindet. {% hint style="success" %} **Beispiel:** Ein Benutzer in einem Campus mit mehreren Standorten ist in Gebäude A (Standort A) ansässig und wechselt für ein Meeting vorübergehend zu Gebäude B (Standort B). Während er sich in Gebäude B befindet, tritt ein dienstbeeinträchtigendes Event auf und der Ausfallsicherheitsmodus wird aktiviert. Obwohl sich der Benutzer in Gebäude B befindet, versucht der Client des Benutzers, sich mit dem am Heimatstandort bereitgestellten ZPLS-Modul in Gebäude A zu verbinden, da Standort A sein Heimatstandort ist. In diesem Szenario wird der Ausfallsicherheitsstatus eines Benutzers durch die Fähigkeit des Benutzergeräts bestimmt, sich über das Campusnetzwerk beim ZPLS-Modul innerhalb seines Heimatstandorts zu registrieren. Wenn das Campusnetzwerk ausfällt, während sich der Benutzer nicht an seinem Heimatstandort befindet, kann der Benutzer nicht vom Ausfallsicherheitsmodul profitieren. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/de/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.