TDoc: S4-260133

[Technical] The proposed “requirements” (e.g., “4K + HDR uplink video capability”, “eye tracking”, “user intention understanding”) are largely service/AI feature statements and not clearly mapped to media delivery functions in TR 26.870 clause 4.2; they need to be reframed as measurable media delivery requirements (latency, bitrate ranges, synchronization, reliability, metadata carriage) or moved to a more appropriate section/spec.

[Technical] “4K + HDR uplink video capability” is underspecified and potentially unrealistic without constraints (frame rate, codec profiles/levels, HDR format such as HDR10/HLG, color depth, end-to-end latency, and uplink bandwidth assumptions); as written it is not testable and risks conflicting with existing 5G/IMS deployment realities.

[Technical] Eye tracking support is introduced without defining what the network/media system must transport (e.g., gaze vectors, timestamps, coordinate systems, sampling rates) and without addressing synchronization with audio/video; this omission makes it unclear whether the requirement impacts RTP payloads, metadata frameworks, or application-layer signaling.

[Technical] “User intention understanding through voice and gesture inputs” is not a media delivery requirement and implies AI inference in the network/operator domain; the CR should clarify whether the requirement is about transporting multimodal sensor streams/metadata, or about network exposure/compute, otherwise it exceeds SA4 media scope.

[Technical] “Device-Aware QoE” is vague: it does not specify the mechanism (adaptation sets, scalable coding, multi-stream, per-device rendering constraints) nor the KPIs (stall rate, motion-to-photon latency, audio-video sync); it should align with existing 26-series QoE/QoS adaptation concepts rather than introducing a new undefined tiering concept.

[Technical] “IMS Extensions: Extensibility of IMS to support these new capabilities” is problematic in TR 26.870 unless it identifies concrete IMS/SIP/SDP capability negotiation needs; otherwise it becomes an open-ended requirement that overlaps with SA2/CT and lacks normative direction.

[Technical] “Multi-Media Protocol Extensions: Review of protocol extensions for multi-media transporting” is not a requirement but an action item; it should be converted into specific protocol needs (e.g., RTP/RTCP extensions, SDP attributes, metadata carriage, multi-stream synchronization) or removed from requirements text.

[Technical] The service definition claims the service “can be natively provided by operators” but does not specify architectural implications (edge compute, media processing functions, exposure APIs) or how this interacts with existing 3GPP media frameworks; this risks creating an ungrounded requirement without feasibility analysis.

[Technical] The contribution references SA1 TR 22.870 use cases for aging populations but does not trace each new requirement back to a specific SA1 requirement/use-case element; lack of traceability weakens justification and may introduce requirements not endorsed by SA1.

[Editorial] The document metadata is inconsistent: it is labeled “Document: S4-260133” but “Document Number: S4-260080”; this needs correction to avoid confusion in CR tracking and meeting records.

[Editorial] Terminology is inconsistent/unclear (“multi-media transporting”, “intelligent immersive calling”, “tiered QoE”); the CR should introduce definitions and use consistent 3GPP wording (e.g., “multimedia transport”, “immersive communication”) aligned with TR 26.870 style.

[Editorial] The summary states “updates to clause 4.2” and “New Clause 4.2.1” but does not show the exact tracked changes text; for a CR for approval, the absence of precise change markup (additions/deletions) makes it impossible to verify consistency with the current clause structure and numbering.