Global modifications to 3GPP TS 29.163 V7.1.0
(clauses 7.2.3 and 7.4)

29.4273GPPEndorsement of the SIP-ISUP Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched CS) networks [3GPP TS 29.163 (Release 7), modified]Release 7TISPANTS

Clause 7.2.3.1.1

Modify as follows.

7.2.3.1.1 Sending of IAM

On reception of a SIP INVITE requesting an audio session, the I‑MGCF shall send an IAM message.

An I-MGCF shall support both incoming INVITE requests containing SIP preconditions and 100rel extensions in the SIP Supported or Require headers, and INVITE requests not containing these extensions, unless the Note below applies.

NOTE: If the I-MGCF is deployed in an IMS network that by local configuration serves no user requiring preconditions, the MGCF may not support incoming requests requiring preconditions.

The I-MGCF shall interwork forked INVITE requests with different request URIs.

If a Continuity Check procedure is supported in the ISUP network, the I-MGCF shall send the IAM immediately after the reception of the INVITE, as shown in figure 3. This procedure applies when the value of the continuity indicator is either set to "continuity check required’ or "continuity check performed on a previous circuit". If the continuity indicator is set to "continuity check required" the corresponding procedures at the Mn interface described in clause 9.2.2.3 also apply.

Figure 3: Receipt of an Invite request (continuity procedure supported in the ISUP network)

If no Continuity Check procedure is supported in the ISUP network, and the SDP in the received INVITE request contains preconditions not met, the I-MGCF shall delay sending the IAM until the SIP preconditions are met.

Figure 4: Receipt of an Invite request (continuity procedure not supported in the ISUP network)

The I-MGCF shall reject an INVITE request for a session only containing unsupported media types by sending a status code 500 "Server Internal error". If several media streams are contained in a single INVITE request, the I-MGCF shall select one of the supported media streams, reserve the codec(s) for that media stream, and reject the other media streams and unselected codecs in the SDP answer, as detailed in RFC 3264 [36]. If supported audio media stream(s) and supported non-audio media stream(s) are contained in a single INVITE request, an audio stream should be selected.

The I-MGCF shall include a To tag in the first backward non-100 provisional response, in order to establish an early dialog as described in RFC 3261 [19].

Clause 7.2.3.1.2.2

Modify as follows.

7.2.3.1.2.2 Nature of connection indicators

bits BA Satellite indicator

0 1 one satellite circuit in the connection

bits DC Continuity check indicator

0 0 continuity check not required) if the continuity check procedure is not supported in the succeeding network (figure 4).

0 1 continuity check required, if a continuity check shall be carried out on the succeeding circuit. (figure 3)

1 0 continuity check performed on a previous circuit otherwise, if the continuity check procedure is supported in the succeeding network, but shall not be carried out on the succeeding circuit otherwise. (figure 3)

bit E Echo control device indicator

  1. outgoing echo control device included

The Echo control device indicator shall be set according to ISUP procedures.

NOTE: For certain calls e.g., TMR "64 kBit/s unrestricted", it is recommended to set the bit E to "outgoing echo control device indicator not included".

Clause 7.2.3.1.2.4

Modify as follows.

7.2.3.1.2.4 Calling party’s category

0 0 0 0 1 0 1 0

ordinary calling subscriber

See annex ZA for the normative interworking of the CPC parameter.

Clause 7.2.3.1.2.5

Modify as follows.

7.2.3.1.2.5 Transmission medium requirement

The I-MGCF may either transcode the selected codec(s) to the codec on the PSTN side or it may attempt to interwork the media without transcoding. If the I-MGCF transcodes, it shall select the TMR parameter to ""3.1 kHz audio"" or "speech". If the I-MGCF does not transcode, it should map the TMR, USI and Access Transport parameters from the selected codec according to Table 2a. The support of any of the media listed in Table 2a is optional. The SDP for the data transfer with 64 kbit/s clearmode [69] shall be mapped to the TMR "64 kbit/s unrestricted".

Table 2a- Coding of TMR/USI/HLC from SDP: SIP to ISUP

m= line

b= line (NOTE 4)

a= line

TMR parameter

USI parameter (optional) (NOTE 1)

HLC parameter (optional)

<media>

<transport>

<fmt-list>

<modifier>:<bandwidth-value>

(NOTE 5)

rtpmap:<dynamic-PT> <encoding name>/<clock rate>[/encoding parameters>

TMR codes

Information Transport Capability

User Information Layer 1 Protocol Indicator

High Layer Characteristics Identification

audio

RTP/AVP

0

N/A or up to 64 kbit/s

N/A

"3.1KHz audio"

"3.1KHz audio"

"G.711 -law"

(NOTE 3)

audio

RTP/AVP

Dynamic PT

N/A or up to 64 kbit/s

rtpmap:<dynamic-PT> PCMU/8000

"3.1KHz audio"

"3.1KHz audio"

"G.711 -law"

(NOTE 3)

audio

RTP/AVP

8

N/A or up to 64 kbit/s

N/A

"3.1KHz audio"

"3.1KHz audio"

"G.711 -law"

(NOTE 3)

audio

RTP/AVP

Dynamic PT

N/A or up to 64 kbit/s

rtpmap:<dynamic-PT> PCMA/8000

"3.1KHz audio"

"3.1KHz audio"

"G.711 A-law"

(NOTE 3)

audio

RTP/AVP

9

AS: 64 kbit/s

rtpmap:9 G722/8000

"64 kbit/s unrestricted"

"Unrestricted digital inf. w/tones/ann"

audio

RTP/AVP

Dynamic PT

AS: 64 kbit/s

rtpmap:<dynamic-PT> CLEARMODE/8000

(NOTE 2)

"64 kbit/s unrestricted"

"Unrestricted digital information"

image

udptl

t38

N/A or up to 64 kbit/s

Based on T.38 [28]

"3.1 KHz audio"

"3.1KHz audio"

"Facsímile
Group 2/3"

image

tcptl

t38

N/A or up to 64 kbit/s

Based on T.38 [28]

"3.1 KHz audio"

"3.1KHz audio"

"Facsímile
Group 2/3"

NOTE 1 In this table the codec G.711 is used only as an example. Other codecs are possible.

NOTE 2 CLEARMODE is specified in RFC4040 [69].

NOTE 3 HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/Q.939 indicates that this would normally be accompanied by a value of "Speech" for the Information Transfer Capability element.

NOTE 4 If the b=line indicates a bandwidth greater than 64kbit/s then the call may use compression techniques or reject the call with a 415 response indicating that only one media stream of 64kbit/s is supported.

NOTE 5 <bandwidth value> for <modifier> of AS is in units of kbit/s.

Clause 7.2.3.1.2.8

Modify as follows.

7.2.3.1.2.8 User service information

For coding of the USI see clause 7.2.3.1.2.5. The Information Transfer Capability Information element is coded as "speech" or "3.1 kHz audio".

Clause 7.2.3.1.4

Modify as follows.

7.2.3.1.4 Sending of 180 ringing

The I-MGCF shall send the SIP 180 Ringing when receiving any of the following messages:

  • ACM with Called party’s status indicator set to subscriber free (figure 6 is replaced by figures 6a and 6b).

Figure 6: The receipt of ACM

  • CPG with Event indicator set to alerting (figure 7 is replaced by figures 7a and 7b).

Figure 7: Receipt of CPG (Alerting)

As a network option, if the INVITE request includes the P-Early-Media header and the I-MGCF supports the header, the I-MGCF shall include in the SIP 180 Ringing response a P-Early-Media header authorizing early media, except when:

  • the I-MGCF has already sent a provisional response including a P-Early-Media header, as defined in IETF RFC 5009 [24]; and
  • the most recently sent P-Early-Media header authorizes early media.

Figure 6a: The receipt of ACM without support of the P-Early-Media header

Figure 6b: The receipt of ACM with support of the P-Early-Media header

NOTE: If the I-MGCF signals the P-Early-Media header authorizing early media, then the SIP network can expect tones or announcements to the calling party to flow from the PSTN/ISDN via an MGW controlled by the I-MGCF. In particular, once the I-MGCF sends the 180 Ringing response, ringback is expected in media from the PSTN/ISDN.

  • CPG with Event indicator set to alerting.

Figure 7a: Receipt of CPG (Alerting) without support of the P-Early-Media header

Figure 7b: Receipt of CPG (Alerting) with support of the P-Early-Media header

Add clause 7.2.3.1.4a.

7.2.3.1.4a Sending of 183 Session Progress for early media scenarios

As a network option, if the I-MGCF supports the P-Early-Media header and has received the P-Early-Media header in the INVITE request, the I-MGCF shall include a P-Early-Media header authorizing early media in the first 18x response.

As a network option, upon receiving one of the following messages and if the I-MGCF supports the P-Early-Media header has received the P-Early-Media header in the INVITE request, and has not already sent a provisional response including a P-Early-Media header with parameters indicating authorization of early media, then the I-MGCF shall send the 183 Session Progress response with a P-Early-Media header authorizing early media:

  • ACM with the value of the called party’s status indicator "no indication" and one of the options described in table 7a1.

Figure 7c: Receipt of ACM No indication

Table 7a.1: ACM Parameters that trigger the 183 Session Progress response

183 Session Progress

ACM

183 Session Progress response including a P-Early-Media header authorizing early media, if not already sent

1)Optional backward call indicators parameter

In-band information indicator

1 In-band info…

2)Backward call indicators parameter

ISDN User Part indicator

0 ISDN User Part not used all the way

  • CPG message, when:

1. Event indicator is set to "in-band information or an appropriate pattern is now available", or

2. Event indicator is set to "Progress" and one of the options described in table 7b1.

Figure 7d: Receipt of CPG (in-band information available)

Table 7b.1: CPG Parameters that trigger the 183 Session Progress response

183 Session Progress

CPG

183 Session Progress response including a
P-Early-Media header authorizing early media, if not already sent

Event indicator

000 0010 (progress)

1)Optional backward call indicators parameter

In-band information indicator

In-band info …

2)Backward call indicators parameter

ISDN User Part indicator

0 ISDN User Part not used all the way

NOTE 1: The mapping of the contents in the CPG message is only relevant if the information received in the message is different compared to earlier received information, e.g., in the ACM message or a CPG message received prior to this message.

NOTE 2: 183 Session Progress message including a P-Early-Media header authorizing early media may only be sent if the USI sent in the IAM was coded 3.1 kHz audio.

Clause 7.2.3.1.9a

Add clause 7.2.3.1.9a.

7.2.3.1.9a Receipt of REFER

Figure 11a: Receipt of REFER method

A REFER received by the MGCF will always be rejected with a 403 Forbidden response.

Clause 7.2.3.2.1

Modify as follows.

7.2.3.2.1 Sending of INVITE

An O-MGCF shall support both the SIP preconditions and 100 rel extensions and indicate the support of the SIP preconditions and 100rel extensions in the INVITE request.

NOTE: If the O-MGCF is deployed in an IMS network that by local configuration serves no user requiring preconditions, it may send the INVITE request without indicating support of preconditions.

If the Continuity Check indicator in the Nature of Connection Indicators parameter in the incoming IAM is set to indicate either ‘continuity check required on this circuit‘ or ‘continuity check performed on previous circuit‘, the
O-MGCF may either defer sending the INVITE request until receiving a COT message or send the INVITE request without waiting for the COT.

NOTE: Waiting for the COT is a network option. Furthermore, it only applies if the Continuity Check indicator in the Nature of Connection Indicators parameter in the incoming IAM is set to indicate either ‘continuity check required on this circuit‘ or ‘continuity check performed on previous circuit‘.

Figure 12: Receipt of an IAM (En bloc signalling in CS network)

Figure 13: Receipt of an IAM (Overlap signalling in CS network)

After initiating the normal incoming BICC/ISUP call establishment procedures, determining the end of address signalling and selecting to route the call to the IMS domain, the O‑MGCF shall send the initial INVITE. Only calls with Transmission Requirements of speech or 3.1 kHz audio will be routed to the IMS domain, all other types of call attempts will be rejected.

The end of address signalling shall be determined by the earlier of the following criteria:

a) by receipt of an end-of-pulsing (ST) signal; or

b) by receipt of the maximum number of digits used in the national numbering plan; or

c) by analysis of the called party number to indicate that a sufficient number of digits has been received to route the call to the called party; or

d) by observing that timer Ti/w1 has expired after the receipt of the latest address message and the minimum number of digits required for routing the call have been received.

If the end of the address signalling is determined in accordance with criteria a) b) or c), the timer Ti/w2 is started when INVITE is sent.

Add clause 7.2.3.2.2.5.

7.2.3.2.2.5 P-Early-Media header

As a network option, if the O-MGCF supports the optional P-Early-Media header then it shall include the header without parameters in each outgoing INVITE request.

Clause 7.2.3.2.4

Modify as follows.

7.2.3.2.4 Sending of ACM and awaiting answer indication

If the Address Complete Message (ACM) has not yet been sent, the following cases are possible trigger conditions that shall lead to the sending the address complete message (ACM).

  • the detection of end of address signalling by the expiry of Timer T i/w1; or

Figure 15: Sending of ACM T i/w1 elapses

  • the reception of the first 180 Ringing response without a P-Early-Media header authorizing early media; or

Figure 16: Sending of ACM (Receipt of first 180 Ringing without authorization of early media)

  • as a network option, the reception at an O-MGCF supporting the P-Early-Media header of the first 180 Ringing that includes a P-Early-Media header authorizing early media; or

Figure 16a: Sending of ACM (Receipt of first 180 Ringing that includes authorization of early media)

NOTE 1: Based on local knowledge that the call is transited to a PSTN network, the O-MGCF can make a decision not to generate the awaiting answer indication when receiving the 180 Ringing message without a
P-Early-Media header.

  • at an O-MGCF supporting the P-Early-Media header as a network option, once all the following sub-conditions have been met: {1} the reception at an O-MGCF supporting the P-Early-Media header, the first 183 Session Progress that includes a P-Early-Media header authorizing early media, {2} the SDP offer/answer procedures are completed, and {3} SDP preconditions are not used or applicable SDP preconditions have been met, or
  • as a network option, once all the following sub-conditions have been met: {1} the O-MGCF supporting the
    P-Early-Media header has received the first 183 Session Progress that includes a P-Early-Media header authorizing early media, and {2} SDP preconditions are not used or applicable SDP preconditions have been met; or

Figure 16b: Sending of ACM (Receipt of first 183 that includes authorization of early media)

  • Ti/w 2 expires after the initial INVITE is sent.

Figure 17: Sending of ACM (Ti/w2 elapses)

The sending of an awaiting answer indication on speech or 3.1 kHz calls is described in clause 9.2.3.3.

  • as a network option, at an O-MGCF supporting the P-Early-Media header, if the O-MGCF receives a 18x response with a P-Early-media header that changes the authorization of early media, the O-MGCF terminates the sending of the awaiting answer indication if the header authorizes early media, and initiates the sending of the awaiting answer indication if the header removes authorization of early media and if the O-MGCF has received the 180 Ringing response.

NOTE 2: Based on local knowledge that the call is transited to a PSTN network, the O-MGCF can make a decision not to generate the awaiting answer indication when receiving the 180 message without a P-Early-Media header.

Clause 7.2.3.2.5

Modify as follows.

7.2.3.2.5 Coding of the ACM

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4].

7.2.3.2.5.1 Backward call indicators

bits AB Charge indicator Contributors

1 0 charge

bits DC Called party’s status indicator

01 subscriber free if the 180 Ringing has been received.

00 no indication otherwise

bits FE Called party’s category indicator

0 0 no indication

bits HG End-to-end method indicator

00 no end-to-end method available

bit I Interworking indicator

1 interworking encountered

As a network operator option, the value I = 0 "no interworking encountered" is used for TMR = 64 kBit/s unrestricted

NOTE: This avoids sending of a progress indicator with Progress information 0 0 0 0 0 0 1 "Call is not end-to-end ISDN; further call progress information may be available in‑band", so the call will not be released for that reason by an ISDN terminal.

bit J End-to-end information indicator

0 no end-to-end information available

bit K ISDN user part/BICC indicator

0 ISDN user part not used all the way

As a network operator option, the value K = 1 "ISDN user part/BICC used all the way" is used for TMR = 64 kBit/s unrestricted

NOTE: This avoids sending of a progress indicator with progress information 0 0 0 0 0 0 1 "Call is not end-to-end ISDN; further call progress information may be available in‑band", so the call will not be released for that reason by an ISDN terminal.

bit L Holding indicator (national use)

0 holding not requested

bit M ISDN access indicator

0 terminating access non-ISDN

As a network operator option, the value M = 1 "terminating access ISDN" is used for TMR = 64 kBit/s unrestricted.

NOTE: This avoids sending of a progress indicator with progress information 0 0 0 0 0 1 0 " Destination access is non-ISDN", so the call will not be released for that reason by an ISDN terminal.

7.2.3.2.5.2 Optional Backward call indicators

Bit A 1 "in-band information or an appropriate pattern is now available" if 183 Session Progress response is received and a P-Early-Media header has been received authorizing early media.

Clause 7.2.3.2.6

Modify as follows.

7.2.3.2.6 Sending of the Call Progress message (CPG)

If the Address Complete Message (ACM) has already been sent, the O-MGCF shall send the Call Progress message (CPG) in the following cases: when receiving the following message:

  • Upon receipt of the SIP 180 Ringing provisional response without recent receipt of a P-Early-Media header authorizing early media; or

Figure 18: Sending of CPG(Alerting)
(Receipt of 180 Ringing response without authorization of early media)

  • as a network option, upon receipt of the SIP 180 Ringing response and recent receipt of a P-Early-Media header authorizing early media at an O-MGCF supporting the P-Early-Media header; or

Figure 18a: Sending of CPG(Alerting)
(Receipt of 180 Ringing response and authorization of early media)

  • as a network option, upon receipt the 183 Session Progress response and recent receipt of a P-Early-Media header authorizing early media at an O-MGCF supporting the P-Early-Media header.

Figure 18b: Sending of CPG(in-band information available)

At an O-MGCF supporting the P-Early-Media header as a network option, if the O-MGCF receives a 18x response with P-Early-media header that changes the authorization of early media, the O-MGCF terminates the sending of the awaiting answer indication if the header authorizes early media and initiates the sending of the awaiting answer indication if the header removes authorization of early media and if the O-MGCF has received the 180 Ringing response.

NOTE: Based on local knowledge that the call is transited to a PSTN network, the O-MGCF can make a decision not to generate the awaiting answer indication when receiving the 180 message without a P-Early-Media header.

Clause 7.2.3.2.7.1

Modify as follows.

7.2.3.2.7.1 Event information

bits G-A Event indicator

0 0 0 0 0 0 1 alerting if 180 Ringing response received

0 0 0 0 0 1 1 in-band information or an appropriate pattern is now available", if 183 Session Progress
response received and most recently received P-Early-Media header authorizes early media

Clause 7.2.3.3

Modify as follows.

7.2.3.3 Timers

Table 19: Timers for interworking

Symbol

Time-out value

Cause for initiation

Normal termination

At expiry

Reference

Ti/w1

4 s to 6 s (default of 4 s)

When last address message is received and the minimum number of digits required for routing the call have been received.

At the receipt of fresh address information.

Send INVITE, send the address complete message and insert ring tone

7.2.3.2.1
7.2.3.2.4
(NOTE 1)

Ti/w2

4 s to 14 s (default of 4 s)

When INVITE is sent unless the ACM has already been sent.

On reception of 180 Ringing ,or 183 Session Progress and P-Early-Media header authorizing early media, or 404 Not Found or 484 Address Incomplete for an INVITE transaction for which Ti/w3 is running, or 200 OK (INVITE).

Send ACM (no indication) and send the awaiting answer indication (e.g. ring tone) or appropriate progress announcement to the calling party.

7.2.3.2.4
7.2.3.2.1

(NOTE 2)

Ti/w3

4 to 6 seconds (default of 4 seconds)

On receipt of 404 Not Found or 484 Address Incomplete if there are no other pending INVITE transactions for the corresponding call.

At the receipt of SAM

Send REL with Cause Value 28 to the BICC/ISUP side.

7.2.3.2.1A, 7.2.3.2.12.1

(NOTE 3)

NOTE 1: This timer is used when overlap signalling is received from BICC/ISUP network and converted to en-block signalling at the MGCF.

NOTE 2: This timer is used to send an early ACM if a delay is encountered in receiving a response from the subsequent SIP network.

NOTE 3: This timer is known as the "SIP dialog protection timer". This timer is only used where the O‑MGCF is configured to send INVITE before end of address signalling is determined.

Clause 7.4.8

Modify as follows.

7.4.8 Explicit Call Transfer (ECT)

When the MGCF receives a FAC message with Generic notification indicator coded as "Call transfer active" and a CPG with Generic notification indicator coded as "Remote hold" was received previously for the current communication, the action described in table 24a applies. In all other cases the actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.732.7 [42] under the clause "Interactions with other networks".

Table 24a: Mapping between ISUP and SIP for the Explicit Communication
Transfer supplementary service

ISUP message

Mapping

FAC with a " call transfer, active " Generic notification indicator

As described for CPG message with a "remote retrieval" Generic notification indicator in Subclause 7.4.10.2

Clause 9.2.3.1.5

Modify as follows.

9.2.3.1.5 Called party alerting

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party using the Send Tone procedure (signals 20 and 21 in figure 37) , when the first of thefollowing conditions is satisfied:

– the MGCF receives the first 180 Ringing message

– Timer T i/w1 expires

– Timer T i/w2 expires

Clause 9.2.3.2.5

Modify as follows.

9.2.3.2.5 Called party alerting

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party using the Send Tone procedure (signals 19 and 20 in figure 38) , when the first of the following conditions is satisfied:

– the MGCF receives the first 180 Ringing message,

Clause 9.2.3.3.5

Modify as follows.

9.2.3.3.5 Called party alerting

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party using the Send TDM Tone procedure (signals 19 and 20 in figure 39) , when the first of the following conditions is satisfied:

– the MGCF receives the first 180 Ringing message without authorization of early media.

– Timer T i/w1 expires

– Timer T i/w2 expires

Clause B.3.2.1.5

Modify as follows.

B.3.2.1.5 Called party alerting

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party using the Send Tone procedure (signals 21 and 22 in figure B.2/1) , when the first of the following conditions is satisfied:

– the MGCF receives the first 180 Ringing message.

– Timer T i/w1 expires

– Timer T i/w2 expires

Annex ZA (normative):
Interworking of Cpc parameter