Reference17:Apps/PbxManager/App Conference Invitations
This article describes the configuration of conference-invitations. Note that changes you made are not only safed when clicking on OK. They will automatically be saved before sending a test email. The following settings can be configured:
Email (receiving)
The app runs its own built-in mail receiver. The address of that server is the one of the AP the conference-invitatiosn service is running on. You need to create an email address in Exchange and let Exchange redirect the mail to conference-invitation, so that conference-invitations will be one of the attantends for meetings created in Outlook as myApps Meeting. This is necessary to let conference-invitations know about the meeting. This are the settings to receive emails:
- Email: The email address of the app itself.
- Email user: User name that the delivering mail server (or relay) may use to authenticate against the app’s built-in mail receiver.
- Email password: Password belonging to email.
- Email domain: The domain name with which the app’s mail receiver identifies itself towards the delivering mail server, e.g. <code>example.com</code>. Some mail servers and relays refuse delivery if the receiving side announces an unexpected or empty name, and the value is also used when the app challenges the delivering server for authentication. Use the domain that matches the E-mail address above.
- SMTP port: TCP port on which the app listens for incoming invitation mails (default 54242).The app platform normally does not let an app occupy the well-known port 25, therefore a high port is used by default. Your mail system must be configured to deliver mail for the E-mail address to the app’s host on exactly this port (transport rule / forwarding / relay entry, depending on your mail product).
Email (sending)
When the app has successfully processed an invitation, it can answer the organizer with an acceptance mail (an iCalendar reply) so that the organizer sees the conference as "accepted" in their calendar. The app also uses this configuration to send the test mail. The reply is only sent if all four of the following fields are filled. If any of them is empty, invitations are still processed and stored normally, but no acceptance mail is sent, and a corresponding warning is written to the app log.
- Email host (sending): The host name with which the app identifies itself towards your outgoing mail server (e.g. pbx.example.com). Many mail servers reject mail from a client that announces an unknown or empty name.
- Email server (sending): The outgoing mail server the app connects to, in the form host or host:port (e.g. mail.example.com:587). If no port is given, the standard SMTP port 25 is used. The field may be left empty when a hosted OAuth2 mode is selected (see below) — in that case the provider’s default server is used.
- Email user (seding): User name of the mailbox that is used to send the acceptance mails.
- Email password (sending): Password of that mailbox. Not needed with OAuth2 authentication — there the token obtained from the OAuth2 fields is used instead of a password.
OAuth2 (authentication against Microsoft mail servers)
If your outgoing mail server no longer accepts a plain user name and password — which is the case for Microsoft 365 / Exchange Online — the app can obtain an access token instead. The following OAuth2 modes can be configured:
| Mode | Meaning |
|---|---|
| Off | No OAuth2. The app authenticates with E-mail user (sending) and E-mail password (sending). Use this for on-premises mail servers and for any provider that still accepts passwords. |
| Exchange (smtp.office365.com:587) | Delegated access to Exchange Online. The app acts on behalf of a mailbox owner whose consent was granted once via the app registration. |
| Microsoft 365 (smtp.office365.com:587) | Access to a Microsoft 365 mailbox using the mailbox owner’s credentials in combination with the registered application. |
Selecting Exchange or Microsoft 365 also fills the placeholder of E-mail server (sending) with <code>smtp.office365.com:587</code>, which is used when you leave that field empty. NOTE: All values below come from the application you register in the Microsoft Entra ID (Azure AD) portal for this purpose. The registered application needs permission to send mail via SMTP for the mailbox in question.
The fields shown below the OAuth2 selector change depending on the selected mode; fields that are not needed are hidden
- OAuth2: The OAuth2 mode to use.
- Client ID: (shown for Exchange and Microsoft 365) The application (client) ID of the registered application.
- Client Secret: (shown for Exchange and Microsoft 365) The client secret created for that registered application. Note that secrets have an expiry date in Entra ID — when the secret expires, sending stops working and the value must be renewed here.
- Owner Username: (shown for Exchange and Microsoft 365) The mailbox that is used for sending, i.e. the account the token is issued for — typically identical to E-mail user (sending).
- Owner Password: (shown for Microsoft 365 only) The password of that mailbox account. Only required for the Microsoft 365 mode, where the token is requested with the owner’s credentials. Stored encrypted; the field shows a masked dummy value.
- Tenant: (shown for Exchange and Microsoft 365) Your Microsoft tenant — either the tenant ID (GUID) or the tenant domain, e.g. <code>example.onmicrosoft.com</code>. It determines against which directory the token is requested.
Testing the email configuration (sending)
To test if your configration is correct, you can send a test email.
Note: Clicking the test email button will save the configuration!
- Test e-mail address: A recipient address to which a test mail is sent, e.g. your own address. The value is not stored in the configuration; it is only used for the test.
- Send test e-mail (button): Saves the current configuration first (so the test really uses what you see on screen) and then sends a short test mail from the configured E-mail address to the address entered above, using the sending configuration and, if selected, OAuth2. The subject and body of the test mail are in the language of your Settings app. The result appears next to the button:
- success message — the mail was handed over to the mail server successfully. Check the recipient’s inbox to confirm the delivery path as well.
- error message — sending failed, together with the reason reported by the mail server. Details are in the app log.
- If the entered address is not a valid e-mail address, the test is not performed and the field is highlighted for correction.
A successful test proves the sending direction only. The receiving direction is verified by creating a meeting with the Outlook add-in and checking that the invitation appears in the app.
PBX conference
Selection list of all conference objects that exist in your PBX. Choosing an entry does two things:
- The app is registered on the selected conference object, i.e. the conference object is linked with this app instance. If the app was previously assigned to another conference, that assignment is removed automatically, so exactly one conference belongs to the app instance.
- The name of the conference object is stored and inserted into the join links that the Outlook add-in writes into the meeting body — both the link that starts a call in the innovaphone client and the link that opens the conference in the browser.
If the list is empty, no conference object exists yet in the PBX. Create one first; without a selected conference the configuration cannot be saved. The settings need to cofigure are:
- Conference object: The conference object to use for the meetings.
- Conference phone no.: The phone number that participants dial to join the conference. It is printed into the meeting invitation text, so that attendees without an innovaphone client (e.g. mobile or external participants) can dial in. When you pick a conference in the list, the field is filled automatically from the number of the selected conference object. If the object has no usable number, the field stays empty and shows a hint to enter the number manually — enter the number in the form external participants must dial, including any prefixes needed from the outside. The field must not be empty!
Outlook add-in
Download manifest… (button)
Downloads the <code>manifest.xml</code> of the Outlook add-in. The file is generated for the current app instance and for the language currently selected in your Settings app, i.e. it already contains the correct URLs of this installation and the localized button label and tooltip. Deploy this file to your users with the mechanism provided by Microsoft (centralized deployment in the Microsoft 365 admin center, or sideloading for a single user). After deployment, organizers get an additional button in the Outlook meeting compose window that creates the conference data for the meeting. The language used for in the XML for the button will be defined by the languge your myApps client has when downlaoding the file.