Merge pull request #301948 from MicrosoftDocs/main

Merged by Learn.Build PR Management system

Author: learn-build-service-prod[bot]

articles/communication-services/concepts/advanced-messaging/whatsapp/template-messages.md

@@ -50,8 +50,8 @@ The `content` field of the template details can include parameter bindings. The
 - A `format` field with a value such as `IMAGE`.
 - Double brackets surrounding a number, such as `{{1}}`. The number, indexed started at 1, indicates the order in which the binding values must be supplied to create the message template.
 - Double brackets surrounding a name, such as `{{movie_name}}`. The named parameters allow developers to reference parameters by name instead of position.
-> [!IMPORTANT]
-> When using named parameters, you must ensure that the name you use when sending the message **exactly matches** the name defined in the template you created in the Meta WhatsApp Manager.
+  > [!IMPORTANT]
+  > When using named parameters, you must ensure that the name you use when sending the message **exactly matches** the name defined in the template you created in the Meta WhatsApp Manager.
 
 
 :::image type="content" source="../../../quickstarts/advanced-messaging/whatsapp/media/template-messages/sample-movie-ticket-confirmation-azure-portal.png" lightbox="../../../quickstarts/advanced-messaging/whatsapp/media/template-messages/sample-movie-ticket-confirmation-azure-portal.png" alt-text="Screenshot that shows template details.":::

articles/communication-services/concepts/call-flows.md

@@ -1,90 +1,91 @@
 ---
-title: Call flows in Azure Communication Services
-titleSuffix: An Azure Communication Services concept document
-description: Learn about call flows in Azure Communication Services.
+title: Call networking internals
+titleSuffix: An Azure Communication Services article
+description: This article describes call flows for different Azure Communication Services call types.
 author: tophpalmer
 manager: chpalm
 services: azure-communication-services
 ms.author: chpalm
-ms.date: 06/30/2021
+ms.date: 06/20/2025
 ms.topic: conceptual
 ms.service: azure-communication-services
 ms.subservice: calling
 ---
-# Call flow basics
 
-The section below gives an overview of the call flows in Azure Communication Services. Signaling and media flows depend on the types of calls your users are making. Examples of call types include one-to-one VoIP, one-to-one PSTN, and group calls containing a combination of VoIP and PSTN-connected participants. Review [Call types](./voice-video-calling/about-call-types.md).
+# Call networking internals
 
-## About signaling and media protocols
+The article describes the call flows in Azure Communication Services. Signaling and media flows depend on the types of calls your users are making. Examples of call types include one-to-one VoIP, one-to-one public switched telephone network (PSTN), and group calls containing a combination of VoIP and PSTN-connected participants. For more information, see [Call types](./voice-video-calling/about-call-types.md).
 
-When you establish a peer-to-peer or group call, two protocols are used behind the scenes - HTTPS (REST) for signaling and SRTP for media.
+## Signaling and media protocols
 
-Signaling between the SDKs or between SDKs and Communication Services Signaling Controllers is handled with HTTPS REST (TLS). Azure Communication Services uses TLS 1.2. For Real-Time Media Traffic (RTP), the User Datagram Protocol (UDP) is preferred. If the use of UDP is prevented by your firewall, the SDK will use the Transmission Control Protocol (TCP) for media.
+When you establish a peer-to-peer or group call, two protocols are used behind the scenes - HTTPS (REST) for signaling and Secure Real-time Transport Protocol (SRTP) for media.
+
+Signaling between the SDKs or between SDKs and Communication Services signaling controllers is handled with HTTPS REST (TLS). Azure Communication Services uses TLS 1.2. For real-time media traffic (RTP), we recommend user datagram protocol (UDP). If the firewall prevents use of UDP, the SDK uses the transmission control protocol (TCP) for media.
 
 Let's review the signaling and media protocols in various scenarios.
 
 ## Call flow cases
 
-### Case 1: VoIP where a direct connection between two devices is possible
+### Case 1: VoIP with a direct connection between two devices
 
-In one-to-one VoIP or video calls, traffic prefers the most direct path. "Direct path" means that if two SDKs can reach each other directly, they'll establish a direct connection. This is usually possible when two SDKs are in the same subnet (for example, in a subnet 192.168.1.0/24) or two when the devices each live in subnets that can see each other (SDKs in subnet 10.10.0.0/16 and 192.168.1.0/24 can reach out each other).
+In one-to-one VoIP or video calls, traffic prefers the most direct path. *Direct path* means that if two SDKs can reach each other directly, they establish a direct connection. Direct path is possible when two SDKs are in the same subnet (such as in a subnet 192.168.1.0/24) or two when the devices each live in subnets that can see each other (SDKs in subnet 10.10.0.0/16 and 192.168.1.0/24 can reach out each other).
 
 :::image type="content" source="./media/call-flows/about-voice-case-1.png" alt-text="Diagram showing a Direct VOIP call between users and Communication Services.":::
 
-### Case 2: VoIP where a direct connection between devices is not possible, but where connection between NAT devices is possible
+### Case 2: VoIP in which a direct connection between devices isn't possible, but a connection between NAT devices is possible
 
-If two devices are located in subnets that can't reach each other (for example, Alice works from a coffee shop and Bob works from his home office) but the connection between the NAT devices is possible, the client side SDKs will establish connectivity via NAT devices.
+If two devices are located in subnets that can't reach each other but the connection between the network address translation (NAT) devices is possible, the client side SDKs establish connectivity via NAT devices. For example, if Alice works from a coffee shop and Bob works from a home office.
 
-For Alice it will be the NAT of the coffee shop and for Bob it will be the NAT of the home office. Alice's device will send the external address of her NAT and Bob's will do the same. The SDKs learn the external addresses from a STUN (Session Traversal Utilities for NAT) service that Azure Communication Services provides free of charge. The logic that handles the handshake between Alice and Bob is embedded within the Azure Communication Services provided SDKs. (You don't need any additional configuration)
+For Alice, it's the NAT of the coffee shop and for Bob it's the NAT of the home office. Alice's device sends the external address of her NAT and Bob's does the same. The SDKs learn the external addresses from a session traversal utilities for NAT (STUN) service that Azure Communication Services provides free of charge. The logic that handles the handshake between Alice and Bob is embedded in the Azure Communication Services provided SDKs. You don't need any added configuration.
 
-:::image type="content" source="./media/call-flows/about-voice-case-2.png" alt-text="Diagram showing a VOIP call which utilizes a STUN connection.":::
+:::image type="content" source="./media/call-flows/about-voice-case-2.png" alt-text="Diagram showing a VOIP call, using a session traversal utilities for NAT (STUN) connection.":::
 
-### Case 3: VoIP where neither a direct nor NAT connection is possible
+### Case 3: VoIP in which a direct nor NAT connection is possible
 
-If one or both client devices are behind a symmetric NAT, a separate cloud service to relay the media between the two SDKs is required. This service is called TURN (Traversal Using Relays around NAT) and is also provided by the Communication Services. The Communication Services Calling SDK automatically uses TURN services based on detected network conditions. TURN charges are included in the price of the call.
+If one or both client devices are behind a symmetric NAT, a separate cloud service is required to relay the media between the two SDKs. This service is called traversal using relays around NAT (TURN) and is also provided by Azure Communication Services. The Communication Services Calling SDK automatically uses TURN services based on detected network conditions. TURN charges are included in the price of the call.
 
-:::image type="content" source="./media/call-flows/about-voice-case-3.png" alt-text="Diagram showing a VOIP call which utilizes a TURN connection.":::
+:::image type="content" source="./media/call-flows/about-voice-case-3.png" alt-text="Diagram showing a VOIP, over a traversal using relays around NAT (TURN) connection.":::
 
 ### Case 4: Group calls with PSTN
 
 Both signaling and media for PSTN Calls use the Azure Communication Services telephony resource. This resource is interconnected with other carriers.
 
-PSTN media traffic flows through a component called Media Processor.
+PSTN media traffic flows through a media processor component.
 
 :::image type="content" source="./media/call-flows/about-voice-pstn.png" alt-text="Diagram showing a PSTN Group Call with Communication Services.":::
 
 > [!NOTE]
-> For those familiar with media processing, our Media Processor is also a Back to Back User Agent, as defined in [RFC 3261 SIP: Session Initiation Protocol](https://tools.ietf.org/html/rfc3261), meaning it can translate codecs when handling calls between Microsoft and Carrier networks. The Azure Communication Services Signaling Controller is Microsoft's implementation of an SIP Proxy per the same RFC.
+> The media processor is also a back to back user agent, as defined in [RFC 3261 SIP: Session Initiation Protocol](https://tools.ietf.org/html/rfc3261), meaning it can translate codecs when handling calls between Microsoft and Carrier networks. The Azure Communication Services signaling controller is Microsoft's implementation of a SIP Proxy per the same RFC.
 
-For group calls, media and signaling always flow via the Azure Communication Services backend. The audio and/or video from all participants is mixed in the Media Processor component. All members of a group call send their audio and/or video streams to the media processor, which returns mixed media streams.
+For group calls, media and signaling always flow via the Azure Communication Services backend. The audio and/or video from all participants is mixed in the media processor. All members of a group call send their audio and video streams to the media processor, which returns mixed media streams.
 
-The default real-time protocol (RTP) for group calls is User Datagram Protocol (UDP).
+The default real-time protocol (RTP) for group calls is user datagram protocol (UDP).
 
 > [!NOTE]
-> The Media Processor can act as a Multipoint Control Unit (MCU) or Selective Forwarding Unit (SFU)
+> The Media Processor can act as a multipoint control unit (MCU) or selective forwarding unit (SFU).
 
 :::image type="content" source="./media/call-flows/about-voice-group-calls.png" alt-text="Diagram showing UDP media process flow within Communication Services.":::
 
-If the SDK can't use UDP for media due to firewall restrictions, an attempt will be made to use the Transmission Control Protocol (TCP). Note that the Media Processor component requires UDP, so when this happens, the Communication Services TURN service will be added to the group call to translate TCP to UDP. TURN charges are included in the price of the call.
+If the SDK can't use UDP for media due to firewall restrictions, it attempts to use the transmission control protocol (TCP). The media processor component requires UDP, so when in this case, the Communication Services TURN service is added to the group call to translate TCP to UDP. TURN charges are included in the price of the call.
 
 :::image type="content" source="./media/call-flows/about-voice-group-calls-2.png" alt-text="Diagram showing TCP media process flow within Communication Services.":::
 
 ### Case 5: Communication Services SDK and Microsoft Teams in a scheduled Teams meeting
 
-Signaling flows through the signaling controller. Media flows through the Media Processor. The signaling controller and Media Processor are shared between Communication Services and Microsoft Teams.
+Signaling flows through the signaling controller. Media flows through the media processor. The signaling controller and media processor are shared between Communication Services and Microsoft Teams.
 
 :::image type="content" source="./media/call-flows/teams-communication-services-meeting.png" alt-text="Diagram showing Communication Services SDK and Teams Client in a scheduled Teams meeting.":::
 
 ### Case 6: Early media
 
-Refers to media (e.g., audio and video) that is exchanged   before a particular session is accepted by the called user. If there is early media flow, the SBC must latch to the first endpoint that starts streaming media; media flow can start before candidates are nominated. The SBC should have support for sending DTMF during this phase to enable IVR/voicemail scenarios. The SBC should use the highest priority path on which it has received checks if nominations have not completed.
+Refers to media that is exchanged, such as audio and video, before the callee accepts the session. For early media flow, the session border controller (SBC) must latch to the first endpoint that starts streaming media; media flow can start before candidates are nominated. The SBC must support sending dual tone multi-frequency (DTMF) during this phase to enable IVR/voicemail scenarios. The SBC should use the highest priority path on which it receives checks, if nominations aren't complete.
 
 ## Next steps
 
 > [!div class="nextstepaction"]
 > [Get started with calling](../quickstarts/voice-video-calling/getting-started-with-calling.md)
 
-The following documents may be interesting to you:
+## Related articles
 
 - Learn more about [call types](../concepts/voice-video-calling/about-call-types.md)
 - Learn about [Client-server architecture](./client-and-server-architecture.md)