Summary of S4-260077: Key Issue Description for Interworking with MTSI

Document Overview

This contribution from Samsung proposes text for Key Issue #2 (Interworking facilitation with MTSI) in TR 26.814 for the DCE_MED study. The document addresses interworking scenarios between DCMTSI UEs and legacy MTSI UEs, identifying gaps between SA2's TS 23.228 and SA4's TS 26.114.

X.2.1 General - Interworking Data Flows

Required Data Flow Setup

The document defines the necessary data flows for interworking between originating DCMTSI UE and terminating MTSI UE:

• Bootstrap data channel: Between originating DCMTSI UE and IMS Data Channel functional entities
• Non-data channel associated media: RTP flows between DCMTSI UE and MTSI UE (e.g., audio/video)
• Data channel associated media:
• Application data channel between DCMTSI UE and IMS Data Channel functional entities
• Interworking paths to terminating MTSI UE:
  • Via MF: RTP flows between MTSI UE and Media Function
  • Via DC AS: Not specified (e.g., SMS)

Signaling Procedures

The document references TS 23.228 clause AC.7.9 procedures:

• When terminating UE doesn't support IMS DC, it returns bootstrap DC negotiation result with port number zero
• DCSF recognizes rejection and establishes bootstrap data channels only between originating UE and MF

Interworking Mechanisms

Via MF: - MF performs transcoding upon DCSF instructions - Transcoded MMTEL media transferred to terminating MTSI UE via associated RTP stream

Via DC AS: - DCSF determines IMS DC interworking based on session event notification from IMS AS - Changes P2P application data channel to P2A - Originating DCMTSI UE sends data channel application media to DC AS - DC AS performs interworking actions (details out of scope for TS 23.228)

X.2.2 Gap Analysis with TS 26.114

Identified Misalignment

The document identifies a critical gap between SA2 and SA4 specifications:

Observation 1: TS 23.228 specifies that IMS AS modifies endpoint type from P2P to P2A to support IMS DC interworking via DC AS.

Observation 2: TS 26.114 clause 6.2.10.3 states that SDP answerer for application DC shall include the same values for "a=3gpp-req-app" from the offer (except optional "app-dc-status" parameter), preventing modification of the "adc-stream-id-endpoint" parameter.

Impact

Observation 3: DC application in originating DCMTSI UE requires capability to identify when interworking mode is enabled to distinguish the actual target endpoint for specific media flows.

Technical Contribution Summary

This document: 1. Provides foundational text describing interworking architecture and data flows for TR 26.814 2. Identifies specification misalignment between TS 23.228 (SA2) and TS 26.114 (SA4) regarding endpoint type modification in "a=3gpp-req-app" attribute 3. Highlights the need for DC application to detect interworking mode for proper endpoint identification

Summary of S4-260092: IMS Bootstrap Data Channel Restart

Introduction

This contribution addresses issues related to IMS Data Channel (DC) failure and exceptional case handling in TS 26.114, which will be reviewed under the newly started study on DC Enhancements (FS_DCE_MED).

Problem Statement

Missing Specifications for Failure Cases

The document identifies that TS 26.114 lacks clear handling procedures for IMS DC failure and exceptional cases, which could result in: - Inconsistent behavior - Interoperability problems

Scope within DC Enhancement Study

The identified problem maps to multiple DC Enhancement study objectives: - Clarifications to HTTP protocol usage on DC - Identification of inconsistencies and ambiguities between TS 23.228, TS 26.114, TS 26.264, and TS 26.567

IMS DC Transport Restart Scenarios

The contribution focuses on IMS DC transport restart (DTLS restart and/or SCTP restart), which may be triggered by: - IMS call forwarding - IMS call forking (typically when using IMS DC as "early media") - Access transport failures causing IP address and/or UDP port changes on core and/or UE side

Note: DTLS and SCTP restart procedures are covered by references to IETF RFC 8864 and RFC 8841 in TS 26.114.

Bootstrap Data Channel (BDC) Initial URL Ambiguity

Current TS 26.114 clause 6.2.10.1 specifies: - Initial entry point accessible at HTTP root ("/") URL after BDC establishment - Per TS 29.176 clause 6.1.6.2.5, this root URL is typically modified in the MF to represent the specific subscriber before being passed to DCSF for user customization - The modified URL is not visible to the UE

Key Gap: The specification does not define which initial URL the UE should use when the BDC is reestablished after a restart.

Potential Solutions

The document presents three alternative approaches for selecting the initial URL in a reestablished BDC:

Option 1: Use Original Initial Entry Point ("/") - Preferred

Characteristics: - Reuse the same initial entry point as first BDC establishment - Possible interpretation of existing text - Straightforward implementation - Provides clearly defined restart point - Maintains possibility for MF to adapt URL to specific subscriber - No identified downsides

Source Position: This is the preferred approach.

Option 2: Use Last URL Before Restart

Limitations: - Would likely fail in forking or forwarding scenarios - IMS network serving the URL may differ before and after restart - Previously valid URL may become invalid in the post-restart IMS network

Option 3: Use Some Other URL

Status: - No current use cases or scenarios exist to guide URL selection - Not a viable option at this time

Proposals

The document proposes two actions for the DC Enhancement study:

1. Include this topic as a key issue in draft TR 26.823
2. Include the above potential solutions to address this key issue in draft TR 26.823

Comprehensive Summary of S4-260125: Automatic Resumption for IMS Data Channel

Document Overview

This contribution from Samsung addresses Key Issue #4 concerning Automatic Resumption functionality in the context of the FS_DCE_MED study. The document responds to an LS from GSMA (S4-250755) requesting technical improvements to support automatic resumption service requirements developed by GSMA TSG IMSDCAS in GSMA PRD NG.129.

Key Issue #4: Support of Automatic Resumption

General Description

Core Functionality: - Automatic resumption enables users to resume streaming experiences from the point where they left off - Provides session continuity in IMS data channel environments - Commonly available on digital streaming platforms to maintain user engagement

Use Cases

The document identifies two primary use case categories:

1. Session Termination Scenarios: - Abnormal or normal session termination (network-initiated or user-initiated) - Enables application session continuation beyond single IMS session duration - Enhances user engagement with the platform

2. System Notification Scenarios: - User receives system notifications (e.g., security alerts) - Allows user to suspend application to address notifications - Enables resumption at appropriate point after handling notification

Application Scenarios

Automatic resumption must support: - Peer-to-peer sessions: Direct communication between caller UE#1 and callee UE#2 - Call transfer cases: Scenarios where caller UE#1 is transferred to UE#3

Technical Requirements Identified by GSMA

Key Technical Element: - Requires a persistent identifier serving as unique key for database storage of application context/state - This identifier must be: - Exchanged between peers - Configurable with defined lifetime

Proposed Analysis: The document proposes to analyze the technical feasibility of implementing this persistent identifier mechanism within the IMS data channel framework.

Scope of Work

The contribution establishes the foundation for technical feasibility analysis of automatic resumption support, focusing on the identifier mechanism required to maintain and restore application state across session boundaries.

Discussion of Using a Single DC Stream for Multi DC Application Data Transmission

Overview

This contribution from China Mobile discusses potential issues with the current DC (Data Channel) application data transmission mechanism and proposes enhancements to support multiple DC applications over a single DC stream.

Problems with Current DC Mechanism

Resource and Implementation Limitations

• Current standard requires each DC application to establish a dedicated ADC (Application Data Channel) with its server or peer terminal before data transmission
• Theoretical support exists for numerous DC channels per call session, but practical implementations face constraints:
• Resource consumption and power usage limitations
• Current chip implementations support only up to 4 ADC bearers per session
• Limited number of bearers cannot flexibly support diverse DC applications with different QoS requirements and destination endpoints

Latency and User Experience Issues

• Each DC application opening requires DC bearer negotiation, introducing 100-500 ms delay
• Sequential application switching (closing DC application 1 and immediately opening DC application 2) can cause negotiation conflicts with non-robust terminal implementations

Signaling Conflicts

• DC applications designed for immediate service upon call answering (e.g., call captioning, translation, background replacement, real-time transcription) face high risk of signaling conflicts
• When both calling and called parties have subscribed to related services, simultaneous DC negotiation requests at call answer time create conflict scenarios

Proposed Solution

Core Suggestion

Support a common DC channel shared among multiple DC applications with the following approach:

• For ordinary data interaction: DC applications can directly request data transmission without first establishing a dedicated DC bearer
• For special requirements: DC applications with specific transport protocol or QoS requirements still need to establish dedicated ADC before data transmission

Solution 1 Details

• Define a generic ADC with fixed stream IDs
• Enable DCSF (Data Channel Selection Function) to support distribution of data from multiple DC applications
• Extend the ADC concept to allow ADC channels with specific stream IDs to carry data for multiple DC applications

Proposal

Study whether to use and how to enhance DC to support multiple DC Application Data Transmission in a single DC stream.

3GPP TR 26.814 V0.0.1 - Study on Enhancements to IMS Data Channel (Release 20)

Document Overview

This Technical Report is an early-stage study document (v0.0.1) from SA4 focusing on enhancements to the IMS Data Channel feature. The document builds upon Release 19 work that introduced architecture and procedure enhancements for IMS DC in TS 23.228 Annex AC, including Data Channel Signalling Function (DCSF), Media Function (MF), Data Channel Application Server (DC AS), and associated procedures.

Scope

The study aims to: - Improve interoperability of IMS Data Channel specified in TS 26.114 - Close ambiguities identified after Release 19 stage 2 architecture work - Address issues raised by external groups (e.g., GSMA) and other 3GPP working groups - Align stage 3 specification work with the Release 19 stage 2 framework

Key focus areas include: - Multi-application multiplexing - Interworking between Data Channel enabled MTSI and MTSI-only endpoints - HTTP subprotocol usage and handling of external resources - Cross-specification alignment

Key Definitions

IMS Data Channel: A WebRTC data channel established within an IMS session according to TS 26.114, typically using DTLS/SCTP

Data Channel Application: An application identified and requested for use over the IMS Data Channel as described in TS 23.228 Annex AC

Data Channel Application Server (DC AS): An application server that provides DC application content and may participate in DC procedures

Data Channel Signalling Function (DCSF): A network function supporting IMS Data Channel application discovery, bootstrap, and policy handling

Media Function (MF): A network function for media anchoring, potentially supporting proxying and interworking functions for IMS Data Channel

Key Issues Identified

KI#1: Multiplexing Edge Cases for Multi-Application IMS DC (TS 23.228 Annex AC.7.10)

Issue Statement: [Empty - to be filled]

Solution Direction: [Empty - to be filled]

Potential Specification Impacts: [Empty - to be filled]

Open Points and Dependencies: [Empty - to be filled]

KI#2: Interworking Facilitation with MTSI (TS 23.228 Annex AC.7.9)

Issue Statement: [Empty - to be filled]

Solution Direction: [Empty - to be filled]

Potential Specification Impacts: [Empty - to be filled]

Open Points and Dependencies: [Empty - to be filled]

KI#3: Clarifications to HTTP Protocol Usage on IMS DC and Handling of External Resources

Issue Statement: [Empty - to be filled]

Solution Direction: [Empty - to be filled]

Potential Specification Impacts: [Empty - to be filled]

Open Points and Dependencies: [Empty - to be filled]

KI#4: Consolidate Release 19 Stage 3 Implications and Address Incoming Liaison Statement Topics

Issue Statement: [Empty - to be filled]

Solution Direction: [Empty - to be filled]

Potential Specification Impacts: [Empty - to be filled]

Open Points and Dependencies: [Empty - to be filled]

KI#5: Cross-Specification Alignment (TS 23.228, TS 26.114, TS 26.264, TS 26.567)

Issue Statement: [Empty - to be filled]

Solution Direction: [Empty - to be filled]

Potential Specification Impacts: [Empty - to be filled]

Open Points and Dependencies: [Empty - to be filled]

KI#6: New Media Use Cases and Gap Analysis for IMS DC

Issue Statement: [Empty - to be filled]

Solution Direction: [Empty - to be filled]

Potential Specification Impacts: [Empty - to be filled]

Open Points and Dependencies: [Empty - to be filled]

Conclusions and Recommended Way Forward

[Empty - to be filled]

Document Status

This is a skeleton/template document (v0.0.1) dated February 2026. All technical content sections are currently empty placeholders awaiting population with actual study results. The document has not been subject to any approval process and is provided for future development work within 3GPP only.

The document establishes the framework for studying six key issues related to IMS Data Channel enhancements, with focus on alignment between stage 2 (TS 23.228) and stage 3 (TS 26.114) specifications, as well as addressing practical implementation concerns around multiplexing, interworking, protocol usage, and cross-specification consistency.

Summary of S4-260204: Time Plan for DC Enhancements WI

Introduction

This document proposes a time plan for the Study Item on Data Channel Enhancements (FS_DCE_MED), which was approved at SA plenary #110. The study aims to address clarifications and enhancements to the Data Channel functionality in TS 26.114.

Study Item Key Issues

The Study Item addresses six key issues:

KI#1: Analyze Multiplexing Edge-Cases (per TS 23.228 AC.7.10)

• Study multi-application multiplexing scenarios where an m-line combines several a=3gpp-req-app attributes with mixed endpoint types (…-UE and …-Server)
• Document examples aligning with stage-2 procedures

KI#2: Interworking Facilitation with MTSI

• Study signaling aspects for associating a DC application stream to MF-anchored RTP legs when interworking is invoked per TS 23.228 AC.7.9
• Document informative examples consistent with TS 23.228 AC.7.9 flows

KI#3: Clarifications to HTTP Protocol Usage on DC

• Study and recommend solutions for handling external resources
• Document guidelines on DC application behavior for the HTTP subprotocol

KI#4: Consolidate Rel-19 Stage 3 Implications

• Address stage 3 implications from NG_RTC_Ph2
• Address identified ambiguities if applicable
• Incorporate features from other 3GPP WGs and SDOs (e.g., GSMA LS on Automatic Resumption)
• Handle any future incoming LSs

KI#5: Identify Inconsistencies and Ambiguities

• Identify inconsistencies between TS 23.228 and TS 26.114, TS 26.264, and TS 26.567
• Document alignment and clarification actions if needed

KI#6: Document New Media Use Cases

• Document new media use cases
• Identify gaps and potential solutions for IMS DC based on SA1 requirements

Proposed Timeline

SA4#134 (17-21 November 2025, Dallas, US)

• Agree study item

3GPP SA4 RTC SWG AHG Telcos

• Agree draft TR 26.814
• Document identified key issues
• Prioritize topics to be addressed
• Document proposed changes

SA4#135 (09-13 February 2026, Goa, IN)

• Agree draft TR 26.814
• Document identified key issues
• Prioritize topics to be addressed
• Submit TR for information

SA4#135e-bis (13-17 April 2026, online)

• Discuss and agree solutions to key issues
• Prepare and document CR drafting plans

SA4#136 (11-15 May 2026, Montreal, CA)

• Finalize solutions to key issues
• Prepare and document CR drafting plans
• Send LSs to other 3GPP groups and SDOs outlining next steps based on TR findings
• Submit TR for approval

SA#112 (09-12 June 2026, Singapore, SG)

• Approve TR 26.814

Summary of S4-260205: External Resources for DC Applications

Introduction

This contribution from Qualcomm addresses the issue of access to external resources by IMS Data Channel (DC) applications, as raised by GSMA. The document proposes solutions for enabling DC web applications to securely access third-party services while maintaining security and compliance with web standards.

Use Case Description

The document describes a scenario from GSMA NG UPG where: - A UE-resident web application is delivered by a DC Application Server (DC AS) - The application integrates an external AI Large Language Model (LLM) hosted at a third-party origin over HTTPS - Authorization is handled via OAuth 2.0 - After the DC AS serves the UI over the Data Channel, the application must contact external endpoints to: - Submit prompts - Stream partial outputs (via WebSockets, Server-Sent Events, or HTTP/2/3) - Fetch auxiliary sub-resources (scripts, fonts, images, authorization panels)

Potential Solutions

3.1 MF as TLS Tunnel or HTTP(S) Proxy

Rejected Approach:

The document strongly recommends against using the MF as an HTTP(s) proxy that terminates TLS connections, as this: - Exposes user credentials and application data to the MF - Creates extreme security risks with potential data leakage

Proxy-Tunnel Approach Analysis:

The document analyzes a proxy-tunnel over IMS Data Channel approach where: - UE uses DTLS/SCTP association established during call setup - Application data channels are opened for tunneling to external origins via MF - Per TS 26.114, each application data channel requires a=dcmap attribute in SDP - UE sends subsequent SDP offer (via SIP re-INVITE or SIP UPDATE per TS 24.229) to add/update channels - MF validates requested authority, opens TCP connection to external origin, and confirms tunnel - UE runs full TLS handshake to origin through tunnel, preserving end-to-end confidentiality

Performance and Scaling Issues: - One external destination maps to one application data channel - Each additional channel requires SDP change and new offer/answer round-trip - P-CSCF and S-CSCF process each update - Non-trivial delay before application bytes can flow on new stream

UE Implementation Complexity: - Standard browser/OS HTTP stacks don't expose IMS primitives - Web application must intercept fetch() and XMLHttpRequest - Must trigger IMS client to create subsequent SDP offer with new a=dcmap entries - Must wait for answer before serializing HTTP over SCTP stream - Must parse response bytes and reconstruct JavaScript Response objects - Complex error handling spanning Service Worker, SIP offer/answer, SCTP stream state, MF policy, and external origin - Long-lived responses (e.g., Server-Sent Events) increase fragility - Service Worker must bridge flow control between browser and SCTP stream - SCTP reset or mid-call session change truncates stream, requiring recovery logic

Provider-Side Security and Operations Issues: - OAuth workflows rely on source network and geolocation context - Provider observes MF's egress address rather than UE's carrier address - Tokens issued in one network context may appear replayed from another - Refresh flows validating by IP continuity may fail - Provider heuristics depending on IP reputation, ASN alignment, or regional consistency can misclassify traffic - Aggregation behind single MF address collapses attribution - Rate limiting, quota enforcement, abuse mitigation, and usage-based billing lose per-user fidelity - Single abusive client can trigger blocks affecting all users sharing the MF - Geolocation and regulatory controls reflect MF's location instead of UE's, creating false rejections and compliance issues - Audit trails record MF as caller, complicating incident response and per-user tracing

3.2 CSP Enforced at the UE with CORS at the External Origin

Recommended Approach:

The CSP-centric solution: - Keeps policy expression at the DC Application Server - Enforcement at the UE - Fully compatible with all web browsers

Mechanism: - DC AS delivers DC web application and declares strict Content-Security-Policy in HTTP response over bootstrap data channel - Policy starts from "default deny" then allows only required external origins for each resource class - UE enforces effective CSP locally - Any fully qualified URL not admitted by policy is blocked before network connection is made

Policy Constraints: - connect-src constrains connections for data exchange - Only authorization server and specific API endpoints needed by LLM workflow are listed - Script execution limited to code authorized by DC AS using per-response nonce or stable hashes

CSP and CORS Integration: - CSP operates together with CORS - Even when CSP admits an origin, cross-origin request only proceeds if external server opts in with correct Access-Control-Allow-Origin value - When credentials are present, external server returns caller origin (no wildcards) - Keeps OAuth flows predictable - Tokens sent only to hosts listed in connect-src - Frames and form submissions restricted to explicit authorization domains - No network element added - Preserves end-to-end TLS between UE and external provider

Example Headers:

Baseline CSP with default deny and nonce-based scripts: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<per-response-random>' 'strict-dynamic'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content

LLM integration with OAuth authorization server: Content-Security-Policy: default-src 'self'; connect-src 'self' https://api.example-llm.com https://auth.example-llm.com; script-src 'self' 'nonce-<per-response-random>' 'strict-dynamic'; style-src 'self'; img-src 'self' data:; font-src 'self'; frame-src https://auth.example-llm.com; form-action 'self' https://auth.example-llm.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content

Way Forward

Proposed Approach

Adopt CSP and CORS based approach for secure external resource access by IMS Data Channel web applications because it: - Keeps standard web security model - Preserves end-to-end TLS between UE and external origins - Avoids introducing network intermediaries that terminate TLS or require per-destination IMS signaling

Proposed Clarifications for TR 26.814 (FS_DCE_MED Rel-20)

1. Application Origin: Clarify that DC AS is the application origin for delivered web content, and that UE applies standard same-origin policy

2. External Resource Fetching: Clarify that external resources may be fetched directly by UE over HTTPS, subject to UE enforcement of Content-Security-Policy delivered by DC AS

3. CORS Processing: Clarify that cross-origin requests follow standard CORS processing at external origin, including rules for credentialed requests

4. Informative Examples: Provide informative examples for common patterns including:

5. OAuth authorization
6. WebSockets
7. Server-Sent Events

8. HTTP/2 or HTTP/3 streaming

9. Scope Boundaries: Clarify that:

10. 3GPP specifies transport and application delivery over IMS Data Channel
11. Trust computation and content source validation follow existing platform and browser security mechanisms, consistent with SA3 feedback

Additional Considerations

Regulation: - Per SA1 guidance, applicability of telecom regulation to Data Channel applications depends on local regulation and service context

CAPIF Framework: - If use case requires network-controlled exposure of third-party APIs, CAPIF framework in TS 23.222 can be considered as reference (per SA6 feedback) - Complementary to CSP and CORS approach for web application resource access

Lawful Intercept (LI): - Additional incoming liaison statements (e.g., SA3-LI requests on LI requirements for IMS Data Channel) should be tracked under KI#4 of FS_DCE_MED - SA4 should document which media plane configurations provide: - Decrypted content at network element (e.g., when MF terminates security association and has access to plaintext) - No decrypted content at network element (e.g., when MF only forwards encrypted packets, or when DTLS is end-to-end between UEs) - SA4 should coordinate with SA2 and SA3 on required stage 2 and security updates, including DTLS profile choices and LI related procedures