←

Read-only Review: 10.4

Release 19 and earlier matters

Meeting:
Generated: 2026-04-07 09:47:53

→

Edit mode Back to Agenda

TDoc Number	Title	Source	Summary	Proposals	Comments
S4-260071	Correcting the DC call constraint	HuaWei Technologies Co., Ltd	No summary available	No proposals available	No comments
S4-260072 (pdf)	Correcting the DC call constraint	HuaWei Technologies Co., Ltd	Summary of 3GPP CR to TS 26.114 Change Request Details CR Number: 0073 Specification: TS 26.114 v19.2.0 Category: F (Correction) Release: Rel-19 Work Item: 5G_MEDIA_MTSI_ext, TEI19 Reason for Change 3GPP R19 SA2 has specified standalone data channel sessions that can establish data channels without MMTel media (e.g., audio, video, messaging). The existing constraint in TS 26.114 clause 6.2.10.1 requiring that a data channel SDP media description shall not be placed before the first SDP speech media description is therefore no longer applicable and needs to be removed to align with the new SA2 specifications. Technical Changes Clause 6.2.10.1 - General Modified Text: The CR updates the paragraph describing data channel SDP media descriptions to remove the ordering constraint. The changes are: Previous text: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text." Updated text: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text." Deleted Constraint: The following sentence is completely removed: - "A data channel SDP media description shall not be placed before the first SDP speech media description." Impact This correction enables: - Standalone data channel sessions without requiring MMTel media - Flexibility in SDP media description ordering - Alignment with SA2 Rel-19 specifications for data channel sessions The change maintains all other requirements including: - Protocol identifier ("UDP/DTLS/SCTP") and media format ("webrtc-datachannel") specifications - Media feature tag requirements (+sip.app-subtype and g.3gpp.dc-mux) - Bandwidth limit determination procedures	Proposal: Deleting the constraint that a data channel SDP media description shall not be placed before the first SDP speech media description in clause 6.2.10.1.	manager: [Technical] Removing “A data channel SDP media description shall not be placed before the first SDP speech media description.” is likely correct for standalone data channel sessions, but the CR does not cite the exact SA2 normative reference (TS number/clause) that introduces “standalone data channel sessions,” making it hard to verify alignment and scope. [Technical] The deleted ordering constraint may have been implicitly relied upon to ensure early offer/answer processing assumptions (e.g., MMTel anchoring, feature negotiation expectations, or legacy interop); the CR should confirm there are no remaining dependencies elsewhere in TS 26.114 (or related MTSI clauses) that assume speech m-lines precede data channels. [Technical] If standalone data channel sessions are allowed, clause 6.2.10.1 should explicitly state that an SDP may contain only data channel m-lines (i.e., no speech/video/text), rather than only implying it via “independently,” to avoid ambiguity for implementers and conformance testing. [Technical] The CR claims “all other requirements” remain, but does not verify whether media feature tags (+sip.app-subtype, g.3gpp.dc-mux) and bandwidth procedures are still applicable when no MMTel media exists; the spec text should clarify applicability conditions for standalone cases. [Technical] The updated wording does not address whether any ordering constraints remain for multiple data channel m-lines (e.g., mux/non-mux, multiple SCTP associations), so removing the only explicit ordering rule could leave undefined behavior if other clauses expect a particular structure. [Editorial] The new sentence “may be added into the SDP independently, or to be added alongside…” is grammatically awkward and redundant; it should be simplified (e.g., “may be included in the SDP either alone or alongside other SDP media descriptions…”). [Editorial] “such as e.g.” is non-idiomatic and appears in both old and new text; replace with either “e.g.” or “such as” to improve readability and align with 3GPP style. [Technical] The CR references RFC 8864 for “data channel SDP media descriptions”; it would be safer to confirm that the intended data channel SDP usage is consistent with the WebRTC data channel SDP conventions (including “UDP/DTLS/SCTP” and “webrtc-datachannel”) in the standalone IMS context, since removing ordering may increase exposure to non-WebRTC SDP stacks. [Editorial] The “Impact” section states “Flexibility in SDP media description ordering,” but the actual change only removes one specific constraint (before first speech m-line); consider tightening the statement to avoid over-claiming broader ordering freedom than actually specified. [Editorial] The CR summary uses “MMTel media (e.g., audio, video, messaging)” where “messaging” is not an SDP media type in the same sense; consider using “speech/audio, video, and real-time text” (or the exact TS 26.114 terminology) to avoid confusion. 2026-02-09 08:42
S4-260073	Correcting the DC call constraint	HuaWei Technologies Co., Ltd	No summary available	No proposals available	No comments
S4-260081 (pdf)	Correcting the DC call constraint	HuaWei Technologies Co., Ltd	Summary of 3GPP CR S4-260081 to TS 26.114 Change Request Details Document: TS 26.114 v19.2.0 CR Number: 0073 Category: F (Correction) Release: Rel-19 Work Item: 5G_MEDIA_MTSI_ext, TEI19 Main Technical Contribution Background and Rationale This CR addresses an outdated constraint in TS 26.114 clause 6.2.10.1 regarding data channel SDP media descriptions. The constraint was introduced when data channels were only supported alongside MMTel media (audio, video, messaging). However, 3GPP R19 SA2 has now specified standalone data channel sessions that can establish data channels without requiring MMTel media. Technical Changes to Clause 6.2.10.1 (General) Removed Constraint The CR removes the following restriction: "A data channel SDP media description shall not be placed before the first SDP speech media description." This constraint is no longer applicable given the support for standalone data channel sessions. Modified Text The clause describing data channel SDP media description placement has been updated from: Before: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text." After: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text." Impact This correction: - Aligns TS 26.114 with SA2 specifications for standalone data channel sessions - Removes an unnecessary ordering constraint on SDP media descriptions - Enables more flexible data channel deployment scenarios without mandatory MMTel media Unchanged Elements The CR maintains all other aspects of clause 6.2.10.1, including: - Media feature tag requirements (+sip.app-subtype with "webrtc-datachannel" value) - Support indication for bootstrap and application data channel multiplexing (g.3gpp.dc-mux) - Protocol identifier and media format specifications (UDP/DTLS/SCTP and webrtc-datachannel) - Bandwidth limit determination requirements	Proposal: Deleting the constraint that a data channel SDP media description shall not be placed before the first SDP speech media description in clause 6.2.10.1.	No comments
S4-260087 (pdf)	Correcting the DC call constraint	Huawei	Summary of 3GPP Technical Document S4-260087 Document Information CR Number: 0604 rev 1 Specification: TS 26.114 v19.2.0 Category: F (Correction) Release: Rel-19 Work Item: 5G_MEDIA_MTSI_ext, TEI19 Main Technical Contribution Problem Statement The current constraint in TS 26.114 clause 6.2.10.1 states that a data channel SDP media description shall not be placed before the first SDP speech media description. This constraint is no longer applicable because 3GPP R19 SA2 has specified standalone data channel sessions that can establish data channels without MMTel media (e.g., audio, video, messaging). Proposed Change Modification to Clause 6.2.10.1 (General) The CR proposes to remove the restrictive placement constraint for data channel SDP media descriptions. Specifically: Deleted Text: - "A data channel SDP media description shall not be placed before the first SDP speech media description." Modified Text: The sentence describing data channel SDP media description inclusion is updated from: - "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text." To: - "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text." Technical Impact This correction enables: - Standalone data channel sessions without requiring MMTel media components - Flexible SDP ordering where data channel media descriptions can appear in any position within the SDP - Alignment with SA2 specifications for Rel-19 standalone data channel functionality Unchanged Requirements The following requirements remain intact: - Support for data channel media remains optional for MTSI clients - Media feature tag requirements (+sip.app-subtype with "webrtc-datachannel" value) - g.3gpp.dc-mux media feature tag for bootstrap and application data channel multiplexing - Protocol identifier and media format specifications (UDP/DTLS/SCTP and webrtc-datachannel) - Bandwidth limit determination requirements per clause 6.2.5	Proposal: Deleting the constraint that a data channel SDP media description shall not be placed before the first SDP speech media description in clause 6.2.10.1.	manager: [Technical] Removing “A data channel SDP media description shall not be placed before the first SDP speech media description” is directionally correct for standalone data channel sessions, but the CR does not add any replacement normative text clarifying that an SDP offer/answer with only data channel m-lines (no speech/video/text) is valid and how it interacts with the rest of clause 6.2.10.1 requirements. [Technical] The change claims alignment with “R19 SA2 standalone data channel sessions” but provides no explicit reference to the SA2 stage-2 specification/clause that introduces this capability; TS 26.114 should normatively cite the relevant TS 24.229/TS 23.xxx/TS 24.xxx clause to justify the behavioral change. [Technical] If ordering constraints are removed, the CR should verify and, if needed, update any dependent procedures elsewhere in TS 26.114 (e.g., offer/answer handling, media stream identification, media feature tag usage) that may implicitly assume speech m-lines exist or appear first. [Technical] The updated sentence only addresses “added into the SDP independently” but does not explicitly state that data channel m-lines may appear in any position; if ordering freedom is the intent, it should be stated normatively (e.g., “may appear before or after any other m-line”) to avoid ambiguous interpretation. [Technical] Standalone data channel sessions may affect session-level attributes (e.g., BUNDLE usage, a=group, a=msid semantics, DTLS role negotiation) and the CR does not assess whether clause 6.2.10.1 or related clauses need additional constraints when no RTP-based media is present. [Editorial] The modified wording “may be added into the SDP independently, or to be added alongside” is grammatically incorrect and redundant; it should be simplified (e.g., “may be included in the SDP either alone or alongside other SDP media descriptions…”). [Editorial] The phrase “added into the SDP” is non-standard SDP/spec wording; TS 26.114 typically uses “included/contained in the SDP offer/answer” and should keep consistent terminology. [Technical] The CR summary says “flexible SDP ordering … in any position,” but the actual proposed text does not explicitly remove all ordering constraints beyond the deleted sentence; confirm there are no other ordering rules in the clause (or elsewhere) that still effectively block standalone/early placement. [Technical] The “Unchanged Requirements” list includes media feature tags (+sip.app-subtype, g.3gpp.dc-mux) but the CR does not confirm whether these tags are still applicable/required in standalone data channel sessions (i.e., without MMTel context) or whether additional tags are needed to indicate standalone usage. [Editorial] The summary references “MMTel media (e.g., audio, video, messaging)” but “messaging” is not an SDP media type in the same sense as audio/video/text; consider tightening the wording to avoid confusion (e.g., “audio/video/text m-lines”). [Technical] If standalone data channel sessions are allowed, TS 26.114 should ensure interoperability guidance exists for endpoints that do not support data channels (optional support): e.g., expected behavior when receiving an offer with only a data channel m-line (reject session vs. reject m-line), which is not addressed by this CR. [Editorial] The change description says “formatted according to IETF RFC 8864 [172]” but does not check whether the reference number [172] and RFC are correct for the data channel SDP format in this TS version; ensure the citation matches the spec’s reference list and intended RFC. 2026-02-09 08:45
S4-260116 (pdf)	CR on SWAP schema inconsistencies	Qualcomm Atheros, Inc.	Summary of 3GPP Technical Document S4-260116 Document Information CR Number: 0014 Specification: TS 26.113 v19.1.0 Work Item: iRTCW-TEI (Interactive Real-Time Communication Work - Technical Enhancement and Improvement) Category: F (Correction) Release: Rel-19 Main Technical Contribution Problem Statement The JSON schema for the SWAP (Service and Workflow Adaptation Protocol) protocol contains inconsistencies that make it invalid and misaligned with the specification text. These issues could hinder proper implementation and interoperability. Technical Changes to Clause 13.2.4.6 (JSON Schema) The CR proposes a complete restructuring of the SWAP message JSON schema with the following key modifications: 1. Schema Structure Simplification Removed: Complex nested `definitions` section that defined `matching_criteria_object` as a reusable component Removed: Separate `payload` property with complex `oneOf` structures Changed: Flattened schema structure by moving payload definitions directly under the root `oneOf` 2. Matching Criteria Handling Before: Matching criteria was defined as a reusable object reference with `type` and `value` properties, allowing both predefined enums and custom strings via `anyOf` After: Simplified to a direct string enum without the flexible `anyOf` structure Impact: More restrictive but clearer definition - only allows predefined matching criteria types (ipv4, ipv6, fqdn, service, user, eas, app, location, qos, processing) 3. Message Payload Structure Before: Payloads were nested under a `payload` property with detailed descriptions for each message type (register, response, connect, accept, reject, application) After: Payloads are defined directly at the root level using `oneOf`, removing the intermediate `payload` wrapper Removed: Explicit descriptions for each payload variant Removed: Array structure for `matching_criteria` in connect payload 4. Required Fields Changed: `"source"` in required fields changed to `"source_id"` to match the actual property name defined in the schema 5. Data Type Corrections Reject/Error Payload: Changed `request` field type from `"integer"` to `"number"` for more flexibility 6. Extensions Object Before: Defined with type `"object"` and description After: Simplified to empty object `{}` Impact Assessment Positive Impacts Corrects schema validation errors Aligns JSON schema with specification requirements Ensures proper interoperability between implementations Potential Concerns The simplified matching criteria structure is less flexible (removed `anyOf` allowing custom strings) Removal of array support for matching criteria in connect payload may limit functionality Loss of descriptive metadata for payload variants may reduce schema self-documentation Affected Specifications Core Specification: TS 26.113 (SWAP protocol) Other Specifications: None directly affected Test Specifications: Not affected O&M Specifications: Not affected	Proposal: Fixes to the JSON schema to make it valid and to align with the specification.	No comments
S4-260117 (pdf)	CR on handling of close operation in SWAP	Qualcomm Atheros, Inc.	Summary of 3GPP Technical Document S4-260117 Document Information Specification: TS 26.113 v19.1.0 CR Number: 0015 Category: F (Correction) Release: Rel-19 Work Item: iRTCW-TEI (Interactive Real-Time Communication Web - Technical Enhancement and Improvement) Source: Qualcomm Inc. Purpose and Rationale The CR addresses an ambiguity in the SWAP (Streaming and WebRTC API) specification regarding the handling of the accept message in response to a close operation. Currently, the specification is unclear about whether the answer field (containing SDP answer) should be included in the accept message when responding to a close message, leading to potential implementation confusion. Technical Changes Accept Message Handling (Clause 13.2.4.4.5) Description Updates (13.2.4.4.5.1) Previous behavior: Accept message always contains answer SDP when replying to connect or update requests Clarification added: Accept message shall contain answer SDP when responding to connect or update messages Accept message shall NOT contain SDP when responding to close messages Explicitly separates the two use cases for the accept message Parameter Definition (13.2.4.4.5.2) answer parameter: Changed from mandatory to optional Modified to "This parameter, when present, shall contain the answer SDP" Makes it clear that answer is conditionally included based on the triggering message type Update Message Clarification (13.2.4.4.6.1) Reinforces that update message is for partial media teardown (half-close) Distinguishes from close message which performs full session termination Note added emphasizing the use of close message for full session termination Close Message Clarification (13.2.4.4.8.1) Explicitly states that accept message response shall be "without an SDP payload" Clarifies session teardown procedure: accept message triggers resource release Note added distinguishing close (full termination) from update (partial teardown) Impact The changes ensure proper protocol behavior by: 1. Removing ambiguity in accept message structure based on context 2. Preventing unnecessary SDP exchange during session termination 3. Clearly delineating between partial media teardown (update) and full session termination (close)	Proposal 1: Clarify that the answer parameter is optional in the accept message.	No comments
S4-260222 (pdf)	CR on correction to animation samples transport	Qualcomm Inc.	Summary of 3GPP CR on Correction to Animation Samples Transport Document Information Specification: TS 26.264 v19.1.0 CR Number: 0017 Category: F (Correction) Release: Rel-19 Work Item: AvCall-MED Source: Qualcomm Inc. Problem Statement The current specification incorrectly implies that avatar animation samples should be carried on the metadata data channel, which is defined as text-only UTF-8 JSON. However, ARF (Avatar Representation Format) animation samples are binary data. This mismatch creates several issues: Requires base64 encapsulation for binary data in text channel Introduces additional latency Creates interoperability problems Risk of incompatible proprietary workarounds and fragmentation Technical Changes 1. Metadata Data Channel Clarification (Clause 6.2) Added clarification: - Explicit NOTE stating that the metadata data channel (sub-protocol "3gpp-ar-metadata") is text-only and not intended for transport of binary data such as avatar animation samples - Explicit statement that the metadata data channel shall not be used to transport ARF avatar animation samples 2. New Avatar Animation Data Channel (Clause 6.3.2) Major addition - dedicated binary transport channel: Channel Characteristics Sub-protocol identifier: "3gpp-ar-animation" Purpose: Binary transport for ARF avatar animation samples (clause 8 of TS 26.565) Separation: Distinct from metadata data channel Content restriction: Shall only carry avatar animation samples Transport Parameters Transmission order: In-order Reliability: Should be reliable by default Partial reliability: May negotiate using data-channel parameters (max-time or max-retr) when supported by both endpoints SDP signaling: Included in dcmap attribute Message Format Each message contains exactly one ARF animation sample No compression scheme defined for animation samples Example SDP `a=dcmap:2 label="avatar-anim-1" subprotocol="3gpp-ar-animation" ordered max-time=150` 3. Removed Content (Clause 6.3.2) Deleted specifications: - Previous avatar animation message format using metadata channel (Table 6.3-1) - Message type "urn:3gpp:avatar:v1:animation" - Subtype field for different animation types (facial, joint, landmark, audio, video) - Payload object structure for animation samples in JSON format Retained control messages: - Stopped message (urn:3gpp:avatar:v1:animation:control:stopped) - Table 6.3-2 - Resumed message (urn:3gpp:avatar:v1:animation:resumed) - Table 6.3-3 - These control messages continue to use the metadata data channel Impact Requirements for AR-MTSI Clients/MF Shall support exchange of avatar animation data over the new Avatar Animation Data Channel Shall establish or accept Avatar Animation Data Channel for animation sample exchange Shall support ARF sample formats per clause 8 of TS 26.565 Consequences if Not Approved Incompatible implementations using workarounds (text/base64, proprietary channels) Fragmentation of implementations Interoperability failures between vendors Summary This CR introduces a fundamental architectural correction by separating binary avatar animation sample transport from text-based metadata transport. It defines a new dedicated data channel with appropriate binary transport characteristics, preventing the need for inefficient text encoding of binary data and ensuring proper interoperability for avatar animation in AR-MTSI calls.	Proposal 1: Add a NOTE in clause 6.2 clarifying that the metadata data channel (sub‑protocol "3gpp‑ar‑metadata") is text‑only and is not intended for the transport of binary data such as avatar animation samples. Proposal 2: Add a new sentence at the end of clause 6.2 stating: "The metadata data channel shall not be used to transport ARF avatar animation samples defined in clause 8 of [10]." Proposal 3: Replace the existing text in clause 6.3.2 with new text that defines an Avatar Animation Data Channel with sub‑protocol "3gpp-ar-animation" for binary transport of ARF avatar animation samples as specified in clause 8 of [10], separate from the metadata data channel defined in clause 6.2. Proposal 4: Specify in clause 6.3.2 that the Avatar Animation Data Channel shall only carry avatar animation samples, with transmission order set to in‑order and transmission reliability set to reliable (with optional negotiation of partial reliability using data‑channel parameters). Proposal 5: Specify in clause 6.3.2 that each "3gpp-ar-animation" data‑channel message shall contain exactly one ARF animation sample. Proposal 6: Remove the existing text in clause 6.3.2 that defines avatar animation messages with type "urn:3gpp:avatar:v1:animation" and the associated message format in Table 6.3-1, as these are replaced by the binary Avatar Animation Data Channel. Proposal 7: Retain the existing text in clause 6.3.2 regarding the stopped and resumed control messages (Tables 6.3-2 and 6.3-3), as these control messages continue to use the metadata data channel.	manager: [Technical] The new “3gpp-ar-animation” data channel definition lacks a normative mapping to WebRTC/RTCDataChannel payload type expectations (binary vs text) and does not explicitly state that messages are sent as binary (e.g., “binary message” / “application/octet-stream”), which is essential to avoid implementations still treating payloads as UTF-8 text. [Technical] The CR removes the JSON “message type” and subtype structure (facial/joint/landmark/audio/video) but does not replace it with any in-band or out-of-band mechanism to identify the animation sample type/stream, risking ambiguity when multiple ARF sample kinds exist or when multiple animation streams are used concurrently. [Technical] “Each message contains exactly one ARF animation sample” is underspecified without defining framing rules relative to ARF (TS 26.565 clause 8): if an ARF sample can exceed SCTP message size/MTU, fragmentation/reassembly behavior and any maximum message size constraints should be specified to ensure interoperability. [Technical] The reliability guidance is inconsistent/weakly normative (“should be reliable by default” + “may negotiate partial reliability”); the spec should clearly state default `ordered`/reliability parameters and the required behavior when endpoints do not support partial reliability, otherwise different defaults will break interop. [Technical] The SDP example uses `a=dcmap` with `ordered max-time=150` but the CR does not specify the full required `dcmap` parameter set (e.g., whether `ordered` is mandatory, whether `max-time/max-retr` are mutually exclusive, and what to do if both are offered), leaving negotiation behavior unclear. [Technical] The statement that the animation channel “shall only carry avatar animation samples” conflicts with the retained “stopped/resumed” control messages remaining on the metadata channel; if control needs tight synchronization with samples, the CR should justify why control is not on the same channel or define correlation rules across channels. [Technical] The CR introduces a new subprotocol identifier but does not address backward compatibility/interworking with Rel-19 implementations that followed the previous JSON/base64 approach; at minimum, it should specify how an endpoint detects peer support and what fallback behavior is permitted/forbidden. [Technical] The new channel purpose references “ARF avatar animation samples (clause 8 of TS 26.565)” but does not normatively constrain codec/profile/versioning of ARF samples or how version mismatches are handled, which was previously partially handled via typed JSON structures. [Technical] Removing the JSON payload object also removes any explicit timestamping/sequence metadata that may have been present or implied; the CR should confirm whether timing/ordering is entirely derived from ARF sample contents and what happens if ARF does not carry sufficient timing for playout. [Technical] The CR says “No compression scheme defined for animation samples” but does not clarify whether ARF samples may already be compressed or whether additional compression is prohibited; this can lead to incompatible assumptions about payload processing. [Editorial] Clause references are potentially inconsistent: the CR claims changes in “Clause 6.3.2” and deletion of “Table 6.3-1” while retaining “Table 6.3-2/6.3-3”; ensure numbering and cross-references in TS 26.264 remain correct after deletions/additions. [Editorial] The wording “metadata data channel … shall not be used to transport ARF avatar animation samples” should be aligned with existing 3GPP normative language and scope (e.g., “AR-MTSI client shall not…”), otherwise it may read as a general prohibition beyond the spec’s intended applicability. [Editorial] The CR summary asserts the metadata channel is “defined as text-only UTF-8 JSON”; if TS 26.264 currently defines it that strictly, cite the exact normative text being corrected—otherwise the CR should adjust the rationale to match the actual spec wording to avoid overstating the error. 2026-02-09 09:09
S4-260367 (pdf)	CR on SWAP schema inconsistencies	S4	No summary available	No proposals available	No comments
S4-260404 (pdf)	CR on SWAP schema inconsistencies	Qualcomm Atheros, Inc.	No summary available	No proposals available	No comments
S4-260406 (pdf)	CR on handling of close operation in SWAP	S4	No summary available	No proposals available	No comments
S4-260457 (pdf)	CR on SWAP schema inconsistencies	S4	No summary available	No proposals available	No comments
S4-260458 (pdf)	CR on handling of close operation in SWAP	S4	No summary available	No proposals available	No comments

Summary of 3GPP CR to TS 26.114

Change Request Details

CR Number: 0073
Specification: TS 26.114 v19.2.0
Category: F (Correction)
Release: Rel-19
Work Item: 5G_MEDIA_MTSI_ext, TEI19

Reason for Change

3GPP R19 SA2 has specified standalone data channel sessions that can establish data channels without MMTel media (e.g., audio, video, messaging). The existing constraint in TS 26.114 clause 6.2.10.1 requiring that a data channel SDP media description shall not be placed before the first SDP speech media description is therefore no longer applicable and needs to be removed to align with the new SA2 specifications.

Technical Changes

Clause 6.2.10.1 - General

Modified Text:

The CR updates the paragraph describing data channel SDP media descriptions to remove the ordering constraint. The changes are:

Previous text: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text."
Updated text: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text."

Deleted Constraint:

The following sentence is completely removed: - "A data channel SDP media description shall not be placed before the first SDP speech media description."

Impact

This correction enables: - Standalone data channel sessions without requiring MMTel media - Flexibility in SDP media description ordering - Alignment with SA2 Rel-19 specifications for data channel sessions

The change maintains all other requirements including: - Protocol identifier ("UDP/DTLS/SCTP") and media format ("webrtc-datachannel") specifications - Media feature tag requirements (+sip.app-subtype and g.3gpp.dc-mux) - Bandwidth limit determination procedures

Proposal: Deleting the constraint that a data channel SDP media description shall not be placed before the first SDP speech media description in clause 6.2.10.1.

manager:

[Technical] Removing “A data channel SDP media description shall not be placed before the first SDP speech media description.” is likely correct for standalone data channel sessions, but the CR does not cite the exact SA2 normative reference (TS number/clause) that introduces “standalone data channel sessions,” making it hard to verify alignment and scope.
[Technical] The deleted ordering constraint may have been implicitly relied upon to ensure early offer/answer processing assumptions (e.g., MMTel anchoring, feature negotiation expectations, or legacy interop); the CR should confirm there are no remaining dependencies elsewhere in TS 26.114 (or related MTSI clauses) that assume speech m-lines precede data channels.
[Technical] If standalone data channel sessions are allowed, clause 6.2.10.1 should explicitly state that an SDP may contain only data channel m-lines (i.e., no speech/video/text), rather than only implying it via “independently,” to avoid ambiguity for implementers and conformance testing.
[Technical] The CR claims “all other requirements” remain, but does not verify whether media feature tags (+sip.app-subtype, g.3gpp.dc-mux) and bandwidth procedures are still applicable when no MMTel media exists; the spec text should clarify applicability conditions for standalone cases.
[Technical] The updated wording does not address whether any ordering constraints remain for multiple data channel m-lines (e.g., mux/non-mux, multiple SCTP associations), so removing the only explicit ordering rule could leave undefined behavior if other clauses expect a particular structure.
[Editorial] The new sentence “may be added into the SDP independently, or to be added alongside…” is grammatically awkward and redundant; it should be simplified (e.g., “may be included in the SDP either alone or alongside other SDP media descriptions…”).
[Editorial] “such as e.g.” is non-idiomatic and appears in both old and new text; replace with either “e.g.” or “such as” to improve readability and align with 3GPP style.
[Technical] The CR references RFC 8864 for “data channel SDP media descriptions”; it would be safer to confirm that the intended data channel SDP usage is consistent with the WebRTC data channel SDP conventions (including “UDP/DTLS/SCTP” and “webrtc-datachannel”) in the standalone IMS context, since removing ordering may increase exposure to non-WebRTC SDP stacks.
[Editorial] The “Impact” section states “Flexibility in SDP media description ordering,” but the actual change only removes one specific constraint (before first speech m-line); consider tightening the statement to avoid over-claiming broader ordering freedom than actually specified.
[Editorial] The CR summary uses “MMTel media (e.g., audio, video, messaging)” where “messaging” is not an SDP media type in the same sense; consider using “speech/audio, video, and real-time text” (or the exact TS 26.114 terminology) to avoid confusion.

2026-02-09 08:42

Summary of 3GPP CR S4-260081 to TS 26.114

Change Request Details

Document: TS 26.114 v19.2.0
CR Number: 0073
Category: F (Correction)
Release: Rel-19
Work Item: 5G_MEDIA_MTSI_ext, TEI19

Main Technical Contribution

Background and Rationale

This CR addresses an outdated constraint in TS 26.114 clause 6.2.10.1 regarding data channel SDP media descriptions. The constraint was introduced when data channels were only supported alongside MMTel media (audio, video, messaging). However, 3GPP R19 SA2 has now specified standalone data channel sessions that can establish data channels without requiring MMTel media.

Technical Changes to Clause 6.2.10.1 (General)

Removed Constraint

The CR removes the following restriction:

"A data channel SDP media description shall not be placed before the first SDP speech media description."

This constraint is no longer applicable given the support for standalone data channel sessions.

Modified Text

The clause describing data channel SDP media description placement has been updated from:

Before:

"One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text."

After:

"One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text."

Impact

This correction: - Aligns TS 26.114 with SA2 specifications for standalone data channel sessions - Removes an unnecessary ordering constraint on SDP media descriptions - Enables more flexible data channel deployment scenarios without mandatory MMTel media

Unchanged Elements

The CR maintains all other aspects of clause 6.2.10.1, including: - Media feature tag requirements (+sip.app-subtype with "webrtc-datachannel" value) - Support indication for bootstrap and application data channel multiplexing (g.3gpp.dc-mux) - Protocol identifier and media format specifications (UDP/DTLS/SCTP and webrtc-datachannel) - Bandwidth limit determination requirements

Proposal: Deleting the constraint that a data channel SDP media description shall not be placed before the first SDP speech media description in clause 6.2.10.1.

Summary of 3GPP Technical Document S4-260087

Document Information

CR Number: 0604 rev 1
Specification: TS 26.114 v19.2.0
Category: F (Correction)
Release: Rel-19
Work Item: 5G_MEDIA_MTSI_ext, TEI19

Main Technical Contribution

Problem Statement

The current constraint in TS 26.114 clause 6.2.10.1 states that a data channel SDP media description shall not be placed before the first SDP speech media description. This constraint is no longer applicable because 3GPP R19 SA2 has specified standalone data channel sessions that can establish data channels without MMTel media (e.g., audio, video, messaging).

Proposed Change

Modification to Clause 6.2.10.1 (General)

The CR proposes to remove the restrictive placement constraint for data channel SDP media descriptions. Specifically:

Deleted Text: - "A data channel SDP media description shall not be placed before the first SDP speech media description."

Modified Text: The sentence describing data channel SDP media description inclusion is updated from: - "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text."

To: - "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text."

Technical Impact

This correction enables: - Standalone data channel sessions without requiring MMTel media components - Flexible SDP ordering where data channel media descriptions can appear in any position within the SDP - Alignment with SA2 specifications for Rel-19 standalone data channel functionality

Unchanged Requirements

The following requirements remain intact: - Support for data channel media remains optional for MTSI clients - Media feature tag requirements (+sip.app-subtype with "webrtc-datachannel" value) - g.3gpp.dc-mux media feature tag for bootstrap and application data channel multiplexing - Protocol identifier and media format specifications (UDP/DTLS/SCTP and webrtc-datachannel) - Bandwidth limit determination requirements per clause 6.2.5

Proposal: Deleting the constraint that a data channel SDP media description shall not be placed before the first SDP speech media description in clause 6.2.10.1.

manager:

[Technical] Removing “A data channel SDP media description shall not be placed before the first SDP speech media description” is directionally correct for standalone data channel sessions, but the CR does not add any replacement normative text clarifying that an SDP offer/answer with only data channel m-lines (no speech/video/text) is valid and how it interacts with the rest of clause 6.2.10.1 requirements.
[Technical] The change claims alignment with “R19 SA2 standalone data channel sessions” but provides no explicit reference to the SA2 stage-2 specification/clause that introduces this capability; TS 26.114 should normatively cite the relevant TS 24.229/TS 23.xxx/TS 24.xxx clause to justify the behavioral change.
[Technical] If ordering constraints are removed, the CR should verify and, if needed, update any dependent procedures elsewhere in TS 26.114 (e.g., offer/answer handling, media stream identification, media feature tag usage) that may implicitly assume speech m-lines exist or appear first.
[Technical] The updated sentence only addresses “added into the SDP independently” but does not explicitly state that data channel m-lines may appear in any position; if ordering freedom is the intent, it should be stated normatively (e.g., “may appear before or after any other m-line”) to avoid ambiguous interpretation.
[Technical] Standalone data channel sessions may affect session-level attributes (e.g., BUNDLE usage, a=group, a=msid semantics, DTLS role negotiation) and the CR does not assess whether clause 6.2.10.1 or related clauses need additional constraints when no RTP-based media is present.
[Editorial] The modified wording “may be added into the SDP independently, or to be added alongside” is grammatically incorrect and redundant; it should be simplified (e.g., “may be included in the SDP either alone or alongside other SDP media descriptions…”).
[Editorial] The phrase “added into the SDP” is non-standard SDP/spec wording; TS 26.114 typically uses “included/contained in the SDP offer/answer” and should keep consistent terminology.
[Technical] The CR summary says “flexible SDP ordering … in any position,” but the actual proposed text does not explicitly remove all ordering constraints beyond the deleted sentence; confirm there are no other ordering rules in the clause (or elsewhere) that still effectively block standalone/early placement.
[Technical] The “Unchanged Requirements” list includes media feature tags (+sip.app-subtype, g.3gpp.dc-mux) but the CR does not confirm whether these tags are still applicable/required in standalone data channel sessions (i.e., without MMTel context) or whether additional tags are needed to indicate standalone usage.
[Editorial] The summary references “MMTel media (e.g., audio, video, messaging)” but “messaging” is not an SDP media type in the same sense as audio/video/text; consider tightening the wording to avoid confusion (e.g., “audio/video/text m-lines”).
[Technical] If standalone data channel sessions are allowed, TS 26.114 should ensure interoperability guidance exists for endpoints that do not support data channels (optional support): e.g., expected behavior when receiving an offer with only a data channel m-line (reject session vs. reject m-line), which is not addressed by this CR.
[Editorial] The change description says “formatted according to IETF RFC 8864 [172]” but does not check whether the reference number [172] and RFC are correct for the data channel SDP format in this TS version; ensure the citation matches the spec’s reference list and intended RFC.

2026-02-09 08:45

Summary of 3GPP Technical Document S4-260116

Document Information

CR Number: 0014
Specification: TS 26.113 v19.1.0
Work Item: iRTCW-TEI (Interactive Real-Time Communication Work - Technical Enhancement and Improvement)
Category: F (Correction)
Release: Rel-19

Main Technical Contribution

Problem Statement

The JSON schema for the SWAP (Service and Workflow Adaptation Protocol) protocol contains inconsistencies that make it invalid and misaligned with the specification text. These issues could hinder proper implementation and interoperability.

Technical Changes to Clause 13.2.4.6 (JSON Schema)

The CR proposes a complete restructuring of the SWAP message JSON schema with the following key modifications:

1. Schema Structure Simplification

Removed: Complex nested definitions section that defined matching_criteria_object as a reusable component
Removed: Separate payload property with complex oneOf structures
Changed: Flattened schema structure by moving payload definitions directly under the root oneOf

2. Matching Criteria Handling

Before: Matching criteria was defined as a reusable object reference with type and value properties, allowing both predefined enums and custom strings via anyOf
After: Simplified to a direct string enum without the flexible anyOf structure
Impact: More restrictive but clearer definition - only allows predefined matching criteria types (ipv4, ipv6, fqdn, service, user, eas, app, location, qos, processing)

3. Message Payload Structure

Before: Payloads were nested under a payload property with detailed descriptions for each message type (register, response, connect, accept, reject, application)
After: Payloads are defined directly at the root level using oneOf, removing the intermediate payload wrapper
Removed: Explicit descriptions for each payload variant
Removed: Array structure for matching_criteria in connect payload

4. Required Fields

Changed: "source" in required fields changed to "source_id" to match the actual property name defined in the schema

5. Data Type Corrections

Reject/Error Payload: Changed request field type from "integer" to "number" for more flexibility

6. Extensions Object

Before: Defined with type "object" and description
After: Simplified to empty object {}

Impact Assessment

Positive Impacts

Corrects schema validation errors
Aligns JSON schema with specification requirements
Ensures proper interoperability between implementations

Potential Concerns

The simplified matching criteria structure is less flexible (removed anyOf allowing custom strings)
Removal of array support for matching criteria in connect payload may limit functionality
Loss of descriptive metadata for payload variants may reduce schema self-documentation

Affected Specifications

Core Specification: TS 26.113 (SWAP protocol)
Other Specifications: None directly affected
Test Specifications: Not affected
O&M Specifications: Not affected

Proposal: Fixes to the JSON schema to make it valid and to align with the specification.

Summary of 3GPP Technical Document S4-260117

Document Information

Specification: TS 26.113 v19.1.0
CR Number: 0015
Category: F (Correction)
Release: Rel-19
Work Item: iRTCW-TEI (Interactive Real-Time Communication Web - Technical Enhancement and Improvement)
Source: Qualcomm Inc.

Purpose and Rationale

The CR addresses an ambiguity in the SWAP (Streaming and WebRTC API) specification regarding the handling of the accept message in response to a close operation. Currently, the specification is unclear about whether the answer field (containing SDP answer) should be included in the accept message when responding to a close message, leading to potential implementation confusion.

Technical Changes

Accept Message Handling (Clause 13.2.4.4.5)

Description Updates (13.2.4.4.5.1)

Previous behavior: Accept message always contains answer SDP when replying to connect or update requests
Clarification added:
Accept message shall contain answer SDP when responding to connect or update messages
Accept message shall NOT contain SDP when responding to close messages
Explicitly separates the two use cases for the accept message

Parameter Definition (13.2.4.4.5.2)

answer parameter: Changed from mandatory to optional
Modified to "This parameter, when present, shall contain the answer SDP"
Makes it clear that answer is conditionally included based on the triggering message type

Update Message Clarification (13.2.4.4.6.1)

Reinforces that update message is for partial media teardown (half-close)
Distinguishes from close message which performs full session termination
Note added emphasizing the use of close message for full session termination

Close Message Clarification (13.2.4.4.8.1)

Explicitly states that accept message response shall be "without an SDP payload"
Clarifies session teardown procedure: accept message triggers resource release
Note added distinguishing close (full termination) from update (partial teardown)

Impact

The changes ensure proper protocol behavior by: 1. Removing ambiguity in accept message structure based on context 2. Preventing unnecessary SDP exchange during session termination 3. Clearly delineating between partial media teardown (update) and full session termination (close)

Proposal 1: Clarify that the answer parameter is optional in the accept message.

Summary of 3GPP CR on Correction to Animation Samples Transport

Document Information

Specification: TS 26.264 v19.1.0
CR Number: 0017
Category: F (Correction)
Release: Rel-19
Work Item: AvCall-MED
Source: Qualcomm Inc.

Problem Statement

The current specification incorrectly implies that avatar animation samples should be carried on the metadata data channel, which is defined as text-only UTF-8 JSON. However, ARF (Avatar Representation Format) animation samples are binary data. This mismatch creates several issues:

Requires base64 encapsulation for binary data in text channel
Introduces additional latency
Creates interoperability problems
Risk of incompatible proprietary workarounds and fragmentation

Technical Changes

1. Metadata Data Channel Clarification (Clause 6.2)

Added clarification: - Explicit NOTE stating that the metadata data channel (sub-protocol "3gpp-ar-metadata") is text-only and not intended for transport of binary data such as avatar animation samples - Explicit statement that the metadata data channel shall not be used to transport ARF avatar animation samples

2. New Avatar Animation Data Channel (Clause 6.3.2)

Major addition - dedicated binary transport channel:

Channel Characteristics

Sub-protocol identifier: "3gpp-ar-animation"
Purpose: Binary transport for ARF avatar animation samples (clause 8 of TS 26.565)
Separation: Distinct from metadata data channel
Content restriction: Shall only carry avatar animation samples

Transport Parameters

Transmission order: In-order
Reliability: Should be reliable by default
Partial reliability: May negotiate using data-channel parameters (max-time or max-retr) when supported by both endpoints
SDP signaling: Included in dcmap attribute

Message Format

Each message contains exactly one ARF animation sample
No compression scheme defined for animation samples

Example SDP

a=dcmap:2 label="avatar-anim-1" subprotocol="3gpp-ar-animation" ordered max-time=150

3. Removed Content (Clause 6.3.2)

Deleted specifications: - Previous avatar animation message format using metadata channel (Table 6.3-1) - Message type "urn:3gpp:avatar:v1:animation" - Subtype field for different animation types (facial, joint, landmark, audio, video) - Payload object structure for animation samples in JSON format

Retained control messages: - Stopped message (urn:3gpp:avatar:v1:animation:control:stopped) - Table 6.3-2 - Resumed message (urn:3gpp:avatar:v1:animation:resumed) - Table 6.3-3 - These control messages continue to use the metadata data channel

Impact

Requirements for AR-MTSI Clients/MF

Shall support exchange of avatar animation data over the new Avatar Animation Data Channel
Shall establish or accept Avatar Animation Data Channel for animation sample exchange
Shall support ARF sample formats per clause 8 of TS 26.565

Consequences if Not Approved

Incompatible implementations using workarounds (text/base64, proprietary channels)
Fragmentation of implementations
Interoperability failures between vendors

Summary

This CR introduces a fundamental architectural correction by separating binary avatar animation sample transport from text-based metadata transport. It defines a new dedicated data channel with appropriate binary transport characteristics, preventing the need for inefficient text encoding of binary data and ensuring proper interoperability for avatar animation in AR-MTSI calls.

Proposal 1: Add a NOTE in clause 6.2 clarifying that the metadata data channel (sub‑protocol "3gpp‑ar‑metadata") is text‑only and is not intended for the transport of binary data such as avatar animation samples.

Proposal 2: Add a new sentence at the end of clause 6.2 stating: "The metadata data channel shall not be used to transport ARF avatar animation samples defined in clause 8 of [10]."

Proposal 3: Replace the existing text in clause 6.3.2 with new text that defines an Avatar Animation Data Channel with sub‑protocol "3gpp-ar-animation" for binary transport of ARF avatar animation samples as specified in clause 8 of [10], separate from the metadata data channel defined in clause 6.2.

Proposal 4: Specify in clause 6.3.2 that the Avatar Animation Data Channel shall only carry avatar animation samples, with transmission order set to in‑order and transmission reliability set to reliable (with optional negotiation of partial reliability using data‑channel parameters).

Proposal 5: Specify in clause 6.3.2 that each "3gpp-ar-animation" data‑channel message shall contain exactly one ARF animation sample.

Proposal 6: Remove the existing text in clause 6.3.2 that defines avatar animation messages with type "urn:3gpp:avatar:v1:animation" and the associated message format in Table 6.3-1, as these are replaced by the binary Avatar Animation Data Channel.

Proposal 7: Retain the existing text in clause 6.3.2 regarding the stopped and resumed control messages (Tables 6.3-2 and 6.3-3), as these control messages continue to use the metadata data channel.

manager:

[Technical] The new “3gpp-ar-animation” data channel definition lacks a normative mapping to WebRTC/RTCDataChannel payload type expectations (binary vs text) and does not explicitly state that messages are sent as binary (e.g., “binary message” / “application/octet-stream”), which is essential to avoid implementations still treating payloads as UTF-8 text.
[Technical] The CR removes the JSON “message type” and subtype structure (facial/joint/landmark/audio/video) but does not replace it with any in-band or out-of-band mechanism to identify the animation sample type/stream, risking ambiguity when multiple ARF sample kinds exist or when multiple animation streams are used concurrently.
[Technical] “Each message contains exactly one ARF animation sample” is underspecified without defining framing rules relative to ARF (TS 26.565 clause 8): if an ARF sample can exceed SCTP message size/MTU, fragmentation/reassembly behavior and any maximum message size constraints should be specified to ensure interoperability.
[Technical] The reliability guidance is inconsistent/weakly normative (“should be reliable by default” + “may negotiate partial reliability”); the spec should clearly state default ordered/reliability parameters and the required behavior when endpoints do not support partial reliability, otherwise different defaults will break interop.
[Technical] The SDP example uses a=dcmap with ordered max-time=150 but the CR does not specify the full required dcmap parameter set (e.g., whether ordered is mandatory, whether max-time/max-retr are mutually exclusive, and what to do if both are offered), leaving negotiation behavior unclear.
[Technical] The statement that the animation channel “shall only carry avatar animation samples” conflicts with the retained “stopped/resumed” control messages remaining on the metadata channel; if control needs tight synchronization with samples, the CR should justify why control is not on the same channel or define correlation rules across channels.
[Technical] The CR introduces a new subprotocol identifier but does not address backward compatibility/interworking with Rel-19 implementations that followed the previous JSON/base64 approach; at minimum, it should specify how an endpoint detects peer support and what fallback behavior is permitted/forbidden.
[Technical] The new channel purpose references “ARF avatar animation samples (clause 8 of TS 26.565)” but does not normatively constrain codec/profile/versioning of ARF samples or how version mismatches are handled, which was previously partially handled via typed JSON structures.
[Technical] Removing the JSON payload object also removes any explicit timestamping/sequence metadata that may have been present or implied; the CR should confirm whether timing/ordering is entirely derived from ARF sample contents and what happens if ARF does not carry sufficient timing for playout.
[Technical] The CR says “No compression scheme defined for animation samples” but does not clarify whether ARF samples may already be compressed or whether additional compression is prohibited; this can lead to incompatible assumptions about payload processing.
[Editorial] Clause references are potentially inconsistent: the CR claims changes in “Clause 6.3.2” and deletion of “Table 6.3-1” while retaining “Table 6.3-2/6.3-3”; ensure numbering and cross-references in TS 26.264 remain correct after deletions/additions.
[Editorial] The wording “metadata data channel … shall not be used to transport ARF avatar animation samples” should be aligned with existing 3GPP normative language and scope (e.g., “AR-MTSI client shall not…”), otherwise it may read as a general prohibition beyond the spec’s intended applicability.
[Editorial] The CR summary asserts the metadata channel is “defined as text-only UTF-8 JSON”; if TS 26.264 currently defines it that strictly, cite the exact normative text being corrected—otherwise the CR should adjust the rationale to match the actual spec wording to avoid overstating the error.

2026-02-09 09:09

Total TDocs: 13 | PDFs: 11 | Comments: 3