G.3 Session setup
26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS
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.
NOTE: They may in addition support the SIP INFO method (TS 24.229 [7]) for setup and modification of supplementary services, when no user plane is necessary. The SIP INFO method is, however, not to be used during MTSI sessions.
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 IETF RFC 4733 [61] section 7.1.1, 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 IETF RFC 4733 [61]. 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.
Table G.3.1: SDP example for narrowband speech and DTMF
|
SDP offer |
|
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 |
|
SDP answer example |
|
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.
Table G.3.2: SDP example for narrowband,wideband and super-wideband for both speech and DTMF
|
SDP offer |
|
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 |
|
SDP answer example |
|
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 |
NOTE 1: Wideband codec ITU-T G.722 uses an RTP clock rate of 8000, although its sampling frequency is 16000 Hz. An SDP offer or answer with G.722/8000 therefore must be combined with telephone-event/8000. The 3GPP EVS codec supports various sampling frequencies, up to 48000 Hz, but only one RTP clock rate of 16000 and the corresponding telephone-event/16000 is used.
NOTE 2: The a=sendrecv attribute applies to all RTP payload types within the same media stream. To comply with the transmission rules defined in clause G.4, SDP offers and SDP answers include audio codecs and telephone-event codec(s) for the same media stream in both directions. The consequence of this is that MTSI clients that want to send DTMF events in local uplink, also allow the remote MTSI client to send DTMF events in the reverse direction.
For MTSI clients in terminals, since support of DTMF events in the receiving direction is not mandatory, it is an implementation consideration to decide how to handle any received RTP packets containing telephone-event codec payload.