MMTelCDIV

This is taken from IR.92 v9.0:

2.3.8 Communication Diversion

It then shows the following table (reformatted)

The following are in scope:

The following are out of scope:

Network configuration is stored in a JSLEE profile table named MMTelCDIVConfigProfileTable.

Individual configurations are entries in this table. The data is scoped on Sentinel Selection Key.

There are three elements of <operator-communication-diversion> received from the HSS that the CDIV feature may apply.

The other child elements of <operator-communication-diversion> are not read by the CDIV feature.

Triggered conditions and non-triggered conditions are part of CDIV rule and condition evaluation.

The request URI is set to the SIP URI or tel URI where the communication is being diverted to. This URI is normalized using the Normalization Component.

This comes from the <target> sub-element of the <forward-to> element in a CDIV rule’s actions:

It may or may not have a target parameter, and always has a cause parameter and MMTel service type parameter.

The MMTelCDIV feature will only ever re-target once. This is because MMTelCDIV is designed to execute on a public network. Private network derivations of this feature do not need to follow this rule.

As the feature re-targets once, it will insert one history-info element into one INVITE to represent a re-targeting.

The only case the feature inserts more than one element into history-info is in the case where no history-info or an empty history-info was received in the initial INVITE.

There is a case where the CDIV feature needs to be suppressed even though it may be active. This is needed on an MT call, when the SCC-AS diverts a call to a CS network as the MSC will have its own CDIV services. This means that, when the call is diverted to CS, the MMTel-AS does not divert any calls, and cancels any remaining no-reply timers. If the SCC-AS utilizes parallel-routing (i.e. forwards call to both PS and CS domain), the MMTel-AS will respond in the same way.

CDIV suppression is achieved by analysing the provisional responses for the given call. These responses contain the OC-Terminating-Domain custom header, which indicates what network the call is diverted to. Because the no-reply timers are typically set upon provisional responses (i.e. 18X responses), it is here that CDIV suppression is engaged/disengaged.

The presence of CDIV suppression is configurable. Setting the SuppressForCSTerminatingDomain attribute of the MmtelCDIVConfigProfile profile to true will enable the aforementioned CDIV suppression. Its default value is false, which leaves CDIV suppression disabled.

The CDIV feature can optionally use a default URI for re-targeting requests. The default URI is stored in the DefaultTargetURI field as a String. This default URI is applied when there is a re-targeting rule and no URI to forward to. The default re-targeting URI can be enabled using the DefaultTargetEnabled boolean variable.

When CDIV sees a 180 Ringing response, it will check to see if there are any rules relevant to Communication Forwarding on No Reply (CFNR). If there is at least one relevant rule, CDIV sets a CDIV No Reply Timer. The duration of the timer is:

The CDIV feature enforces a limit on the maximum number of times a call may be diverted, this limit is:

Before a call is diverted, this limit is checked against the number of diversions that have already occurred to ensure the new diversion can go ahead.

When the diversion limit is exceeded there are a number of things that can happen based on these Network Operator Data fields: NoRetargetURI, MaxDiversionAction, and MaxDiversionFixedDestination.

First, the feature will check the value of the next target URI against the list of URI’s in the NoRetargetURI field. This field contains a comma separated list of known URI’s that will never themselves trigger additional re-targeting. If the next target URI is equal to a URI on this list, after both are normalized using the Normalization Component, the feature considers it "safe" to allow the diversion to take place and the diversion limit will not be immediately enforced.

In the event that the next target URI is not in the NoRetargetURI list, the feature will execute its max diversion behaviour. There are two possible outcomes, based on the value of the MaxDiversionAction field.

If the MaxDiversionAction field is set to DELIVER_TO_FIXED_DESTINATION, but the MaxDiversionFixedDestination field does not contain a valid URI, then the feature will reject the INVITE as if MaxDiversionAction field had been set to REJECT.

The <communication-diversion> and <operator-communication-diversion> sections of the MMTel-Services XML document can contain diversion rules. A rule may be relevant for a diversion scenario (e.g CFB) and it may be applicable to a particular communication session (i.e its condition evaluates to true).

The CDIV feature:

Consider the following example, where there are two rules relevant for CFU.

The subscriber rule will cause audio calls to be forwarded to sip:bob@audio.somewhere.com. The operator rule will cause video calls to be forwarded to sip:bob@video.somewhere.com.

case #1 Alice makes a Video call to bob.

case #2 Alice makes an Audio call to bob.

It is possible to configure a list of NonProvisionableRetargetURIs in the feature configuration. Retargeting to these URIs is not permitted. When selecting the CDIV rule to apply, any rules whose target URI (after normalization) matches a URI on the NonProvisionableRetargetURIs list (after normalization), are ignored. Normalization is done using the Normalization Component.