anchorOverview of Guest-to-Guest Meetings

In the context of guest-to-guest Webex meetings, guests are defined as non-licensed users. Guests are often used in applications that provide some form of expert services. For example, a doctor may talk to a patient or a customer may talk to a support agent, or a plumber may have a video conference with a homeowner to pre-consult the work. Common to these use-cases is the idea that none of the participating parties are permanently licensed as hosts for Webex meetings.

In the past, these apps were built on top of space-backed meetings where a space was established between the two parties to conduct the meeting. This approach used to work, albeit with limited functionality. For example, recording the meeting, providing meeting transcripts, or patching in a translator was impossible. In addition, meetings between only guests are expressly denied under our terms and conditions, which in all cases mandates a licensed user to sponsor the meeting.

With the advent of the Webex Suite Meeting Platform (WSMP), the approach to guest-to-guest meetings is changing. The space-backed meetings are no longer available and instead replaced by regular Webex Meetings licensed by a guest-to-guest Service App. The proven and successful meeting backend now powers all meeting functionality. The new attendee experience is a full-featured meeting with all the standard meeting controls like recording, transcription, etc., available even when only guests participate. The meetings infrastructure licenses the guest-to-guest meeting experience from the licensed Service App, which only counts the number of simultaneous meetings. The following sections provide additional background information and developer guidance on the development of guest-to-guest Service Apps.

anchorDeveloping a Guest-to-Guest App

To develop a guest-to-guest Service App you need to do the following:

1. Get a trial subscription from Cisco Commerce Workspace (CCW) or a sandbox that is configured for guest-to-guest meetings. Cisco preconfigures the sandbox with a guest-to-guest meeting site as part of the sandbox setup. You can find the name of the guest-to-guest site by logging in to your sandbox’s Control Hub as an admin and loading the meeting site list.
2. With your sandbox developer account, log on to developer.webex.com and create a Service App with the mandatory scopes guest-meeting:rw, meeting:schedules_readmeeting:schedules_write ,and any additional desired scopes, depending on which Webex APIs you want to call to manage your meetings, spaces and guests.

3. Submit your app for admin approval. This action makes your Service App visible to an admin in Control Hub in your sandbox organization.
4. As an admin in Control Hub, authorize your Service App to manage your guest-to-guest site and meetings. This can be done in Control Hub here. Your Service App must be tied to only one available guest-to-guest site. For now, Control Hub enforces a 1-to-1 mapping between a service app with the guest meeting:rw scope and a guest meeting site.

5. As a developer, retrieve the access and refresh tokens for the service app from your Service App details page on developer.webex.com. Safely store the tokens.

6. With the access token in hand, schedule a meeting via the meetings API. The meeting siteUrl must be the guest-to-guest site and should be autoconfigured during the Service App licensing and authorization process.

7. Create join links for the guests. When the scheduled time comes around, the guests can use the join link to attend the meeting. You may need to have one guest use the startLink while the other guest uses the joinLink. The guest with the startLink will be treated as the host. Your guests, who are not individually licensed for Webex Meetings, can now experience the full meeting experience.

anchorMeetings without a host role joining

Sometimes, you may not want to grant host privileges to an attendee. Instead, both parties can use the joinLink to join and start the meeting. To achieve this behavior, you need to do the following:

1. In Control Hub, make sure you have enabled the setting They can join the meeting under Services -> Meeting -> [Select your guest site] -> All -> Security -> Webex Meeting Security. This allows an attendee to join a meeting without the host.

2. The Service App meetingPreferences should include the following settings:

   ...
   "schedulingOptions": {
   "enabledJoinBeforeHost": true,
   "joinBeforeHostMinutes": 5,
   "enabledAutoShareRecording": false,
   "enabledWebexAssistantByDefault": false
   },
   ...
   

   You can retrieve the Service App meetingPreferences using the Service App access token.

3. When scheduling the meeting via the create a meeting API with the Service App access token, please set the following field: "unlockedMeetingJoinSecurity": "allowJoin". A full request body for a guest-to-guest meeting may look like this

   {
   "title": "g2g Meeting Blue",
   "start": "2024-07-24T15:00:00Z",
   "end": "2024-07-24T15:30:00Z",
   "enabledJoinBeforeHost" : true,
   "joinBeforeHostMinutes" : 15,
   "unlockedMeetingJoinSecurity" : "allowJoin"
   }
   

Persistent guests

If you give your Service App the guest-issuer:read and guest-issuer:write scopes, you can use it to create two or more guests. You can do this with a POST to /guests/token and the Service App's access token as the Bearer token. Details can be found here. Then, you would launch the SDK with the guest token and let them join the meeting.

The persistent guest approach is also suitable if you want the guests to chat outside a meeting in the Webex App or to reach parity with previous space-backed workflows.

Here is a comparison with the previous workflow:

*Adhoc meetings in spaces can be facilitated by setting the roomId and adHoc=true in the create a meeting API call.

anchorGuest Experience

When guests click the join link, they can join the meeting either via an installed Webex native client or the Webex browser. If you want host control over a meeting, a join link with host control can be generated, i.e., startLink. This allows a guest to have full meeting controls, including the ability to manage the recording functions in the meeting, add additional guests dynamically, and more.

The guests can also join the meeting via our Webex SDKs, usually from an Android or iOS device. If you want to use the SDKs, you will have to create guests via the Service App and use the guest to join the meeting. More details can be found in the section Join the Meeting by Entering a Password or Captcha.

anchorAdditional Reading

At this point, you should now be well on your way with the new Webex Suite Meeting Platforms method of creating guest-to-guest meetings. You can add your own unique application functionality, whether it be reporting, transcription, or AI. Once your users are satisfied with your app, you may consider submitting it to the Webex App Hub for broader consumption by the larger Webex user base. The following sections provide additional background information for users not familiar with the Service App concept.

anchorService App Background Information

What are Service Apps?

Service Apps represent a specific application type in the Webex developer program. They are recommended for apps that are mission-critical and long-lived, often required for administrative functionality. Service Apps are commonly used for ongoing provisioning or reporting systems. They serve as a combination of two other application types: bots and integrations.

Service Apps inherit their independent nature from bots. When a Service App is authorized, a machine account is created in the authorizer's organization. The developer retrieves the access and refresh token pair for each Service App's machine account. All API calls made with the Service App tokens are performed on behalf of this machine account. Since the machine account is not directly managed, it cannot be accidentally deleted or manipulated in a way that would disrupt the app's functionality.

From integrations, Service Apps adopt the concept of scopes and the requirement for authorization through OAuth clients.

Scopes determine the specific API calls that a Service App is permitted to make. Service App authorization is carried out in the Control Hub GUI and must be performed by a Full Admin. In essence, Service Apps can be thought of as bots with scopes.

Choosing Between a Bot and a Service App

When faced with the decision between a bot or a Service App as your application type, you should consider the least privilege principle. If a bot can provide all the necessary functions, it is recommended to use the bot application type. However, bots have certain limitations:

• They cannot act as compliance officers.
• They don't have administrative privileges.
• They cannot access messages that are not directed to them.
• They are not equipped to handle meetings or media (audio/video), which is why they are unsuitable for our guest-to-guest meetings.

If you require any form of administrative functionality or any of the capabilities mentioned above, it is advisable to use a Service App, as we do for our guest-to-guest flow. Currently, Service Apps always have an administrative role.

anchorService Apps as Guest-to-Guest Meeting Facilitators

In the guest-to-guest meeting scenario, we use the Service App as the meeting orchestrator for guest-to-guest meetings. If we consider what makes Service Apps special, our design decision becomes apparent. The app needs to run continuously, and we cannot risk it stopping because a user leaves or changes their password. Additionally, the app requires access to meeting functionality to schedule, monitor, and report on meetings. Using a user-authorized integration as an alternative application type would pose a risk, as the user's departure or accidental deletion, or password change, would render the tokens invalid. In addition any human user can start only a limited set of simultaneous meetings while our guest-to-guest Service App can start as many simultaneous meetings as it is licensed for.

Service Apps as Guest Creators

Guests are temporary, unnamed, and unlicensed users. They are used in situations where a named user license is not necessary or when interaction in Webex is time-bound. For example, when a customer launches the Webex meetings or chat widget from a company website, they typically do not need ongoing interaction through Webex. Instead, they should be provided with a temporary identity that allows them to interact with the agent, which will be discarded after the exchange.

In the past, guests were created through a different app type called the Guest Issuer. However, we have changed the guest creation process and now allow Service Apps to create guests. The main advantage of guest creation via Service Apps is that the flow is inherently admin-approved. Guest creation via the guest issuer was possible for any developer in an organization without admin approval. With the old Guest Issuer flow, the guest organizations were not admin-managed, and admins had no insight into which guests were created in the organization. With the new approach, guests can only be created after an admin approves the Service App in the Control Hub. Admins can also query the number of guests created by the Service App.

Guest-To-Guest Subscriptions, Guest Sites, and Licenses

We offer a new subscription for guest-to-guest meetings and, along with it, a new license. Remember, guest-to-guest meetings, or meetings without the sponsor of a license, were and are a terms and conditions violation. Now, the Service App takes on the role of the license sponsor. The Service App does not need to participate in the meeting but does need to schedule and start it ( via a startLink) and may create the guests who ultimately join the meeting. Unlike a regular user, the Service App can sponsor as many simultaneous meetings as allowed by the subscription. When procuring the subscription, the partner orders a specific number of concurrent meetings.

For example, let's say the partner ordered 150 meetings with the subscription. This means the Service App can sponsor up to 150 meetings in the inProgress state at the same time, allowing it to host up to 150 simultaneous meetings. When there are already 150 ongoing meetings and a guest tries to start the 151 st meeting by clicking the join link or joining via the SDK, a license error is issued. Each meeting can have up to 400 participants joining.

Service Apps in the guest-to-guest flow are bonded during the authorization process to a specially configured and marked site, known as the guest-to-guest site. The site is set up in the organization when an admin activates the subscription via the provisioning wizard. The admin determines and assigns the site name, which, like any other site setup, must be globally unique. The necessary configuration for this guest-to-guest site is handled by our backend system. Only the Service App is allowed as a user on this site. Guests join guest-to-guest meetings but are not part of the guest-to-guest site.

Webhook Notification

The organization of the Service App developer and the organization where the guest-to-guest meetings occur are not necessarily the same. In fact, for most applications, the developer and the authorizing admin are in separate organizations. The developers need to be informed of the authorization of the Service App by the admin in order for them to retrieve the tokens. To facilitate this, we provide a webhook with the resource serviceApp and the event types authorized and deauthorized. When the admin authorizes the Service App, a webhook is sent to the registered targetURL. The webhook contains information about the Service App, such as the granted scopes and the list of guest-to-guest sites the Service App was authorized for. With the webhook, the developer knows they can retrieve the tokens to make API calls. They also know which Webex sites these tokens can be used for scheduling meetings. When an admin deauthorizes a Service App, the tokens become invalid. The developer will receive a serviceApp:deauthorized webhook.

anchorConclusion

Guest-to-guest meetings replace the older space backed meetings approach. When using this mechanism guests and hosts are awarded with a full fledged meeting experience. They also get rid of the process of pooling licenses from human users to manage guest-to-guest meetings.