[FS_DCE_MED] Key Issue Description for Interworking with MTSI
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.
The document defines the necessary data flows for interworking between originating DCMTSI UE and terminating MTSI UE:
The document references TS 23.228 clause AC.7.9 procedures:
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)
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.
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.
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