Review: 10.4

[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.

[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.

[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.