# Summary of S4-260217: Support for Dual-Tone Multi-Frequency for IMS Voice over NB-IoT NTN

## Background

SA1 has mandated support for Dual-Tone Multi-Frequency (DTMF) for IMS voice over NB-IoT NTN. The document addresses the need to consider multiplexing of DTMF traffic with voice traffic in the system design, referencing RFC 4733 for DTMF payload formats.

## DTMF Use in IMS Voice Services and Traffic Characteristics

### DTMF Payload Types

RFC 4733 defines two DTMF payload format types:
- **Telephone events**: User button presses (0-9, *, #) during calls
- **Tones**: Ringing tone, busy tone, etc.

For IMS calls, tones are generated locally (e.g., "180 Ringing" or "486 Busy Here" SIP messages trigger local tone generation), so **only telephone events need to be transported** over the air.

### Technical Specifications

- **RTP payload size**: 4 bytes
- **Telephone events**: Standard DTMF digits and symbols

### Traffic Characteristics

The document identifies key DTMF traffic characteristics:
- DTMF packets are transmitted infrequently (only on button press)
- Telephone events may or may not overlap with active voice activity
- Multiple DTMF packets may be transmitted per button press, with the RTP marker bit indicating the first packet
- RTP packets must differentiate between voice and DTMF packets for multiplexing

### Design Assumptions

Three key assumptions are established:
1. **DTMF packet size ≤ voice packet size**
2. **DTMF delay requirements are less stringent than voice service**
3. **DTMF takes priority over voice**

### SPS Configuration Considerations

When SPS (Semi-Persistent Scheduling) is configured for voice traffic with fixed TBS:
- If DTMF packets don't overlap with active voice frames, they can be multiplexed with SID frames (smaller than active voice frames) and transmitted in SPS occasions
- If overlapping occurs, the UE can puncture an active voice frame and send the DTMF frame instead
- SA4 needs to coordinate with RAN1 and RAN2 on SPS design

## Proposals

**Proposal 1**: Make DTMF support an integral part of IMS voice service over NB-IoT NTN

**Proposal 2**: Design DTMF support based on the three assumptions:
- DTMF packet size ≤ voice packet size
- DTMF delay requirement less stringent than voice
- DTMF priority over voice

**Proposal 3**: SA4 to design mechanisms for voice and DTMF multiplexing for SPS and coordinate with RAN1 and RAN2