How to resolve "Failed to submit this app" error?
Hi Team, Just from Today, while submitting teams custom app via Developer Portal, error "Failed to submit this app." started to occur. I have tried with below condition but this error always occurs. Error also occurs on the app which we can submit update till yesterday. What is happening and how can we resolve it? (from this error message, we couldn't guess anything about the reason..) Checked: ・Publish from outside Developer Portal (apps > manage apps > send app to organization) succeeded so seems Developer Portal related Issue. ・For all apps, no validation error in "Publish to store" is found. Manifest itself seems to be fine. ・Create new custom app with minimum configuration and publish but failed with same error. ・Tried publish from both Teams client and Browser but failed with same error. ・Try same operation with different tenant but failed with same error.
Unable to get custom Teams app supported in shared channel
Hello everyone, I'm developing a Teams app which is working fine apart that I cannot the app supported in Teams shared channels. The app is a configurable tab app with no bots and no personal / static tabs Here is my manifest file: { "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.23/MicrosoftTeams.schema.json", "manifestVersion": "1.23", "version": "1.6.5", "id": "135a5af5-6bf3-XXXX-XXXX-XXXXXXXXXXXX", "developer": { "name": "COMPANY", "websiteUrl": "https://www.company.com/", "privacyUrl": "https://www.company.com/privacy", "termsOfUseUrl": "https://www.company.com/termsofuse", "mpnId": "XXXXXXX" }, "icons": { "color": "color.png", "outline": "outline.png" }, "name": { "short": "APP name", "full": "Full app name" }, "description": { "short": "A useful configurable Teams app", "full": "useful Teams app" }, "accentColor": "#FFFFFF", "configurableTabs": [ { "configurationUrl": "https://app.example.com/setup", "canUpdateConfiguration": true, "scopes": [ "team" ], "context": [ "channelTab" ] } ], "supportedChannelTypes": [ "privateChannels", "sharedChannels" ], "webApplicationInfo": { "id": "e11ad337-b136-XXXX-XXXX-XXXXXXXXXXXX", "resource": "api://app.example.com/e11ad337-b136-XXXX-XXXX-XXXXXXXXXXXX" }, "bots": [], "composeExtensions": [], "permissions": [ "identity" ], "validDomains": [ "app.example.com" ] } Does anyone have a similar issue? I've also tried to recreate the app using the Teams Developer Portal, but with no luck. Thank you Tobias
joinUrl is null when fetching via /chats/
Hi we have a production app for Teams that has broken as a result of a seemingly random api change that we can't find any documentation for in the api change log or anywhere for that matter. We are sending the following request via our front end app: https://graph.microsoft.com/v1.0/chats/19:meeting_MDc0NmQ4OWYtNTNiOC00NjY2LWIzYWItZGQ3ZTQyMWFjNzk2@thread.v2 { "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#chats/$entity", "id": "19:meeting_MDc0NmQ4OWYtNTNiOC00NjY2LWIzYWItZGQ3ZTQyMWFjNzk2@thread.v2", "topic": "Besprechung mit <organiser_name>", "createdDateTime": "2025-08-21T10:41:11Z", "lastUpdatedDateTime": "2025-08-21T12:49:30.002Z", "chatType": "meeting", "webUrl": "https://teams.microsoft.com/l/chat/19%3Ameeting_MDc0NmQ4OWYtNTNiOC00NjY2LWIzYWItZGQ3ZTQyMWFjNzk2%40thread.v2/0?tenantId=<tenant_id>", "tenantId": "<tenant_id>", "isHiddenForAllMembers": false, "viewpoint": { "isHidden": false, "lastMessageReadDateTime": "2025-08-21T12:59:24.376Z" }, "onlineMeetingInfo": { "calendarEventId": null, "joinWebUrl": null, "organizer": { "id": null, "displayName": null, "userIdentityType": "aadUser" } } } In this request we would parse `onlineMeetingInfo` for the joinWebUrl however we now get `null` We've tried using the webUrl but this does not work since it doesn't contain the organisation Id which we later rely on. Our flow is the following: We make a graph api request to fetch the joinUrl We send the joinWebUrl to our backend That Url is passed to a Teams Bot we are hosting on Azure which parses the URL to send a bot join request to Microsoft. However the new webUrl does not have the organiser Id and as a result the bot fails to join. We've verified by hardcoding the organiser Id var meetingInfo = new OrganizerMeetingInfo { Organizer = new IdentitySet { User = new Identity { Id = <we_hard_coded_this> }, }, }; meetingInfo.Organizer.User.SetTenantId(tenantId) And we then use this as following: var tenantId = (meetingInfo as OrganizerMeetingInfo)?.Organizer .GetPrimaryIdentity() .GetTenantId(); var mediaSession = this.CreateLocalMediaSession(); var joinParams = new JoinMeetingParameters(chatInfo, meetingInfo, mediaSession) { TenantId = tenantId, }; if (!string.IsNullOrWhiteSpace(callParams.DisplayName)) { // Teams client does not allow changing of ones own display name. // If display name is specified, we join as anonymous (guest) user // with the specified display name. This will put bot into lobby // unless lobby bypass is disabled. joinParams.GuestIdentity = new Identity { Id = Guid.NewGuid().ToString(), DisplayName = callParams.DisplayName }; } if (!callParameters.TryAdd(chatInfo.GetMeetingId(), new() { AccessToken = callParams.AccessToken, AccountId = callParams.AccountId, BackendUrl = callParams.BackendUrl, JoinUrl = callParams.JoinUrl, Protocol = callParams.Protocol, Origin = callParams.Origin, InviterParticipantId = callParams.InviterParticipantId, SubscriptionId = callParams.SubscriptionId, })) { logger.Warning("Parameters for call already exist."); } var statefulCall = await this.Client.Calls() .AddAsync(joinParams) .ConfigureAwait(false); This is quite urgent as it's impacting our customers, could someone please have a look at provide us an update here? Thank you.
No Tabs or Buttons Appearing in Teams
I just started a new Community in Teams. The only option I have in the tool bar is to upload files. Nothing to create anything new like folders. It's coming up that way on other computers and I've run out of ideas. Here is what I am seeing. Any help would be appreciated. Thanks. ChuckA Point of View on transitioning from PRI/BRI Lines to SIP Trunking
The telecommunications industry from past few years is witnessing a significant migration from traditional circuit-switched technologies like Primary Rate Interface (PRI) and Basic Rate Interface (BRI) to modern packet-switched Session Initiation Protocol (SIP) trunking. This transition represents a fundamental shift in how voice communications are delivered and managed in business environments. Let first begin with understanding the basics of PRI and BRI technologies PRI (Primary Rate Interface) is a circuit-switched technology that operates as part of the Integrated Services Digital Network (ISDN). PRI channels can carry 23 Bearer (B) channels and one Delta (D) channel for T1 circuits in the US, or 30 B channels and one D channel for E1 circuits in other regions. Each Bearer channel operates at 64 Kbps for voice and data transmission, while the Delta channel operates at 16 Kbps for signalling and control. BRI (Basic Rate Interface) is the smaller version of ISDN, typically providing 2 B channels and 1 D channel (2B+1D configuration). Both technologies use dedicated physical lines and require specialized hardware for operation. SIP Trunking Architecture SIP (Session Initiation Protocol) trunking is an application layer protocol that enables voice, video, and messaging services over internet protocol (IP) networks. Unlike PRI/BRI which relies on physical circuit-switched connections, SIP is a packet-switched technology that utilizes existing data networks to transmit voice communications. Key technical differences include: • Technology Base: PRI/BRI uses circuit-switched technology, while SIP uses packet-switched technology • Infrastructure: PRI requires physical hardware installation and dedicated lines, while SIP is software-based and uses existing IP networks • Capacity: PRI has fixed capacity (23 channels per T1 line), while SIP can handle unlimited channels based on available bandwidth • Flexibility: SIP works across different networks including VoIP and PSTN, while PRI is designed primarily for PSTN integration. Technical Migration Aspects: 1. Infrastructure Assessment The migration begins with a comprehensive infrastructure audit to determine if the existing phone systems support IP technology natively or require an ISDN to SIP converter. Organizations must evaluate their current PBX compatibility and network readiness. It is very important to call out the Analog dependencies like loud speaker, ring bell mechanisms and paging system so that their integration and compatibility can be checked and determined in designing phase. 2. Network Bandwidth Planning Network bandwidth assessment is critical for SIP deployment. As a thumb rule, organizations should plan for approximately 100 Kbps per concurrent call. For example, replacing an ISDN30 (30-channel PRI) would require approximately 3 Mbps of dedicated bandwidth. 3. Hardware Integration Options ISDN to SIP Converters serve as bridge devices for organizations wanting to retain existing PBX systems: • BRI Converter (ISIP8): Converts Basic Rate ISDN lines to SIP • PRI Converter (ISIP30): Converts Primary Rate ISDN lines to SIP These converters allow legacy PBX systems to interface with modern SIP trunk providers without requiring complete system replacement. 4. Session Border Controller (SBC) Implementation Session Border Controllers are essential components that manage traffic, enhance security, and ensure compatibility between different networks and protocols. SBCs provide secure communication channels between the organization’s network and SIP providers. You can consider it as a Voice Firewall. 5. Quality of Service (QoS) Configuration Network QoS configuration ensures voice traffic receives priority over data traffic, maintaining call quality equivalent to traditional telephony systems. This includes bandwidth allocation, traffic shaping, and latency management. Technical Advantages of SIP Trunking Cost Optimization: SIP trunking eliminates the need for separate physical lines, utilizing existing data network infrastructure. Organizations only pay for the number of trunks used, unlike PRI which comes in fixed 23-channel increments. Scalability and Flexibility SIP trunking offers dynamic scalability without hardware constraints. Businesses can scale on-demand by adjusting software settings rather than installing additional physical lines. Enhanced Reliability SIP traffic can be routed to backup connections automatically during network disruptions. This built-in redundancy provides superior disaster recovery capabilities compared to physical PRI connections that can be affected by power outages or physical damage. Unified Communications Integration SIP trunking enables seamless integration of voice, video, and data on a single platform. This convergence eliminates the need for multiple communication systems and enables advanced collaboration features. Implementation Challenges and Considerations Network Dependency: SIP trunking requires a stable internet connection and organizations must maintain reliable backup connectivity to handle outages. Quality depends heavily on network performance and available bandwidth. Security Considerations: SIP systems can be vulnerable to cyber threats and require implementation of security measures including Secure Real-time Transport Protocol (SRTP) to protect voice data. Equipment Compatibility: Older hardware such as desk phones might need replacement to fully leverage SIP trunking capabilities. Organizations should budget for potential equipment upgrades during migration planning. Migration Best Practices Parallel Operation Testing: Organizations should run parallel operations of both PRI and SIP during transition phases, allowing testing and issue resolution before complete PRI phase-out. Comprehensive Validation: Thorough testing and validation of SIP infrastructure for compatibility and functionality is essential before full deployment. This includes call quality testing, feature verification, and failover testing. User Training and Support: Comprehensive user training facilitates adoption of new system capabilities and ensures optimal utilization of SIP trunking features. Summary : Why are organizations transitioning from PRI/BRI to SIP Trunking? Cost Efficiency SIP trunking eliminates the need for physical lines, reducing infrastructure and maintenance costs. Calls, especially long-distance and international, are significantly cheaper over IP. Scalability & Flexibility Unlike PRI/BRI which have fixed channel limits, SIP trunks can be scaled up or down easily based on business needs, without additional hardware. Unified Communications SIP enables integration of voice, video, messaging, and collaboration tools, supporting modern communication platforms and remote work environments. Business Continuity SIP trunks offer better disaster recovery options and call rerouting capabilities, ensuring communication remains uninterrupted during outages. Global Reach SIP trunking supports global connectivity without the need for local infrastructure in every region, making it ideal for multinational organizations. Futureproofing As telecom providers phase out legacy systems, SIP trunking ensures compatibility with evolving technologies and cloud-based services.
