Typically, "DTMF events" are triggered by an end-user (on either side of the speech call) by pressing some key of the user's terminal, with the goal to control services in the network or in an application server. This may happen throughout the duration of the speech call on both ends of the call. It might happen that DTMF events are forwarded as telephone events to the (remote) MTSI client in terminal. In such a case, the MTSI client in terminal may convert the telephone events into audible DTMF tone-pairs. There is, however, no requirement in 3GPP for handling downlink telephone events. This Annex describes a method for sending DTMF events as telephone events within the same RTP media stream as the speech, i.e. "inband", using the same IP address and UDP port as the RTP for speech, but using a different RTP Payload Type number.

• MTSI clients in terminal offering speech communication shall support the below described method in the transmitting direction (uplink) and should support it in the receiving direction (downlink).
• MTSI media gateways offering speech communication shall support the below described method in both directions with respect to the MTSI client in terminal, the transmitting direction (downlink) and in the receiving direction (uplink). For MTSI media gateways, the described method applies only to the PS session between the MTSI gateway and the MTSI client in terminal.
• The use of the telephone-event codec between MTSI media gateways is recommended. Typically, DTMF events are also transported between MTSI media gateways as telephone events in both directions.

DTMF events shall be encoded and transmitted in MTSI sessions as "telephone events" in RTP packets, using the selected "telephone-event" codec. DTMF events in this Annex refer to the DTMF Named Events described in Table 3, Section 3.2 of RFC 4733, i.e. events (0-9, *, # and A-D) which are encoded with event code values 0-9, 10, 11 and 12-15 respectively. DTMF events are carried as part of the audio stream which can either be narrowband, wideband, super-wideband or fullband audio, i.e. use 8 kHz or 16 kHz RTP clock rate respectively. MTSI clients that in addition to narrowband also support wideband, super-wideband or fullband speech shall support telephone-event RTP clock rates matching all supported codecs. When switching between speech and DTMF, telephone events shall use the same RTP clock rate as the currently used codec for the speech signal in the same RTP stream. The encoding of DTMF events includes specifying the duration time for the events, see RFC 4733. Supporting long-lasting DTMF events, where the duration time exceeds the maximum duration time expressible by the duration field, is optional. If supported, long-lasting DTMF events shall be divided into segments, see RFC 4733. To harmonize with legacy DTMF signalling, TS 23.014, ETSI ES 201 235-2 [63], the tone duration of a DTMF event shall be at least 65 ms and the pause duration in-between two DTMF events shall be at least 65 ms. The duration of the DTMF event and the pause time to the next DTMF event, where applicable, should be selected such that it enables incrementing the RTP Time Stamp with an integer multiple of the number of timestamp units corresponding to the frame length of the speech codec used for the speech media before the DTMF event.

The MTSI client(s) in terminal and the IMS network(s) shall support the telephone-event codec(s) for the transport of DTMF events during the whole MTSI session. When sending an SDP offer, an MTSI client should indicate support of all DTMF Named Events 0 to15 in the fmtp attribute. As defined by Section 7.1.1 of RFC 4733, if this fmtp parameter is not included, then the default applies: 0-15. If the SDP offer includes a single audio codec then, this SDP offer shall also include the telephone-event codec with the same RTP clock rate as used for the offered audio codec, as described by Errata 3489 to RFC 4733. If the SDP offer includes multiple audio codecs with different RTP clock rates, then this SDP offer shall also include the telephone-event codecs with different payload type numbers for these different RTP clock rates. The answerer, which determines the Selected (audio) Codec(s), shall, if telephone-event was included in the SDP offer, include in the SDP answer the corresponding telephone-event codec that matches the highest RTP clock rate from the Selected (audio) Codec(s). If the SDP offer or answer contains multiple m=audio lines, then the telephone-event shall only be included for the first m=audio line. An example of SDP offer and answer from MTSI clients in terminals using 3GPP access is provided in Table G.3.1 when narrowband speech codec with RTP clock rate 8000 is offered.

m=audio 49152 RTP/AVPF 97 98 99
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:20
a=maxptime:240
a=sendrecv

m=audio 49152 RTP/AVPF 97 99
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:20
a=maxptime:240
a=sendrecv

An example of SDP offer and answer from MTSI clients in terminals using 3GPP access is provided in Table G.3.2 when narrowband speech codecs with RTP clock rate 8000 and wideband and super-wideband speech codecs with RTP clock rate 16000 are offered.

m=audio 49152 RTP/AVPF 96 97 98 99 100 101 102
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:99 telephone-event/16000
a=fmtp:99 0-15
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-change-capability=2; max-red=220
a=rtpmap:101 AMR/8000/1
a=fmtp:101 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
a=maxptime:240
a=sendrecv

m=audio 49152 RTP/AVPF 96 99
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:99 telephone-event/16000
a=fmtp:99 0-15
a=ptime:20
a=maxptime:240
a=sendrecv

For sending and receiving DTMF events via telephone events with RTP, the RTP payload format for "DTMF Named Events" of the telephone-event codec(s), RFC 4733, shall be supported by MTSI clients in terminal and MTSI media gateways. Telephone events shall use the same RTP media stream as for speech, i.e. the same IP address, UDP port, RTP SSRC and RTP clock rate as the Selected (Speech) Codec. Thereby, RTP Sequence Number and RTP Time Stamp shall be synchronized between RTP packets for speech and RTP packets for DTMF events. For example, by setting the initial random values the same and when switching from speech to DTMF, or vice versa, the RTP Sequence Number and RTP Time Stamp shall continue from the value that was used for the other audio media (speech or DTMF event). The RTP Sequence Number for telephone events shall increment in the same way as for speech, i.e. by 1 for each transmitted RTP packet. The RTP Time Stamp for telephone events should increment in the same way as for RTP speech packets or with an integer multiple. Example: if the RTP Time Stamp increments with 160 between RTP speech packets (Codec with RTP clock rate 8000 and 20 ms frame duration) then the RTP Time Stamp increment during DTMF events and when switching between speech and DTMF events should be 160 or an integer multiple of 160. The RTP Time Stamp should not increment with a smaller interval for DTMF events than for speech frames. The RTP Time Stamp shall use the same RTP clock rate as for the speech codec that is transmitted in the same RTP stream immediately before the start of the DTMF event(s). Speech packets shall not be transmitted such that the resulting decoded speech would overlap in time with the audible representation of DTMF events, when DTMF events are transmitted in the same RTP media stream.