Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.231  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   4.4.2   4.4.3   4.4.4   4.4.5…   6…   6.1.2…   6.2…   6.2.2…   7…   7.2.3   7.2.4…   7.3…   8…   9…   13…   14…   15…

 

14  Interactions with Other Network Features and Servicesp. 61

14.1  Customised Applications for Mobile network Enhanced Logic (CAMEL)p. 61

The procedures specified for Customised Applications for Mobile network Enhanced Logic (CAMEL) in TS 23.205, clause 14.1 shall be followed, with the clarifications given in the following clauses. The examples specified in TS 23.205, clauses 14.6 also apply.

14.1.1  Play Announcement/Send Tonep. 61

The procedures specified for the Play Announcement/Send Tone in TS 23.205, clause 14.1.1 shall be followed, with the following modifications:
  • the procedures for providing tones or announcements and the procedures for stopping providing tones or announcements defined in clause 14.6 shall be applied.

14.1.2  User Interactionp. 62

The procedures specified for the User Interaction in TS 23.205, clause 14.1.2 shall be followed, with the following modifications:
  • the procedures for providing tones or announcements and the procedures for stopping providing tones or announcements defined in clause 14.6 shall be applied.
  • the procedures for detecting and reporting DTMF tones defined in clause 14.4 shall be applied.
Up

14.1.3  Call Party Handling (CPH)p. 62

14.2  ISTp. 62

See TS 23.205, clause 14.2 with the following modification:
  • the (G)MSC server initiated call clearing procedures defined in clause 7 shall be applied.

14.3  Operator Determined Barring (ODB)p. 62

The procedures specified for the Operator Determined Barring service in TS 23.205, clause 14.3 shall be followed, with the following modifications:
  • the call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied;
  • the procedures for providing in-band information defined in clause 14.6 shall be applied.
  • Optimized or deferred MGW selection may apply for the establishment of the incoming side bearer, as specified in clauses 4.4.2 and 4.4.3.
Up

14.4  DTMFp. 62

14.4.1  Generalp. 62

This clause only specifies the requirements to be supported for DTMF signalling on SIP-I based Nc. Interworking of DTMF between BICC and SIP-I on Nc and interworking between DTMF in external networks and SIP-I is specified in TS 29.235.
DTMF signalling via the RTP telephony-event according to RFC 4733 on Nb Interface shall be supported in SIP-I based Circuit Switched Core Network [y].
Inband DTMF signalling (generation, detection) shall also be supported in SIP-I based Nc to ensure open interoperability between two MSC servers from different vendors, when terminating MSC server selects PCM and does not offer RTP telephony-event in the answer.
When the negotiation for telephone events via the SDP offer-answer mechanism is complete and the needed preconditions defined in RFC 3312 are fulfilled, if RTP telephony-event has been successfully negotiated then telephone events can be sent in RTP payload. If a speech codec other than the default PCM codec has been selected (via the 3GPP SIP-I codec negotiation procedures, see TS 23.153), DTMF shall be sent as an RTP Telephony Event. If the default PCM speech codec is selected, DTMF transport in the RTP telephony-event is optional. However, if the RTP telephony-event is included in the SDP answer, it shall be used to transport DTMF (rather than inband transport in the default PCM speech codec).
Interworking Procedures to external networks at the G-MSC server are specified in TS 29.235.
Up

14.4.2  DTMF handling in SIP-I Offer/Answerp. 63

(G)MSC Servers and MGWs shall support the reception and transmission of the RTP MIME type "telephone event" as defined in RFC 4733 and as per the following requirements:
  • An MSC Server initiating an SDP offer shall include the MIME type "telephone events" with default events in the first SDP offer, if it offers any codecs other than the default PCM codec. An MSC Server initiating an SDP offer with only the default PCM codec as speech codec may include the MIME type "telephone events" in the first SDP offer,
  • An MSC Server terminating an SDP offer shall accept the MIME type "telephone events" with default events in any SDP answer, if it selects any codec other than the default PCM codec. An MSC Server terminating an SDP offer that selects the default PCM codec as speech codec may include the MIME type "telephone events" in the SDP answer, if present in the SDP offer,
  • A 3GPP SIP-I intermediate node receiving an SDP offer with the MIME type "telephone events" shall forward the MIME type "telephone-events" in the offer to the succeeding node.
Up

14.4.3  Server to MGW Proceduresp. 63

The (G)MSC Server indicates the transport mode of DTMF to the MGW as follows in the "Configure RTP Connection Point" procedure or "Reserve and Configure RTP Connection Point " procedure:
  • The (G)MSC Server shall configure the RTP telephony event payload at the MGW if successfully negotiated in the SDP Offer/Answer.
  • If the (G)MSC Server configures the RTP telephony event payload at the MGW for a given termination and applies the Detect DTMF procedure to request the detection of DTMF, the MGW shall detect DTMF within the RTP telephony event payload according to RFC 4733 and shall not detect inband DTMF within a speech codec.
  • If the (G)MSC Server does not configures the RTP telephony event payload at the MGW for a given termination and applies the "Detect DTMF" procedure to request the detection of DTMF, the MGW shall detect inband DTMF within the speech codec; the (G)MSC Server shall not request "Detect DTMF" without RTP Telephony Event in combination with any codec other than the default PCM codec.
  • If the (G)MSC Server configures the RTP telephony event payload at the MGW for a given termination and applies the Send DTMF procedure to request the sending of DTMF, the MGW shall send DTMF within the RTP telephony event payload according to RFC 4733.
  • If the (G)MSC Server does not configure the RTP telephony event payload at the MGW for a given termination and applies the "Send DTMF" procedure to request the sending of DTMF, the MGW shall send inband DTMF within the speech codec; the (G)MSC Server shall not request "Send DTMF" without RTP Telephony Event in combination with any codec other than the default PCM codec.
  • If the (G)MSC Server requests reporting of DTMF via "Detect DTMF" Procedure then when the MGW has reported a DTMF Digit Event the MGW shall not forward the DTMF to the succeeding interface as this could result in double detection of the same digit.
  • If the (G)MSC Server has requested support of RTP Telephony Event via the "Configure RTP Connection Point" procedure or "Reserve and Configure RTP Connection Point" procedure but has not requested reporting of DTMF digits via the "Detect DTMF" procedure the MGW shall forward received RTP Telephony Events to succeeding/preceding interface for a connection that is configured to support RTP Telephony Event.
  • If the (G)MSC Server does not wish to receive DTMF (has not configured "DTMF Detect") but has requested support of RTP Telephony Event via the "Configure RTP Connection Point" procedure or "Reserve and Configure RTP Connection Point " procedure at one bearer termination but not at the other bearer termination, if the other termination is default PCM MGW shall then relay DTMF (see clauses 14.4.8 and 14.4.9).
Up

14.4.4  RTP Telephony Event DTMF Digit Generationp. 64

14.4.4.1  Generalp. 64

The RTP Telephony Event DTMF digit generation shall be performed in accordance with RFC 4733. The following clauses describe the additional requirements for the bearer independent CS core network.

14.4.4.2  Start DTMFp. 64

When the MSC server receives the Start DTMF message from the UE, it shall use the Send DTMF procedure to request the MGW to modify the bearer termination to transmit the requested digit.

14.4.4.3  Stop DTMFp. 64

When the MSC server receives the Stop DTMF message from the UE, it shall use the Stop DTMF procedure to request the MGW to modify the bearer termination to stop digit transmission.
Upon reception of the Stop DTMF procedure, the MGW shall ensure the minimum digit duration is kept, in accordance with TS 23.014 and then terminate the digit transmission by sending RTP Telephony Event with "End-bit" set to YES.
If implicit DTMF timing is deployed (as shown in example Figure 14.4.4.3.1) and the MGW has already completed the digit transmission it shall not take any action upon the reception of the Stop DTMF procedure.
Up

14.4.4.4  Examplep. 64

When the UE sends Start DTMF and Stop DTMF messages, the MSC server uses resources in the MGW to transmit a digit by modifying the bearer termination.
Copy of original 3GPP image for 3GPP TS 23.231, Fig. 14.4.4.4.1: DTMF Digit generation - implicit timing over RTP Telephony Event (message sequence chart)
Up

14.4.5  DTMF Tone Generationp. 64

DTMF Tone Generation shall only occur if the RTP Telephony Event has not been negotiated and the default PCM codec is selected for the user plane. The MSC Server shall apply the "Send DTMF" procedure to the core network side termination (PCM) in accordance with TS 23.205, clause 14.4.1.1

14.4.6  RTP Telephony Event DTMF Digit Detectionp. 65

14.4.6.1  Generalp. 65

The RTP Telephony Event DTMF digit detection shall be performed in accordance with RFC 4733. The following clauses describe the additional requirements for the bearer independent CS core network.

14.4.6.2  Detect DTMF Digitp. 65

An MSC server uses the Detect DTMF procedure to request a MGW to report DTMF Digits. If a MGW receives the Detect DTMF procedure, it shall configure the bearer termination to receive DTMF digits. The result of the digit detection shall be reported within Notify DTMF Digit procedure.
The Detect DTMF procedure permits the MSC Server to request reporting either of Start and End of DTMF detection, or only of End of DTMF Detection. The support of "start of DTMF detection" is optional for the MGW; if not supported the MGW shall indicate the appropriate error code.
If the MSC Server does not request DTMF notification then the MGW shall relay the DTMF to the succeeding interface.
Up

14.4.6.3  Example - DTMF Notificationp. 65

Copy of original 3GPP image for 3GPP TS 23.231, Fig. 14.4.6.3.1: DTMF Notification with both start and end events
Up
Copy of original 3GPP image for 3GPP TS 23.231, Fig. 14.4.6.3.2: DTMF Notification with only end DTMF event
Up

14.4.7  Inband DTMF Tone Detectionp. 66

DTMF tone detection within the PCM speech codec as specified by clause 14.4.2.1 of TS 23.205 shall only be required by applications making use of the DTMF information within the (G)MSC server, and only if the RTP telephony event is not negotiated with SDP offer/answer.
A server controlling a MGW requests detection of inband DTMF by applying the Detect DTMF procedure but not configuring the RTP Telephony Event payload at the corresponding termination.
Up

14.4.8  Interworking between RTP Telephony Events and Inband DTMF Tonesp. 66

A (G)MSC Server or Interworking Node may need to interwork a SIP-I associated bearer where the usage of RTP Telephony Event has been negotiated with a bearer where PCM encoded speech but no RTP Telephony Event has been negotiated. The MGW shall relay the DTMF between the terminations of a context if the following conditions apply:
  • the (G)MSC Server or Interworking Node configures a MGW with SIP-I associated bearer termination to support RTP Telephony Event from/to the preceding node and;
  • the (G)MSC Server has not requested DTMF detection to be reported and;
  • the selected codec to the succeeding node is default PCM and;
  • the succeeding SIP-I node has not selected RTP Telephony Event.
RTP Telephony events received on SIP-I associated bearer are inserted into the PCM stream (bullet 2 in Figure 14.4.8.1). Inband DTMF received from the preceding node shall be inserted as RTP Telephony events on succeeding bearer termination (bullet 3 in Figure 14.4.8.1).
When detecting inband DTMF the MGW shall ensure the minimum duration for valid DTMF validation is detected in accordance with TS 23.014 before signalling an RTP telephony Event.
Copy of original 3GPP image for 3GPP TS 23.231, Fig. 14.4.8.1: DTMF Relay between RTP Telephony Event and inband DTMF
Up

14.5  ORp. 67

The procedures specified for Optimal Routeing network service in TS 23.205, clause 14.5 shall be followed with the following modification:
  • the procedures for call clearing defined in clause 7 shall be applied.

14.6  Providing tones or announcementsp. 67

14.6.1  Introductionp. 67

The procedures specified for providing tones or announcements in TS 23.205, clause 14.6 shall be followed, with the clarifications given in the following clauses. The examples specified in TS 23.205, clauses 14.6 also apply.

14.6.2  Preconditions when providing in-band information to the calling subscriberp. 67

For a mobile terminating/forwarded call, announcements/tones may be provided to the calling subscriber only when the following conditions are satisfied:
  1. Either:
    1. The incoming INVITE(IAM) indicated that remote preconditions had not been met, and new SDP has been received indicating that preconditions have been met, or
    2. The incoming INVITE(IAM) did not include any preconditions information or indicated that remote preconditions had been met;
    and
  2. The incoming side RTP connection point has been successfully reserved and configured in the MGW.
For a mobile originating call, the traffic channel assignment shall be completed before providing the in-band information to the calling subscriber.
Up

14.6.3  Preconditions when providing in-band information to the called subscriberp. 68

The called party is selected by the calling party, or a supplementary service (call forwarding, call deflection, CAMEL redirection etc), or a call is initiated by the gsmSCF using the Initiate Call Attempt procedure. The called party may also be in the PSTN.
Announcements/tones may be provided to the called subscriber only when the following conditions are satisfied:
  1. The called party has answered and is still active in the call, and
  2. The outgoing side RTP Connection point has been successfully reserved and configured in the MGW.
Up

14.6.4  Preconditions when providing in-band information to multiple subscribersp. 68

14.6.5  Request to play an announcement/tonep. 68

14.6.6  Stopping an announcement/tonep. 68

14.6.7  Announcement/tone completedp. 68

14.7  Global Text Telephonyp. 68

Global Text Telephony shall be supported as described in TS 23.205, clause 14.7 where the CTM package properties are included in the "Reserve RTP Connection Point" and "Configure RTP Connection Point" for Access side terminations and default PCM codec selected for the Core Network side terminations.

14.8  Emergency Callsp. 68

Emergency Calls shall be handled as in clause 6.1 Basic Mobile Originating Call and clause 6.2 Basic Mobile Terminating Call. The Procedure Emergency Call Indication may be used for informing the MGW about the emergency call.

14.9  Subscriber and equipment tracep. 68

14.10  Customized Alerting Tonesp. 68


Up   Top   ToC