Why is STUN traffic between VoIP server identified as ms-teams-audio-video?

Why is STUN traffic between a Microsoft Teams VoIP server and an internal VoIP server identified as ms-teams-audio-video when it was previously identified only as stun?

• Product: Next-Generation Firewall (NGFW)
• Feature: App-ID
• Applications: stun, ms-teams-audio-video

This behavior occurs because Microsoft utilizes the same IP addresses for both VoIP trunk communication and Teams Client communication. The NGFW uses contextual logic to identify applications; when a specific IP is associated with Teams activity, the firewall "promotes" the generic stun traffic to a more specific App-ID.

How the Classification Changes:

1. Initial Identification: When the VoIP servers first communicate, the traffic pattern matches the generic signatures for the stun App-ID.
2. IP-to-App Mapping: When a Microsoft Teams Client (user) communicates with that same Microsoft VoIP server, the NGFW identifies the session as ms-teams-audio-video.
3. Persistence/Tagging: The firewall caches this identification. It now "knows" that this specific Microsoft IP is a Teams endpoint.
4. Reclassification: Any subsequent STUN traffic involving that tagged IP—including server-to-server trunk traffic—is automatically identified as ms-teams-audio-video. This is intended behavior to ensure that Teams-related traffic is correctly categorized for Quality of Service (QoS) and security policy enforcement

Comparison of Traffic Logic:

The suggestion is to include all of the app-ids for the relevant application (in this case MS Teams) in the security policy rule to identify the app-ids correctly.