In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie Sie mithilfe von API-Befehlen Gastzugriff und Host-Zugriff auf Bereiche des Cisco Meeting Server (CMS) einrichten.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Die Informationen in diesem Dokument basieren auf CMS Version 2.1.
Die Informationen in diesem Dokument wurden aus einem Gerät in einer bestimmten Laborumgebung erstellt. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
In diesem Dokument werden die folgenden Szenarios beschrieben:
Es gibt vier Möglichkeiten zur Unterscheidung zwischen Gast- und Host-Teilnehmern im CMS, die in den nächsten vier Beispielen beschrieben werden und hauptsächlich auf unterschiedlichen callLegProfiles basieren, die das während des Gesprächs auftretende Verhalten der Teilnehmer bestimmen, die im Raum teilnehmen.
Zunächst wird die Methode durch Verwendung eines anderen URI (oder Anruf-ID) für Gastteilnehmer und Hostteilnehmer erläutert. Anschließend wird sie mithilfe verschiedener Passcodes (oder Timeouts) im gleichen URI angefügt, um die Unterscheidung zwischen Gastteilnehmern und Hostteilnehmern zu ermöglichen. Die dritte Methode eines Timeout- oder leeren PIN-Eintrags für Gastbenutzer wurde als neue Funktion in CMS 2.1 eingeführt, wie in Abschnitt 2.4 der Versionshinweise gezeigt. Die vierte Methode erläutert, wie der Gastzugriff und der Host-Zugriff auf Leerzeichen mit zugewiesenen Besitzern/Membern eingerichtet und das Mitglied des Leerzeichens (Eigentümer) zum Host des Leerzeichens gemacht wird.
Dies ist die Basiskonfiguration, die vor der Version CMS 2.1 verfügbar war und mit einer anderen Anruf-ID identisch ist. Die nächsten Schritte müssen ausgeführt werden, um die Unterscheidung zwischen Gast- und Gastzugriff im gleichen Raum zu ermöglichen:
Schritt 1: Erstellen Sie einen Gast-callLegProfile (fordert Aktivierung = true).
Ein callLegProfile bestimmt das während des Gesprächs. Standardmäßig weisen Sie das Verhalten des Gastbenutzers im Gespräch dem Leerraum zu, sodass Sie später eine andere Zugriffsmethode auf demselben Leerzeichen haben können, und dass der Host beitreten kann.
Hinweis: Sie können dies auch auf Tenant-Ebene (/api/v1/Tenants/<Tenant-ID>) oder auf Systemebene (/api/v1/system/profiles) zuweisen, um dies beispielsweise für alle Leerstellen (oder pro Tenant) anzuwenden, aber hier wird es im Leerzeichen selbst angezeigt. Berücksichtigen Sie, dass die spezifischste Zuweisung des callLegProfile für das während des Gesprächs auftretende Verhalten berücksichtigt wird.
Der bedarfsgesteuerte Aktivierungsparameter ist hier der wichtigste für das Gastgeber-/Gastverhalten, da der Teilnehmer bei der Einstellung auf true nicht Audio- und Videosignale empfangen oder einsenden kann, bis ein oder mehrere vollständige/aktive (Host-)Teilnehmer beitreten. Weitere Parameter im callLegProfile finden Sie in Abschnitt 8.4.3 des API-Handbuchs, unter dem die gezeigten Parameter ebenfalls für diese Konfiguration relevant sein können (je nach Ihren Anforderungen):
Um den Gast-CallLegProfile zu erstellen, stellen Sie eine POST-Anforderung für /api/v1/callLegProfiles mit den bevorzugten Parametern und AnforderungenDer Aktivierungsparameter ist auf true festgelegt, sodass Sie anschließend eine GET-Anforderung für diese CallLegProfile-ID ausführen können. Beispiel:
< needsActivation>true needsActivation> speakerOnly false true false < deactivationMode>deactivate deactivationMode>
Notieren Sie sich die callLegProfile-ID, die fett markiert ist, da diese auf den Bereich in Schritt 3 für den (Standard-)Gastzugriff angewendet werden muss.
Schritt 2: Erstellen Sie einen Host-callLegProfile (needActivation = false).
Erstellen Sie auf ähnliche Weise das Host-callLegProfile für das während des Aufrufs aufgenommene Verhalten. Es gelten die gleichen Parameter wie zuvor, obwohl die Parameter nach Ihren eigenen Vorstellungen und Anforderungen ausgewählt werden können. Das Hauptelement besteht hier darin, den requireActivation-Parameter auf false festzulegen, um ihm die Hostrolle zuzuweisen.
Sie erstellen sie durch eine POST-Anforderung für /api/v1/callLegProfiles mit den bevorzugten Parametern und benötigtActivation-Parametern, die auf false festgelegt sind, sodass Sie anschließend eine GET-Anforderung für diese CallLegProfile-ID ausführen können, wobei das Ergebnis z. B. ist:
< needsActivation> false needsActivation> speakerOnly true false false
Notieren Sie sich die callLegProfile-ID, die fett markiert ist, da diese für den Hostzugriff auf die Zugriffsmethode in Schritt 4 angewendet werden muss.
Schritt 3: Weisen Sie dem Gast callLegProfile einen vorhandenen oder neuen Speicherplatz zu (dies ist die standardmäßige accessMethod).
Führen Sie entweder einen PUT-Befehl auf einem vorhandenen Speicherplatz (/api/v1/coSpaces/<coSpace-ID>) aus, um den Leerzeichen oder einen POST-Befehl auf /api/v1/coSpaces so zu erstellen, dass ein neuer Befehl mit dem GastLegProfile-Parameter erstellt wird, wie in Schritt 1 als das Verhalten für diesen Raum angegeben. Sie können auch die URI, Passcode und Anruf-ID-Parameter für diesen Bereich festlegen, wie in Abschnitt 6.2 des API-Handbuchs beschrieben.
Führen Sie eine GET-Anforderung für diesen Bereich aus (/api/v1/coSpaces/<coSpace-ID>), um zu überprüfen, ob dem Gast-LegProfile sowie dem URI- und Anruf-ID-Wert zugewiesen sind. Eine Beispielausgabe mit diesem Beispiel, der Gast-callLegProfile in Schritt 1 erstellt hat, ist diese Ausgabe mit einem URI-Wert guest.space und Anruf-ID von 62821815 (kein Passcode-Satz):
Guest.space true < uri>guest.space uri>< callId>628821815 callId>< callLegProfile> d4bfe12d-68cd-41c0-a671-48395ee170ab callLegProfile>bc392aaa-8c6d-4619-ad2f-cb30c4c53766 Guest@cms.steven.lab iWqZQ.tTMIleeQHKMB.JYg 1
Notieren Sie sich die Leerzeichen-ID, die fett markiert ist, da diese in Schritt 4 zum Erstellen der accessMethod für diesen bestimmten Bereich verwendet werden muss.
Schritt 4: Erstellen Sie eine neue accessMethod in diesem Bereich mit einem anderen URI (und Anruf-ID), und weisen Sie ihm das HostanrufLegProfile zu.
Sie möchten eine andere Zugriffsart für den Bereich als den Gastzugriff erstellen, der derzeit die Standardeinstellung ist. Dies erfolgt durch Angeben einer accessMethod im Leerzeichen selbst mithilfe eines POST-Befehls in /api/v1/coSpaces/<coSpace-ID>/accessMethods, wobei die coSpace-ID der fett markierte Wert in Schritt 3 ist (7cc797c9-c0a8-47cf-b51) 9-8dc5a01f1ade), auf die der Host CallLegProfile von Schritt 2 angewendet wird, sowie das verschiedene URI- und Anruf-ID-Feld.
Nach einer GET-Anforderung für diese Space AccessMethod (/api/v1/coSpaces/<coSpace-ID>/accessMethods/<accessMethod-ID>) müssen Sie eine ähnliche Ausgabe wie diese sehen können, in der Sie eine andere URI (host.space) und eine Anruf-ID (888) als der standardmäßigen ZugriffsMethod des Raumes sowie des speziell verknüpften Host callLegProfile, wie in Schritt 2 eingerichtet:
< uri>host.space uri>< callId>888 callId>< passcode> passcode>< callLegProfile> 7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912 callLegProfile> r8.QXRrOMFp719gDL5ck6Q
Sie können sich jetzt bei demselben Meeting einwählen:
- indem Sie sich bei guest.space URI (gefolgt von der Domäne, wie sie in den Anrufzuordnungsregeln konfiguriert wurde) einwählen.
- durch Eingabe des Anruf-ID-Werts 628821815 über IVR oder WebRTC join (kein Passcode)
- indem Sie sich an host.space URI (gefolgt von der Domäne, wie sie in den Anrufzuordnungsregeln konfiguriert wurde) wenden.
- durch Eingabe des Anruf-ID-Werts 888 über IVR oder WebRTC join (kein Passcode)
Wenn nur Gäste in den Raum eintreten, werden sie alle in einem Empfangsraum untergebracht, der darauf wartet, dass der Gastgeber beitritt. Sobald ein Gastgeber Mitglied wird, werden alle Gäste und Gastgeber in Konferenz gesetzt. Wenn keine Hosts mehr im Raum verbunden sind, aber noch einige Gäste, kehren sie zum Lobby-Bildschirm zurück, wie in der Konfiguration der Deaktivierung im Deaktivierungsmodus-Parameter im Gast-CallLegProfile wie in Schritt 1 gezeigt.
Diese Konfiguration ähnelt der Konfiguration im vorherigen Beispiel und ist bereits vor der Version CMS 2.1 verfügbar. Sowohl der Gast als auch der Host müssen eine nicht leere PIN oder einen nicht leeren Passcode eingeben, damit hierüber differenziert werden kann, wenn sie den gleichen URI wählen.
Die Konfigurationsschritte ähneln dem vorherigen Konfigurationsbeispiel:
Schritt 1: Erstellen Sie einen Gast-callLegProfile (fordert Aktivierung = true).
Es kann dieselbe Konfiguration wie im vorherigen Beispiel 1 verwendet werden, und selbst der gleiche Gast-CallLegProfile (d4bfe12d-68cd-41c0-a671-48395ee170ab) kann verwendet werden.
Schritt 2: Erstellen Sie einen Host-callLegProfile (requireActivation = false)
Es kann die gleiche Konfiguration wie im vorherigen Beispiel 1 und sogar der gleiche Host-CallLegProfile (7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912) verwendet werden.
Schritt 3: Weisen Sie den Gast-callLegProfile einem vorhandenen oder neuen Speicherplatz zu, und geben Sie einen Gast-Passcode (PIN) an (dies ist die standardmäßige accessMethod).
Ähnlich wie zuvor können Sie entweder einen PUT-Vorgang für einen vorhandenen Speicherplatz (/api/v1/coSpaces/<cospace-ID>) oder einen POST-Vorgang durchführen, um einen neuen Leerraum (/api/v1/coSpaces) mit den gewünschten Parametern für den URI, Passcode und Anruf-ID wie auch für den Gast--Anruf zu erstellen. Profil (aus Schritt 1), das Sie ihm gemäß Abschnitt 6.2 des API-Leitfadens zugewiesen haben.
Wenn Sie eine GET-Anforderung für diesen Bereich ausführen, müssen Sie eine ähnliche Ausgabe wie diese sehen, in der Sie einen URI von guestpin.space, eine Anruf-ID von 189, unser zuvor erstelltes Gast-LegProfile und einen Passcode von 789 sehen können:
Guest/Host PIN false < uri>guestpin.space uri>< callId>189 callId>< callLegProfile> d4bfe12d-68cd-41c0-a671-48395ee170ab callLegProfile>< passcode>789 passcode>X7f83UX7PHcIYp0JbT0fUA 1
Notieren Sie sich die Leerzeichen-ID, die fett markiert ist, da diese in Schritt 4 zum Erstellen der accessMethod für diesen bestimmten Bereich verwendet werden muss.
Schritt 4: Erstellen Sie eine neue accessMethod in diesem Bereich mit demselben URI (unterschiedliche Anruf-ID), und weisen Sie dem Host callLegProfile einschließlich eines Hostkenncodes (PIN) das Host-LegProfile zu.
In diesem Bereich erstellen Sie auch eine andere Zugriffsmethode für die Hosts (da das Gast-CallLegProfile im Leerzeichen selbst als Standardverknüpfungsoption zugewiesen wird), wie im ersten Konfigurationsbeispiel. Dies geschieht mithilfe eines POST-Befehls auf/api/v1/coSpaces/<coSpace-ID>/accessMethods mit dem coSpace-ID-Wert für unseren Raum 22d9f4ca-8b88-4d11-bba9-e2a2f7428b wie im vorherigen Schritt hervorgehoben. Mit diesem POST-Befehl können Sie verschiedene Parameter wie den URI (guestpin.space, identisch mit dem ursprünglichen), die Anruf-ID (889), den Host callLegProfile wie in Schritt 2 definiert und den Host Passcode oder die PIN (in diesem Fall 1234) angeben.
Wenn Sie eine GET-Anforderung für diese accessMethod ausführen, müssen Sie eine ähnliche Ausgabe sehen können, die den gleichen URI von guestpin.space, eine Anruf-ID von 889, den Host callLegProfile-Verweis und die Host-PIN von 1234 anzeigt:
< uri>guestpin.space uri>< callId>889 callId>< passcode>1234 passcode>< callLegProfile> 7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912 callLegProfile> c0wnqI1qB9JGRdmekHEO1w
Sie können sich jetzt bei demselben Meeting einwählen:
- indem Sie den URI guestpin.space (gefolgt von der Domäne, wie sie in den Anrufzuordnungsregeln konfiguriert ist) wählen und PIN 789 eingeben.
- durch Eingabe des Anruf-ID-Werts 189 über IVR oder WebRTC-Join mit PIN 789
- indem Sie den URI guestpin.space (gefolgt von der Domäne, die in den Anrufzuordnungsregeln konfiguriert ist) wählen und die PIN 1234 eingeben.
- durch Eingabe des Anruf-ID-Werts 889 über IVR oder WebRTC-Join mit PIN 1234
Wenn nur Gäste in den Raum eintreten, werden sie alle in einem Empfangsraum untergebracht, der darauf wartet, dass der Gastgeber beitritt. Sobald ein Gastgeber Mitglied wird, werden alle Gäste und Gastgeber in Konferenz gesetzt. Wenn keine Hosts mehr im Raum verbunden sind, aber noch einige Gäste, kehren sie zum Lobby-Bildschirm zurück, wie in der Konfiguration der Deaktivierung im Deaktivierungsmodus-Parameter im Gast-CallLegProfile wie in Schritt 1 gezeigt.
Diese Konfiguration ist erst ab Version 2.1 des CMS verfügbar, da einige API-Befehle des passcodeMode- und passcodeTimeout im callProfile-Abschnitt neu hinzugefügt wurden. Dies ermöglicht eine leere PIN, an der Gäste teilnehmen können (entweder durch Eingabe von # oder Timeout), während der Host über eine PIN verfügt, um auf den Bereich zuzugreifen und ihn zu aktivieren. Das callProfile steuert die Anruferfahrung für SIP-Anrufe (einschließlich Lync) und ist daher nicht für CMA-Clients (Thick Client und WebRTC) geeignet.
Die Konfigurationsschritte ähneln denen in Beispiel 2, wobei das callProfile-System hinzugefügt wird:
Da die Konfigurationen mit den Konfigurationsbeispielen 1 und 2 identisch sind, gibt es Verweise auf diese. Für den Test wurde derselbe Leerraum wie in Beispiel 2 verwendet, aber jetzt mit callProfile hinzugefügt.
Schritt 1: Erstellen Sie einen Gast-callLegProfile (fordert Aktivierung = true).
Es kann dieselbe Konfiguration wie im vorherigen Beispiel 1 und sogar derselbe GastanrufLegProfile (d4bfe12d-68cd-41c0-a671-48395ee170ab) verwendet werden.
Schritt 2: Erstellen Sie einen Host-callLegProfile (needActivation = false).
Es kann dieselbe Konfiguration wie im vorherigen Beispiel 1 und sogar der gleiche Host-CallLegProfile (7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912) verwendet werden.
Schritt 3: Erstellen Sie ein callProfile mit der gewünschten passcodeMode- und passcodeTimeout-Konfiguration.
Sie können ein CallProfile erstellen, das die Gesprächserfahrung für SIP-Anrufe (einschließlich Lync) bestimmt. Hier sind einige mögliche Konfigurationen möglich, wie z.B. das Zulassen von Aufnahme oder Streaming oder die maximale Teilnehmergrenze, aber der Schwerpunkt liegt hier auf den neuen API-Ergänzungen von CMS 2.1 bezüglich der Passcode-Verarbeitung. Weitere Parameter finden Sie in Abschnitt 8.2 des API-Leitfadens.
Das Passcode-Verhalten wird hier durch zwei Parameter bestimmt:
- erforderlich: Die IVR wartet ewig darauf, dass ein Benutzer die PIN oder # für eine leere PIN (für Gäste) eingibt.
- Timeout: Die IVR wartet auf eine PasscodeTimeout-Anzahl von Sekunden, bis der Teilnehmer die PIN eingibt. Wenn innerhalb dieser Zeit kein Eintrag erfolgt ist, wird davon ausgegangen, dass eine leere (#) PIN eingegeben wurde.
Um das callProfile zu erstellen, führen Sie einen POST-Befehl für /api/v1/callProfiles (oder PUT auf/api/v1/callProfiles/<callProfile-ID>, wenn Sie eine vorhandene ändern möchten,) mit den gewünschten Parametern für PasscodeMode und PasscodeTimeout aus. Wenn Sie einen GET-Befehl für das jeweilige CallProfile ausführen, müssen Sie ein ähnliches Ergebnis erhalten, z. B. wenn Sie den Modus als Timeout und als Timeout-Wert von 5 Sekunden eingerichtet haben:
< passcodeMode>timeout passcodeMode>< passcodeTimeout>5 passcodeTimeout>
Notieren Sie sich die CallProfile-ID, die fett markiert ist, da diese dem Leerzeichen zugewiesen werden muss, damit dieses während des Gesprächs in Schritt 4 funktioniert.
Schritt 4: Weisen Sie den Gast-AufrufLegProfile und CallProfile von Schritt 3 einem vorhandenen oder neuen Speicherplatz zu, indem Sie einen Gast-Passcode (PIN) angeben (die Standardzugriffsmethode).
Ähnlich wie zuvor können Sie entweder eine PUT-Operation für einen vorhandenen Speicherplatz (/api/v1/coSpaces/<cospace-ID>) oder eine POST-Operation durchführen, um einen neuen Speicherplatz (/api/v1/coSpaces) mit den gewünschten Parametern für URI und Anruf-ID, z. (aus Schritt 1). Der Unterschied zu den vorherigen Beispielen besteht darin, dass callProfile aus Schritt 3 und kein Passcode zugewiesen wurde.
Wenn Sie eine GET-Anforderung für diesen Bereich ausführen, müssen Sie eine ähnliche Ausgabe wie in diesem Beispiel sehen können, in der der URI von guestpin.space, eine Anruf-ID von 189, das zuvor erstellte Gast-LegProfile und das Anrufprofil, wie in Schritt 3 festgelegt, angezeigt werden:
Guest/Host PIN false < uri>guestpin.space uri>< callId>189 callId>< callLegProfile> d4bfe12d-68cd-41c0-a671-48395ee170ab callLegProfile>< callProfile> 4b0eff60-e4aa-4303-8646-a7e800a4eac6 callProfile>X7f83UX7PHcIYp0JbT0fUA 1
Notieren Sie sich die in Fettdruck markierte Leerzeichen-ID, da diese zum Erstellen der accessMethod für diesen bestimmten Bereich in Schritt 5 verwendet werden muss.
Schritt 5: Erstellen Sie eine neue accessMethod auf demselben Speicherplatz mit demselben URI (unterschiedliche Anruf-ID), und weisen Sie dem Host callLegProfile einschließlich eines Hostkenncodes (PIN) das Host-LegProfile zu.
In diesem Bereich erstellen Sie auch eine andere Zugriffsmethode für die Hosts (da das Gast-CallLegProfile im Leerzeichen selbst als Standardverknüpfungsoption zugewiesen wird), wie im ersten Konfigurationsbeispiel. Dies geschieht mithilfe eines POST-Befehls auf /api/v1/coSpaces/<coSpace-ID>/accessMethods, wobei der coSpace-ID-Wert durch den Wert für Ihren Speicherplatz 22d9f4ca-8b88-4d11-bba9-e2a2f7 ersetzt wird. 428c46 wie im vorherigen Schritt für diesen Fall hervorgehoben. Mit diesem POST-Befehl können Sie verschiedene Parameter wie den URI (guestpin.space, identisch mit dem ursprünglichen), die Anruf-ID (889), den Host callLegProfile wie in Schritt 2 definiert und den Host-Passcode oder die PIN (in diesem Fall 1234) angeben.
Wenn Sie eine GET-Anforderung für diese accessMethod ausführen, müssen Sie eine ähnliche Ausgabe sehen können, die den gleichen URI von guestpin.space, eine Anruf-ID von 889, den Host callLegProfile-Verweis und die Host-PIN von 1234 anzeigt:
< uri>guestpin.space uri>< callId>889 callId>< passcode>1234 passcode>< callLegProfile> 7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912 callLegProfile> c0wnqI1qB9JGRdmekHEO1w
Sie können sich jetzt bei demselben Meeting einwählen:
- indem Sie unter guestpin.space URI wählen (gefolgt von der Domäne, wie sie in den Anrufzuordnungsregeln konfiguriert wurde) und # als PIN eingeben oder nach 5 Sekunden die Zeitüberschreitung zulassen.
- durch Eingabe des Anruf-ID-Werts 189 über IVR oder WebRTC join
- indem Sie unter guestpin.space URI wählen (gefolgt von der Domäne, wie sie in den Anrufzuordnungsregeln konfiguriert wurde) und PIN 1234 eingeben.
- durch Eingabe des Anruf-ID-Werts 889 über IVR oder WebRTC-Join mit PIN 1234
Die nächsten Schritte müssen ausgeführt werden, um die Unterscheidung zwischen dem Gastzugriff und dem Host für Mitglieder und Nichtmitglieder im gleichen Raum zu ermöglichen:
Schritt 1: Erstellen Sie einen Gastaufruf LegProfile (requireActivation = true).
In diesem Beispiel wird die gleiche Konfiguration wie im vorherigen Beispiel 1 und der GastaufrufLegProfile (bfe7d07f-c7cb-4e90-a46e-4811bbaf6978) verwendet.
Notieren Sie sich die callLegProfile-ID, die fett markiert ist, da diese auf den Bereich in Schritt 3 für den Gastzugriff angewendet werden muss.
Schritt 2: Erstellen eines Host-callLegProfile (requireActivation = false)
In diesem Beispiel wird die gleiche Konfiguration wie im vorherigen Beispiel 1 und der Host CallLegProfile (0e76e943-6d90-43df-9f23-7f1985a74639) verwendet.
Notieren Sie sich die callLegProfile-ID, die fett markiert ist, da diese auf die Zugriffsmethode für den Speicherzugriff in Schritt 4 für den Hostzugriff und auf das coSpace-Mitglied in Schritt 6 angewendet werden muss.
Schritt 3: Weisen Sie dem Gast callLegProfile einen vorhandenen oder neuen Speicherplatz zu (dies ist die Standardzugriffsmethode).
Führen Sie entweder einen PUT-Befehl auf einem vorhandenen Speicherplatz (/api/v1/coSpaces/<coSpace-ID>) aus, um den Leerzeichen oder einen POST-Befehl auf /api/v1/coSpaces so zu erstellen, dass ein neuer Befehl mit dem GastLegProfile-Parameter erstellt wird, wie in Schritt 1 als das Verhalten für diesen Raum angegeben. Sie können auch die URI- und Anruf-ID-Parameter für diesen Bereich festlegen, wie Sie es wünschen (siehe Abschnitt 6.2 des API-Handbuchs).
Führen Sie eine GET-Anforderung für diesen Bereich aus (/api/v1/coSpaces/<coSpace-ID>), um zu überprüfen, ob dem Gast-LegProfile sowie dem URI- und Anruf-ID-Wert zugewiesen sind. Eine Beispielausgabe mit diesem Beispiel, der Gast-callLegProfile in Schritt 1 erstellt hat, ist diese Ausgabe mit einem URI-Wert von global und Anruf-ID von 1234 (kein Passcode-Satz), NichtMemberAccessSet in true:
<?xml version="1.0" ?> <coSpace id="96d28acb-86c6-478d-b81a-a37ffb0adafc"> <name>Global</name> <autoGenerated>false</autoGenerated> <uri>global</uri> <callId>1234</callId> <callLegProfile>bfe7d07f-c7cb-4e90-a46e-4811bbaf6978</callLegProfile> <nonMemberAccess>true</nonMemberAccess> <secret>0w4O2zTTF0WdL4ymF8D0_A</secret> <defaultLayout>allEqual</defaultLayout> </coSpace>
Notieren Sie sich die Leerzeichen-ID, die fett markiert ist, da diese in Schritt 4 zum Erstellen der accessMethod für diesen bestimmten Bereich verwendet werden muss.
Schritt 4: Erstellen Sie eine neue accessMethod in diesem Bereich mit demselben URI (und Anruf-ID), und weisen Sie ihm das HostanrufLegProfile zu.
Sie möchten eine andere Zugriffsart für den Bereich als den Gastzugriff erstellen, der derzeit die Standardeinstellung ist. Dies geschieht durch Angeben einer accessMethod im Leerzeichen selbst mithilfe eines POST-Befehls auf /api/v1/coSpaces/<coSpace-ID>/accessMethoden, wobei die coSpace-ID der fett markierte Wert in Schritt 3 ist (96d28acb-86c6-478d-b81d a-a37ffb0adafc), auf die das LegProfile des Hosts von Schritt 2 sowie dasselbe URI- und Anruf-ID-Feld angewendet wird. Sie können einen nicht leeren Passcode für die Hosts hinzufügen, die über CallID eine Verbindung herstellen (ohne als Benutzer über webRTC angemeldet zu sein).
Nach einer GET-Anforderung für diese Space AccessMethod (/api/v1/coSpaces/<coSpace-ID>/accessMethods/<accessMethod-ID>) müssen Sie eine ähnliche Ausgabe wie diese sehen können, in der Sie dieselbeURI (global) und Anruf-ID (1234) sowie die Einrichtung von CallLegProfile für den Host 2 und Host-Passcode(12345):
<?xml version="1.0" ?> <accessMethod id="c4ecc16e-945f-4e35-ba03-d9b69107b32c"> <uri>global</uri> <callId>1234</callId> <passcode>12345</passcode> <callLegProfile>0e76e943-6d90-43df-9f23-7f1985a74639</callLegProfile> <secret>kffO1zTTE0feL4fsdf43w_B </secret> </accessMethod>
Schritt 5: Weisen Sie dem Speicherplatz den Benutzer ownerJidto zu. (falls nicht zugewiesen). Fügen Sie ownerJID zum Speicherplatz hinzu, indem Sie den Befehl aPUTcommand on/api/v1/coSpaces/<coSpace-ID> (user1@evacanoalone.net) auf dem Speicherplatz angeben.
Nachdem Sie eine GET-Anforderung für diesen Bereich gesendet haben, müssen Sie sehen können, dass ownerID und ownerJidhave dem Bereich zugewiesen wurde:
<?xml version="1.0" ?> <coSpace id="96d28acb-86c6-478d-b81a-a37ffb0adafc"> <name>Global</name> <autoGenerated>false</autoGenerated> <uri>global</uri> <callId>1234</callId> <callLegProfile>bfe7d07f-c7cb-4e90-a46e-4811bbaf6978</callLegProfile> <nonMemberAccess>true</nonMemberAccess> <ownerId>1d942281-413e-4a2a-b776-91a674c3a5a9</ownerId> <ownerJid>user1@evacanoalone.net</ownerJid> <secret>0w4O2zTTF0WdL4ymF8D0_A</secret> <numAccessMethods>1</numAccessMethods> <defaultLayout>allEqual</defaultLayout> </coSpace>
Notieren Sie sich die OwnerID (1d942281-413e-4a2a-b776-91a674c3a5a9).
Schritt 6.Fügen Sie diese OwnerID (1d942281-413e-4a2a-b776-91a674c3a5a9) aus Schritt 5 als Mitgliedsbenutzer dem Speicher hinzu, und weisen Sie diesem Member-Benutzer hostcallLegProfile zu. Dazu geben Sie UserJIdandhost callLegProfiledas Leerzeichen selbst (geben Sie die CoSpaceID an) mithilfe des POST-Befehls (/api/v1/coSpaces/<coSpaceID>/coSpaceUsers) an.Andere Parameter im CoSpaceUsers. Sie finden sie in Abschnitt 6.4.2 des API-Leitfadens, in dem die gezeigten APIs ebenfalls für diese Konfiguration relevant sein können:
<canDestroy>true</canDestroy>
<canAddRemoveMember>true</canAddRemoveMember>
<canChangeName>true</canChangeName>
<canChangeUri>false</canChangeUri>
<canChangeCallId>false</canChangeCallId>
<canChangePasscode>true</canChangePasscode>
<canPostMessage>true</canPostMessage>
<canDeleteAllMessages>false</canDeleteAllMessages>
<canRemoveSelf>false</canRemoveSelf>
Vergewissern Sie sich, dass der Member-Benutzer durch aGETcommand (/api/v1/coSpaces/<coSpaceID>/coSpaceUsers?) zum Speicherplatz hinzugefügt wurde.
<?xml version="1.0" ?> <coSpaceUsers total="1"> <coSpaceUser id="1d942281-413e-4a2a-b776-91a674c3a5a9"> <userId>1d942281-413e-4a2a-b776-91a674c3a5a9</userId> <userJid>user1@evacanoalone.net</userJid> <autoGenerated>false</autoGenerated> </coSpaceUser> </coSpaceUsers>
Notieren Sie sich die Benutzer-ID (falls es sich um eine andere Formulareigner-ID im Formular Schritt 5 handelt). Überprüfen, ob der CallLegProfile CoSpaceUser durch eine GET-Anforderung zugewiesen wurde, die die CoSpaceIDund BenutzerID (/api/v1/coSpaces/<coSpaceID>/coSpaceUsers/<userID>) spezifiziert hat
<?xml version="1.0" ?> <coSpaceUser id="1d942281-413e-4a2a-b776-91a674c3a5a9">1d942281-413e-4a2a-b776-91a674c3a5a9 user1@evacanoalone.net <autoGenerated>false</autoGenerated> <canDestroy>true</canDestroy> <canAddRemoveMember>true</canAddRemoveMember> <canChangeName>true</canChangeName> <canChangeUri>false</canChangeUri> <canChangeCallId>false</canChangeCallId> <canChangePasscode>true</canChangePasscode> <canPostMessage>true</canPostMessage> <canDeleteAllMessages>false</canDeleteAllMessages> <canRemoveSelf>false</canRemoveSelf> <canChangeNonMemberAccessAllowed>true</canChangeNonMemberAccessAllowed>0e76e943-6d90-43df-9f23-7f1985a74639 </coSpaceUser>
Sie können sich jetzt bei demselben Meeting einwählen:
- durch Wählen einer URI (gefolgt von der Domäne, wie sie in Ihren Anrufzuordnungsregeln konfiguriert ist)
- durch Eingabe des Anruf-ID-Werts 1234 über IVR oder WebRTC join (kein Passcode)
Indem Sie sich als Benutzer (Mitglied des Bereichs mit zugewiesenem "host" callLegProfile, in diesem Szenario mit user1@evacanoalone.net) über webRTC anmelden und dem Leerzeichen ("globale" URI) beitreten.
- indem Sie den globalen URI (gefolgt von der Domäne, wie sie in Ihren Anrufzuordnungsregeln konfiguriert wurde) und den Passcode 12345 wählen.
- durch Eingabe des Anruf-ID-Werts 1234 über IVR oder WebRTC join (mit Host-Passcode 12345)
Wenn nur Gäste in den Raum eintreten, werden sie alle in einem Empfangsraum untergebracht, der darauf wartet, dass der Gastgeber beitritt. Sobald ein Gastgeber Mitglied wird, werden alle Gäste und Gastgeber in die Konferenz aufgenommen. Wenn keine Hosts mehr im Raum verbunden sind, aber noch einige Gäste, kehren sie zum Lobby-Bildschirm zurück, wie in der Konfiguration der Deaktivierung im Deaktivierungsmodus-Parameter im Gast-CallLegProfile wie in Schritt 1 gezeigt.
Host (Eigentümer/Mitglied) kann ein Kennwort für Gäste direkt in der WebRTC-App festlegen (bearbeiten/entfernen) oder den Zugriff eines Nichtmitglieds (Gast) für den Raum vollständig deaktivieren:
Dieser Abschnitt enthält Informationen, die Sie zur Fehlerbehebung bei Ihrer Konfiguration verwenden können.
Die Protokollierung von CMS zeigt uns kurz an, wenn Sie als Gast beitreten oder der erste Host beitritt. Am besten ist es jedoch, zu überprüfen, ob GET-Anforderungen das callProfile sowie die Definition von Gast- und Host-CallLegProfile und deren Zuweisung zu den jeweiligen accessMethods (oder der Standardzugriffsmethode) oder auf höherer Ebene (globaler Ebene oder Tenant-Ebene) verwenden.
Über diese Struktur erhalten Sie alle Informationen:
In der in diesem Beispiel gezeigten CMS-Protokollierung kommen die ersten beiden Gastteilnehmer ein (rufen Sie 38 von 2000@steven.lab an und rufen Sie 39 von 1060@steven.lab an), die sich in den guestpin.space@acano.steven.lab-Bereich begeben und dann dem Host beitreten. Sie können aus dem Ausschnitt sehen, dass er uns für Gäste darüber informiert, was damit getan werden muss (deaktiviert werden), und Sie können sehen, dass sich dieses Verhalten für diese Anrufe ändert, wenn der Host (stejanss.movi@steven.lab) mit dem Raum verbunden ist (aufhört zu deaktivieren). Ebenso kann man die gleiche Protokollierung wiedersehen, wenn die Gäste wieder in die Lobby gehen, sobald keine Hosts mehr auf dem Raum vorhanden sind (zu deaktivieren).
2017-02-21 17:48:54.809 Info call 38: incoming encrypted SIP call from "sip:2000@steven.lab" to local URI "sip:guestpin.space@acano.steven.lab" 2017-02-21 17:48:54.822 Info call 38: setting up UDT RTP session for DTLS (combined media and control) 2017-02-21 17:48:54.837 Info call 38: compensating for far end not matching payload types 2017-02-21 17:48:54.847 Info sending prompt response (2) to BFCP message 2017-02-21 17:48:54.847 Info call 38: sending BFCP hello as client following receipt of hello when BFCP not active 2017-02-21 17:48:54.883 Warning call 38: replacing pending BFCP message "PrimitiveHelloAck" with "PrimitiveHelloAck" 2017-02-21 17:48:54.883 Info call 38: BFCP (client role) now active 2017-02-21 17:48:59.294 Info call 39: incoming encrypted SIP call from "sip:1060@steven.lab" to local URI "sip:guestpin.space@acano.steven.lab" 2017-02-21 17:48:59.310 Info call 39: setting up UDT RTP session for DTLS (combined media and control) 2017-02-21 17:48:59.323 Info call 39: compensating for far end not matching payload types 2017-02-21 17:48:59.569 Info sending prompt response (2) to BFCP message 2017-02-21 17:48:59.569 Info call 39: sending BFCP hello as client following receipt of hello when BFCP not active 2017-02-21 17:48:59.746 Info call 39: BFCP (client role) now active 2017-02-21 17:49:07.971 Info configuring call e2264fb0-483f-45bc-a4f3-5a4ce326e72c to be deactivated 2017-02-21 17:49:07.972 Info participant "2000@steven.lab" joined space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN) 2017-02-21 17:49:12.463 Info configuring call b1b5d433-5ab5-49e1-9ae3-3f4f71703d1b to be deactivated 2017-02-21 17:49:12.463 Info participant "1060@steven.lab" joined space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN) 2017-02-21 17:49:12.463 Info conference "Guest/Host PIN": unencrypted call legs now present 2017-02-21 17:49:16.872 Info call 40: incoming encrypted SIP call from "sip:stejanss.movi@steven.lab" to local URI "sip:guestpin.space@acano.steven.lab" 2017-02-21 17:49:16.885 Info call 40: setting up UDT RTP session for DTLS (combined media and control) 2017-02-21 17:49:24.260 Info call 40: audio prompt play time out 2017-02-21 17:49:26.670 Info participant "stejanss.movi@steven.lab" joined space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN) 2017-02-21 17:49:26.670 Info call e2264fb0-483f-45bc-a4f3-5a4ce326e72c ceasing to be deactivated 2017-02-21 17:49:26.670 Info call b1b5d433-5ab5-49e1-9ae3-3f4f71703d1b ceasing to be deactivated 2017-02-21 17:49:30.832 Info call 40: ending; remote SIP teardown - connected for 0:14 2017-02-21 17:49:30.833 Info participant "stejanss.movi@steven.lab" left space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN) 2017-02-21 17:49:30.833 Info configuring call e2264fb0-483f-45bc-a4f3-5a4ce326e72c to be deactivated 2017-02-21 17:49:30.833 Info configuring call b1b5d433-5ab5-49e1-9ae3-3f4f71703d1b to be deactivated