updates content added

Author: amagginetti

articles/communication-services/concepts/analytics/logs/call-diagnostics-updates-log-schema.md

@@ -14,8 +14,9 @@ ms.subservice: calling
 
 # Call Diagnostics Updates Log Schema
 
+The only difference in properties between the Call Diagnostics Updates Log Schema and the [Call Diagnostics Log Schema](call-diagnostics-log-schema.md) is the additional `CallUpdatesVersion` property. The `CallUpdatesVersion` property indicates how recent the log is. The Call Diagnostics Updates Log Schema has lower latency than the [Call Diagnostics Log Schema](call-diagnostics-log-schema.md), it achieves this low latency by sending schema properties as soon as they can be sent. In contrast, the [Call Diagnostics Log Schema](call-diagnostics-log-schema.md) does not send you a log schema until the entire log schema has completed internal Microsoft creation. When using the Call Summary Updates Log Schema, always refer to the `CallUpdatesVersion` to ensure you have the most up-to-date information. Whenever call data is updated, a new version of the log is created, providing a complete history of changes.
 
-Call diagnostics updates logs provide important information about the endpoints and the media transfers for each participant. They also provide measurements that help you understand quality problems.
+The Call Diagnostics Updates logs provide important information about the endpoints and the media transfers for each participant. They also provide measurements that help you understand quality problems.
 
 For each `EndpointId` within a call (including the server), Azure Communication Services creates a distinct call diagnostics updates log for each media stream (audio or video, for example) between endpoints.
 In a P2P call, each log contains data that relates to each of the outbound streams associated with each endpoint. In group calls, `participantId` serves as a key identifier to join the related outbound logs into a distinct participant connection. Call diagnostics updates logs remain intact and are the same regardless of the participant tenant.
@@ -66,6 +67,7 @@ The table below describes each property.
 | `VideoBitRateMax` | The maximum bitrate (bits per second) for a video or screenshare stream.  <br><br> A low bitrate value could indicate poor network issue. The minimum bitrate (bandwidth) required can be found here: [Network bandwidth](../../voice-video-calling/network-requirements.md#network-bandwidth). |
 | `StreamDirection` | The direction of the media stream. It is either Inbound or Outbound. |
 | `CodecName` | The name of the codec used for processing media streams. It can be OPUS, G722, H264S, SATIN, and so on. |
+| `CallUpdatesVersion`| Represents the log version, with higher numbers indicating the most recently published version. |
 
 ## Sample data for various call types
 

articles/communication-services/concepts/analytics/logs/call-summary-updates-log-schema.md

@@ -14,8 +14,9 @@ ms.subservice: calling
 
 # Call Summary Updates Log Schema
 
-The call summary updates log contains data to help you identify key properties of all calls. A different call summary updates log is created for each `participantId` (or `endpointId` for peer-to-peer [P2P] calls) value in the call.
+The only difference in properties between the Call Summary Updates Log Schema and the [Call Summary Log Schema](call-summary-log-schema.md) is the additional `CallUpdatesVersion` property. The `CallUpdatesVersion` property indicates how recent the log is. The Call Summary Updates Log Schema has lower latency than the [Call Summary Log Schema](call-summary-log-schema.md), it achieves this low latency by sending schema properties as soon as they can be sent. In contrast, the [Call Summary Log Schema](call-summary-log-schema.md) does not send you a log schema until the entire log schema has completed internal Microsoft creation. When using the Call Summary Updates Log Schema, always refer to the `CallUpdatesVersion` to ensure you have the most up-to-date information. Whenever call data is updated, a new version of the log is created, providing a complete history of changes.
 
+The call summary updates log contains data to help you identify key properties of all calls. A different call summary updates log is created for each `participantId` (or `endpointId` for peer-to-peer [P2P] calls) value in the call.
 
 For each participant within a call, Communication Services creates a distinct call summary updates log. If someone rejoins a call, that participant has the same `EndpointId` value but a different `ParticipantId` value. That endpoint can then have two call summary updates logs.
 
@@ -63,6 +64,7 @@ The table below describes each property.
 | `ParticipantEndSubCode `| Represents the Calling SDK error subcode that the SDK emits (when relevant) for each `participantId` value. | 
 | `ResultCategory `| Represents the category of the participant ending the call. It can be one of these 4 values: Success, ExpectedError, UnexpectedClientError, UnexpectedServerError. |
 | `DiagnosticOptions `| This value allows developers to attach custom tags to their client telemetry, which can then be viewed in the Call Diagnostics section. This helps in identifying and troubleshooting issues more effectively. To learn how to add custom tags to this value, refer to [Tutorial on adding custom tags to your client telemetry](../../../tutorials/voice-video-calling/diagnostic-options-tag.md) |
+| `CallUpdatesVersion`| Represents the log version, with higher numbers indicating the most recently published version. |
 
 ### Error codes