Konfiguration und Fehlerbehebung für Gastzugriff und Hostzugriff in CMS-Bereichen

Einführung

In diesem Dokument wird beschrieben, wie Sie mithilfe von API-Befehlen Gastzugriff und Host-Zugriff auf Bereiche des Cisco Meeting Server (CMS) einrichten.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Cisco Meeting Server (CMS) mit eingerichteten Räumen, die Anrufe tätigen können
• API-Client (z. B. Poster, Postman) oder 
• CMS API-Leitfaden

Verwendete Komponenten

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.

Hintergrundinformationen

In diesem Dokument werden die folgenden Szenarios beschrieben:

• Gast- und Host-Teilnehmer verwenden unterschiedliche URIs oder Anruf-IDs.
• Derselbe URI wird von Gastteilnehmern und Host-Teilnehmern verwendet, bei denen die Differenzierung auf der Grundlage der PIN oder des Passcode-Eintrags erfolgt (beide nicht leer).
• Derselbe URI wird von Gastteilnehmern und Host-Teilnehmern verwendet, bei denen die Differenzierung auf der Grundlage von PIN- oder Passcode-Einträgen erfolgt (Mischung aus leer/nicht leer)
• Ein Host-Benutzer ist Mitglied des Bereichs und autorisiert über WebRTC-Anmeldung, Gastbenutzer treten dem Meeting mit callID bei. Dieselbe URI und CallID wird von Gastteilnehmern und Host-Teilnehmern mit leeren oder nicht leeren PIN-/Passcodes für Gastbenutzer verwendet.

Konfigurieren

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.

1) Konfiguration mit unterschiedlichen URIs

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:

1. Erstellen Sie einen Gast-CallLegProfile (fordert Aktivierung = true).
2. Erstellen Sie einen Host-callLegProfile (requireActivation = false)
3. Zuweisen des Gast-callLegProfile zu einem vorhandenen oder neuen Speicherplatz (die Standardzugriffsmethode)
4. Erstellen Sie eine neue accessMethod auf demselben Speicherplatz mit einem anderen URI (und Anruf-ID), und weisen Sie ihm das aufrufendeHostprofil zu.

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):

• präsentationBeitragZulässig
• rxAudioMute
• rxVideoMute
• Deaktivierungsmodus (deaktiviert) | Trennen | continueActivated) und deaktivierungModeTime [Aktion auszuführen, wenn der letzte Aktivator den Anruf verlässt]

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 
       
     

Überprüfen

Sie können sich jetzt bei demselben Meeting einwählen:

• Als Gast

        - 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)

• Als Host

         - 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.

2) Konfiguration mit denselben URIs, jedoch nicht leeren Gast- und Host-PINs/Passcodes

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:

1. Erstellen Sie einen Gast-CallLegProfile (fordert Aktivierung = true).
2. Erstellen Sie einen Host-callLegProfile (requireActivation = false)
3. Weisen Sie dem Gast callLegProfile einen vorhandenen oder neuen Speicherplatz zu, indem Sie einen Gast-Passcode (PIN) angeben (die Standardzugriffsmethode).
4. Erstellen Sie eine neue accessMethod auf demselben Speicherplatz mit demselben URI (unterschiedliche Anruf-ID), und weisen Sie dem Host callLegProfile einschließlich eines Host-Passcodes (PIN) zu.

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 
       
     

Überprüfen

Sie können sich jetzt bei demselben Meeting einwählen:

• Als Gast

           - 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

• Als Host

           - 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.

3) Konfiguration mit denselben URIs mit Kombination aus leerer Gast-PIN und nicht leerer Host-PIN

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:

1. Erstellen Sie einen Gast-CallLegProfile (fordert Aktivierung = true).
2. Erstellen Sie einen Host-callLegProfile (requireActivation = false)
3. Erstellen Sie ein callProfile mit der gewünschten passcodeMode- und passcodeTimeout-Konfiguration.
4. Weisen Sie dem Gast callLegProfile und callProfile von Schritt 3 einem vorhandenen oder neuen Speicherplatz zu, indem Sie einen Gast-Passcode (PIN) angeben (die Standardzugriffsmethode).
5. Erstellen Sie eine neue accessMethod auf demselben Speicherplatz mit demselben URI (unterschiedliche Anruf-ID), und weisen Sie dem Host callLegProfile einschließlich eines Host-Passcodes (PIN) zu.

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:

• passcodeMode

            - 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.

• passcodeTimeout: muss nur festgelegt werden, wenn passcodeMode auf Timeout gesetzt ist und die Zeitspanne vor der Interpretation des Passcodes als leeres Feld steuert

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 
       
     

Überprüfen

Sie können sich jetzt bei demselben Meeting einwählen:

• Als Gast

               - 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

• Als Host

               - 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

4) Ein Host-Benutzer ist Mitglied des Bereichs und autorisiert per webRTC-Anmeldung, Gastbenutzer treten dem Meeting mit callID bei. Dieselbe URI und CallID wird von Gastteilnehmern und Host-Teilnehmern mit leeren oder nicht leeren PIN-/Passcodes für Gastbenutzer verwendet.

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:

1. Erstellen Sie einen Gast-callLegProfile(needActivation = true).
2. Erstellen eines Host-callLegProfile(needActivation = false)
3. Zuweisen des Gast-callLegProfile zu einem vorhandenen oder neuen Speicherplatz (die Standardzugriffsmethode)
4. Erstellen Sie eine neue Zugriffsmethode auf demselben Speicherplatz mit demselben URI (und Anruf-ID), und weisen Sie ihm das Hosts callLegProfile zu.
5. Weisen Sie dem BenutzersownerJID denselben Speicherplatz zu. (falls nicht zugewiesen)
6. Fügen Sie dieseOwnerID als Memberbenutzer demselben Speicherplatz hinzu, und weisen Sie diesem MemberbenutzerLegProfile zu.

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>

Überprüfen

Sie können sich jetzt bei demselben Meeting einwählen:

• Als Gast

        - 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)

• Als Host

           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:

  

Fehlerbehebung

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:

1. GET auf /api/v1/callProfiles (bei Verwendung mit dem passcodeMode)
   > überprüfen Sie detailliert die gewünschte CallProfile-ID mithilfe von GET on/api/v1/callProfiles/<callProfile-ID>
2. GET auf /api/v1/callLegProfiles
   > überprüfen Sie detailliert die gewünschten CallLegProfile-IDs von Gast und Host mithilfe von GET on/api/v1/callProfiles/<callProfile-ID>
3. GET auf /api/v1/coSpaces
   > die gewünschte Leerzeichen-ID mithilfe von GET/api/v1/coSpaces/<coSpace-ID> im Detail überprüfen
   > Überprüfen Sie, ob die gewünschte CallProfile-ID (Schritt 1) und der Gast-CallLegProfile (Schritt 2) diesem Bereich zugeordnet sind.
      [falls nicht vorhanden, überprüfen Sie die weniger spezifischen Elemente wie Tenant (/api/v1/Tenants/<Tenant-ID>) oder globale (/api/v1/system/profiles) Ebene]
4. GET on /api/v1/coSpaces/<coSpace-ID>/accessMethods
   > überprüfen Sie detailliert die gewünschte accessMethod mithilfe von GET on/api/v1/coSpaces/<coSpace-ID>/accessMethods/<accessMethod-ID>, um zu überprüfen, ob dem Host callLegProfile zugewiesen wurde.

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

Zugehörige Informationen

• Technischer Support und Dokumentation - Cisco Systems
• CMS-Dokumentation