Azure Bot Calling - 403 Forbidden / 7505 Tenant Mismatch on Existing Meeting

Question

I'm struggling to bypass the 403/7505 error, how to bypass it?

I have done the following configuration:

App Registration: Multi-tenant application (AzureADMultipleOrgs) with Admin Consent granted for Calls.JoinGroupCall.All, Calls.InitiateGroupCall.All, and Calls.AccessMedia.All.

Tenant Consistency: The Bot, the App Registration, the Meeting Organizer, and the Meeting itself are ALL in the exact same Tenant ID.

Bot Implementation: Python using MS Graph SDK.

Infrastructure: I verified that the Application Access Policy is assigned to the bot's App ID and that the Bot Channels Registration has "Calling" enabled with the correct webhook.

My latest test result showing: When attempting to join a pre-existing, valid scheduled meeting, the Graph API consistently returns 403 Forbidden with error code 7505 (Request authorization tenant mismatch). This happens even though I have verified via JWT decoding that the Access Token has the correct Tenant ID and Audience.

Technical Data (IDs redacted for privacy):

1. Configuration

Bot App ID: [My-App-ID] (Configured as Multi-Tenant)

Bot Tenant ID: [My-Tenant-ID]

Meeting Tenant: [My-Tenant-ID] (Verified via meeting URL tid parameter)

Token Roles: Verified as Calls.JoinGroupCall.All, Calls.AccessMedia.All, Calls.InitiateGroupCall.All.

2. The Join Request Payload (joinWebUrl Strategy)

JSON

{
  

3. The Error Response

Plaintext

HTTP Status:        403
Error Code:         7505
Error Message:      Request authorization tenant mismatch.
Inner Error:        Request authorization tenant mismatch.

(Note: I have the specific Request-ID and Client-Request-ID available to share in a private message if required by support).

Since the tenant IDs are identical across the board (Token, Payload, and URL), why is the Media Control Plane rejecting this as a mismatch? Is there a known issue where a Multi-tenant App Registration fails to authorize against an existing meeting if the Bot Service resource configuration was recently toggled?

Answer 1

The 403 Forbidden error with code 7505 indicating a "Request authorization tenant mismatch" typically occurs when there is a discrepancy in the tenant information used during the API request. Here are some steps to troubleshoot and potentially resolve this issue:

1. Verify Token Audience and Tenant ID: Ensure that the access token being used has the correct audience (aud) and tenant ID. You mentioned that you have already verified this, but double-checking can help rule out any oversight.
2. Check App Registration Permissions: Confirm that the app registration has the necessary permissions granted and that these permissions are consented to by an administrator. You should ensure that Calls.JoinGroupCall.All, Calls.InitiateGroupCall.All, and Calls.AccessMedia.All are indeed granted.
3. Application Access Policy: Since you've assigned the Application Access Policy to the bot's App ID, verify that the policy is correctly configured and that it allows the bot to access the necessary resources in the tenant.
4. Meeting Configuration: Ensure that the meeting itself is configured correctly and that it is accessible by the bot. Sometimes, meetings may have specific settings that restrict access.
5. Multi-Tenant Configuration: Since your app is configured as a multi-tenant application, ensure that there are no restrictions or policies in place that might prevent it from accessing resources across tenants. Sometimes, multi-tenant configurations can lead to unexpected behavior if not set up correctly.
6. Recent Changes: If you recently toggled any configurations related to the Bot Service resource, consider reverting those changes to see if that resolves the issue. Sometimes, changes can take time to propagate or may lead to temporary inconsistencies.
7. Debugging Information: Utilize the Request-ID and Client-Request-ID you have to gather more information from support if the issue persists. This can help in diagnosing the problem more effectively.

If after checking all these points the issue still persists, it may be beneficial to reach out to Microsoft support for further assistance, providing them with the specific Request-ID and Client-Request-ID for more targeted help.