4 Communications Diversion (CDIV)

24.5043GPPProtocol specificationPSTN/ISDN simulation services: Communication Diversion (CDIV)Release 8TISPANTS

4.1 Introduction

The Communications Diversion (CDIV) service enables diverting user, to divert the communications addressed to diverting user to an other destination.

4.2 Description

4.2.1 General description

The service description of the following Communication Services CFU, CFB, CFNR and CD is based on the PSTN/ISDN Supplementary Services, whereas CFNL is Communication service based on requirements for IP based networks and CFNRc is based on requirements for mobile networks.

Generally the following requirements should be fulfilled:

  • It shall be possible for the user or the network to identify an alternative destination for an IP multimedia session or individual media of an IP multimedia session.
  • It shall be possible for redirection to be initiated at various stages of an IP Multimedia session. For example:
  • Prior to the set up of an IP Multimedia session.
  • During the initial request for an IP Multimedia session (CFU).
  • During the establishment of an IP Multimedia session (CD).
  • Redirection can be applied for all Multimedia sessions unconditionally or it can be caused by any of a set list of events or conditions. Typical causes could be:
  • Identity of the originating user.
  • Presence of the originating or destination party.
  • If the destination party is already in a session (CFB).
  • If the destination party is unreachable or unavailable in some other way (CFNL; CFNR, CFNRc).
  • If the destination party does not respond (CFNR).
  • After a specified alerting interval (CFNR).
  • User’s preference on routing for specific IP Multimedia session based on the capabilities of multiple UEs sharing the same IMS service subscription.
  • The sending party, receiving party or the network on their behalf, may initiate redirection to alternative destinations.

It shall be possible for the user to subscribe to receive notifications of his/her communications diversions. The following services describe applications based on a subset of the above-mentioned requirements to provide user different possibilities to divert a communication.

It should be possible that a user has the option to restrict receiving communications that are forwarded.

Communication Forwarding Unconditional (CFU)

The CFU service enables a served user to have the network redirect to another user communications which are addressed to the served user’s address. The CFU service may operate on all communications, or just those associated with specified services. The served user’s ability to originate communications is unaffected by the CFU supplementary service. After the CFU service has been activated, communications are forwarded independent of the status of the served user.

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder indication that the CFU service has been activated. This indication shall be provided when the served user originates a communication and if the CFU service has been activated for the served user’s address and for the service requested for the communication.

The maximum number of diversions permitted for each communication is a service provider option. The service provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are included.

Communication Forwarding on Busy user (CFB)

The CFB service enables a served user to have the network redirect to another user communications which are addressed to the served user’s address and meet busy. The CFB service may operate on all communications, or just those associated with specified services. The served user’s ability to originate communications is unaffected by the CFB supplementary service.

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder indication that the CFB service has been activated. This indication shall be provided when the served user originates a communication and if the CFB service has been activated for the served user’s address and for the service requested for the communication.

The maximum number of diversions permitted for each communication is a service provider option. The service provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are included.

For more information on the procedures for determination of the busy condition see ES 183 028 [11].

Communication Forwarding on no Reply (CFNR)

The CFNR service enables a served user to have the network redirect to another user communications which are addressed to the served user’s address, and for which the connection is not established within a defined period of time. The CFNR service may operate on all communications, or just those associated with specified services. The served user’s ability to originate communications is unaffected by the CFNR supplementary service.

The CFNR service can only be invoked by the network after the communication has been offered to the served user and an indication that the called user is being informed of the communication has been received.

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder indication that the CFNR service has been activated. This indication shall be provided when the served user originates a communication and if the CFNR service has been activated for the served user’s address and for the service requested for the communication.

The maximum number of diversions permitted for each communication is a service provider option. The service provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are included.

Communication Forwarding on Subscriber Not Reachable (CFNRc)

The CFNRc service enables a user to have the network redirect all incoming communications, when the user is not reachable (e.g. there is no IP connectivity to the user’s terminal), to another user. The CFNRc service may operate on all communications, or just those associated with specified services. The user’s ability to originate communications is unaffected by the CFNRc simulation service.

As a service provider option, a subscription option can be provided to enable the user to receive an indication that the CFNRc service has been activated. This indication may be provided when the user originates a communication if the CFNRc service has been activated for the user and for the service requested for the communication.

The maximum number of diversions permitted for each communication is a service provider option. The service provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are included.

Communication Deflection (CD)

The CD service enables the served user to respond to an incoming communication by requesting redirection of that communication to another user. The CD service can only be invoked before the connection is established by the served user, i.e. in response to the offered communication (before ringing), i.e. CD Immediate, or during the period that the served user is being informed of the communication (during ringing). The served user’s ability to originate communications is unaffected by the CD supplementary service.

The maximum number of diversions permitted for each communication is a network provider option. The network provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are included.

Communication Forwarding on Not Logged-in (CFNL)

The Communication Forwarding on Not Logged-in (CFNL) service enables a served user to redirect incoming communications which are addressed to the served user’s address, to another user (forwarded-to address) in case the served user is not registered (logged-in). The CFNL service may operate on all communications, or just those associated with specified basic services.

As a service provider option, a subscription option can be provided to enable the served user to receive a reminder indication that the CFNL service has been activated. This indication shall be provided when the served user logs out according to procedures described in RFC 3261 [6].

The maximum number of diversions permitted for each communication is a service provider option. The service provider shall define the upper limit of diversions. When counting the number of diversions, all types of diversion are included.

4.3 Operational requirements

4.3.1 Provision/withdrawal

The CDIV services (Communication forwarding unconditional, Communication forwarding busy, Communication forwarding no reply, Communication forwarding not logged-in, Communication deflection and Communication Diversion Notification) shall be provided after prior arrangement with the service provider.

The CDIV services shall be withdrawn at the served user’s request or for administrative reasons.

The CDIV simulation services can be offered separately with subscription options. For each subscription option, only one value can be selected. These subscription options are part of the call diversion profile for the served user. The subscription options are shown in table 4.3.1.1.

Table 4.3.1.1: Subscription options for CDIV services

Subscription options

Value

Applicability

Served user receives indication that a communication has been forwarded (indication of communication diversion to the diverting user).

No (default)
________________________

Yes

CFU
CFB
CFNR

CFNRc

Originating user receives notification that his communication has been diverted (forwarded or deflected).

No
________________________

Yes (default)

CFU
CFB
CFNR

CFNRc
CFNL
CD

Served user allows the presentation of diverted to URI to originating user in diversion notification.

No
________________________

Not reveal as GRUU
________________________

Yes (default)

CFU
CFB
CFNR

CFNRc
CFNL
CD

Served user receives reminder indication on outgoing communication that CDIV is currently activated.

No (default)
________________________

Yes

CFU
CFB
CFNR

CFNRc
CFNL

Served user allows the presentation of his/her URI to diverted‑to user.

No
________________________

Not reveal as GRUU
________________________

Yes (default)

CFU
CFB
CFNR

CFNRc
CFNL
CD

Served user allows the presentation of his/her URI to originating user in diversion notification.

No
________________________

Not reveal as GRUU
________________________

Yes (default)

CFU
CFB
CFNR

CFNRc
CFNL
CD

The following network provider options are available for the CDIV services:

Table 4.3.1.2: Network provider options for CDIV services

Network provider option

Value

Applicability

Served user communication retention on invocation of diversion (forwarding or deflection).

Retain communication to the served user until alerting begins at the diverted-to user
________________________

Clear communication to the served user on invocation of call diversion

CFNR
CD

Served user communication retention when diverting is rejected at
diverted-to user.

Continue to alert the diverting user (see note 1)
________________________

No action at the diverting user (see note 2)

CFNR

CD

Subscription option is provided for "served user receives reminder indication on outgoing communication that CDIV is currently activated".

No

________________________

Yes

CFU

CFB

CFNR

CFNRc

CFNL

Total number of all diversions for each communication.

Maximum number of diverted connections
( upper limit is based on operator policy)

CFU
CFB
CFNR

CFNRc
CFNL
CD

CDIV Indication Timer.

Timer duration shall be a service provider option

CFU
CFB
CFNR

CFNRc
CFNL
CD

Communication forwarding on no reply timer.

Timer default duration shall be a service provider option (NOTE 3)

CFNR

NOTE 1: This applies to the retention of the communication at invocation of communication diverting.

NOTE 2: This applies to the clearing communication option on invocation of communication diverting.

NOTE 3: As a network provider option, It shall be possible to change the timer duration by the served user..

For user configuration of the CDIV the Ut interface described in ES 282 001 [12] could be used. More detail is described in clause 4.9.

Other possibilities for provisioning could be used too, like web based provisioning or pre-provisioning by the operator.

4.3.2 Requirements on the originating network side

No specific requirements are needed in the network.

4.3.3 Requirements in the network

No specific requirements are needed in the network.

4.4 Coding requirements

ES 283 003 [2] defines the messages and parameters for this simulation service. The following messages and parameters are used to support the Communication diversion service due to fulfil the requirements.

4.4.1 SIP-Messages

4.4.1.1 SIP messages for redirection

The following SIP messages are used due to the coding rules in ES 283 003 [2].

Table 4.4.1.1: SIP Header information for redirection

SIP Message

Reference

SIP Header

INVITE

[3]

[8]

[14]

[23]

History-Info header

Privacy header

cause-param URI parameter

"gr" URI parameter

180 (Ringing)

[3]

[8]

[14]

[23]

History-Info header

Privacy header

cause-param URI parameter

"gr" URI parameter in the Contact

181 (Call Is Being Forwarded)

[3]

[8]

[14]

[23]

History-Info header

Privacy header

cause-param URI parameter

"gr" URI parameter in the Contact

200 (OK) response

[3]

[8]

[14]

[23]

History-Info header

Privacy header

cause-param URI parameter

"gr" URI param URI parameter

302 (Moved Temporarily)
(see note)

[2]

[14]

Contact header

cause-param URI parameter

NOTE: The 302 (Moved Temporarily) response is in the present document only used for the CD services.

More information on the cause-param URI parameter is given in annex C.

An AS that implements the CDIV service shall support the REFER method RFC 3515 [17], to be able to handle the interaction with ECT TS 183 029 [16].

4.4.1.2 Void

4.4.2 Parameters

The Privacy header is described in ES 283 003 [2]. The present document refers for the History-Info header to
RFC 4244 [3], for the Privacy header and P-Asserted-Identity to RFC 3325 [8], for GRUU to RFC 5627 [23] and for the cause-param to RFC 4458 [14].

4.5 Signalling requirements

4.5.0 General

For user configuration of the CFU, CFB, CFNR, CFNL, CFNRc and CD services the Ut interface should be used.

See clause 4.9 for further information about the structure of the XML document.

NOTE: Other possibilities for user configuration, as web-based provisioning or pre-provisioning by the operator are outside the scope of the present document.

4.5.1 Activation/deactivation

The services CFU, CFB, CFNR, CFNL, CFNRc and CD are individually activated at provisioning or at the subscribers request by using for example the Ut interface.

The services CFU, CFB, CFNR, CFNL, CFNRc and CD are individually deactivated at withdrawal or at the subscribers request by using for example the Ut interface.

4.5.1a Registration/erasure

For registration of diversion information for the services CFU, CFB, CFNR, CFNL, CFNRc and CD, the Ut interface should be used. The diverted-to party address of the services CFU, CFB, CFNR, CFNL, CFNRc and CD can individually be registered at the subscribers request by using the Ut interface.

For erasure of diversion information for the services CFU, CFB, CFNR, CFNL, CFNRc and CD, the Ut interface should be used. The diverted-to party address of the services CFU, CFB, CFNR, CFNL, CFNRc and CD can individually be erased at the subscribers request by using the Ut interface.

4.5.1b Interrogation

For interrogation of the services CFU, CFB, CFNR, CFNL, CFNRc and CD, the Ut interface should be used.

4.5.2 Invocation and operation

4.5.2.1 Actions at the originating UA

When communication diversion has occurred on the served user side and the network option "Originating user receives notification that his communication has been diverted (forwarded or deflected)" is set to true, the originating UA may receive a 181 (Call is being forwarded) response according to the procedures described in ES 283 003 [2].

The Information given by the History-Info header could be displayed by the UA if it is a UE.

4.5.2.2 Actions at the originating P-CSCF

Procedures according to ES 283 003 [2] shall apply.

4.5.2.3 Actions at the originating S-CSCF

Procedures according to ES 283 003 [2] shall apply.

4.5.2.4 Actions at the diverting S-CSCF

Procedures according to ES 283 003 [2] shall apply.

Based on the Initial Filter Criteria (IFC) Rules, indicating that the served user is subscribed to the CDIV simulation services, the communication is be forwarded to an AS.

NOTE: An example of the use of IFC is shown in annex B.

4.5.2.5 Actions at the diverted to S-CSCF

Procedures according to ES 283 003 [2] shall apply.

4.5.2.6 Actions at the AS of the diverting User

4.5.2.6.1 Checking of the diversion limits

When receiving an INVITE request and the AS determines that the AS shall divert a communication the AS shall check if diverting the communication exceeds the number of diversions allowed within the network. The AS shall calculate the number of diversions by examination of the History-Info header field:

– using the entries including a cause-param URI parameter with cause values specified in subclause 4.5.2.6.2.2; or

– examining the entries in the Index entries parameter;

to see if another diversion is allowed due to network provider allowed limit of diversions.

If the number of diversions exceed the given limit then the following response sent to the originating user shall apply:

a) communication diversion forwarding busy a 486 (Busy here) shall be sent;

b) communication forwarding no reply, 480 (Temporarily unavailable) shall be sent;

c) communication forwarding unconditional 480 (Temporarily unavailable) shall be sent;

d) communication deflection, 480 (Temporarily unavailable) shall be sent.

NOTE: It is based on operator policy that the communication can be delivered to the latest diverting party when it is known.

In all cases a Warning header field indicating that the communication is released due to the extension of diversion hops (e.g. "Too many diversions appeared") shall be sent.

4.5.2.6.2 Setting of the diversion parameters by the AS

4.5.2.6.2.1 Overview

After checking the limit of diversions the following settings of the INVITE request shall be performed.

4.5.2.6.2.2 Diversion where served user is not last in received History-Info header

If an AS determines that the AS shall divert a communication and the AS shall apply the procedures in the present subclause if any of the following conditions apply for the received INVITE request:

– no History-Info header field received; or

– a History-Info header field is received in which the last history-info entry contains no hi-targeted-to-uri element for the served user.

The following information is to be set in the retargeted request:

– the diverting parties address;

– the diverted-to party address;

– diversion information.

The following header fields shall be included or modified with the specified values:

a) The Request URI – shall be set to the SIP URI where the communication is to be diverted to (see <target> element in clause 4.9.1.4). In advance of this, if the <target> element contains a tel URI, the AS shall convert the tel URI into a SIP URI as specified in RFC 3261 [6], and include a user parameter set to "phone".

The AS shall add the cause-param as defined by RFC 4458 [14] to the request URI. The mapping between the diversion conditions and the coding of the cause-param parameter values as defined by RFC 4458 [14] shall be as follows:

– for communication forwarding busy, the cause value "486";

– for communication forwarding no reply, the cause value "408";

– for communication forwarding unconditional, the cause value "302";

– for communication deflection (Immediate Response), the cause value "480";

– for communication forwarding not logged in , the cause value "404";

– for communication deflection during alerting, the cause value "487"; and

– for communication forwarding on subscriber not reachable, the cause value "503".

b) The History-Info header field – Two hist-info entries that shall be generated.

b.1) The first entry includes the hi-targeted-to-uri of the served user.

The privacy header "history" shall be escaped within the hi-targeted-to-uri, if:

– the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or

– the served used has the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" set to false.

Otherwise, if the first entry contains the "gr" parameter and the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" is set to "not-reveal-as-GRUU", then it shall be changed as follows:

  • replace the first entry with the public user identity of the served user.

If the diversion is based on a SIP response from the served user, a Reason header as defined in RFC 3326 [22] shall be included in escaped form in the hi-targeted-to-uri in accordance with RFC 4244 [3].

When a Reason header field or a Privacy header field needs to be included in the hi-targeted-to-uri, the hi-targeted-to-uri shall be a SIP URI.

b.2) The second entry includes the new Request URI as described under bullet a) as hi-targeted-to-uri .

NOTE: In accordance with RFC 4458 [14], hi-targeted-to-uri will contain a cause-param in non-escaped format.

c) The To header field:

If the served user does not want to reveal its identity to the diverted-to party, then the To header shall be changed to the URI where the communication is diverted to. The served user does not want to reveal its identity when one of the following conditions holds true:

– if the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or

– if the served used has the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" set to "false".

Otherwise, if the To header contains the "gr" parameter and the served user has the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" set to "not-reveal-as-GRUU", then the To header field shall be changed to a public user identity of the served user.

In all other cases the To header shall not be changed.

4.5.2.6.2.3 Diversion with served user last in received History-Info header

If an AS determines that the communication shall be diverted the AS shall apply the procedures in the present subclause if the received INVITE request includes a History-Info header, which in the last history-info entry includes a hi-targeted-to-uri with an entry for the served user, encoded as in subclause 4.5.2.6.2.2. In this case the AS shall add a new history-info entry to the History-Info header field according to the rules defined in RFC 4244 [3]. The following information has to be added to the retargeted request:

  • the diverted-to party address;
  • diversion information.

The following header fields shall be included or modified with the specified values;

a) Request URI – shall be set to the SIP or SIPS URI where the communication is to be diverted to (see <target> element in subclause 4.9.1.4). In advance of this, if the <target> element contains a tel URI, the AS shall convert the tel URI into a SIP URI as specified in RFC 3261 [6], and include a user parameter set to "phone".

The AS shall add the cause-param as defined by RFC 4458 [14] to the request URI. The mapping between the diversion conditions and the coding of the cause-param parameter shall be as defined under bullet a) in subclause 4.5.2.6.2.2.

b) History-Info header shall be modified in accordance with RFC 4244 [3]. The history entry corresponding to the previous request URI can be modified. One history entry is added.

b.1) The existing history entry corresponding to the previous request URI shall be treated as follows:

If the Privacy header field does not contain "history", the privacy header "history" in escaped format shall be added or modified within the hi-targeted-to-uri, if:

– the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or

– the served used has the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" set to false.

If the history entry representing the served user contains the "gr" parameter and the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" set to "not-reveal-as-GRUU", it shall be changed to a public user identity of the served user.

If the diversion is based on a SIP response from the served user, a Reason header in escaped form shall be included in the hi-targeted-to-uri, in accordance with RFC 4244 [3].

When a Reason header field or a Privacy header field needs to be included in the existing hi-targeted-to-uri that is a tel URI, the hi-targeted-to-uri shall be first converted to a SIP URI.

b.2) A history entry shall be added containing the new Request URI as described under bullet a) as hi-targeted-to-uri.

NOTE: In accordance with RFC 4458 [14], hi-targeted-to-uri will contain a cause-param in non-escaped format.

c) To header:

If the served user does not want to reveal its identity to the diverted-to party, then the To header shall be changed to the URI where the communication is diverted to. The served user does not want to reveal its identity when one of the following conditions holds true:

– if the served user wishes privacy (e.g. the served user is subscribed to the OIR Service); or

– if the served used has the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" set to false.

Otherwise, if the To header contains the "gr" parameter and the served user has the subscription option "Served user allows the presentation of his/her URI to diverted‑to user" set to "not-reveal-as-GRUU", then the To header shall be changed to a public user identity of the served user.

In all other cases the To header shall not be changed.

4.5.2.6.2.4 Overview of the operation

Figure 4.5.2.6.2.4 shows the example of a communication path for multiple diversions.

Figure 4.5.2.6.2.4: Originally A calls B Information transferred in the INVITE request

Table 4.5.2.6.2.4 shows which parameters and header fields that are added or modified in a diversion AS.

Table 4.5.2.6.2.4: Parameter information for multiple redirections

HOP 1

HOP 2

HOP 3

HOP 4

HOP 5

Number Information:

P-Asserted-Identity

Request URI

A

B

A

C

A

D

A

E

A

F

hi-entry

B

C

B

C

D

B,

C

D

E

B,

C,

D

E

F

Information added:

hi-targeted-to-uri (NOTE 4)

Reason header (NOTE 2)

cause-param (NOTE 3)

Privacy

Hi-index (NOTE 1)

B

V

W

index 1

C

U

index 2

No changes

V

W

D

U

index 3

No changes

V

W

E

U

index 4

No changes

V

W

F

U

index 5

U = Value for the cause-param parameter as specified in 4.5.2.6.2.2 and 4.5.2.6.2.3

V = Value in accordance with the rules in RFC 4244 [3].

W = privacy value (history) or (none) or no entry.

NOTE 1: The hi-index field shall be set or incremented according to the basic forwarding rules as specified in subclause 4.3.3.1.3 of RFC 4244 [3].

NOTE 2: The encoding of the reason header and the contained protocol-cause parameter are specified in RFC 3326 [22]. It is embedded in the hi-targeted-to-uri of the history info header in escaped format according to the rules in RFC 4244 [3].

NOTE 3: The cause-param is specified in RFC 4458 [14]. It is embedded in the hi-targeted-to-uri of the history info header in non-escaped format according to the rules in RFC 4458 [14].

NOTE 4: If the received hi-targeted-to-uri is a tel URI, it is converted to a SIP URI if the Reason or the Privacy header field has to be embedded.

4.5.2.6.3 Diversion procedures at the diverting AS

The diverting AS shall continue the communication depending on the service that is causing the diversion:

1) Communication Forwarding Unconditional or Communication Forwarding Busy network determined user busy or Communication forwarding on Not Logged in

The AS shall continue in the following manner:

– If the notification procedure of the originating user is supported then the originating user shall be notified as described in the clause 4.5.2.6.4.

– An INVITE request containing the diverted-to URI shall sent to the (outgoing) S-CSCF. The INVITE request shall includes the parameter information as shown in table 4.5.2.6.2.4 and described in clause 4.5.2.6.2.

  • If the served user has subscribed to the indication of communication diversion to the diverting user, then the served user will be notified of the communication diversion as described in clause 4.5.2.6.5.

2) Communication Forwarding No Reply

After receiving the first 180 (Ringing) response the no reply timer (definition see clause 4.8) shall be started. If forking is provided by the S-CSCF a further received 180 (Ringing) response does not refresh the timer.

With receiving a 200 (OK) response the no reply timer shall be terminated and the call follows the Basic call procedure as described within ES 283 003 [2]. Other open early dialogs shall be terminated as described within ES 283 003 [2], clause 9.2.3.

When the no reply timer defined in clause 4.8 expires:

The dialog(s) to the diverting user shall be terminated e.g. by sending a CANCEL request or BYE request according to the rules and procedures in RFC 3261 [6].

If the notification procedure of the originating user is supported then the originating user shall be notified as described in the clause 4.5.2.6.4.

An INVITE request is sent to the (outgoing) S-CSCF towards the diverted-to user. The INVITE request includes the parameter information as shown in table 4.5.2.6.2.4.

If the served user has subscribed to the indication of communication diversion to the diverting user, then the served user will be notified of the communication diversion as described in clause 4.5.2.6.5.

3) Communication Forwarding No Reply (ringing continues)

After receiving the first 180 (Ringing) response the no reply timer (definition see clause 4.8) shall be started. If forking is provided by the S-CSCF a further received 180 (Ringing) response does not refresh the timer.

When the no reply timer defined in subclause 4.8 expires, an INVITE is sent to the outgoing S-CSCF towards the diverted to user. The INVITE address message includes the parameter information as shown in table 4.5.2.6.2.4.

When the diverting AS receives a provisional response or 200 (OK) response to initial INVITE from diverted-to-user based on operator policy, the dialog(s) to the diverting user shall be terminated e.g. by sending a CANCEL request or a BYE request according to the rules and procedures in IETF RFC 3261 [6], and if the notification procedure of the originating user is supported, the originating user shall be notified as described in subclause 4.5.2.6.4.

If the served user has subscribed to the indication of communication diversion to the diverting user, then the served user will be notified of the communication diversion as described in clause 4.5.2.6.5.

If diverting user accepts the communication after sending the INVITE request the communication path towards the diverted to user shall be released according to the rules and procedures in RFC 3261 [6].

4) Communication Forwarding User Determined Busy

The Communication Forwarding User Determined Busy is offered to the served user when the AS:

– The received 486 Busy shall be acknowledged with a ACK.

– If the notification procedures of the originating user is supported then the originating user shall be notified as described in the clause 4.5.2.6.4.

– An INVITE message containing the diverted-to URI is sent to the outgoing S-CSCF. The INVITE address message includes the parameter information as shown in table 4.5.2.6.2.4.

  • If the served user has subscribed to the indication of communication diversion to the diverting user, then the served user will be notified of the communication diversion as described in clause 4.5.2.6.5.

5) Communication Deflection immediate response

The Communication Deflection immediate response is offered to the served user.

A 302 (Moved Temporarily) response is received.

If the notification procedures of the originating user is supported then the originating user shall be notified as described in clause 4.5.2.6.4.

An INVITE message containing the diverted-to URI is sent to the outgoing S-CSCF. The INVITE address message includes the parameter information as shown in table 4.5.2.6.2.4.

If the served user has subscribed to the indication of communication diversion to the diverting user, then the served user will be notified of the communication diversion as described in clause 4.5.2.6.5.

6) Communication Deflection during alerting

When Communication Deflection during alerting is invoked after the AS receives a 180 (Ringing) "Ringing" response. then:

  • A 302 (Moved Temporarily) response is received; and
  • if the notification procedures of the originating user is supported then the originating user shall be notified as described in clause 4.5.2.6.4; and
  • an INVITE request containing the URI received in the Contact header of the 302 as the diverted-to URI shall be sent as specified in ES 283 003 [2]. The diverted-to URI could be restricted by setting the privacy header for the entry of the diverted-to URI to "history"; and
  • the INVITE request shall include the parameter information as shown in table 4.5.2.6.2.4 "Parameter information for multiple redirection".

If the served user has subscribed to the indication of communication diversion to the diverting user, then the served user will be notified of the communication diversion as described in clause 4.5.2.6.5.

7) Communication Forwarding on Subscriber Not Reachable

When the AS receives a not reachable indication (see clause 4.5.2.6.6) on the INVITE forwarded to the served user, then the following criteria shall apply before the Communication Forwarding on Subscriber Not Reachable procedure is executed:

  • the served user has an active forwarding rule containing not-reachable condition (see clause 4.9); and
  • the served user is registered.

The following steps shall be followed to perform Communication Forwarding on Subscriber Not Reachable:

  1. If the notification procedures of the originating user is supported then the originating user shall be notified as described in the clause 4.5.2.6.4.
  2. An INVITE message containing the diverted-to URI is sent to the outgoing S-CSCF. The INVITE address message includes the parameter information as shown in table 4.5.2.6.2.4.

If the served user has subscribed to the indication of communication diversion to the diverting user, then the served user will be notified of the communication diversion as described in clause 4.5.2.6.5.

4.5.2.6.4 Notification procedures of the originating user (Subscription Option)

When Communication Diversion occurs and if served user has the subscription option "Originating user receives notification that his communication has been diverted (forwarded or deflected)." set to true then a 181 (Call Is Being Forwarded) response shall be sent towards the originating user.

The following header fields shall be included or modified with the specified values:

a) The P-Asserted-Identity includes the URI of the diverting user.

b) The Privacy header with the value "id" shall be included, if:

  • the served user wishes privacy (e.g. the served user is subscribed to the TIR Service); or
  • the served used has the subscription option " Served user allows the presentation of his/her URI to originating user in diversion notification." set to false.

c) The following entries shall be added to the History-Info header field:

c.1) If this is the first diversion then the first entry shall be populated with the hi-targeted-to-uri of the served user. The Index is set to index = 1 according to the rules specified in RFC 4244 [3].

c.2) On the history entry that represents the served user:

the privacy header with value "history" shall be escaped within the hi-targeted-to-uri, if:

  • the served user wishes privacy (e.g. the served user is subscribed to the TIR Service); or
  • the served used has the subscription option "Served user allows the presentation of his/her URI to originating user in diversion notification." set to false.

If the history is already escaped with the correct privacy value no modification is needed.

If the history entry representing the served user contains the "gr" parameter and the served user has the subscription option "Served user allows the presentation of his/her URI to originating user in diversion notification" set to "not-reveal-as-GRUU", it shall be changed to the public user identity of the diverted-to user.

In all other cases the history entry representing the served user shall not be changed.

c.3) A history entry shall be added according to the rules of clause 4.5.2.6.2.3 item b.2. In addition, for this entry.

c.3.1) if the history entry representing the forwarded to URI contains the "gr" parameter and the served user has the subscription option "Served user allows the presentation of forwarded to URI to originating user in diversion notification" set to "not-reveal-as-GRUU", it shall be changed to the public user identity of the diverted-to user.

c.3.2) the privacy header with value "history" shall be escaped within the hi-targeted-to-uri, if the served used has the subscription option "Served user allows the presentation of forwarded to URI to originating user in diversion notification" set to "false".

Additional the AS may initiate an announcement to be included towards the calling user in order to inform about the diversion. Announcements may be played according to procedures as are described in TS 183 028 [11].

4.5.2.6.5 Indication of communication diversion to the diverting user (subscription option)

If the subscription option "Served user receives notification that a communication has been forwarded" has been set to "yes", one or a combination of the following procedures are possible:

1) When the diverting user is registering to the communication system, the AS sends a MESSAGE request including the information where his calls are diverted to if any. As an option; the MESSAGE request may be sent to the user after a period of time according to the timer value TCDIV_IND as defined in clause 4.8.3 that can be provided by the user.

2) A diverting user will be informed periodically with a MESSAGE request the information where the call is diverted to.

NOTE 1: A diverting user could be informed via a Voicemail or Message mail system in the communication states described above.

3) If the subscription option "Served user receives reminder notification on outgoing communication that CDIV is currently activated" has been set to "yes", then a diverting user will be informed with a MESSAGE request after the diverting user has initiated a new outgoing communication. The MESSAGE request includes the information where the call is diverted to.

NOTE 2: A diverting user could be informed via a Voicemail or Message mail system in the communication states described above.

The description of information text contained in the MESSAGE request is out of scope of the present document.

4.5.2.6.5.1 Void

4.5.2.6.5.2 Void

4.5.2.6.6 not reachable indication

It is recommended that the AS interprets the reception of one of the following response events as not reachable indication:

  • 408 Request timeout response;
  • 503 Service unavailable;
  • 500 Server internal error;

and no provisional response, different than 100 Trying, has been received on the same dialog.

NOTE 1: Once the response code for signalling channel outage between the UE and the P-CSCF is standardized this response has to be added to this list.

NOTE 2: There may be other means to discover this condition. These other means are out of the scope of the present document.

4.5.2.7 Actions at the AS of the diverted to user

The AS shall store the History-Info header of an incoming Request.

If a 180, 181 or 200 response does not contain a History Info header field, the AS shall include the stored History-Info header field and if diverted to user is subscribed to the TIR service the Privacy header field of all responses the
priv-value of the last entry in the History-Info header field shall be set to "history".

NOTE: A response including no History-Info header Field is coming from an untrusted entity or the History-Info header field is not included due to the privacy status within the SIP request.

4.5.2.8 Void

4.5.2.9 Actions at the incoming I-CSCF

Procedures according to ES 283 003 [2] shall apply.

4.5.2.10 Actions at the outgoing IBCF

Procedures according to ES 283 003 [2] shall apply.

4.5.2.11 Actions at the incoming IBCF

Procedures according to ES 283 003 [2] shall apply.

4.5.2.12 Actions at the BGCF

Basic call procedures according to ES 283 003 [2] shall apply.

The interworking with other NGN is described in clause 4.7.3.

4.5.2.13 Actions at the MGCF

Procedures according to ES 283 003 [2] shall apply.

The interworking is described in clause 4.7.1.

4.5.2.14 Actions at the destination P-CSCF

Procedures according to ES 283 003 [2] shall apply.

4.5.2.15 Actions at the diverted to UA

Procedures according to ES 283 003 [2] shall apply.

4.5.2.16 Actions at the diverting UA

Procedures according to ES 283 003 [2] shall apply.

To invoke Communication Deflection the UA shall send a 302 including a Contact header field with the address where the communication is diverted to.

4.6 Interaction with other services

4.6.1 Communication Hold (HOLD)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.2 Terminating Identification Presentation (TIP)

A P-Asserted-Identity and History-Info header field received in the diverting AS is passed unmodified to the originating entity. The originating S-CSCF is responsible for the interpretation of the privacy header field.

4.6.3 Terminating Identification Restriction (TIR)

A P-Asserted-Identity and History-Info header field received in the diverting AS is passed unmodified to the originating entity. The originating CSCF is responsible of the interpretation of the privacy header field.

If the served (diverting) user selects the option that the originating user is notified, but without the diverted-to SIP, TEL or SIPS URI, then the AS shall not send the connected user’s identity when the communication is answered, unless the originating user has an override capability.

4.6.4 Originating Identification Presentation (OIP)

When a communication has been diverted and the diverted-to user has been provided with the originating identification presentation simulation service, the S-CSCF of the diverted-to user shall sent the SIP, TEL or SIPS URI of the original originating user, if this originating user has not subscribed to or invoked the originating identification restriction simulation service.

4.6.5 Originating Identification Restriction (OIR)

When the originating identification restriction simulation service has been invoked, the originating user’s address shall not be presented to the diverted-to user unless the diverted-to user has an override capability.

4.6.6 Conference calling (CONF)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.7 Communication Diversion Services (CDIV)

For the redirection services, no impact, i.e. neither service shall affect the operation of the other service.

For the indication of communication diversion to the diverting user service, the provision and activation of at least one redirection service is a pre-requirement to provision and activate the indication of communication diversion to the diverting user service.

4.6.8 Malicious Communication Identification (MCID)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.9 Anonymous Communication Rejection and Communication Barring (ACR/CB)

If the user where the communication is forwarded to has subscribed to a call barring service "inhibition of incoming forwarded communication" the procedures described in TS 183 011 [9] shall take precedence.

If the user is subscribed to an Outgoing Communication Barring (OCB) service that includes the forwarded communication the OCB shall take precedence. The CDIV service has to check if the forwarded to SIP, TEL or SIPS URI is restricted and release the communication in such a case.

4.6.10 Explicit Communication Transfer (ECT)

4.6.10.1 Actions at the diverting AS

4.6.10.1.1 Determine whether ECT is applied to the diverted communication

See TS 183 029 [16] clause 4.5.2.4.1 on the criteria that determine that a REFER request is to be treated as a request for transfer of an existing communication.

4.6.10.1.2 Handling of transfer requests

When a REFER request is received in the context of a call transfer scenario (see clause 4.6.10.1.1), it shall perform the following steps:

1) Create a new CDIV Session Identifier URI addressed to this AS. The URI shall be created in such a way that a new dialog set up towards this URI can be easily correlated with the current REFER dialog.

2) The AS stores the value of the Refer-To header field (transfer target) from the REFER request and links it to the CDIV Session Identifier URI.

3) The AS Replaces the Refer-To header field with the CDIV Session Identifier URI. (This ensures that the diverting AS remains in the loop when the transferee sets up the communication with the transfer target.).

4) The AS forwards the REFER request to the transferee using basic communication procedures ES 283 003 [2].

4.6.10.1.3 Actions when CDIV is invoked again by the transferred communication

When an INVITE is received targeted at the CDIV Session Identifier URI created earlier when transfer of the diverted ongoing communication was requested, the AS shall perform the following actions:

1) The AS replaces the request URI with the stored Refer-To header field value linked to the specific CDIV Session Identifier URI.

NOTE: If needed the AS may generate charging events to charge for the extra leg.

2) The AS sets the diversion parameters (History-Info and To header fields) as specified in clause 4.5.2.6.2, in step 4.5.2.6.2.2 b2) or 4.5.2.6.2.3 b2) the cause-param value 302 shall be used.

3) The AS forwards the INVITE request towards the transfer target using basic communication procedures ES 283 003 [2].

4.7 Interworking with other networks

4.7.1 Interworking with PSTN/ISDN

In case of interworking with networks which do not provide any notification of the communication diversion or communication redirection information (e.g. redirection counter) in the signalling system, the communication continues according to the basic call procedures.

4.7.1.1 Interworking at the O-MGCF

For the mapping of IAM to the INVITE Message no additional procedures beyond the basic call and interworking procedures are needed unless Call Forwarding within the ISUP network appeared.

With regard to the backward messages the following mapping is valid.

Table 4.7.1.1.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)

See table 4.7.1.1.6

CPG indicating call forwarding
(see note)

181 (Call Is Being Forwarded)

See table 4.7.1.1.7

ACM indicating ringing

180 (Ringing)

See table 4.7.1.1.8

CPG indicating Alerting (see note)

180 (Ringing)

See table 4.7.1.1.9

ANM

200 (OK)

See table 4.7.1.1.10

CON

200 (OK) (Neither a 181 (Call Is Being Forwarded) nor a 180 (Ringing) was received)

See table 4.7.1.1.10

NOTE: A CPG will be sent if an ACM was already send.

NOTE: The mapping of the basic Messages is shown in ES 283 027 [13].

Table 4.7.1.1.2: Mapping of History-Info Header 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 last History-Info hi-entry containing a cause-param URI parameter, as defined in IETF RFC 4458 [14].

The global number portion of the URI is assumed to be in form
"+" CC + NDC + SN. (NOTE)

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
NDC + SN.

If NOA is "international number"

then set to CC + NDC + SN.

NOTE: If it is SIP URI and doesn’t contain “user=phone”, mapping to redirection number is impossible, therefore no need to generate Redirection number and Redirection number restriction (per table 4.7.1.1.3). Notification subscription options can’t be set as “presentation allowed with redirection number”.

Table 4.7.1.1.3: Mapping of History-Info header to ISUP Redirection number restriction

Source SIP header field and component

Source Component value

Redirection number restriction

Derived value of parameter field

Privacy, priv‑value component

"history" or “session” or “header”

Presentation restricted indicator

"Presentation restricted"

Privacy header field absent

or "none"

"Presentation allowed" or absent

Table 4.7.1.1.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, priv‑value component

"history" or “session” or “header”

Notification subscription options

If the priv-value "history" or “session” or “header” is set for the History-Info header or to the hist-info element entries concerning the redirecting (see table 4.7.1.2.2) and diverted to uri (see table 4.7.1.1.2) then presentation not allowed shall be set

If the priv-value "history" or “session” or “header” is set only to the hist-info element concerning the diverted-to uri then presentation allowed without redirection number shall be set

Privacy header field absent

or "none"

Presentation allowed with redirection number

hi-targeted-to-uri cause-param URI parameter, as defined in RFC 4458 [14] of the last History-Info hi-entry containing such an a cause-param.

cause-param value

Call diversion information

Redirecting Reason

404

Unknown

302

Unconditional

486

User busy

408

No reply

480

Deflection immediate

503

Mobile subscriber not reachable

487

Deflection during alerting

Table 4.7.1.1.5: Void

Table 4.7.1.1.6: Mapping of 181 (Call Is Being Forwarded)  ACM if no ACM was sent before

Source SIP header field and component

Source Component value

ISUP Parameter

Derived value of parameter field

181 (Call Is Being Forwarded)

ACM

Generic notification indicators

Call is diverting

History-Info Header

See table 4.7.1.1.2

Redirection number

See table 4.7.1.1.2

Priv-value

See table 4.7.1.1.3

Redirection number restriction

See table 4.7.1.1.3

Priv-value

See table 4.7.1.1.4

Call diversion information Notification subscription options

See table 4.7.1.1.4

hi-targeted-to-uri; cause-param URI parameter as defined in IETF RFC 4458[14] of the last History-Info hi-entry containing such an a cause-param.

See table 4.7.1.1.4

Call diversion information

Redirecting Reason

See table 4.7.1.1.4

Table 4.7.1.1.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)

CPG

Generic notification indicators

Call is diverting

hi-targeted-to-uri; cause-param URI parameter, as defined in IETF RFC 4458 [14] of the last History-Info hi-entry containing such an a cause-param.

486

Event indicator

CFB (national use)

408 (see note)

CFNR (national use)

302

CFU (national use)

Any other value, or if appropriate national use value CFB, CFNR or CFU is not used in a network. or if no agreement exists between operators to use theses values, or if no hi-targeted-to-uri cause-param URI parameter is contained in the SIP 181.

PROGRESS

History-Info Header

See table 4.7.1.1.2

Redirection number

See table 4.7.1.1.2

Priv-value

See table 4.7.1.1.3

Redirection number restriction

See table 4.7.1.1.3

Priv-value

See table 4.7.1.1.4

Call diversion information Notification subscription options

See table 4.7.1.1.4

hi-targeted-to-uri; cause-param URI parameter, as defined in RFC 4458 [14]

See table 4.7.1.1.4

Call diversion information Redirecting Reason

See table 4.7.1.1.4

NOTE: This appears in the cases of CFNR.

Table 4.7.1.1.8: Mapping of 180 (Ringing)  ACM if no ACM was sent before

Source SIP header field and component

Source Component value

ISUP Parameter

Derived value of parameter field

180 (Ringing)

ACM

History Header

If hi-targeted-to-uri of at least one History-Info hi-entry contains a cause-param URI parameter, as defined in IETF RFC 4458 [113].

Generic notification indicators

Call is diverting

History Header

See table 4.7.1.1.2

Redirection number (NOTE)

See table 4.7.1.1.2

Priv-value

See table 4.7.1.1.3

Redirection number restriction (NOTE)

See table 4.7.1.1.3

Priv-value

See table 4.7.1.1.4

Call diversion information Notification subscription options (NOTE)

See table 4.7.1.1.4

hi-targeted-to-uri; cause-param URI parameter, as defined in IETF RFC 4458 [14] of the last History-Info hi-entry containing such an a cause-param.

See table 4.7.1.1.4

Call diversion information Redirecting Reason (NOTE)

See table 4.7.1.1.4

NOTE: Parameter shall only be supplied if hi-targeted-to-uri of at least one History-Info hi-entry contains a cause-param URI parameter, as defined in IETF RFC 4458 [113].

The mapping described within table 4.7.1.1.1 can only appear if the communication has already undergone a Call Forwarding in the ISDN/PSTN and the 180 is the first provisional response sent in backward direction.

The IWU can indicate the call diversion in the mapping of 180 (Ringing) to CPG in fact if the response before was a 181 (Call Is Being Forwarded).

Table 4.7.1.1.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)

CPG

History-Info header field

If hi-targeted-to-uri of at least one History-Info hi-entry contains a cause-param URI parameter, as defined in IETF RFC 4458 [113].

Generic notification indicators

Call is diverting

Event indicator

ALERTING

History Header

See table 4.7.1.1.2

Redirection number (NOTE)

See table 4.7.1.1.2

Priv-value

See table 4.7.1.1.3

Redirection number restriction (NOTE)

See table 4.7.1.1.3

Priv-value

See table 4.7.1.1.4

Call diversion information Notification subscription options (NOTE)

See table 4.7.1.1.4

hi-targeted-to-uri; cause-param URI parameter, as defined in IETF RFC 4458 [14] of the last History-Info hi-entry containing such an a cause-param.

See table 4.7.1.1.4

Call diversion information Redirecting Reason (NOTE)

See table 4.7.1.1.4

NOTE: Parameter shall only be supplied if hi-targeted-to-uri of at least one History-Info hi-entry contains a cause-param URI parameter, as defined in IETF RFC 4458 [113].

The mapping in table 4.7.1.1. 9 appears when a 181 previously was mapped to an ACM. Therefore the statemachine of the MGCF knows that a CDIV is in Progress.

Table 4.7.1.1.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

History-Info Header

See table 4.7.1.1.2

Redirection number

See table 4.7.1.1.2

Priv-value

See table 4.7.1.1.3

Redirection number restriction

See table 4.7.1.1.3

4.7.1.1.1 Void
4.7.1.1.2 Call forwarding within the ISUP Network appeared

The following Scenario shows if a Call Forwarding appears in the ISUP/PSTN Network and the redirected Number is within the SIP Network. Table 4.7.1.1.2.1 should be seen as example.

For the mapping of 180 (Ringing) and 200 (OK) response OK to the regarding ISUP messages and parameters no additional procedures beyond the basic call procedures are needed.

To interwork the redirection number at the O-MGCF it can be needed to create placeholder History entries. Such a History entry has to provide a hi-target-to-uri with a placeholder value "unknown@unknown.invalid" a cause-param and a index as described within table 4.7.1.1.2.1.

Table 4.7.1.1.2.1: Mapping of IAM to SIP INVITE

ISUP Parameter or IE

Derived value of parameter field

SIP component

Value

IAM

INVITE

Redirecting number

History Header

hi-targeted-to-uri of the penultimate created hi-entry IF Redirection counter exceeds 1 ELSE no mapping

Nature of address indicator:

"national (significant) number"

hi-targeted-to-uri

Add CC (of the country where the MGCF is located) to Generic Number Address Signals then map to user portion of URI scheme used.

Addr-spec

"+" CC NDC SN mapped to user portion of URI scheme used

"international number"

Map complete Redirection number Address Signals to user portion of URI scheme used.

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

"+" CC NDC SN mapped to userinfo portion of URI scheme used

Redirecting number

APRI

Privacy Header that

corresponds to 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 Header that

corresponds to the penultimate hi-targeted-to-uri entry in the History-Info header

Priv-value

Call diverted

"none" (NOTE 4)

Call diverted, all redirection info presentation restricted

"History"

Redirection Information

Redirection counter

1

History Index

Number of diversions are sown due to the number of Index Entries

Index for original called Party Number = 1

Address Signals (CdPN)

Number = 1.1

2

Index for original called Party Number = 1

Index for Redirecting number

with Index = 1.1

Address Signals (CdPN)

Number = 1.1.1

N

Index for original called Party Number = 1

Placeholder History entry with Index = 1.1

Fill up

Index for Redirecting Number

with = 1+[(N-1)*".1"]

Index for Address Signals (CdPN)

= 1+N* ".1" (e.g. N=3  1.1.1.1)

Redirection Information

Redirecting Reason and

Original Redirection Reason

(NOTE 1)

hi-targeted-to-uri; cause-param URI parameter, as defined in IETF RFC 4458 [14] . The Redirecting Reason shall be mapped to the last hi-targeted-to-uri.

If the redirection counter is 2 or higher, the Original Redirection Reason shall be mapped to the second hi-targeted-to-uri.

If the redirection counter is 3 or higher, for each hi-targeted-to-uri following a placeholder History entry the value "404" shall be taken (NOTE 2)

Cause value

unknown

404

unconditional

302

User Busy

486

No reply

408

Deflection during alerting

487

Deflection immediate response

480

Mobile subscriber not reachable

503

Called Party Number

See Redirecting number

History Header see hi-targeted-to-uri

URI of the last hi-targeted-to-uri entry of History Header

Original Called Party Number

See Redirecting number

History Header see hi-targeted-to-uri

URI of first hi-targeted-to-urientry of History Header

Original Called Party Number

APRI

Privacy Header

Priv-value

"presentation restricted"

"history"

"presentation allowed"

"none"

NOTE 1: Original Redirection Reason contains only the "unknown" parameter.

NOTE 2: For all History entries except the first one a cause-param URI parameter as defined in RFC 4458 [14] has to be included.

NOTE 3: If the Redirecting Indicator has the value "Call diverted, all redirection info 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.

4.7.1.2 Interworking at the I-MGCF

Table 4.7.1.2.1: Mapping of SIP to ISUP messages

Message received from SIP

Message send to BICC/ISUP

INVITE

IAM

Table 4.7.1.2.2: Mapping of History-Info Header to ISUP Redirecting number

Source SIP header field and component

Source Component value

Redirecting number

Derived value of parameter field

In History-Info SIP header field, hi-targeted-to-uri in hi-entry before last hi-entry containing a cause-param URI parameter as defined in IETF RFC 4458 [14] (NOTE 1)

Redirecting number

Hi-target-to-uri

appropriate global number portion of the URI, assumed to be in form
"+" CC + NDC + SN

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
NDC + SN.

If NOA is "international number"

then set to CC + NDC + SN

Privacy Header , priv‑value component

In History-Info header field as specified 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 redirecting number is impossible, therefore no need to generate Redirecting number.

NOTE 2: It is possible that an entry of the In History-Info header field itself is marked as restricted or the whole History header.

Table 4.7.1.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 priv‑value of hi-entry before the last hi-entry containing a cause-param URI parameter as defined in IETF RFC 4458 [14] of the History Info header field.

"history" or “session” or “header”

for the Privacy header field or for the hi-targeted-to-uri entry

Redirecting indicator

Call diverted, all redirection info presentation restricted

Privacy header field and the privacy component of the hi-targeted-to-uri entry either absent

or

"none

Call diverted

Original redirection reason

Unknown

Cause-param value in the last hi-targeted-to-uri containing a cause-param URI parameter, as defined in IETF RFC 4458 [14]

cause-param value

Redirecting Reason

Redirecting Reason

404

Unknown/not available

302

Unconditional

486

User busy

408

No reply

480

Deflection immediate response

487

Deflection during alerting

503

Mobile subscriber not reachable

Hi-index

Redirection counter

number of History entries containing a cause-param with cause as listed in the cause-param row in this table

Table 4.7.1.2.4: Mapping of History-Info Header 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-target-to-uri of hi-entry preceding the 1st hi-targeted-to-uri containing a cause-param URI parameter, as defined in IETF RFC 4458 [14]; the

global number portion of the URI is assumed to be in form
"+" CC + NDC + SN (NOTE 2)

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
NDC + SN.

If NOA is "international number"

then set to CC + NDC + SN

priv‑value component

in History-Info header field of the History-Info header field entry as defined above in this table (Note 1)

"history" or “session” or “header”

APRI

"presentation restricted"

Privacy header field absent or "none"

"presentation allowed"

NOTE 1: It is possible that an entry of the History-Info header field itself is marked as restricted or the whole History-Info header.

NOTE 2: 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.

Table 4.7.1.2.5: Mapping of INVITE to IAM

INVITE

IAM

History Header

See table 4.7.1.2.2

Redirecting number

See table 4.7.1.2.2

History-Info Header

See table 4.7.1.2.3

Redirection Information

See table 4.7.1.2.3

cause-param in the last hi-targeted-to-uri containing a cause-param as defined in IETF RFC 4458 [14]cause-param

cause-param value

Redirection Information

Redirecting Reason

404

Unknown/not available

302

Unconditional

486

User busy

408

No reply

480

Deflection immediate response

487

Deflection during alerting

503

Mobile subscriber not reachable

History-Infoh eader field

See table 4.7.1.2.4

Original Called Number

See table 4.7.1.2.4

Table 4.7.1.2.6: Mapping of ISUP to SIP Massages

Message sent to SIP

Message Received from BICC/ISUP

181 (Being forwarded)

ACM no indication with Redirection number and call diversion information (CFU, CFB, CDi)

See table 4.7.1.2.8

180 (Ringing)

ACM indicating ringing, oBCi: Call diversion may occur (CFNR, CDa)

Basic call procedure as described within ES 283 027 [13]

181 (Being forwarded)

CPG indicating progress or subsequent diversion indicated in the CPG with Redirection number and call diversion information (CFNR, CDa)

See table 4.7.1.2.9

180 (Ringing)

CPG indicating ringing and Redirection number restriction parameter

See table 4.7.1.2.10

200 (OK)

ANM and Redirection number restriction parameter

See table 4.7.1.2.11

In the ISUP destination Exchange of the diverted-to user (see EN 300 356-15 [10]) only the Redirection Number Restriction parameter will be included into the ACM, CPG, ANM or CON message. Therefore only the mapping of this parameter is shown in the following table.

Table 4.7.1.2.7: 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"

"History"

"Presentation allowed" or absent AND any previous received notification subscription option was NOT "presentation not allowed" OR was NOT "presentation allowed without redirection number"

Privacy header field absent

or

"none"

A received CPG shall be mapped t a 180 (Ringing) if the CPC indicates a Alerting is due to the mapping rules defined within the basic call.

Table 4.7.1.2.8: Mapping of ACM  181 (Call Is Being Forwarded)

ISUP Parameter

Derived value of parameter field

SIP component

Value

Generic notification indicators

Call is diverting

Redirection number

History-Info Header with one hi-entry

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 then map to user portion of URI scheme used.

Addr-spec

"+" CC NDC SN mapped to user portion of URI scheme used

according to the rules of clause 4.5.2.6.4 item c

"international number"

Map complete Redirection number Address Signals to user portion of URI scheme used

according to the rules of clause 4.5.2.6.4 item c

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

"+" CC NDC SN mapped to userinfo portion of URI scheme used

Call diversion information

Redirecting Reason

IETF RFC 4458 [14] cause-param URI parameter hi-targeted-to-uri entry (NOTE)

cause-param value

Unknown/not available

404

Unconditional

302

User busy

486

No reply

408

Deflection immediate response

480

Deflection during alerting

487

Mobile subscriber not reachable

503

Notification subscription option

Privacy

Roles

unknown

Escaped Privacy value is set according to the rules of clause 4.5.2.6.4 item c

presentation not allowed

A 181 Being Forwarded shall not be sent

presentation allowed with redirection number

Escaped Privacy value is set according to the rules of clause 4.5.2.6.4 item c

presentation allowed without redirection number

Escaped Privacy value is set according to the rules of clause 4.5.2.6.4 item c

NOTE: Needs to be stored for a possible inclusion into subsequent messages.

Table 4.7.1.2.9: Mapping of CPG  181 (Call Is Being Forwarded)

ISUP Parameter

Derived value of parameter field

SIP component

Value

Event Indicator

Progress

Generic notification indicators

Call is diverting

Redirection number

History-Info Header

hi-targeted-to-uri:

Nature of address indicator

"national (significant) number"

hi-targeted-to-uri field with one hi-entry

Add CC (of the country where the MGCF is located) to Redirection number Address Signals then map to user portion of URI scheme used.

Addr-spec

"+" CC NDC SN mapped to user portion of URI scheme used

according to the rules of clause 4.5.2.6.4 item c

"international number"

hi-targeted-to-uri

Map complete Redirection number Address Signals to user portion of URI scheme used

according to the rules of clause 4.5.2.6.4 item c

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

"+" CC NDC SN mapped to userinfo portion of URI scheme used

Call diversion information

Redirecting Reason

IETF RFC 4458 [14] cause-param in the hi-targeted-to-uri (NOTE)

cause param value

Unknown/not available

404

Unconditional

302

User busy

486

No reply

408

Deflection immediate response

480

Deflection during alerting

487

Mobile subscriber not reachable

503

Notification subscription option

Privacy

Roles

unknown

Escaped Privacy value is set according to the rules of clause 4.5.2.6.4 item c

presentation not allowed

A 181 Being Forwarded shall not be sent

presentation allowed with redirection number

Escaped Privacy value is set according to the rules of clause 4.5.2.6.4 item c

presentation allowed without redirection number

Escaped Privacy value is set according to the rules of clause 4.5.2.6.4 item c

NOTE: Needs to be stored for a possible inclusion into subsequent messages.

Table 4.7.1.2.10: Mapping of CPG  180 (Ringing)

ISUP Parameter

Derived value of parameter field

SIP component

Value

Event Indicator

Alerting

Redirection number

History-Info Header with one hi-entry

See table 4.7.1.2.8

RFC 4458 [14] cause-param in the hi-targeted-to-uri

Value stored from a previous received ACM or CPG. See table 4.7.1.2.8 and 4.7.1.2.9.

Redirection number restriction

See table 4.7.1.2.7

Table 4.7.1.2.11: Mapping of ANM  200 OK (INVITE)

ISUP Parameter

Derived value of parameter field

SIP component

Value

Redirection number

History-Info Header with one hi-entry

See table 4.7.1.2.8

RFC 4458 [14] cause-param URI parameter in the hi-targeted-to-uri

cause value= as stored from a previous received the ACM or CPG. See tables 4.7.1.2.8 and 4.7.1.2.9.

Redirection number restriction

See table 4.7.1.2.7

4.7.2 Interworking with PSTN/ISDN Emulation

The Interworking with PSTN/ISDN Emulation is for further study.

4.7.3 Interworking with external IP networks

For SIP based networks the procedures used shall be compliant with ES 283 003 [2].

The interworking with non SIP networks is for further study.

4.8 Parameter values (timers)

4.8.1 No reply timer

No reply timer: Timer duration shall be a service provider option.

4.8.2 Void

4.8.3 CDIV Indication Timer

TCDIV_IND 60 sec – 00 sec.

The timer is started when the diverting user is registering to the communication system. Based on operator policy the user has the possibility to choose a certain timer value within the defined range.

4.9 Service Configuration for redirection services

4.9.1 Structure of the XML Document

Communication Diversion documents are subtrees of the simservs document specified in TS 183 023 [4]. As such, Communication Diversion documents use the XCAP application usage in TS 183 023 [4].

In addition to the considerations and constraints defined by the simservs document TS 183 023 [4], we define the additional constraints and considerations for the Communication Diversion subtree:

XML schema: Implementations in compliance with the present document shall implement the XML schema that minimally includes the XML Schema defined in clause 4.9.2 and the simservs XML schema specified in clause 6.3 of TS 183 023 [4].

Data semantics: The semantics of the communication diversion XML configuration document is specified in clause 4.9.1.

An instance of the simulation services configuration containing a communication diversion configuration document.

<?xml version="1.0" encoding="UTF-8"?>

<simservs

xmlns= http://uri.etsi.org/ngn/params/xml/simservs/xcapu

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:ocp="urn:oma:xml:xdm:common-policy">

<communication-diversion active="true">

rule set

</communication-diversion>

</simservs>

The communication diversion service contains a rule set that specifies how the communication diversion service shall react to external stimuli.

4.9.1.1 Communication Diversion Element

The communication diversion configuration contains a noReplyTimer element, a rule set, or a noReplyTimer element followed by a rule set. The rule set reuses the syntax as specified by the common policy draft (see RFC 4745 [18]).

<communication-diversion active="true">

<NoReplyTimer>NoReplyTimerValue</NoReplyTimer>

<cp:ruleset>

rule1

rule2

</cp:ruleset>

</communication-diversion>

In general the following procedure applies:

When the service processes a set of rules it shall start executing the first rule. If:

– the rule has no <conditions> element;

– the rule has an empty <conditions> element; or

– conditions are present and they all evaluate to true;

then the rule matches and the specified action shall be executed.

When the rule does not match the following rule shall be selected and the same procedure repeated, until a matching rule is found or the set of remaining rules is empty.

However not all rules can be matched at the same moment in the call. Some conditions imply that rules that carry them are checked at specific events in the call, for example the no-answer condition only holds when the called party does not answer after a while. In this case the same procedure shall apply as above with the modification that the set of rules to process contains only the rules applicable for that specific network event.

In clause 4.9.1.3 all allowed conditions are specified, normally rules are evaluated at communication setup time, for conditions where this is not the case this is explicitly indicated.

The shown "active" attribute is inherited from the simservType from TS 183 023 [4], its meaning is also specified in TS 183 023 [4].

4.9.1.1A NoReplyTimer

NoReplyTimer: An optional element that covers the time to elapse until the communication diversion shall perform, if the served user does not answer when alerted.

4.9.1.2 Communication Diversion Rules

The Communication Diversion service is configured with an ordered set of forwarding rules. The XML Schema reuses the rule syntax as specified by the common policy draft (see RFC 4745 [18]). The rules take the following form:

<cp:rule id="rule66">

<cp:conditions>

condition1

condition2

</cp:conditions>

<cp:actions>

<forward-to>

<target>

targetAddress1

</target>

<notify-caller>true</notify-caller>

</forward-to>

</cp:actions>

</cp:rule>

When the service processes a set of rules it shall start executing the first rule. If:

– the rule has no <conditions> element;

– the rule has an empty <conditions> element; or

– conditions are present and they all evaluate to true;

then the rule matches and the specified action is executed. When a rule matches remaining rules in the rule set shall be discarded. Applied to the fragment above this means that only if the expression (condition1 AND condition2) evaluates to true that then the rule66 matches and the forward-to action is executed.

When the rule does not match the following rule shall be selected and the same procedure repeated, until a matching rule is found or the set of remaining rules is empty.

The "id" attribute value of a rule shall uniquely identify the rule within a rule set. This can be used in XCAP usage to address one specific rule.

4.9.1.3 Communication Diversion Rule Conditions

The following conditions are allowed by the XML Schema for the communication diversion service:

busy: This condition evaluates to true when the called user is busy. In all other cases the condition evaluates to false. Rules with this condition are evaluated when a busy indication is received from the called party.

not-registered: This condition evaluates to true when the called user is not registered. In all other cases the condition evaluates to false.

presence-status: This condition evaluates to true when the called user’s current presence activity status is equal to the value set for this condition. In all other cases the condition evaluates to false.

cp:identity: This condition evaluates to true when the calling user’s identity matches with the value of the identity element. The interpretation of all the elements of this condition is described in OMA-TS-XDM-Core-V1_1 [20]. In all other cases the condition evaluates to false. The Identity shall be matched against the value taken from the P-Asserted-Identity header field, unless both the <identity> element value and the Contact header field value contain a "gr" parameter, then the <identity> element value shall be matched against the value taken from the Contact header field.

anonymous: This condition evaluates to true when the P-Asserted-Identity of the calling user is not provided or privacy restricted.

cp:sphere: Not applicable in the context of the Communication Diversion service.

cp:validity: Specifies a period. The condition evaluates to true when the current time is within the validity period expressed by the value of this condition. In all other cases the condition evaluates to false.

media: When the incoming call request for certain media, the forwarding rule can decide to forward the call for this specific media. This condition evaluates to true when the value of this condition matches the media field in one of the "m=" lines in the SDP (RFC 2327 [5]) offered in an INVITE (RFC 3261 [6]).

no-answer: This condition evaluates to true when the called user does not answer. In all other cases the condition evaluates to false. Rules with this condition are evaluated when a no-answer timeout is detected.

rule-deactivated: This condition always evaluates to false. This can be used to deactivate a rule, without loosing information. By removing this condition the rule can be activated again.

ocp:external-list: This condition evaluates to true when the calling users identity is contained in an external resource list to which the value of external-list refers. The exact interpretation of this element is specified in
OMA-TS-XDM-Core-V1_1 [20] (see bibliography).

ocp:other-identity: Not applicable in the context of communication diversion service.

not-reachable: This condition evaluates to true when there is a signalling channel outage during session setup to the served user’s UE and the served user is registered. In all other cases this condition evaluates to false.

NOTE: As described in RFC 4745 [18] the case of unconditional evaluates to be true in all cases where all other reasons are not applicable. A communication diversion is performed as soon as the served user is the called user. The indication of unconditional is the absence of any reason element in the ss:condition element.

The condition elements that are not taken from the common policy schema (see RFC 4745 [18]) or oma common policy schema (see OMA-TS-XDM-Core-V1_1 [20] in bibliography) are defined in the simservs document schema specified in 3GPP TS 183 023 [4].

4.9.1.4 Communication Diversion Rule Actions

The action supported by the communication service is forwarding of calls. For this the forward-to action has been defined. The forward-to action takes the following elements:

target: Specifies the address of the forwarding rule. It should be a SIP URI or SIPS (RFC 3261 [6]), TEL URL
(RFC 3966 [7]).

notify-caller: An optional element that can be used to disable the default behaviour that the caller is notified that the call is being forwarded (see subscription option "Originating user receives notification that his communication has been diverted (forwarded or deflected)" in table 4.3.1.1).

reveal-served-user-identity-to-caller: An optional element that can be used to disable the default behaviour that the caller, when notified that the call is being forwarded, receives the diverting party’s identity information (see subscription option "Served user allows the presentation of his/her URI to originating user in diversion notification" in table 4.3.1.1).

reveal-identity-to-caller: An optional element that can be used to disable the default behaviour that the caller, when notified that the call is being forwarded, receives some diverted-to party’s identity information (see subscription option "Served user allows the presentation of forwarded to URI to originating user in diversion notification" in table 4.3.1.1).

notify-served-user: An optional element that can be used to enable that the served user is indicated that calls are being forwarded. Default this is switched off (see subscription option "Served user receives notification that a communication has been forwarded" in table 4.3.1.1).

notify-served-user-on-outbound-call: An optional element that can be used to enable that the served user is notified that calls are being forwarded when he makes a call attempt. Default this is switched off (see subscription option "Served user receives reminder notification on outgoing communication that forwarding is currently activated" in table 4.3.1.1).

reveal-identity-to-target: An optional element that can be used to disable the default behaviour that the diverted-to party receives some identity information of the diverting party (see subscription option "Served user allows the presentation of his/her URI to diverted‑to user" in table 4.3.1.1).

4.9.2 XML Schema

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ss="http://uri.etsi.org/ngn/params/xml/simservs/xcap"

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:ocp="urn:oma:xml:xdm:common-policy"

targetNamespace="http://uri.etsi.org/ngn/params/xml/simservs/xcap"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<!– import common policy definitions –>

<xs:import namespace="urn:ietf:params:xml:ns:common-policy" schemaLocation="common-policy.xsd"/>

<!– import OMA common policy extensions –>

<xs:import namespace="urn:oma:xml:xdm:common-policy" schemaLocation="OMA-SUP-XSD_xdm_commonPolicy-V1_0_2-20070830-A.xsd"/>

<!– communication diversion specific extensions to IETF common policy conditions. The cp:conditionsType is expanded with the elements: ss:not-registered, ss:busy, ss:no-answer, ss:not-reachable, ss:media as optional elements –>

<!– communication diversion rule set based on the common policy rule set.–>

<xs:element name="communication-diversion" substitutionGroup="ss:absService">

<xs:annotation>

<xs:documentation>This is the communication diversion configuration document.</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:complexContent>

<xs:extension base="ss:simservType">

<xs:sequence>

<!– add service specific elements here–>

<xs:element ref="ss:NoReplyTimer" minOccurs="0"/>

<xs:element ref="cp:ruleset" minOccurs="0"/>

</xs:sequence>

</xs:extension>

<!– service specific attributes can be defined here –>

</xs:complexContent>

</xs:complexType>

</xs:element>

<!– communication diversion specific extensions to IETF common policy actions–>

<xs:element name="forward-to" type="ss:forward-to-type"/> <xs:simpleType name="reveal-URI-options-type">

<xs:restriction base="xs:string">

<xs:enumeration value="false"/>

<xs:enumeration value="not-reveal-GRUU"/>

<xs:enumeration value="true"/>

</xs:restriction>

</xs:simpleType>

<!– communication diversion specific type declarations –>

<xs:complexType name="forward-to-type">

<xs:sequence>

<xs:element name="target" type="xs:anyURI" minOccurs="1" maxOccurs="1"/>

<xs:element name="notify-caller" type="xs:boolean" default="true" minOccurs="0"/>

<xs:element name="reveal-identity-to-caller" type="ss:reveal-URI-options-type" default="true" minOccurs="0"/>

<xs:element name="reveal-served-user-identity-to-caller" type="ss:reveal-URI-options-type" default="true" minOccurs="0"/>

<xs:element name="notify-served-user" type="xs:boolean" default="false" minOccurs="0"/>

<xs:element name="notify-served-user-on-outbound-call" type="xs:boolean" default="false" minOccurs="0"/>

<xs:element name="reveal-identity-to-target" type="ss:reveal-URI-options-type" default="true" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:element name="NoReplyTimer">

<xs:simpleType>

<xs:restriction base="xs:positiveInteger">

<xs:minInclusive value="5"/>

<xs:maxInclusive value="180"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:schema>

4.10 Void

Annex A (informative):
Signalling Flows