# 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