7.4 Supplementary Services
29.1633GPPInterworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networksTS
The following clauses describe the MGCF behaviour related to supplementary services as defined in ITU-T Recommendations Q.730 to ITU-T Q.737 [42] when interworking with an IMS which does not use a Multimedia Telephony Application Server (MTAS) providing supplementary services according to 3GPP according to 3GPP TS 24.173 [88]. The support of these supplementary services is optional. If the supplementary services are supported, the procedures described within this clause shall be applied.
7.4.1 Calling line identification presentation/restriction (CLIP/CLIR)
The inter working between the Calling Party Number parameter and the P-Asserted-Identity header field and vice versa used for the CLIP-CLIR service is defined in the clauses 7.2.3.1.2.6 and 7.2.3.2.2.3. This inter working is essentially the same as for basic call and differs only in that if the CLIR service is invoked the "Address Presentation Restriction Indicator (APRI)" (in the case of ISUP to SIP calls) or the "priv value" of the "calling" Privacy header field (in the case of SIP to ISUP calls) is set to the appropriate "restriction/privacy" value.
In the specific case of ISUP originated calls, use of the CLIP service additionally requires the ability to determine whether the number was network provided or provided by the access signalling system. Due to the possible SIP indication of the P-Asserted-Identity header field the Screening indicator is set to network provided as default. For the CLIP-CLIR service the mapping of the APRI from privacy header at the O-MGCF is described within table 16 in clause 7.2.3.2.2.3.
At the O-MGCF the presentation restricted indication shall be mapped to the Privacy header field values "id" and "header". This is described in table 12 in clause 7.2.3.2.2.3.
7.4.2 Connected line presentation and restriction (COLP/COLR)
7.4.2.0 General
The COLP/COLR services are only to be interworked between trusted nodes – that is before passing any COLP/COLR information over the SIP-BICC/ISUP boundary the MGCF shall satisfy itself that the nodes on the BICC/ISUP side to which the information is to be passed are trusted.
The procedure within clause 7.5.2 for the generic number ("additional connected number") mapping shall apply.
7.4.2.1 Incoming Call Interworking from SIP to BICC/ISUP at the I-MGCF
7.4.2.1.1 INVITE to IAM interworking (SIP to ISUP/BICC calls)
In the case of SIP to ISUP/BICC calls the I-MGCF may invoke the COLP service as an operator option by setting the "Connected Line Identity Request indicator" field of the "Optional forward call indicators" parameter of the IAM to "requested".
NOTE: This implies that all outgoing calls will invoke the COLP service.
7.4.2.1.2 ANM/CON to 200 OK (INVITE)
Tables 20 and 21 specify the interworking required in the case when the COLP has been automatically requested on behalf of the originating SIP node. The table also indicates the inter workings required if the COLP service has been invoked and the called party has or has not invoked the COLR service.
Table 20: Mapping to P-Asserted-Identity and Privacy Header Fields
|
SIP Component |
Setting |
|
P-Asserted-Identity |
See table 21 |
|
Privacy |
See table 22 |
Table 21: Mapping of connected number parameter to SIP P-Asserted-Identity header fields
|
BICC/ISUP parameter / field |
Value |
SIP component |
Value |
|---|---|---|---|
|
Connected Number |
P-Asserted-Identity header field |
||
|
Nature of Address Indicator |
"national (significant) number" |
Tel URI or SIP URI (NOTE 1) |
Add CC (of the country where the MGCF is located) to Connected PN address signals to construct E.164 number in URI. Prefix number with "+". |
|
"international number" |
Map complete Connected address signals to construct E.164 number in URI. Prefix number with "+". |
||
|
Address signal |
If NOA is "national (significant) number" then the format of the address signals is: NDC + SN If NOA is "international number" then the format of the address signals is: CC + NDC + SN |
Tel URI or SIP URI (NOTE 1) |
CC+NDC+SN as E.164 number in URI. Prefix number with "+". |
|
NOTE 1: A tel URI or a SIP URI with "user=phone" is used according to operator policy. |
|||
Table 22: Mapping of BICC/ISUP APRIs into SIP privacy header fields
|
BICC/ISUP parameter / field |
Value |
SIP component |
Value |
|---|---|---|---|
|
Connected Number |
Privacy header field |
priv-value |
|
|
APRI (See to determine which APRI to use for this mapping) |
"presentation restricted" |
Priv-value |
"id" ("id" included only if the P-Asserted-Identity header is included in the SIP INVITE) |
|
"presentation allowed" |
Priv-value |
omit Privacy header or Privacy header without "id" and "header" if other privacy service is needed |
7.4.2.2 Outgoing Call Interworking from BICC/ISUP to SIP at O-MGCF
7.4.2.2.1 IAM to INVITE interworking (ISUP to SIP calls)
The O-MGCF determines that the COLP service has been requested by the calling party by parsing the "Optional Forward Call Indicators" field of the incoming IAM. If the "Connected Line Identity Request indicator" is set to "requested" then the BICC/ISUP to SIP interworking node shall ensure that any backwards "connected party" information is interworked to the appropriate parameters of the ISUP ANM or CON message sent backwards to the calling party as detailed within this subclause.
The O-MGCF has to store the status of the "Connected Line Identity Request indicator".
7.4.2.2.2 18x to ANM or CON interworking
If the P-Asserted-Identity header field is included within a 18x SIP response, the identity shall be stored within the O-MGCF together with information about the SIP dialogue of the 18x SIP response and shall be included within the ANM or CON message if required by the procedures described in clause 7.4.2.2.3. In accordance with ISUP procedures, a connected number shall not be included within the ACM message. The mapping of the of the P-Asserted-Identity and Privacy header fields is shown in tables 23 and 24.
7.4.2.2.3 200 OK (INVITE) to ANM/CON interworking
Tables 23 and 24 specify the interworking required in the case when the calling party has invoked the COLP service. The tables also indicate the interworking procedures required if the calling party has invoked the COLP service and the called party has or has not invoked the COLR service.
If no P-Asserted-Identity header field is provided within the 200 OK (INVITE) message, the stored information previously received in the last provisional 18x response of the same SIP dialogue shall be used.
NOTE: Due to forking, other P-Asserted-Identities might have been received in different SIP dialogues.
If the Calling Party has requested the COLP service (as indicated by the stored request status) but the 200 OK (INVITE) and previous 18x provisional responses do not include a P-Asserted-Identity header field, the O-MGCF shall set up a network provided Connected Number with an Address not Available indication.
If the P-Asserted-Identity is available then the Connected number has to be setup with the screening indication network provided. The mapping of the P-Asserted-Identity and Privacy (if available) is shown in table 24.
Table 23: Connected number parameter mapping
|
ANM/CON |
200 OK INVITE |
|
Connected Number (Network Provided) |
P-Asserted-Identity |
|
Address Presentation Restricted Indicator |
Privacy |
Table 24: Mapping of P-Asserted-Identity and privacy headers to the ISUP/BICC connected number parameter
|
SIP component |
Value |
BICC/ISUP parameter / field |
Value |
|---|---|---|---|
|
P-Asserted-Identity header field (NOTE) |
E.164 number |
Connected Number |
|
|
Number incomplete indicator |
"Complete" |
||
|
Numbering Plan Indicator |
"ISDN/Telephony (E.164)" |
||
|
Nature of Address Indicator |
If CC encoded in the URI is equal to the CC of the country where MGCF is located AND the next BICC/ISUP node is located in the same country then set to "national (significant) number" else set to "international number" |
||
|
Address Presentation Restricted Indicator (APRI) |
Depends on priv-value in Privacy header. |
||
|
Screening indicator |
Network Provided |
||
|
Addr-spec |
"CC" "NDC" "SN" from the URI |
Address signal |
if NOA is "national (significant) number" then set to "NDC" + "SN". If NOA is "international number" then set to "CC"+"NDC"+"SN". |
|
Privacy header field is not present |
APRI |
Presentation allowed |
|
|
Privacy header field |
priv-value |
APRI |
"Address Presentation Restricted Indicator" |
|
priv-value |
"header" |
APRI |
Presentation restricted |
|
"user" |
APRI |
Presentation restricted |
|
|
"none" |
APRI |
Presentation allowed |
|
|
"id" |
APRI |
Presentation restricted |
|
|
NOTE: It is possible that a P-Asserted-Identity header field includes both a tel URI and a SIP URI. In this case, either the tel URI or the SIP URI with user="phone" and a specific host portion, as selected by operator policy, may be used. |
|||
7.4.3 Direct Dialling In (DDI)
A direct dialling in call is a basic call and no additional treatment is required by the MGCF.
7.4.4 Malicious call identification
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.731.7 [42] under the clause "Interactions with other networks".
7.4.5 Subaddressing (SUB)
7.4.5.1 General
The ISDN subaddress information in ISUP is transported within the Access Transport Parameter. The coding of the subaddress parameter within the Access Transport Parameter is described within ETSI EN 300 403‑1 [96]. The isdn-subaddress parameter "isub" carried within a tel or SIP URI is defined within IETF RFC 3966 [97]. The isdn-subaddress encoding type parameter "isub-encoding" carried within a tel or SIP URI is defined within IETF RFC 4715 [108] and extended within 3GPP TS 24.229 [9].
7.4.5.2 Interworking at I-MGCF
The mapping in table 24ba of the isdn-subaddress parameter received within a tel or SIP URI of the initial INVITE request to the ISUP Access Transport Parameter encapsulating the subaddress information (calling party subaddress and/or called party subaddress information elements) to be sent within the IAM message shall be applied.
The mapping in table 24bb of the subaddress information (connected subaddress information element) received within an ANM message or a CON message containing the ISUP Access Transport Parameter to the isdn-subaddress parameters "isub" and "isub-encoding" of a tel or SIP URI to be sent within a 200 OK (INVITE) shall be applied.
Table 24ba: Mapping of the isdn-subaddress received in an initial INVITE to the subaddress information sent in the IAM
|
SIP Message INVITE |
ISUP Message IAM |
|||||
|
Source SIP header field and component |
Source component value |
ISUP Parameter field |
Derived value of parameter field |
|||
|
To header field including the isdn-subaddress (NOTE 1) |
"isub=" 1*uric "uric" containing the subaddress digits |
isub-encoding not present |
Access Transport Parameter |
called party subaddress |
Type of subaddress = "NSAP" (000) |
|
|
"isub-encoding=nsap-ia5" |
||||||
|
"isub-encoding=nsap-bcd" |
Type of subaddress = "NSAP" (000) |
|||||
|
"isub-encoding=nsap" |
Type of subaddress = "NSAP" (000) |
|||||
|
"isub-encoding=user-specified" (NOTE 2) |
Type of subaddress = "user specified" (010) (NOTE 2) |
|||||
|
"isub=" 1*uric ("uric" containing the subaddress digits) and isub-encoding does not contain "nsap-ia5" or "nsap-bcd" or "nsap" or "user-specified" value (NOTE 2) |
No mapping |
|||||
|
P-Asserted-Identity header Field including the isdn-subaddress |
";isub=" 1*uric "uric" containing the subaddress digits |
isub-encoding not present |
Access Transport Parameter |
calling party subaddress |
Type of subaddress = "NSAP" (000) |
|
|
"isub-encoding=nsap-ia5" |
||||||
|
"isub-encoding=nsap-bcd" |
Type of subaddress = "NSAP" (000) |
|||||
|
"isub-encoding=nsap" |
Type of subaddress = "NSAP" (000) |
|||||
|
"isub-encoding=user-specified" (NOTE 2) |
Type of subaddress = "user specified" (010) (NOTE 2) |
|||||
|
"isub=" 1*uric ("uric" containing the subaddress digits) and isub-encoding does not contain "nsap-ia5” or “nsap-bcd” or "nsap" or "user-specified" value (NOTE 2) |
No mapping |
|||||
|
NOTE 1: As an operator option, an isdn-subaddress within the Request-URI may also be mapped into the ISUP Access Transport parameter. NOTE 2: The interworking between "user-specified" encoding-type parameter and "user-specified" type of subaddress is an operator option. |
||||||
Table 24bb: Mapping of the subaddress information received in an ANM or CON to the isdn subaddress sent in the 200 OK (INVITE)
|
ISUP Message ANM or CON |
SIP Message 200 (OK) |
||
|
ISUP Parameter field |
Source component value |
Source SIP header field and component |
Derived value of parameter field |
|
Access Transport Parameter |
connected subaddress and Type of subaddress = "NSAP" (000) |
P-Asserted-Identity including the isdn-subaddress |
";isub=" 1*uric and "isub-encoding=nsap-ia5" The subaddress digits included into the "uric" shall be derived from the Access Transport Parameter. |
|
connected subaddress and Type of subaddress = "user specified" (010) (NOTE) |
";isub=" 1*uric and "isub-encoding=user-specified" The subaddress digits included into the "uric" shall be derived from the Access Transport Parameter. (NOTE) |
||
|
connected subaddress and Type of subaddress ≠ "NSAP" (000) or "user specified" (010) (NOTE) |
No mapping |
||
|
NOTE: The interworking between "user-specified" encoding-type parameter and "user-specified" type of subaddress is an operator option. |
|||
7.4.5.3 Interworking at O-MGCF
The mapping in table 24bc of the subaddress information received in the Access Transport Parameter (calling party subaddress and/or called party subaddress information elements) of the IAM message to the isdn-subaddress parameters "isub" and "isub-encoding" of a tel or SIP URI to be sent within the initial INVITE request shall be applied.
The mapping in table 24bd of the isdn-subaddress information received within a tel or SIP URI of a 200 OK (INVITE) to the subaddress information of the ISUP Access Transport Parameter (connected subaddress information element) to be sent within the ANM or CON message shall be applied.
Table 24bc: Mapping of the subaddress information received in an IAM to the isdn-subaddress sent in the INVITE
|
ISUP IAM Message |
SIP INVITE Message |
||
|
ISUP Parameter field |
Source component value |
Source SIP header field and component |
Derived value of parameter field |
|
Access Transport Parameter |
called party subaddress and Type of subaddress = "NSAP" (000) |
To header field including the isdn-subaddress, and, as an operator option, Request URI |
";isub=" 1*uric and "isub-encoding=nsap-ia5" The subaddress digits included into the "uric" shall be derived from the Access Transport Parameter. |
|
called party subaddress and Type of subaddress = "user specified" (010) (NOTE) |
";isub=" 1*uric and "isub-encoding=user-specified" The subaddress digits included into the "uric" shall be derived from the Access Transport Parameter. (NOTE) |
||
|
called party subaddress and Type of subaddress ≠ "NSAP" (000) OR "user specified" (010) (NOTE) |
No mapping |
||
|
calling party subaddress and Type of subaddress = "NSAP" (000) |
P-Asserted-Identity header field including the isdn-subaddress |
";isub=" 1*uric and "isub-encoding=nsap-ia5" The subaddress digits included into the "uric" shall be derived from the Access Transport Parameter. |
|
|
calling party subaddress and Type of subaddress = "user specified" (010) (NOTE) |
";isub=" 1*uric and "isub-encoding=user-specified" The subaddress digits included into the "uric" shall be derived from the Access Transport Parameter. (NOTE) |
||
|
calling party Subaddress and Type of Subaddress ≠ "NSAP" (000) or "user specified" (010) (NOTE) |
No mapping |
||
|
NOTE: The interworking between "user-specified" encoding-type parameter and "user-specified" type of subaddress is an operator option. |
|||
Table 24bd: Mapping of the isdn subaddress received in a 200OK to the subaddress information sent in the ANM or CON
|
SIP Message 200 (OK) |
ISUP Message ANM or CON |
||||
|
Source SIP header field and component |
Source component value |
ISUP Parameter field |
Derived value of parameter field |
||
|
P-Asserted-Identity header Field including the isdn-subaddress |
"isub=" 1*uric "uric" containing the subaddress digits |
isub-encoding not present |
Access Transport Parameter |
connected subaddress |
Type of subaddress = "NSAP" (000) |
|
"isub-encoding=nsap-ia5" |
|||||
|
"isub-encoding=nsap-bcd" |
Type of subaddress = "NSAP" (000) |
||||
|
"isub-encoding=nsap" |
Type of subaddress = "NSAP" (000) |
||||
|
"isub-encoding=user-specified" (NOTE) |
Type of subaddress = "user-specified" (010) (NOTE) |
||||
|
"isub=" 1*uric ("uric" containing the subaddress digits) and isub-encoding does not contain "nsap-ia5" or "nsap-bcd" or "nsap" or "user-specified" value (NOTE) |
No mapping |
||||
|
NOTE: The interworking between "user-specified" encoding-type parameter and "user-specified" type of subaddress is an operator option. |
|||||
7.4.6 Call Forwarding Busy (CFB)/ Call Forwarding No Reply (CFNR) / Call Forwarding Unconditional (CFU) / Call Deflection (CD)
7.4.6.1 General
A MGCF within an IMS network applying the Communication Diversion service uses the procedures defined in clause 7.5.4.
This clause describes additional interworking of call forwarding service information between a PSTN/PLMN network and an IMS network. This can also be used when interworking between SIP networks (e.g., IMS network interworking with enterprise networks making use of the History-Info header field with an escaped Reason header field as described in IETF RFC 7044 [91]). The procedures support the interworking of the diversion reason within the History-Info header field using an escaped Reason header field defined by IETF RFC 3326 [116] as described in IETF RFC 7044 [91] and also support the diversion cause using the "cause" URI parameter as described by IETF RFC 4458 [113].
If the MGCF is supporting the interworking of Call Forwarding and also applying the Communication Diversion services as defined by 3GPP TS 24.604 [60], it uses both IETF RFC 7044 [91] and IETF RFC 4458 [113] to signal the diversion reason. An IMS network supporting the interworking of Call Forwarding and not applying the IMS Communication Diversion supplementary service according to 3GPP TS 24.604 [60] uses IETF RFC 7044 [91] and can also use IETF RFC 4458 [113] based on network option.
When interworking the SIP History-Info header field to ISUP, and both the diversion reason based on IETF RFC 7044 [91] and IETF RFC 4458 [113] are present for the same diversion instance, the MGCF should use the "cause" URI parameter per IETF RFC 4458 [113] for deriving the ISUP. When the "cause" URI parameter per IETF RFC 4458 [113] is used, the corresponding interworking as described in clause 7.5.4 shall be applied for that diversion instance. Otherwise, the interworking as defined in the present clause should be applied.
When interworking from ISUP to the History-Info header field, to signal the diversion reason the MGCF should use the escaped Reason header field from IETF RFC 7044 [91] and apply the interworking procedures in the present subclause. The MGCF should also apply the interworking procedures described in clause 7.5.4 to use the "cause" URI parameter from IETF RFC 4458 [113] to signal the diversion reason.
In the event that the interworking procedures described in this clause as well as the interworking procedures in clause 7.5.4 are not applied, the actions of the MGCF at the ISUP/BICC side as described in ITU-T Recommendation Q.732.2-5 [42] under the clause "Interactions with networks not providing any call diversion information" may be applied as a network option.
7.4.6.2 Interworking at the O-MGCF
7.4.6.2.1 General
This clause describes the optional mapping of Call Forwarding information at the O-MGCF to the protocol-cause specified in IETF RFC 3326 [116].
7.4.6.2.2 Interworking SIP to ISUP
Table 7.4.6.2.2.1: Mapping of SIP messages to ISUP messages
|
Message sent to ISUP |
Message Received from SIP |
|
|
ACM indicating call forwarding |
181 (Call Is Being Forwarded) response |
See table 7.4.6.2.2.6 |
|
CPG indicating call forwarding (see NOTE) |
181 (Call Is Being Forwarded) response |
See table 7.4.6.2.2.7 |
|
ACM indicating ringing |
180 (Ringing) response |
See table 7.4.6.2.2.8 |
|
CPG indicating alerting (see NOTE) |
180 (Ringing) response |
See table 7.4.6.2.2.9 |
|
ANM |
200 (OK) response |
See table 7.4.6.2.2.10 |
|
CON |
200 (OK) response (Neither a 181 (Call Is Being Forwarded) response nor a 180 (Ringing) response was received) |
See table 7.4.6.2.2.10 |
|
NOTE: A CPG will be sent if an ACM was already sent. |
||
Table 7.4.6.2.2.2: Mapping of History-Info header field to ISUP Redirection number
|
Source SIP header field and component |
Source Component value |
Redirection number |
Derived value of parameter field |
|
hi-targeted-to-uri of the hi-entry following the last hi-entry containing a Reason "headers" component as defined in IETF RFC 7044 [91] with cause value as listed in table 7.4.6.2.2.4. Appropriate global number portion of the hi-targeted-to-uri, assumed to be in form |
CC |
Nature of address indicator |
If CC is equal to the country code of the country where O‑MGCF is located AND the next ISUP node is located in the same country, then set to "national (significant) number" else set to "international number". |
|
CC, NDC, SN |
Address signals |
If NOA is "national (significant) number" then set to If NOA is "international number" then set to CC + NDC + SN. |
|
|
NOTE: If the SIP URI doesn’t contain "user=phone", mapping to redirection number is impossible, therefore no need to generate Redirection number and Redirection number restriction parameter (per table 7.4.6.2.2.3), Notification subscription options can’t be set as "presentation allowed with redirection number". |
|||
Table 7.4.6.2.2.3: Mapping of History-Info header field to ISUP Redirection number restriction
|
Source SIP header field and component |
Source Component value |
Redirection number restriction |
Derived value of parameter field |
|
Privacy header field, or/and Privacy "headers" component of the hi-entry following the last hi-entry containing a Reason "headers" component as defined in IETF RFC 7044 [91] with cause value as listed in table 7.4.6.2.2.4 |
"history" or "session" or "header" |
Presentation restricted indicator |
"Presentation restricted" |
|
Privacy "headers" component of the hi-targeted-to-uri and Privacy header field absent or "none" |
"Presentation allowed" or absent |
Table 7.4.6.2.2.4: Mapping of hi-targeted-to-uri to ISUP Call Diversion Information
|
Source SIP header field and component |
Source Component value |
Call Diversion Information |
Derived value of parameter field |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
Notification subscription options |
If the priv-value "history" or "session" or "header" is received within the Privacy header field or the priv-value "history" is received within the "headers" component of the hi-targeted-to-uri representing the diverting URI(s) and within the hi-targeted-to-uri representing diverted-to URI then "presentation not allowed" shall be set. Otherwise, if the priv-value "history" is received only within the "headers" component of the hi-targeted-to-uri representing the diverted-to URI then "presentation allowed without redirection number" shall be set. (NOTE 1, NOTE 2) Otherwise, "presentation allowed with redirection number" shall be set. |
|
|
hi-targeted-to-uri; Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter |
Cause parameter value |
Redirecting reason |
|
|
302 |
Deflection immediate response |
||
|
486 |
User busy |
||
|
408 |
No reply |
||
|
503 |
Mobile subscriber not reachable |
||
|
all other cause values |
Unknown |
||
|
NOTE 1: diverting URI corresponds to the hi-targeted-to-uri of the hi-entry containing a hi-index value that match the "mp" header field parameter value of the diverted-to URI. If the diverted-to URI does not contain the "mp" header field parameter, the diverting URI corresponds to the hi-targeted-to-uri of the last hi-entry containing a Reason "headers" component with cause parameter. NOTE 2: diverted-to URI corresponds to the hi-targeted-to-uri of the hi-entry following the last hi-entry containing a Reason "headers" component with cause parameter and is mapped to the Redirection number, see table 7.4.6.2.2.2. |
|||
Table 7.4.6.2.2.5: Void
Table 7.4.6.2.2.6: Mapping of 181 (Call Is Being Forwarded) ACM when ACM was not previously sent
|
Source SIP header field and component |
Source Component value |
ISUP Parameter |
Derived value of parameter field |
|
181 (Call Is Being Forwarded) |
ACM |
||
|
Generic notification indicator Notification indicator |
Call is diverting |
||
|
History-Info header field |
See table 7.4.6.2.2.2 |
Redirection number |
See table 7.4.6.2.2.2 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.3 |
Redirection number restriction |
See table 7.4.6.2.2.3 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.4 |
Call diversion information Notification subscription options |
See table 7.4.6.2.2.4 |
|
hi-targeted-to-uri; Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter |
See table 7.4.6.2.2.4 |
Call diversion information Redirecting reason |
See table 7.4.6.2.2.4 |
Table 7.4.6.2.2.7: Mapping of 181 (Call Is Being Forwarded) CPG if ACM was already sent
|
Source SIP header field and component |
Source Component value |
ISUP Parameter |
Derived value of parameter field |
|
181 (Call Is Being Forwarded) response |
CPG |
||
|
Generic notification indicator Notification indicator |
Call is diverting |
||
|
hi-targeted-to-uri; Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter |
486 |
Event information Event indicator |
CFB (national use) |
|
408 (see NOTE) |
CFNR (national use) |
||
|
all other values, or if appropriate "national use" value (CFB, CFNR or CFU) is not used in a network, or if no hi-targeted-to-uri "cause" URI parameter is contained in the SIP 181 (Call Is Being Forwarded) response. |
Progress |
||
|
History-Info header field |
See table 7.4.6.2.2.2 |
Redirection number |
See table 7.4.6.2.2.2 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.3 |
Redirection number restriction |
See table 7.4.6.2.2.3 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.4 |
Call diversion information Notification subscription options |
See table 7.4.6.2.2.4 |
|
hi-targeted-to-uri; Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter |
See table 7.4.6.2.2.4 |
Call diversion information Redirecting reason |
See table 7.4.6.2.2.4 |
|
NOTE: This appears in the cases of CFNR. |
|||
Table 7.4.6.2.2.8: Mapping of 180 (Ringing) ACM when ACM was not previously sent
|
Source SIP header field and component |
Source Component value |
ISUP Parameter |
Derived value of parameter field |
|
180 (Ringing) response |
ACM |
||
|
History-Info header field |
If hi-targeted-to-uri of at least one History-Info hi-entry contains a Reason "headers" component as defined in IETF RFC 7044 [91]. |
Generic notification indicator Notification indicator |
Call is diverting |
|
History-Info header field |
See table 7.4.6.2.2.2 |
Redirection number (NOTE) |
See table 7.4.6.2.2.2 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.3 |
Redirection number restriction (NOTE) |
See table 7.4.6.2.2.3 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.4 |
Call diversion information Notification subscription options (NOTE) |
See table 7.4.6.2.2.4 |
|
hi-targeted-to-uri; Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter |
See table 7.4.6.2.2.4 |
Call diversion information Redirecting reason (NOTE) |
See table 7.4.6.2.2.4 |
|
NOTE: Parameter shall only be supplied if hi-targeted-to-uri contains a Reason "headers" component, as defined in IETF RFC 7044 [91] with cause value as listed in table 7.4.6.2.2.4. |
|||
The mapping described within table 7.4.6.2.2.8 can only appear if the communication has already undergone a Communications diversion in the IMS and the 180 (Ringing) is the first provisional response sent in backward direction.
The O-MGCF can indicate the call diversion information in the mapping of 180 (Ringing) provisional response to a CPG message in fact if the response before was a 181 (Call Is Being Forwarded).
Table 7.4.6.2.2.9: Mapping of 180 (Ringing) CPG if ACM was already sent
|
Source SIP header field and component |
Source Component value |
ISUP Parameter |
Derived value of parameter field |
|
180 (Ringing) response |
CPG |
||
|
Generic notification indicator Notification indicator |
Call is diverting |
||
|
History-Info header field |
Event information Event indicator |
ALERTING |
|
|
History-Info header field |
See table 7.4.6.2.2.2 |
Redirection number (NOTE) |
See table 7.4.6.2.2.2 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.3 |
Redirection number restriction (NOTE) |
See table 7.4.6.2.2.3 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.4 |
Call diversion information Notification subscription options (NOTE) |
See table 7.4.6.2.2.4 |
|
hi-targeted-to-uri; Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter |
See table 7.4.6.2.2.4 |
Call diversion information Redirecting reason (NOTE) |
See table 7.4.6.2.2.4 |
|
NOTE: Parameter shall only be supplied if hi-targeted-to-uri contains a Reason "headers" component, as defined in IETF RFC 7044 [91] with cause value as listed in table 7.4.6.2.2.4. |
|||
The mapping in table 7.4.6.2.2.9 appears when a 181 (Call Is Being Forwarded) provisional response previously was mapped to an ACM. Therefore the state machine of the O-MGCF knows that a CDIV is in progress.
Table 7.4.6.2.2.10: Mapping of 200 (OK) response
|
Source SIP header field and component |
Source Component value |
ISUP Parameter |
Derived value of parameter field |
|
200 (OK) response |
ANM/CON (NOTE) |
||
|
History-Info header field |
See table 7.4.6.2.2.2 |
Redirection number |
See table 7.4.6.2.2.2 |
|
Privacy "headers" component of the hi-targeted-to-uri or/and Privacy header field |
See table 7.4.6.2.2.3 |
Redirection number restriction |
See table 7.4.6.2.2.3 |
|
NOTE:Redirection number shall only be supplied if 200 (OK) response is mapped to ANM message. |
|||
7.4.6.2.3 Interworking ISUP to SIP
For the interworking of 180 (Ringing) response and 200 (OK) response (to the INVITE request) to the regarding ISUP messages and parameters no additional procedures beyond the basic call procedures are needed.
To interwork the redirecting number at the O-MGCF it can be needed to create placeholder History-Info hi-entries. Such a History-Info hi-entry shall contain a hi-targeted-to-uri set to an "Unknown User Identity" (value "sip:unknown@unknown.invalid" as defined in 3GPP TS 23.003 [74]), a Reason "headers" component with a cause parameter, a hi-index and an "mp" header field parameter as described within table 7.4.6.2.3.1.
Table 7.4.6.2.3.1: Mapping of IAM to SIP INVITE request
|
ISUP Parameter or IE |
Derived value of parameter field |
SIP component |
Value |
|---|---|---|---|
|
IAM |
INVITE request |
||
|
Redirecting number |
History-Info header field |
IF Redirection counter exceeds 1 hi-targeted-to-uri of the penultimate created hi-entry (NOTE 9) IF Redirecting number is available set to the value of the Redirecting number ELSE set to the Unknown User Identity (NOTE 10) ELSE no mapping (NOTE 8) |
|
|
Nature of address indicator: |
"national (significant) number" |
hi-targeted-to-uri |
Add CC (of the country where the MGCF is located) to Redirecting number Address Signals to construct E.164 number in URI. |
|
"international number" |
Map complete Redirecting number Address Signals to E.164 number in URI. |
||
|
Address Signals |
If NOA is "national (significant) number" then the format of the Address Signals is: NDC + SN If NOA is "international number" then the format of the Address Signals is: CC + NDC + SN |
hi-targeted-to-uri |
Addr-spec "+" CC NDC SN mapped to userinfo portion of SIP URI. (NOTE 5) Add "user=phone". |
|
Redirecting number |
APRI |
Privacy "headers" component of the penultimate hi-targeted-to-uri entry in the History-Info header |
Priv-value |
|
"presentation restricted" |
"history" |
||
|
"presentation allowed" |
Privacy header field absent or "none" (NOTE 3) |
||
|
Redirection Information |
Redirecting indicator |
Privacy "headers" component of the penultimate hi-targeted-to-uri entry in the History-Info header |
Priv-value |
|
Call diverted |
Privacy header field absent or "none" (NOTE 4) |
||
|
Call diverted, all redirection information presentation restricted |
"history" |
||
|
Redirection Information |
Redirection counter 1 |
hi-index and "mp" header field parameter (NOTE 7) |
Number of diversions is shown to the number of levels in hi-index. Index for Original called number = 1 Index for Called party number = 1.1 and addition of "mp=1" |
|
2 |
Index for Original called number = 1 Index for Redirecting number = 1.1 and addition of "mp=1" Index for Called party number = 1.1.1 and addition of "mp=1.1" |
||
|
N |
Index for Original called number = 1 Placeholder History-Info hi-entry with Index = 1.1 and addition of "mp=1" … Fill up … Index for Redirecting number = 1.[(N-1)* ".1"] and addition of "mp" set to the hi-index value of the hi-targeted-to-uri that precede. Index for Called party number = 1.N* ".1" (e.g. N=3 1.1.1.1) and addition of "mp=1.[(N-1)*].1" |
||
|
Redirection Information |
Redirecting Reason and Original Redirection Reason (NOTE 1) |
hi-targeted-to-uri; Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter. For a placeholder History-Info hi-entry the value "404" shall be taken (NOTE 2). Cause parameter for redirecting reason will be put in the entry of redirecting number, and cause parameter for original redirection reason will be put in the entry of original called number. |
Cause parameter value |
|
unknown/not available |
404 |
||
|
unconditional |
302 |
||
|
User Busy |
486 |
||
|
No reply |
408 |
||
|
Deflection during alerting |
302 |
||
|
Deflection immediate response |
302 |
||
|
Mobile subscriber not reachable |
503 |
||
|
Called Party Number |
See Redirecting number Nature of address indicator and Address signal |
History-Info header field see hi-targeted-to-uri |
URI of the last hi-targeted-to-uri entry of History-Info header field (NOTE 6) |
|
Original called number |
See Redirecting number Nature of address indicator and Address signal |
History-Info header field see hi-targeted-to-uri |
URI of first hi-targeted-to-uri entry of History-Info header field (NOTE 5, NOTE 9) IF the Original called number is available: set to the value of the Original called number ELSE IF the Redirection counter equals 1 AND the Redirecting number is available, set to the value of the Redirecting number ELSE set to the Unknown User Identity (NOTE 10) |
|
Original called number |
APRI |
Privacy "headers" component of the first hi-targeted-to-uri entry of History-Info header |
Priv-value |
|
"presentation restricted" |
"history" |
||
|
"presentation allowed" |
Privacy header field absent or "none" |
||
|
NOTE 1: Original Redirection Reason contains only the "unknown/not available " parameter NOTE 2: For all History-Info hi-entries except the last one a cause parameter in Reason "headers" component as defined in IETF RFC 7044 [91] has to be included. NOTE 3: If the Redirecting indicator has the value "Call diverted, all redirection information presentation restricted", the privacy value "history" shall be set. NOTE 4: If the redirecting number APRI has the value "presentation restricted", the privacy value "history" shall be set. NOTE 5: Used URI scheme shall be SIP URI. The Reason "headers" component with a cause parameter cannot be added if hi-targeted-to-uri is a tel URI. NOTE 6: The used URI scheme can be tel or SIP since the last hi-targeted-to-uri entry of the History-Info header field does not contain the Reason "headers" component with a cause parameter. NOTE 7: The hi-target-param defined in IETF RFC 7044 [91] defines the mp-param "mp" as a header field parameter that contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted, thus identifying the "mapped from" target. Since the hi-entries are created based on the redirection counter to reflect the diverting/diverted-to entries, the hi-target-param "mp" shall be present in each entry except the first one. NOTE 8: If the Original called number parameter is not available and if the value of the Redirecting counter is equal to one, the Redirecting number parameter is used for the first hi-targeted-to-uri entry of the History-Info header field. NOTE 9: If a further SIP to ISUP interworking occurs, parameters not present in the original message can then be included. NOTE 10: The "History-Info" header field may contain an "Unknown User Identity". An "Unknown User Identity" includes information that does not point to the served user and indicates that the user’s identity is unknown. The encoding of the "Unknown User Identity" shall be as defined in 3GPP TS 23.003 [74]. |
|||
7.4.6.3 Interworking at the I-MGCF
7.4.6.3.1 General
This clause describes the interworking of the Call Forwarding information at the I-MGCF.
7.4.6.3.2 Interworking from SIP to ISUP
Table 7.4.6.3.2.1: Mapping of SIP to ISUP messages
|
Message received from SIP |
Message send to BICC/ISUP |
|
INVITE request |
IAM |
Table 7.4.6.3.2.2: Mapping of History-Info header field to ISUP Redirecting number
|
Source SIP header field and component |
Source Component value |
Redirecting number |
Derived value of parameter field |
|
latest History-Info header field entry containing a Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter (NOTE 1) |
Redirecting number |
||
|
hi-targeted-to-uri appropriate global number portion of the URI, assumed to be in form |
CC |
Nature of address indicator |
If CC is equal to the country code of the country where MGCF is located AND the next ISUP node is located in the same country, then set to "national (significant) number" else set to "international number" |
|
CC, NDC, SN |
Address signals |
If NOA is "national (significant) number" then set to If NOA is "international number" then set to CC + NDC + SN |
|
|
Privacy header field or/and Privacy "headers" component of the hi-entry in History-Info header field as specified in this table (NOTE 2) |
APRI |
If the priv-value "history" or "session" or "header" is received within the Privacy header field or if the priv-value "history" is received within the "headers" component of the hi-targeted-to-uri in the latest hi-entry containing a Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter, then "presentation restricted" shall be set. Otherwise, "presentation allowed" shall be set. |
|
|
NOTE 1: If the SIP URI doesn’t contain "user=phone", mapping to redirecting number is impossible, therefore no need to generate Redirecting number. NOTE 2: It is possible that an entry of the History-Info header field itself is marked as restricted or the whole History-Info header. |
|||
Table 7.4.6.3.2.3: Mapping of History-Info header to ISUP Redirection Information
|
Source SIP header field and component |
Source Component value |
Redirection Information |
Derived value of parameter field |
|
Privacy header field, and in History-Info header field in the Privacy "headers" component of the last hi-targeted-to-uri containing a Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter value as listed in the cause parameter row in this table |
"history" or "session" or "header" for the Privacy SIP header or for the hi-targeted-to-uri entry |
Redirecting indicator |
Call diverted, all redirection information presentation restricted |
|
Privacy header field and the privacy component of the hi-targeted-to-uri entry either absent or set to "none" |
Call diverted |
||
|
Original redirection reason |
Unknown/not available |
||
|
Cause parameter in the last hi-targeted-to-uri containing a Reason "headers" component as defined in IETF RFC 7044 [91] |
Cause parameter value |
Redirecting Reason |
|
|
302 |
Deflection immediate response |
||
|
486 |
User busy |
||
|
408 |
No reply |
||
|
503 |
Mobile subscriber not reachable |
||
|
All other values |
unknown |
||
|
History-Info header field |
Redirection counter |
number of History-Info hi-entry(ies) containing a Reason "headers" component with a cause parameter (NOTE 1, NOTE 2) |
|
|
NOTE 1: If the determined number of redirection in SIP exceeds the ISUP maximum parameter value, the MGCF shall set the Redirection counter to its maximum value. For instance, in ISUP ITU-T Q.763 [4], the Redirection counter parameter cannot exceed 5. NOTE 2: The Redirection counter value will be incremented regardless of the SIP URI format. |
|||
Table 7.4.6.3.2.4: Mapping of History-Info header field to ISUP Original Called number
|
Source SIP header field and component |
Source Component value |
Original called number |
Derived value of parameter field |
|
Numbering Plan Indicator |
"ISDN (Telephony) numbering plan (Recommendation E.164)" |
||
|
hi-targeted-to-uri of 1st hi-targeted-to-uri containing a Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter; appropriate global number portion of the URI, assumed to be in form (NOTE 1) |
CC |
Nature of address indicator |
If CC is equal to the country code of the country where MGCF is located AND the next ISUP node is located in the same country, then set to "national (significant) number" else set to "international number" |
|
CC, NDC, SN |
Address signals |
If NOA is "national (significant) number" then set to If NOA is "international number" then set to CC + NDC + SN |
|
|
Privacy "headers" component in History-Info header field of the History-Info header field entry as defined above in this table (NOTE 2) |
"history" or "session" or "header" |
APRI |
"presentation restricted" |
|
Privacy header field absent or "none" |
"presentation allowed" |
||
|
NOTE 1: If it is SIP URI and doesn’t contain "user=phone", mapping to Original Called number is impossible, therefore no need to generate Original Called number. NOTE 2: It is possible that an entry of the History-Info header field itself is marked as restricted or the whole History-Info header. |
|||
Table 7.4.6.3.2.5: Mapping of INVITE to IAM
|
INVITE |
IAM |
||
|
History-Info header field |
See table 7.4.6.3.2.2 |
Redirecting number |
See table 7.4.6.3.2.2 |
|
History-Info header field |
See table 7.4.6.3.2.3 |
Redirection Information |
See table 7.4.6.3.2.3 |
|
History-Info header field |
See table 7.4.6.3.2.4 |
Original Called Number |
See table 7.4.6.3.2.4 |
7.4.6.3.3 Interworking from ISUP to SIP
Table 7.4.6.3.3.1: Mapping of ISUP to SIP Messages
|
Message sent to SIP |
Message Received from BICC/ISUP |
|
|
181 (Call Is Being Forwarded) |
ACM no indication with Redirection number and Call diversion information parameters (CFU, CFB, Cdi) |
See table 7.4.6.3.3.3 |
|
180 (Ringing) |
ACM indicating ringing, OBCI: "Call diversion may occur" (CFNR, Cda) |
See clause 7.2.3.1.4 |
|
181 (Call Is Being Forwarded) |
CPG indicating progress or subsequent diversion indicated in the CPG with Redirection number and Call diversion information parameters (CFNR, Cda) |
See table 7.4.6.3.3.4 |
|
180 (Ringing) |
CPG indicating ringing and Redirection number restriction parameter |
See table 7.4.6.3.3.5 |
|
200 (OK) |
ANM and Redirection number restriction parameter |
See table 7.4.6.3.3.6 |
Table 7.4.6.3.3.2: Mapping of ISUP Redirection Number Restriction to History-Info header field
|
Redirection Number Restriction |
Derived value of parameter field |
SIP component |
Value |
|
Presentation restricted indicator |
"Presentation restricted" |
Privacy "headers" component of the hi-targeted-to-uri |
"History" |
|
"Presentation allowed" or absent AND a previously received notification subscription options was NOT "presentation not allowed" OR was NOT "presentation allowed without redirection number" |
Privacy header field absent or "none" |
Table 7.4.6.3.3.3: Mapping of ACM 181 (Call Is Being Forwarded) response
|
ISUP Parameter |
Derived value of parameter field |
SIP component |
Value |
|
Generic notification indicator Notification indicator |
Call is diverting |
||
|
1st hi-entry of History-info header having an index = 1 (NOTE 1) |
Unknown User Identity (NOTE 4) |
||
|
Redirection number |
2nd hi-entry of History-Info header field having an index 1.1 |
hi-targeted-to-uri: |
|
|
Nature of address indicator: |
"national (significant) number" |
hi-targeted-to-uri |
Add CC (of the country where the MGCF is located) to Redirection number Address Signals to construct E.164 number in URI. |
|
"international number" |
Map complete Redirection number Address Signals to E.164 number in URI. |
||
|
Address Signals |
If NOA is "national (significant) number" then the format of the Address Signals is: NDC + SN If NOA is "international number" then the format of the Address Signals is: CC + NDC + SN |
hi-targeted-to-uri |
Addr-spec "+" CC NDC SN mapped to userinfo portion of SIP URI (NOTE 3) Add "user=phone". |
|
Call diversion information |
Redirecting Reason |
Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter in the penultimate hi-entry (NOTE 2) |
Cause parameter value |
|
Unknown |
404 |
||
|
Unconditional |
302 |
||
|
User busy |
486 |
||
|
No reply |
408 |
||
|
Deflection immediate response |
302 |
||
|
Deflection during alerting |
302 |
||
|
Mobile subscriber not reachable |
503 |
||
|
Notification subscription options |
Privacy "headers" component associated with Redirection number hi-targeted-to-uri (NOTE 2) |
||
|
unknown |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
presentation not allowed |
A 181 (Call Is Being Forwarded) shall not be sent |
||
|
presentation allowed with redirection number |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
presentation allowed without redirection number |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
NOTE 1: It is necessary to create two History-Info header entries to carry both Redirection number and Call diversion information. Since the original called number is not available from the ISUP message a hi-targeted-to-uri set to an "Unknown User Identity" is included in the first entry. Only two entries are provided because the number of diversions is not available. NOTE 2: Needs to be stored for a possible inclusion into subsequent messages. NOTE 3: Used URI scheme shall be SIP URI. The Reason "headers" component with a cause parameter cannot be added if hi-targeted-to-uri is a tel URI. NOTE 4: The "History-Info" header field may contain an "Unknown User Identity". An "Unknown User Identity" includes information that does not point to the served user and indicates that the user’s identity is unknown. The encoding of the "Unknown User Identity" shall be as defined in 3GPP TS 23.003 [74]. |
|||
Table 7.4.6.3.3.4: Mapping of CPG 181 (Call Is Being Forwarded) response
|
ISUP Parameter |
Derived value of parameter field |
SIP component |
Value |
|
Event information Event Indicator |
Progress |
||
|
Generic notification indicator Notification indicator |
Call is diverting |
||
|
1st hi-entry of History-Info header having an index =1 (NOTE 1) |
Unknown User Identity (NOTE 4) |
||
|
Redirection number |
2nd hi-entry of History-Info header field having an index = 1.1 |
hi-targeted-to-uri: |
|
|
Nature of address indicator |
"national (significant) number" |
hi-targeted-to-uri |
Add CC (of the country where the MGCF is located) to Redirection number Address Signals to construct E.164 number in URI. |
|
"international number" |
hi-targeted-to-uri |
Map complete Redirection number Address Signals to E.164 number in URI. |
|
|
Address Signals |
If NOA is "national (significant) number" then the format of the Address Signals is: NDC + SN If NOA is "international number" then the format of the Address Signals is: CC + NDC + SN |
hi-targeted-to-uri |
Addr-spec "+" CC NDC SN mapped to userinfo portion of SIP URI (NOTE 3) Add "user=phone". |
|
Call diversion information |
Redirecting Reason |
Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter in the penultimate hi-entry (NOTE 2) |
Cause parameter value |
|
Unknown |
404 |
||
|
Unconditional |
302 |
||
|
User busy |
486 |
||
|
No reply |
408 |
||
|
Deflection immediate response |
302 |
||
|
Deflection during alerting |
302 |
||
|
Mobile subscriber not reachable |
503 |
||
|
Notification subscription options |
Privacy "headers" component associated with Redirection number hi-targeted-to-uri (NOTE 2) |
||
|
unknown |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
presentation not allowed |
A 181 Call is Being Forwarded shall not be sent |
||
|
presentation allowed with redirection number |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
presentation allowed without redirection number |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
NOTE 1: It is necessary to create two History-Info header entries to carry both Redirection number and Call diversion information. Since the original called number is not available from the ISUP message a hi-targeted-to-uri set to an "Unknown User Identity" is included in the first entry. Only two entries are provided because the number of diversions is not available. NOTE 2: Needs to be stored for a possible inclusion into subsequent messages. NOTE 3: Used URI scheme shall be SIP URI. The Reason "headers" component with a cause parameter cannot be added if hi-targeted-to-uri is a tel URI. NOTE 4: The "History-Info" header field may contain an "Unknown User Identity". An "Unknown User Identity" includes information that does not point to the served user and indicates that the user’s identity is unknown. The encoding of the "Unknown User Identity" shall be as defined in 3GPP TS 23.003 [74]. |
|||
Table 7.4.6.3.3.5 addresses two separate conditions: the CPG message is received from the diverting exchange in which case the Call diversion information parameter is included; and the CPG message is received from the diverted-to exchange in which case the Call diversion information parameter is not included. Interworking for both conditions is shown.
Table 7.4.6.3.3.5: Mapping of CPG 180 (Ringing) response
|
ISUP Parameter |
Derived value of parameter field |
SIP component |
Value |
|
Event information Event Indicator |
Alerting |
||
|
1st hi-entry of History-Info header having an index = 1 (NOTE 1) |
Unknown User Identity (NOTE 3) |
||
|
Call diversion information |
Redirecting Reason |
Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter in the penultimate hi-entry (NOTE 2) |
Cause parameter value |
|
Unknown |
404 |
||
|
Unconditional |
302 |
||
|
User busy |
486 |
||
|
No reply |
408 |
||
|
Deflection immediate response |
302 |
||
|
Deflection during alerting |
302 |
||
|
Mobile subscriber not reachable |
503 |
||
|
Notification subscription options |
Privacy "headers" component associated with Redirection number hi-targeted-to-uri (NOTE 2) |
||
|
unknown |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
presentation not allowed |
The 180 (Ringing) response shall be sent without the the History-Info header field included |
||
|
presentation allowed with redirection number |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
presentation allowed without redirection number |
Escaped Privacy value is set according to the rules of TS 24.604 [60] clause 4.5.2.6.4 item c |
||
|
Redirection number |
2nd hi-entry of History-Info header field having an index = 1.1 |
See table 7.4.6.3.3.3 |
|
|
If no Call diversion information parameter is present |
Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter in the penultimate hi-entry |
Value stored from a previous received ACM or CPG. See tables 7.4.6.3.3.3 and 7.4.6.3.3.4 |
|
|
Privacy "headers" component associated with Redirection number hi-targeted-to-uri |
Value stored from a previous received ACM or CPG. See tables 7.4.6.3.3.3 and 7.4.6.3.3.4 |
||
|
Redirection number restriction |
See table 7.4.6.3.3.2 |
||
|
NOTE 1: It is necessary to create two History-Info header entries to carry both Redirection number and Redirecting reason. Since the original called number is not available from the ISUP message a hi-targeted-to-uri set to an "Unknown User Identity" is included in the first entry. Only two entries are provided because the number of diversions is not available. NOTE 2: Needs to be stored for a possible inclusion into subsequent messages. NOTE 3: The "History-Info" header field may contain an "Unknown User Identity". An "Unknown User Identity" includes information that does not point to the served user and indicates that the user’s identity is unknown. The encoding of the "Unknown User Identity" shall be as defined in 3GPP TS 23.003 [74]. |
|||
Table 7.4.6.3.3.6: Mapping of ANM 200 (OK) response (to INVITE request)
|
ISUP Parameter |
Derived value of parameter field |
SIP component |
Value |
|
1st hi-entry of History-Info header having an index = 1 (NOTE 1) |
Unknown User Identity (NOTE 2) |
||
|
Redirection number |
2nd hi-entry of History-Info header field having an index = 1.1 |
See table 7.4.6.3.3.3 |
|
|
Reason "headers" component as defined in IETF RFC 7044 [91] with cause parameter in the penultimate hi-entry |
Value stored from a previously received ACM or CPG. See tables 7.4.6.3.3.3 and 7.4.6.3.3.4 |
||
|
Redirection number restriction |
See table 7.4.6.3.3.2 |
||
|
NOTE 1: It is necessary to create two hi-entries of History-Info header field to carry both Redirection number and Redirecting reason. Since the original called number is not available from the ISUP message a hi-targeted-to-uri set to an "Unknown User Identity" is included in the first entry. Only two entries are provided because the number of diversions is not available. NOTE 2: The "History-Info" header field may contain an "Unknown User Identity". An "Unknown User Identity" includes information that does not point to the served user and indicates that the user’s identity is unknown. The encoding of the "Unknown User Identity" shall be as defined in 3GPP TS 23.003 [74]. |
|||
7.4.7 Void
7.4.8 Explicit Call Transfer (ECT)
When the MGCF receives a FAC message with Generic notification indicator coded as "Call transfer active" or "call transfer alerting" and a CPG with Generic notification indicator coded as "Remote hold" was received previously for the current communication, the action described in table 24be 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 24be: Mapping between ISUP and SIP for the Explicit Communication Transfer supplementary service
|
ISUP message |
Mapping |
|---|---|
|
FAC with a "call transfer, active" or "call transfer, alerting" Generic notification indicator |
As described for CPG message with a "remote retrieval" Generic notification indicator in Clause 7.4.10.2 |
7.4.9 Call Waiting
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Q.733.1 [42] under the clause "Interactions with other networks".
7.4.10 Call Hold
The service is interworked as indicated in 3GPP TS 23.228 [12].
7.4.10.1 Session hold initiated from the IM CN subsystem side
The IMS network makes a hold request by sending an UPDATE or re-INVITE request containing an SDP offer with:
– an "a=inactive" SDP attribute if the stream was a "recvonly" media stream; or
– an "a=sendonly" SDP attribute if the stream was a "sendrecv" media stream.
Upon receipt of the hold request from the IMS network, the MGCF shall send a CPG message to the CS side with a "remote hold" Generic notification indicator. Towards the IMS network the MGCF shall send a 200 OK final response containing an SDP answer with:
– an "a=inactive" SDP attribute if the received SDP offer contained an "a=inactive" SDP attribute; or
– an "a=recvonly" SDP attribute if the received SDP offer contained an "a=sendonly" SDP attribute.
To resume the session, the IMS network sends an UPDATE or re-INVITE request containing an SDP offer with:
– an "a=recvonly" SDP attribute if the stream was an "inactive" media stream; or
– an "a=sendrecv" SDP attribute or without any direction SDP attribute ("a=sendrecv", "a=recvonly", "a=sendonly", "a=inactive") if the stream was a "sendonly" media stream.
Upon receipt of the resume request from the IMS network, the MGCF shall send a CPG message to the CS side with a "remove retrieval" Generic notification indicator. Towards the IMS network the MGCF shall send a 200 OK final response containing an SDP answer with:
– an "a=sendonly" SDP attribute if the received SDP offer contained an "a=recvonly" SDP attribute; or
– an "a=sendrecv" SDP attribute or without any direction SDP attribute ("a=sendrecv", "a=recvonly", "a=sendonly", "a=inactive") if the received SDP offer contained an "a=sendrecv" SDP attribute.
However, the I-MGCF shall not send a CPG message upon reception of SDP offer containing "a=inactive" SDP attribute within an initial INVITE request establishing a new SIP dialogue and upon reception of the first subsequent SDP offer activating those media.
The user plane interworking of the hold/resume request is described in the clause 9.2.9.
Figure 30a: Session hold/resume initiated from the IM CN subsystem side
7.4.10.2 Session hold initiated from the CS network side
If an MGCF receives a CPG message with a "remote hold" Generic notification indicator and there is no dialog established towards the IMS UE the MGCF shall send, when the first dialog is established, an UPDATE or re-INVITE request containing an SDP offer with:
– an "a=sendonly" SDP attribute if the stream on this dialog was a "sendrecv" media stream; or
– an "a=inactive" SDP attribute if the stream on this dialog was a "recvonly" media stream,
NOTE 1: If a media stream directionality towards the IMS UE was "sendonly" or "inactive" a call hold request is not interworked.
as described in IETF RFC 3264 [36]. For an early dialog an UPDATE request shall be used.
When an MGCF receives a CPG message with a "remote hold" Generic notification indicator and the media on the IMS side are "sendrecv" or "recvonly", the MGCF shall forward the hold request by sending an UPDATE request on the early dialog which was last established containing an SDP offer with:
– an "a=sendonly" SDP attribute if the stream on this dialog was a "sendrecv" media stream;" or
– an "a=inactive" SDP attribute" if the stream on this dialog was a "recvonly" media stream,
NOTE 2: If a media stream directionality towards the IMS UE was "sendonly" or "inactive" a call hold request is not interworked.
as described in IETF RFC 3264 [36].
If an additional early dialog is established during the "remote hold" condition the MGCF shall send on this new dialog an UPDATE request containing an SDP offer with an "a=sendonly" or an "a=inactive" SDP attribute, depending on media stream directionality on this dialog, as described above.
If an UPDATE request with an SDP offer is received on one of the early dialogs for a call in the "remote hold" condition the MGCF shall send an appropriate SDP answer. If the MGCF had not invoked a call hold service towards the IMS on that dialog before, the MGCF shall then send a new UPDATE request including an SDP offer with an "a=sendonly" or an "a=inactive" SDP attribute, depending on media stream directionality on this dialog, as described above.
If an MGCF receives a 200 OK (INVITE) response on an early dialog for the call in a "remote hold" condition and if the MGCF on the dialog where 200 OK (INVITE) response was received had not invoked a call hold service before, the MGCF shall send an UPDATE or re-INVITE request (according to implementation option) containing an SDP offer with an "a=sendonly" or an "a=inactive" SDP attribute, depending on media stream directionality on this dialog, as described above. If the Contact header field of the received 200 OK (INVITE) response contained an "isfocus" media feature tag, defined in IETF RFC 3840 [135], the MGCF shall order the IM-MGW to disconnect the media towards the IMS.
If the MGCF receives a CPG with Generic Notification Indicator "remote hold" and there is a confirmed dialog on IMS side then the MGCF shall send a SIP re-INVITE or UPDATE request (according to implementation option) containing an SDP offer with an "a=sendonly" or an "a=inactive" SDP attribute, depending on media stream directionality on this dialog, as described above.
If the MGCF receives a CPG with a Generic Notification Indicator "remote retrieval" and there is an early dialog on IMS side then a SIP UPDATE request containing an SDP offer with:
– an "a=recvonly" SDP attribute if the stream was an "inactive" media stream; or
– an "a=sendrecv" SDP attribute or without any direction SDP attribute ("a=sendrecv", "a=recvonly", "a=sendonly", "a=inactive") if the stream was a "sendonly" media stream,
shall be sent if the call hold service had been invoked on this early dialog before. For each subsequent early dialog for which the MGCF receives an 18x response or an UPDATE request with an SDP offer, the MGCF shall send a SIP UPDATE request with the SDP offer indicating call retrieval (as described above) after a possible SDP answer to the SDP offer, if that dialog had received a call hold indication before.
If the MGCF receives a CPG with Generic Notification Indicator "remote retrieval" and there is a confirmed dialog on IMS side then a SIP re-INVITE or UPDATE request (according to implementation option) containing an SDP offer with:
– an "a=recvonly" SDP attribute if the stream was an "inactive" media stream; or
– an "a=sendrecv" SDP attribute if the stream was a "sendonly" media stream,
shall be sent for this dialog only if the call hold service had been invoked for this dialog before.
If link aliveness information is required at the IM-MGW while the media are on hold, and RTCP was previously disabled the MGCF should provide modified SDP RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] within the UPDATE or re-INVITE request holding and retrieving the media to temporarily enable RTCP while the media are on hold, as detailed in clause 7.3.1 of 3GPP TS 26.114 [104]. If no link aliveness information is required at the IM-MGW or RTCP was previously enabled, the MGCF should provide the SDP RR and RS bandwidth modifiers previously used.
The interworking does not impact the user plane with the following exceptions:
– the MGCF provides modified SDP RR and RS bandwidth modifiers within the UPDATE or re-INVITE request;
– the Contact header of the IMS remote party contains the "isfocus" media feature tag; or
– the MGCF has identified a speech call as an "ICS call" as specified in clause 7.2.3.1.2.12 or in clause 7.2.3.2.7a.
If the MGCF provides modified SDP RR and RS bandwidth modifiers to the IMS side, the MGCF shall also provide modified SDP RR and RS bandwidths to the IM-MGW, as described in the clause 9.2.10.
If there is a confirmed dialog on the IMS side for which the MGCF received the Contact header of the IMS remote party (in the initial INVITE request or in the 200 OK (INVITE) response) with the "isfocus" media feature tag, defined in IETF RFC 3840 [135], then upon reception of the CPG message with:
– a "remote hold" Generic notification indicator the MGCF shall request the IM-MGW to suspend sending media towards the IMS side; or
– a "remote retrieval" Generic notification indicator the MGCF shall request the IM-MGW to re-establish communication towards the IMS network if the MGCF requested the IM-MGW to suspend sending media on the "remote hold" request,
prior to sending of the UPDATE or re-INVITE request to the IMS side.
NOTE 3: If a participant of a conference invokes a hold request, it is not desirable to provide an announcement to the conference.
For a speech call that is identified as the "ICS call", upon reception of the CPG message with:
– a "remote hold" Generic notification indicator the MGCF shall request the IM-MGW to suspend sending media towards the IMS side; or
– a "remote retrieval" Generic notification indicator the MGCF shall request the IM-MGW to re-establish communication towards the IMS network if the MGCF requested the IM-MGW to suspend sending media on the "remote hold" request,
prior to sending of the UPDATE or re-INVITE request to the IMS side.
Figure 30b: Session hold/resume initiated from the CS network side
7.4.11 Call Completion on busy subscriber
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.733.3 [42] under the clause "Interactions with other networks".
7.4.12 Completion of Calls on No Reply (CCNR)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.733.5 [42] under the clause "Interactions with other networks".
7.4.13 Terminal Portability (TP)
Terminal Portability is defined as an ISUP supplementary service within ITU-T Rec. Q.733.4. [42].
A Suspend message containing the Suspend/Resume indicators set to "ISDN subscriber initiated" shall be treated like a CPG with "remote hold" in Clause 7.4.10 Resume message containing the Suspend/Resume indicators set to "ISDN subscriber initiated" shall be treated like a CPG with "remote retrieval" in Clause 7.4.10.
7.4.14 Conference calling (CONF) / Three-Party Service (3PTY)
The default behaviour of the MGCF at the ISUP/BICC side is described in ITU-T Recommendation Q.734.1[42] under the clause "Interactions with other networks". In addition, the MGCF may apply the interworking from ISUP to SIP described in Table 24aa.
Alternatively, the MGCF may apply the interworking to the Conference supplementary service described in clause 7.5.6.
Table 24aa: Mapping between ISUP and SIP for the Conference Calling (CONF) and Three-Party Service (3PTY) supplementary service
|
ISUP message |
Mapping |
|---|---|
|
CPG with a "Conference established" Generic notification indicator |
As described for CPG message with a "remote retrieval" Generic notification indicator in Clause 7.4.10.2 |
|
CPG with a "Conference disconnected" Generic notification indicator |
As described for CPG message with a "remote retrieval" Generic notification indicator in Clause 7.4.10.2 |
|
CPG with an "isolated" Generic notification indicator |
As described for CPG message with a "remote hold" Generic notification indicator in Clause 7.4.10.2 |
|
CPG with a "reattached" Generic notification indicator |
As described for CPG message with a "remote retrieval" Generic notification indicator in Clause 7.4.10.2 |
7.4.15 Void
7.4.16 Closed User Group (CUG)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.1[42] under the clause 1.5.2.4.2 "Exceptional procedures".
7.4.17 Multi-Level Precedence and Pre-emption (MLPP)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.3 [42] under the clause "Interactions with other networks".
7.4.18 Global Virtual Network Service (GVNS)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.6 [42] under the clause "Interactions with other networks".
7.4.19 International telecommunication charge card (ITCC)
An International Telecommunication charge card call is a basic call and no additional treatment is required by the MGCF.
7.4.20 Reverse charging (REV)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.736.3 [42] under the clause "Interactions with other networks".
7.4.21 User-to-User Signalling (UUS)
7.4.21.0 General
Procedures for the ISDN supplementary service "User-to-user signalling" are specified in ITU‑T Recommendation Q.737.1 [42].
7.4.21.1 User-to-User Signalling (UUS) service 1 (implicit)
7.4.21.1.0 General
The coding of the User-user information element is described within ITU-T Recommendation Q.931 [149]. The User-user information element is carried within the ISDN user part parameter user-to-user information, as defined in ITU-T Recommendation Q.763 [4]. The User-to-User header field is defined within IETF RFC 7433 [99]. A package for interworking user-to-user information with the ISDN is defined by IETF RFC 7434 [99A].
7.4.21.1.1 Void
7.4.21.1.2 User-to-user information Interworking from SIP to ISUP
On the receipt of a User-to-User header field with the "purpose" header field parameter set to "isdn-uui", or a User-to-User header field without a "purpose" parameter, with "encoding" header field parameter set to "hex" or without an "encoding" parameter, with "content" header field parameter set to "isdn-uui" or without a "content" parameter, that is valid as defined by IETF RFC 7434 [99A], the MGCF shall map the content of the "uui-data" field to the "protocol discriminator" and "user information" parameters of the User-user information element.
The "length of user-user contents" parameter shall be set by the MGCF according to the normal procedures.
The MGCF maps the messages transporting the user-to-user information according to the normal interworking procedures (see table 24ab).
Table 24ab: Mapping of the User-to-User header field to the ISUP user-to-user information parameter
|
SIP parameter |
ISUP parameter |
||
|
SIP header field |
Source component value |
ISUP parameter name |
ISUP parameter field |
|
User-to-User |
uui-data |
User-to-user |
Protocol discriminator and user information |
7.4.21.1.3 User-to-user information Interworking from ISUP to SIP
On the receipt of the user-to-user information parameter the MGCF shall map the protocol discriminator and user information parameter fields to the uui-data field of the User-to-User header field (see table 24ac).
If sent, the "purpose", "content" and "encoding" header field parameters are not mapped and are set in accordance with IETF RFC 7434 [99A]
The MGCF maps the messages transporting the user-to-user information parameters according to the normal interworking procedures.
Table 24ac: Mapping of the ISUP user-to-user information parameter to the User-to-User header field
|
ISUP parameter |
SIP parameter |
||
|
ISUP parameter name |
ISUP parameter field |
SIP header field |
Source component value |
|
User-to-user |
Protocol discriminator and user information |
User-to-User |
uui-data (NOTE) |
|
NOTE: The MGCF shall always send uui-data as a token (see IETF RFC 7433 [99]). The letters used for the hex digits shall always be capital form. |
|||
7.4.21.2 User-to-User Signalling (UUS) service 1 (explicit)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.737.1 [42] under the clause "Interaction with other networks".
7.4.21.3 User-to-User Signalling (UUS) service 2 (explicit)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.737.1 [42] under the clause "Interaction with other networks".
7.4.21.4 User-to-User Signalling (UUS) service 3 (explicit)
The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.737.1 [42] under the clause "Interaction with other networks".
7.4.22 Multiple Subscriber Number (MSN)
A MSN call is a basic call and no additional treatment is required by the MGCF.
7.4.23 Anonymous Call rejection
7.4.23.0 General
The Anonymous Call rejection (ACR) supplementary service in the CS domain is described within 3GPP TS 23.088 [134]. The ETSI ACR service is described within ETSI EN 300 356-21 [71].
7.4.23.1 ISUP-SIP protocol interworking at the I-MGCF
If ISUP Cause Value field in the ISUP REL includes Cause Value 24 "call rejected due to feature at the destination" the I-MGCF shall map this to a 433 (Anonymity Disallowed) SIP response code as described in RFC 5079 [77].
7.4.23.2 SIP-ISUP protocol interworking at the O-MGCF
SIP response code 433 (Anonymity Disallowed) shall be mapped to the ISUP Cause Value field 24 "call rejected due to feature at the destination" in the ISUP REL.
7.4.24 Customized Alerting Tones (CAT) in the 3GPP CS domain
The Customized Alerting Tones (CAT) in the 3GPP CS domain service is described in 3GPP TS 23.205 [27].
To pass CAT early media from the CS network towards the IM CN subsystem, no special interworking procedures beyond basic call at the I-MGCF are required. The procedure to supply the "P-Early-Media" header field is described in clause 7.2.3.1.4, clause 7.2.3.1.4A and clause 7.2.3.1.4B.