4 Customized Alerting Tones (CAT)

24.1823GPPIP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT)Protocol specificationRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Introduction

The CAT service is an operator specific service by which an operator enables the subscriber to customize the media which is played to the calling party during alerting of the called party. The media can consist of favourable songs, multi-media clips or other customized alerting tones. CAT service should not negatively affect the conversation between calling and called parties.

4.2 Description

4.2.1 General description

The service user is able to subscribe to the CAT service, activate (or de-activate) the service, and update the settings, e.g., to change by configuration the active CAT media. The media can consist of favourable songs, multimedia clips or other customized alerting tones. The CAT subscriber is able to refine the CAT media selection behaviour with configured rules, e.g. time, calling party’s location, called party’s location, the identity of the calling and called party. The CAT service is able to select the appropriate CAT media according to the rules.

CAT is a terminating network service, but can also have an originating network functional component. That is, CAT media can be selected on behalf of the called subscriber for playback to the calling party, but the calling (IMS) subscriber can also subscribe to and activate the CAT service. In such a case, the CAT media selected by the calling party takes precedence for playback purposes over that selected by the called party. Whether or not the calling party’s CAT media has precedence over the called party’s selected CAT media is a matter of configuration in the calling party’s (originating) network.

The start of playback of the selected CAT media toward the calling party occurs some time following the initiation of a session, but prior to session answer. When the called party answers, playback of the CAT media either stops or continues to play during the conversation, depending on operator or user preferences. When the CAT media is playing, the calling party is able to stop (e.g. mute) it.

4.3 Operational requirements

4.3.1 Provision/withdrawal

4.3.1.1 CAT provision/withdrawal

The CAT service may be provided after prior arrangement with the service provider.

The CAT service may be withdrawn at the subscriber’s request or for administrative reasons.

4.3.1.2 Requirements on the originating network side

The originating network side may support the "early-session" extension as described in RFC 3959 [7].

NOTE 1: the CAT service implementing the early-session model needs the early-session extension to be supported by intermediate entities and the originating UE, else CAT media can not be provided to the caller.

The CAT service implementing the forking model and gateway model add no additional requirements on the originating network side.

For the early session model, if the CAT service is provided by the originating network, the CAT AS shall control an MRF as described in 3GPP TS 24.229 [4] that is acting on behalf of a calling subscriber who has activated CAT.

NOTE 2: The interworking between different models for CAT service is out of scope of this specification.

4.3.1.3 Requirements on the terminating network side

For the early session model, if the CAT service is provided by the terminating network, the CAT AS shall control an MRF as described in 3GPP TS 24.229 [4] that is acting on behalf of a called subscriber who has activated CAT.

NOTE: The interworking between different models for CAT service is out of scope of this specification.

4.4 Syntax requirements

There are no special SIP syntax requirements for the CAT service.

4.5 Signalling procedures

4.5.1 General

Configuration of supplementary services by the user should:

– take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [6]; or

– use SIP based user configuration as described in 3GPP TS 24.238 [3];

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

The details of the Ut interface based user configuration of CAT service are not specified in this version of the document.

4.5.2 Activation/deactivation

The CAT service is activated at provisioning and deactivated at withdrawal.

When a CAT service is activated a subscriber can specify which CAT a calling user should experience, or use the operator’s default setting.

After a subscriber has activated their CAT service a calling user experiences the CAT that was chosen by the subscriber.

4.5.3 Registration/erasure

The CAT service requires no registration. Erasure is not applicable.

4.5.4 Interrogation

For CAT, interrogation is not applicable.

4.5.5 Invocation and operation

4.5.5.1 Actions at the originating UE

4.5.5.1.1 General

The UE shall follow the procedures specified in 3GPP TS 24.229 [4] for session initiation and termination.

If the originating UE supports the early session mechanism then the UE shall make use of the procedures as specified in RFC 3959 [7].

The originating UE shall follow the actions at the originating UE in 3GPP TS 24.628 [14] with addition that the UE may play CAT media if an early media session is already established between the UE and the CAT AS, independently of receiving 180 (Ringing) response.

4.5.5.1.2 UE Actions for CAT copy

In order for the calling party to copy the media for the CAT service, the UE shall send a specific DTMF digit for CAT copy to the AS.

NOTE: The definition of which DTMFs are used is outside the scope of this specification and is dependant on the implementation of operator.

4.5.5.1.3 UE Actions for CAT stop

In order for the calling party to stop the media for the CAT service, the UE shall send a specific DTMF digit for CAT stop to the AS.

In order for the calling party to restart the media for the CAT service, the UE shall send a specific DTMF digit for CAT restart to the AS.

NOTE: The definition of which DTMFs are used is outside the scope of this specification and is dependant on the implementation of operator.

4.5.5.1.4 UE support of DTMF

In addition to indicating support of the telephone-event media subtype in the SDP offer, as defined in 3GPP TS 24.229 [4], the UE shall indicate support the SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [4], by including a Recv-Info header field with a "infoDtmf" value, as defined in IETF RFC 6086 [11].

NOTE: For telephone-event based DTMF transport, the DTMF digits are sent to the AS via an MRF.

The AS will indicate to the UE which DTMF transport mechanism to use for CAT control.

4.5.5.2 Actions at the AS serving the originating UE

4.5.5.2.1 General

The procedures specified in 3GPP TS 24.229 [4] for an AS acting as a routing B2BUA apply with additions described in the clauses below.

If the initial INVITE originated from the served user includes a Supported header field with "early-session" option-tag and the AS supports the "early-session" extension as described in RFC 3959 [7], the AS shall based on operator policy follow the procedures in clause 4.5.5.2.3 to provide CAT service. The procedures in clause 4.5.5.2.3 shall not be used if there are intermediaries in the network that do not understand the procedures.

The interactions between the AS and the MRF are described in 3GPP TS 24.229 [4].

4.5.5.2.2 AS Actions for forking model

The AS performing the forking model shall follow the procedure as specified in annex D in 3GPP TS 24.628 [14] with the additional procedures described in this clause.

If the terminating network provides early media (e.g. CAT service) towards the originating UE, the AS decides which CAT service should have priority based on the operator policy and the calling CAT service subscriber’s preferences. The procedures in this clause are applicable if the CAT service provided by the AS serving the originating UE has priority. If the CAT service provided by the AS serving the originating UE has no priority, the AS does not perform any CAT specific procedures. The AS can determine whether the terminating network provides early media if the AS receives a P-Early-Media header field with a "sendrecv" value or a "sendonly" value.

Upon receiving an initial SIP INVITE request destined to the terminating UE, the AS shall:

a) based on local policy remove the P-Early-Media header field, if present;

b) forward the initial SIP INVITE request to the terminating UE;

c) contact the MRF to request CAT resources; and

d) send a reliable SIP 183 (Session Progress) response to the originating UE. The AS shall include in the SIP 183 (Session Progress) provisional response:

– a P-Asserted-Identity header field containing the public user identity of the terminating UE unless privacy policy or restriction services prevent providing any public user identity of the terminating party;

– a To header field with a To tag locally generated by the AS;

– a P-Early-Media header field with a "sendrecv" value or a "sendonly" value;

– an SDP answer, based on information received from the MRF. The AS shall include an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value in the SDP answer; and

– if a Supported header field with an option tag " precondition" was received in the initial INVITE request and the AS decides to use the precondition mechanism , an indication in the SDP answer that the local preconditions are fulfilled.

If preconditions are used, the AS shall not instruct the MRF to start applicable media for the CAT service before the originating UE has indicated that preconditions are fulfilled. The point when the AS instructs the MRF to start applicable media for the CAT service is based on local policy. If the AS can provide CAT media for media lines not included in the original SDP offer and the UE in the Contact header field included media feature tags indicating support for the additional media, the AS shall send an UPDATE request towards the UE in the dialog with a negotiated SDP. The AS shall include in this UPDATE request:

a) an SDP offer based on an offer from the MRF with any new media lines placed after the existing media-lines. The AS shall include an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value in all the media lines;

b) a P-Early-Media header field with a "sendrecv" value or a "sendonly" value; and

c) if preconditions are used, an indication in the SDP offer that local preconditions are fulfilled.

NOTE 1: The AS can, based on local policy, wait to send the SIP 183 (Session Progress) response to the originating UE until the AS has received a SIP 180 (Ringing) provisional response from the terminating UE.

NOTE 2: The AS can, based on local policy, wait to instruct the MRF to start CAT media until the AS has received a SIP 180 (Ringing) provisional response from the terminating UE.

NOTE 3: The interaction between the AS and MRF is not specified for the CAT service but can use the Cr reference point as described in 3GPP TS 24.229 [4].

NOTE 4: If the AS acts as a Proxy and does not want to remain in the signalling path between the originating UE and the terminating UE, the AS does not need to add its own SIP-URI to the SIP Record-Route header field. If the AS acts as a B2BUA, the AS will always remain in the signalling path.

NOTE 5: The AS can, if it supports the P-Early-Media header field, based on local policy choose to not provide the CAT service to the originating UE if the initial INVITE request does not contain a P-Early-Media header field with a "supported" value.

Upon receiving a reliable provisional response from a terminating UE containing an SDP answer to the original SIP INVITE request, the AS:

a) may forward the provisional response to the originating UE reliably;

b) may, unless the provisional response contained a 199 response code, change the response code to SIP 183 (Session Progress) response;

c) shall insert a P-Early-Media header field, or modify an existing header field, with an "inactive" value before forwarding the provisional response;

d) shall, if the reliable provisional response is not forwarded to the originating UE, acknowledge the received provisional response by sending a SIP PRACK request as defined in RFC 3262 [5] to the terminating UE; and

e) shall, if the reliable provisional response contained an SDP answer and the provisional response is not forwarded to the originating UE, save the SDP answer contained in the reliable provisional response for that particular early dialog. If forking has occurred toward the terminating UE, the AS may save SDP answers from several different UEs;

If precondition procedures are used between the originating UE and the terminating UE, the AS shall forward reliable provisional responses which contain SDP to the originating UE, in order to allow the UEs to exchange additional SDP offers and answers associated with the precondition procedures.

Upon receiving an unreliable provisional response from the terminating UE to the original SIP INVITE request, the AS may forward the provisional response to the originating UE reliably. Unless the provisional response contained a 199 response code, the AS may change the response code to SIP 183 (Session Progress) response.

If the AS supports the P-Early-Media header field, the AS shall insert a P-Early-Media header field with an "inactive" value before forwarding the provisional response.

Upon receiving a SIP 200 (OK) response to the initial SIP INVITE request from the terminating UE indicating that the terminating UE has answered the call, the AS shall:

a) instruct the MRF to stop the media for the CAT service;

b) forward the SIP 200 (OK) response to the originating UE; and

c) if the AS has saved the SDP answer associated with the dialog confirmed by the SIP 200 (OK) response and if the AS has not forwarded the SDP answer to the originating UE, the AS shall include the saved SDP answer in the SIP 200 (OK) response.

Upon receiving a SIP 4xx, 5xx or 6xx response from a terminating UE the AS shall:

a) instruct the MRF to stop the media for the CAT service; and

b) forward the final response to the originating UE.

Upon receiving a SIP PRACK request including the P-Early-Media header field with an "inactive" value, the AS shall:

a) instruct the MRF to release the media resource reserved for the CAT service; and

b) forward the SIP PRACK request to the terminating UE.

4.5.5.2.3 AS Actions for early session model

The procedures in clause 4.5.5.3.3 shall apply with following additions:

– Upon receiving the first SIP 18x response containing an early-session SDP offer containing an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value to the initial INVITE request, the AS:

– decides which CAT service should have priority based on the operator policy and the calling CAT service subscriber’s preferences;

NOTE 1: Based on the operator policy, the AS can decide which CAT service should have priority when receiving the first SIP INVITE request or receiving the first SIP 18x response.

– if the CAT service provided by the AS serving the originating UE has no priority, then forward the SIP 18x response and do not provide CAT service;

– if the CAT service provided by the AS serving the originating UE has priority, then:

– send a reliable SIP 18x response to the originating UE. The SIP 18x response shall:

– include a P-Asserted-Identity header containing the public user identity of the served user unless privacy policy or restriction services prevent providing any public user identity of the terminating party;

– include a Require header with option tag "early-session";

– include the SDP content, with an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value, for CAT service provided by the AS serving the originating UE instead of the CAT service provided by the AS serving the terminating UE as early-session SDP offer and if preconditions are used, and CAT resource has been requested, indicate the local preconditions are fulfilled;

– if a SIP PRACK request from originating UE containing an SDP answer related to an early session is received, the AS shall forward the SIP PRACK request with a new SDP answer related to the early-session and set all port numbers of the media types to "0".

– Upon receiving the first SIP 18x response including the P-Early-Media header and an SDP answer containing an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value, the AS:

– decides which CAT service should have priority based on the operator policy and the calling CAT service subscriber’s preferences;

– if the CAT service provided by the AS serving the originating UE has no priority, then forward the SIP 18x response and do not provide CAT service;

– if the CAT service provided by the AS serving the originating UE has priority, then:

– send a reliable SIP 18x response to the originating UE. The SIP 18x response shall:

– include a Require header with option tag "early-session";

– include the SDP content, with an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value, for CAT as early-session SDP offer and if preconditions are used, and CAT resource has been requested, indicate the local preconditions are fulfilled;

– if a SIP PRACK request from originating UE containing an SDP answer related to an early session is received, the AS shall forward the SIP PRACK after removing the SDP answer related to the early session and including the P-Early-Media header field with an "inactive" value.

4.5.5.2.3A AS Actions for CAT Reject

This clause describes the procedures when the CAT AS has decided to reject CAT offered by the AS serving the terminating UE.

Upon receiving the first reliable SIP 18x response containing an early-session SDP offer, containing an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value, to the initial INVITE request, the AS shall decide whether CAT service provided by the AS serving the terminating UE needs to be rejected or not based on the operator policy and the calling CAT service subscribers preferences.

NOTE 1: Based on the operator policy, the AS can decide whether to reject the terminating CAT service when receiving the first SIP INVITE request or receiving the first SIP 18x response.

If the CAT service provided by the AS serving the terminating UE needs to be rejected, when the AS receives a reliable SIP 18x response, the AS shall:

– include a P-Asserted-Identity header field containing the public user identity of the terminating user unless privacy policy or restriction services prevent providing any public user identity of the terminating party;

– if present, remove the early-session SDP offer from the response;

– forward the SIP 18x response to the originating UE; and

– when a SIP PRACK request from originating UE is received, if the SIP 18x response contained an early-session SDP offer, ,the AS shall insert an early-session SDP answer with all media port numbers set to "0" before forwarding the SIP PRACK request.

Upon receiving the first SIP 18x response including the P-Early-Media header field and an SDP answer containing an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value, the AS shall decide whether CAT service provided by the AS serving the terminating UE needs to be rejected or not based on the operator policy and the calling CAT service subscriber’s preferences;

NOTE 2: Based on the operator policy, the AS can decide whether to reject the terminating CAT service when receiving the first SIP INVITE request or receiving the first SIP 18x response.

If the CAT service provided by the AS serving the terminating UE needs to be rejected, when the AS receives a SIP 18x response, the AS shall:

– if the AS supports the P-Early-Media header field, the AS shall insert a P-Early-Media header field, or modify an existing header field, with an "inactive" value before forwarding the provisional response;

– remove the SDP a=content media-level attribute "g.3gpp.cat" value;

– forward the SIP 18x response to the originating UE; and

– when a SIP PRACK request from originating UE is received, the AS shall forward the SIP PRACK including the P-Early-Media header field with an "inactive" value.

4.5.5.2.4 AS Actions for CAT stop

Upon receipt of specific DTMF digit for CAT stop, the AS instructs the MRF to stop the media for the CAT service.

Upon receipt of specific DTMF digit for CAT restart, the AS instructs the MRF to restart the media for the CAT service.

4.5.5.2.5 AS support of DTMF

If the UE has indicated support of both the "telephone-event" media subtype and the SIP INFO mechanism for DTMF transport, the AS shall based on operator policy choose which DTMF transport mechanism to use for CAT control between the UE and the AS.

If the AS wants to use the SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [4], the AS shall indicate support of the mechanism in a reliable response sent to the UE by including a Recv-Info header field with a "infoDtmf" value, as defined in IETF RFC 6086 [11].

If the AS wants to use the "telephone-event" media subtype for DTMF transport, the AS shall include the "telephone-event" in the SDP for CAT media, sent to the UE.

NOTE: The usage of the "telephone-event" media subtype for CAT control requires that intermediates allow the telephone-event packages to traverse from the UE to the AS during the early dialog.

For the remainder of this clause, when the term "receipt of DTMF digit" is used, it means either the detection of a DTMF digit by the MRF, which is then passed to the AS over the Cr interface, or the receipt of an INFO request containing the appropriate INFO package, as negotiated above.

4.5.5.2.6 AS Actions for Gateway model

The AS performing the Gateway model shall follow the procedure as specified in RFC 3960 [8] and annex G in 3GPP TS 24.628 [14] with the additional procedures described in this clause.

Upon receiving an initial INVITE request, before forwarding the initial INVITE request towards the terminating UE, the AS shall:

a) store the SDP offer sent from the originating side if the AS is going to update media with both originating side and terminating side when the 200 (OK) response to the initial INIVTE request is received;

b) if required by local policy, remove the P-Early-Media header field, if present; and

c) contact the MRF to request CAT resource.

When the video media feature tag is not included in the Contact header field of the initial INVITE request towards the terminating UE and there is no video description in the SDP offer included in the initial INVITE request, the AS shall not request video CAT resource from MRF, and shall not apply video CAT media to the originating UE.

Editor’s note: [TEI15, CR0096] the mechanism and procedure to support the selection of the media type of early media by end users is FFS.

NOTE: If playing customized media before alerting is allowed based on operator’s policy, upon forwarding the initial INVITE request to the terminating UE, the AS can play customized media before alerting by following the procedure as specified in annex G in 3GPP TS 24.628 [14]. When to stop the customized media depends on operator’s policy.

Upon receiving an SIP 180 (Ringing) response or SIP 183 (Session Progress) response to the initial SIP INVITE request sent to the terminating UE, before forwarding the response towards the originating UE, the AS shall:

a) if the SIP 180 (Ringing) response or the SIP 183 (Session Progress) response to the initial SIP INVITE request includes an SDP answer, store the SDP answer received from the terminating UE;

b) if the AS has not sent an SDP answer:

1) generate an SDP answer in the provisional response which is sent to the originating user, either:

i) based on the SDP answer as received from the terminating UE, if:

– the originating UE indicated support for the precondition mechanism by including the "precondition" option tag in the Supported header field in the initial INVITE request and the terminating UE applied the precondition mechanism to the session by including "precondition" option tag in the Require header field in the 18x response sent to the originating UE as described in RFC 3312 [17], and the resources required between the originating UE and the terminating UE are more than the resources required between originating UE and MRF associated with the AS for CAT; or

– the media types required between originating UE and MRF associated with the AS for CAT are different from the media types required between the originating UE and the terminating UE; or

ii) based on the information received from the MRF associated with AS for CAT, for all other cases;

2) include an SDP content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value in the generated SDP answer; and

3) remove the received P-Early-Media header field if present, and include a P-Early-Media header field with a "sendrecv" value or a "sendonly" value; and

c) if the AS has sent an SDP answer in a previous reliable provisional response to the initial SIP INVITE request, the AS shall not generate an SDP answer in the provisional response which is sent to the originating user.

NOTE: The procedures for handling multiple early dialogs, due to forking, is not specified in the current release of this specification.

If the originating UE indicated support for the precondition mechanism and the precondition mechanism was applied to the session, the AS shall not instruct the MRF to start applicable media for the CAT service before the originating UE has indicated that preconditions are fulfilled. The point when the AS instruct the MRF to start applicable media for the CAT service is based on local policy.

If the originating UE indicated support for the precondition mechanism and local resources were indicated not available in the initial INVITE request, and if the precondition mechanism was applied to the session, after forwarding an UPDATE request from the originating UE to the terminating UE which indicates that resources at the originating UE are available, upon receiving an SIP 200 (OK) response for the UPDATE request from the terminating UE, the AS shall:

a) store the SDP of the terminating UE; and

b) forward the SDP of the terminating UE to the originating UE.

Upon receiving the first 18x response without applying the precondition mechnism or a 180 (Ringing) response to the initial INVITE request from the terminating UE used to indicate that resources are available on the terminating UE and user is being alerted,

a) if the originating UE indicated support for the precondition mechanism and

1) if the precondition mechanism was applied to the session, the AS shall

i) send an UPDATE request with an SDP offer based on the SDP of CAT to the originating UE, the media types required in the SDP offer can include additional media types compared to the SDP offer initiated by the originating UE in the previous INVITE request, and

ii) use the precondition mechanism in the UPDATE request as specified in RFC 3312 [17], and not instruct the MRF to start applicable media for the CAT service before the originating UE has indicated that preconditions are fulfilled in the 200 (OK) response to the UPDATE request or subsequent UPDATE request; or

2) if the precondition mechanism was not applied to the session, when the media types required in the SDP of the CAT and the previous SDP offer in INVITE request are different,

i) the AS shall send an UPDATE request with an SDP offer based on the SDP of the CAT to the originating UE; and

ii) the AS may based on local policy use the precondition mechanism in the UPDATE request as specified in RFC 3312 [17], if the precondition mechanism is used in the UPDATE request, the AS shall not instruct the MRF to start applicable media for the CAT service before the originating UE has indicated that preconditions are fulfilled in the 200 (OK) response to the UPDATE request or subsequent UPDATE request; or

b) if the originating UE did not indicate support for the precondition mechanism, and if the media types required in the SDP of the CAT and the previous SDP offer in the initial INVITE request are different, the AS shall send an UPDATE request to the originating UE with an SDP offer based on the SDP of the CAT.

If UPDATE request containing an SDP offer from terminating side is received when a 180 (Ringing) response has been sent and a 200 (OK) response to the initial INVITE has not been sent yet, the AS shall:

a) not forward the UPDATE request to the originating side;

b) store the SDP offer contained in the UPDATE request, and if SDP answer or SDP offer from terminating side has been stored previously, the AS shall replace it with the new received SDP offer; and

c) respond to the UPDATE request with a 200 (OK) response and generate an SDP answer based on the SDP offer previously sent from the originating side.

Upon receiving an SIP 200 (OK) (INVITE) from terminating UE, if it is not allowed to continue playing video CAT by operator or user settings, or if video CAT media has not been played during the called party alerting, the AS shall instruct the MRF to stop the media for the CAT service and either:

a) if the AS is going to update media only with the originating side, generate an UPDATE request as specified in RFC 3311 [13] to update the media with the originating UE using either:

1) if the AS has previously stored the SDP answer or SDP offer sent from the terminating side, the SDP answer of the terminating UE as previously stored; or

2) if the AS has not previously stored SDP answer or SDP offer sent from the terminating side, the SDP answer received in the immediate 200 (OK) response to the SIP INVITE request; or

b) if the AS is going to update media with both originating side and terminating side:

1) send an offerless re-INVITE request to the terminating side;

2) upon receiving a SIP response to the re-INVITE request containing an SDP offer from the terminating side, generate an UPDATE request as specified in RFC 3311 [13] to send an SDP offer to the originating UE. The SDP offer shall only contain the media components which appeared both in the SDP offer contained in the SIP response to the re-INVITE request and the previously stored SDP offer in the initial INVITE, and set the port number of the corresponding m-line to zero if it has been set to zero during previous SDP negotiation; and

3) upon receiving a 200 (OK) response to the UPDATE request from the originating side, generate an SDP answer to the terminating side, included in the ACK request associated with the re-INVITE request. The SDP answer shall be based on the SDP answer contained in the 200 (OK) response to the UPDATE request, and for the media components which not appear in the SDP answer in the 200 (OK) response, set the port number of the corresponding m-line to zero.

If video CAT has been played during the called party alerting, and if it is allowed to continue playing video CAT by operator and user settings during converstion, upon receiving an SIP 200 (OK) (INVITE) from terminating UE, the AS shall perform either above bullet a) or bullet b) in the paragraph above related to the reception of 200 (OK) on INVITE with additions described below:

a) before using the SDP answer received from terminating UE to update media with originating UE by UPDATE request, the AS shall:

1) if the SDP answer only includes audio components, which means the conversation is going to be audio conversation, insert video components into this SDP answer based on the CAT information previously received from MRF, the video components shall include:

i) a media-level attribute "c=", as specified in RFC 4566 [15], with a value of the corresponding IP address for CAT media;

ii) a media-level attribute with a "g.3gpp.cat" value; and

iii) an "a=sendonly" attribute.

2) if the SDP answer includes video components but with zero port number or with an "a=inactive" attribute, which also means the conversation is going to be audio conversation, replace the existed video components with new video components based on the CAT information previously received from MRF, the new video media components shall include:

i) a media-level attribute "c=", as specified in RFC 4566 [15], with a value of the corresponding IP address for CAT media;

ii) a media-level attribute with a "g.3gpp.cat" value; and

iii) an "a=sendonly" attribute.

3) if the SDP answer includes video descriptions with port number greater than zero and without an "a=inactive" attribute, instruct the MRF to stop to play CAT media.

b) upon receiving a 200 (OK) response associated with the UPDATE request mentioned in the first sentence of bullet a) from the originating side:

1) if the AS is going to forward the SDP answer contained in this 200 (OK) response to terminating UE, before forwarding the SDP answer to the terminating UE, the AS shall exclude CAT related media descriptions from the SDP answer; and

2) if the SDP answer in this 200 (OK) response includes the video components of video CAT, after the media update in bullet a) in the paragraph above related to continue playing video CAT is finished, the AS shall instruct the MRF to stop the audio stream of video CAT.

When the AS sends a 200 (OK) response to the initial SIP INVITE request, if the AS has sent an SDP answer in a reliable provisional response to the initial SIP INVITE request, the AS shall not include any SDP in the 200 (OK) response to the initial SIP INVITE request.

4.5.5.3 Actions at the AS serving the terminating UE

4.5.5.3.1 General

The procedures specified in 3GPP TS 24.229 [4] for an AS acting as a routing B2BUA apply with additions described in the clauses below.

If the initial INVITE destined to served user includes a Supported header field with "early-session" option-tag and the AS supports the "early-session" extension as described in RFC 3959 [7], the AS shall based on operator policy follow the procedures in clause 4.5.5.3.3 to provide CAT service. The procedures in clause 4.5.5.3.3 shall not be used if there are intermediaries in the network that do not understand the procedures.

Depending on the operator policy, it shall also be possible for the AS to perform the actions specifed as Gateway model in RFC 3960 [8].

The AS shall follow procedures specified in clause 4.6 for any services where interaction shall be considered.

4.5.5.3.2 AS actions for forking model

The AS performing the forking model shall follow the procedure as specified in annex D in 3GPP TS 24.628 [14] with the additional procedures described in this clause.

Upon receiving an initial SIP INVITE request destined to the served user, the AS shall:

a) based on local policy remove the P-Early-Media header field, if present;

b) forward the initial SIP INVITE request to the served user;

c) contact the MRF to request CAT resources; and

d) send a reliable SIP 183 (Session Progress) response to the originating UE. The SIP 183 (Session Progress) provisional response shall:

– include a P-Asserted-Identity header field containing the public user identity of the served user unless privacy policy or restriction services prevent providing any public user identity of the terminating party;

– include a To header field with a To tag locally generated by the AS;

– include a P-Early-Media header field with a "sendrecv" value or a "sendonly" value;

– include an SDP answer, based on information received from the MRF. The AS shall include an SDP a=content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value in the SDP answer; and

– if a Supported header field with an option tag "precondition"was received in the initial INVITE request and the AS decides to use the precondition mechanism , indicate in the SDP answer that the local preconditions are fulfilled.

b) a P-Early-Media header field with a "sendrecv" value or a "sendonly" value; and

c) if preconditions are used, an indication in the SDP offer that local preconditions are fulfilled.

NOTE 2: The AS can, based on local policy, wait to instruct the MRF to start CAT media until the AS has received a SIP 180 (Ringing) provisional response from the served UE.

NOTE 3: The interaction between the AS and MRF is not specified for the CAT service but can use the Cr reference point as described in 3GPP TS 24.229 [4].

Upon receiving a reliable provisional response from a served UE containing an SDP answer to the original SIP INVITE request, the AS:

– may forward the provisional response to the originating UE reliably and, unless the provisional response contained a 199 response code, after changing the Status-Line to SIP 183 (Session Progress) response;

– shall insert a P-Early-Media header field, or modify an existing header field, with an "inactive" value before forwarding the provisional response;

– shall, if the reliable provisional response is not forwarded to the originating UE, acknowledge the received provisional response by sending a SIP PRACK request as defined in RFC 3262 [5] to the served UE; and

– shall, if the reliable provisional response contained an SDP answer and the provisional response is not forwarded to the originating UE, save the SDP answer contained in the reliable provisional response for that particular early dialog. If forking has occurred toward the served user, the AS may save SDP answers from several different UEs;

If precondition procedures are used between the originating UE and the served UE, the AS shall forward reliable provisional responses which contain SDP to the originating UE, in order to allow the UEs to exchange additional SDP offers and answers associated with the precondition procedures.

Upon receiving an unreliable provisional response from a served UE to the original SIP INVITE request, the AS may forward the provisional response to the originating UE and, unless the provisional response contained a 199 response code, after changing the Status-Line to SIP 183 (Session Progress) response.

If the AS supports the P-Early-Media header field, the AS shall insert a P-Early-Media header field with an "inactive" value before forwarding the provisional response.

Upon receiving a SIP 200 (OK) response to the initial SIP INVITE request from a served UE indicating that the served user has answered the call, the AS shall:

– instruct the MRF to stop the media for the CAT service;

– forward the SIP 200 (OK) response to the originating UE; and

– if the AS has saved the SDP answer associated with the dialog confirmed by the SIP 200 (OK) response and if the AS has not forwarded the SDP answer to the originating UE, the AS shall include the saved SDP answer in the SIP 200 (OK) response.

Upon receiving a SIP 4xx, 5xx or 6xx response from a served UE the AS shall:

– instruct the MRF to stop the media for the CAT service; and

– forward the final response to the originating UE.

Upon receiving a SIP PRACK request including the P-Early-Media header field with an "inactive" value, the AS shall:

– instruct the MRF to release the media resource reserved for the CAT service; and

– forward the SIP PRACK request to the served UE.

4.5.5.3.3 AS Actions for early session model

Upon receiving an initial INVITE request destined to the served user including a Supported header with "early-session" tag, as described in RFC 3959 [7], the AS:

– may contact the MRF to request CAT resource if session SDP preconditions are not used, or local preconditions are fulfilled;

– if required by local policy, remove the P-Early-Media header field, if present; and

– shall forward the initial INVITE request to the served user.

Upon receiving the first SIP 18x response to the initial INVITE request, the AS shall:

– if session SDP preconditions are not used in the initial INVITE request, or local preconditions in the initial INVITE request are fulfilled, then contact the MRF to request CAT resource if it has not been requested;

– send a reliable SIP 18x response to the originating UE. The SIP 18x response shall:

– include a Require header with option tag "early-session";

Upon receiving additional SIP 18x response to the initial INVITE request, the AS shall forward it to the originating UE.

Upon receiving a SIP request containing an early-session SDP offer that indicates the local preconditions are fulfilled, the AS shall:

– contact the MRF to request CAT resource;

– generate an early-session SDP answer based on the information from the MRF and, if preconditions are used, indicate that the local preconditions are fulfilled; and

– after receiving a SIP 200 (OK) response to the request, include the early-session SDP answer in the SIP 200 (OK) response, and forwards it to the originator.

If preconditions are used, the AS should not instruct the MRF to start applicable media for the CAT service before the originating UE indicates that early-session SDP local preconditions are fulfilled. Wheter to start applicable media for the CAT service before or after receiving the SIP 180 (Ringing) response from the served UE is based on local policy.

If a SIP message from served UE containing an SDP offer related to an early session is received, the AS shall send an SDP answer to the SDP offer related to the early-session sent by the served UE and set all port numbers of the media types to "0".

Upon receiving a SIP 200 (OK) response form the served UE to the initial INVITE request, the AS shall instruct the MRF to stop media for the CAT service and forward the SIP 200 (OK) response to the originating UE.

NOTE 1: The interaction between the AS and MRF is not specified for the CAT service but can use the Cr reference point as described in 3GPP TS 24.229 [4].

Upon receiving a SIP 4xx, 5xx or 6xx response from a served UE the AS shall:

– instruct the MRF to stop the media for the CAT service; and

– forward the final response to the originating UE.

4.5.5.3.4 AS Actions for CAT copy

Upon receipt of the specific DTMF digit, the AS copies the media for the called party’s CAT service.

NOTE: How the AS copies the called party’s CAT is out of the scope of this document.

4.5.5.3.5 AS Actions for CAT stop

Upon receipt of the specific DTMF digit for CAT stop, the AS instructs the MRF to stop the media for the CAT service.

Upon receipt of the specific DTMF digit for CAT restart, the AS instructs the MRF to restart the media for the CAT service.

4.5.5.3.6 AS support of DTMF

If the AS wants to use the "telephone-event" media subtype for DTMF transport, the AS shall include the "telephone-event" in the SDP for CAT media, sent to the UE.

NOTE: The usage of the "telephone-event" media subtype for CAT control requires that intermediates allow the telephone-event packages to traverse from the UE to the AS during the early dialog.

4.5.5.3.7 AS Actions for Gateway model

The AS performing the Gateway model shall follow the procedure as specified in RFC 3960 [8] and annex G in 3GPP TS 24.628 [14] with the additional procedures described in this clause.

Upon receiving an initial INVITE request, before forwarding the initial INVITE request towards the terminating UE, the AS shall:

b) if required by local policy, remove the P-Early-Media header field, if present; and

c) contact the MRF to request CAT resource.

Editor’s note: [TEI15, CR0096] the mechanism and procedure to support the selection of the media type of early media by end users is FFS.

a) if the SIP 180 (Ringing) response or the SIP 183 (Session Progress) response to the initial SIP INVITE request includes an SDP answer, store the SDP answer received from the terminating UE;

b) if the AS has not sent an SDP answer:

1) generate an SDP answer in the provisional response which is sent to the originating user, either:

i) based on the SDP answer as received from the terminating UE, if:

– the originating UE indicated support for the precondition mechanism by including the"precondition" option tag in the Supported header field in the initial INVITE request and the terminating UE applied the precondition mechanism to the session by including "precondition" option tag in the Require header field in the 18x response sent to the originating UE as described in RFC 3312 [17], and the resources required between the originating UE and the terminating UE are more than the resources required between originating UE and MRF associated with the AS for CAT; or

– the media types required between originating UE and MRF associated with the AS for CAT are different from the media types required between the originating UE and the terminating UE; or

ii) based on the information received from the MRF associated with AS for CAT, for all other cases;

2) include an SDP content media-level attribute, as specified in RFC 4796 [12], with a "g.3gpp.cat" value in the generated SDP answer; and

3) remove the received P-Early-Media header field if present, and include a P-Early-Media header field with a "sendrecv" value or a "sendonly" value; and

NOTE: The procedures for handling multiple early dialogs, due to forking, is not specified in the current release of this specification.

If the originating UE indicated support for the precondition mechanism and local resources were indicated not available in the initial INVITE request, and if the precondition mechanism was applied to the session after forwarding an UPDATE request from the originating UE to the terminating UE which indicates that resources at the originating UE are available, upon receiving an SIP 200 (OK) response for the UPDATE request from the terminating UE, the AS shall:

a) store the SDP of the terminating UE; and

b) forward the SDP of the terminating UE to the originating UE.

a) if the originating UE indicated support for the precondition mechanism and

1) if the precondition mechanism was applied to the session, the AS shall

2) if the precondition mechanism was not applied to the session, when the media types required in the SDP of the CAT and the previous SDP offer in INVITE request are different,

i) the AS shall send an UPDATE request with an SDP offer based on the SDP of the CAT to the originating UE; and

a) not forward the UPDATE request to the originating side; and

b) store the SDP offer contained in the UPDATE request, and if SDP answer or SDP offer from terminating side has been stored previously, the AS shall replace it with the new received SDP offer; and

c) respond to the UPDATE request with a 200 (OK) response and generate an SDP answer based on the SDP offer previously sent from the originating side.

a) if the AS is going to update media only with the originating side, generate an UPDATE request as specified in RFC 3311 [13] to update the media with the originating UE using either:

1) if the AS has previously stored the SDP answer or SDP offer sent from the terminating side, the SDP answer of the terminating UE as previously stored; or

2) if the AS has not previously stored SDP answer or SDP offer sent from the terminating side, the SDP answer received in the immediate 200 (OK) response to the SIP INVITE request.or

b) if the AS is going to update media with both originating side and terminating side:

1) send an offerless re-INVITE request to the terminating side;

a) before using the SDP answer received from terminating UE to update media with originating UE by UPDATE request, the AS shall:

i) a media-level attribute "c=", as specified in RFC 4566 [15], with a value of the corresponding IP address for CAT media;

ii) a media-level attribute with a "g.3gpp.cat" value; and

iii) an "a=sendonly" attribute.

i) a media-level attribute "c=", as specified in RFC 4566 [15], with a value of the corresponding IP address of CAT media;

ii) a media-level attribute with a "g.3gpp.cat" value; and

iii) an "a=sendonly" attribute.

3) if the SDP answer includes video descriptions with port number greater than zero and without an "a=inactive" attribute, which means the conversation is going to be video conversation, instruct the MRF to stop to play CAT media.

b) upon receiving a 200 (OK) response associated with the UPDATE request mentioned in the first sentence of bullet a) from the originating side:

4.6 Interaction with other services

4.6.1 Communication session Hold (HOLD)

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

4.6.2 Termination Identification Presentation (TIP)

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

4.6.3 Termination Identification Restriction (TIR)

The TIR service takes precedence over the CAT service subscribed by the called party. If the TIR service prevents CAT media from being played to the calling party, then the AS providing CAT service shall not apply the CAT service to the session.

4.6.4 Originating Identification Presentation (OIP)

The order of the services in the filter criteria list should be configured so that CAT service appears before OIP service, in order for the CAT service to provide CAT media associated with the calling party’s identity (i.e., the called party may play one type of CAT media to a particular caller and other types of CAT media to other callers depending on the called party’s subscription).

NOTE: If the called party does not subscribe to OIP service, the AS providing OIP service will remove P-Asserted-Identity according to 3GPP TS 24.607 [10], and it will not be possible to provide CAT service based on calling party’s identity if the OIP service was applied prior to CAT service in this given case. Unless the network operator can assure that such scenario do not occur based on their service configuration, as CAT service cannot be aware of whether OIP service is subscribed by the user, and OIP service cannot be aware of how CAT service is to be performed, CAT service will always need to be performed prior to OIP service.

4.6.5 Originating Identification Restriction (OIR)

The OIR service takes precedence over the CAT service subscribed by the called party. The behaviour of the CAT service is dependent on whether if the called party has a CAT service associated with the calling party’s identity (i.e., the called party may play one type of CAT media to a particular caller and other types of CAT media to other callers depending on the called party’s subscription) and whether OIR service is requested.

The AS providing CAT service shall:

1) if the called party has CAT service associated with that specific calling party’s identity, the AS shall:

– inspect the priv-value set in the Privacy header field in the request; and

– if the Privacy header field is set to either "id", "header", or "user", i.e. OIR service is requested, then the AS shall not apply CAT service to the session.

2) in all other cases (i.e. except for the case if the called party has CAT service associated with that specific calling party’s identity, and OIR service is requested), the AS shall process CAT service based on the called party’s subscription.

NOTE: OIR service itself is independent from CAT service, as the identities that need to be restricted towards the terminating user will be handled, i.e. restricted, appropriately by other functional entities as specified in 3GPP TS 24.229 [4], e.g. at the boundary of trust domain which may be the terminating P-CSCF.

4.6.6 Conference (CONF)

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

4.6.7 Communication DIVersion services (CDIV)

4.6.7.1 General

If the diverting party has both CAT service and CDIV active, and the diverted-to party has CAT service active, based on operator policy, either:

1) the CAT service of the diverted-to party shall be applied to the session by the AS providing the CAT service of diverted-to party, except in the case of CFNR. The interaction of CAT service with CFNR is described in clause 4.6.7.2; or

2) the CAT service of the diverting party shall be applied to the session by the AS providing CAT service for the diverting party, without the CAT service for the diverted-to party applied to the session.

NOTE 1: the above network operator option can be deployed in cases where diversion of the call is hidden from the calling party.

If the diverting party has both CAT service and CDIV active, and the diverted-to party does not have an active service, based on operator policy, either:

1) no CAT service shall be applied to the session when CDIV is invoked; or

NOTE 2: the above network operator option can be deployed in cases where diversion of the call is hidden from the calling party.

4.6.7.2 CFNR

If the diverting party has both CAT service and CFNR active, and the diverted-to party has CAT service active, based on operator policy, either:

1) the CAT service of the diverting party shall be applied to the session by the AS providing CAT service for the diverting party until the CFNR timer expires. Upon the CFNR timer expiring, the AS providing CAT service for the diverting party shall stop applying the CAT for the diverting user and the AS providing CAT service for the diverted-to party shall apply the CAT service of the diverted-to party; or

NOTE 1: the above network operator option can be deployed in cases where diversion of the call is hidden from the calling party.

If the diverting party has CAT service and CFNR active, and the diverted-to party does not have an active service, based on operator policy, either:

1) the CAT service of the diverting party shall be applied to the session by the AS providing CAT service for the diverting party until the CFNR timer expires; or

NOTE 2: the above network operator option can be deployed in cases where diversion of the call is hidden from the calling party.

4.6.8 Message Waiting Indication (MWI)

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

4.6.9 Communication Barring (CB)

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

4.6.10 Explicit Call Transfer (ECT)

If the transfer target has CAT service active, the AS providing CAT service shall apply the transfer target’s CAT in the case of blind transfer. The AS providing CAT service shall not apply the transfer target’s CAT in the case of consultative transfer while the call is transferring to the transfer target.

The CAT service of the transferor shall not be applied when ECT is invoked.

4.6.11 Communication Wait

In the case that the called party has Communication Waiting and CAT services active, the AS providing the CAT service for the called party shall apply the called party’s CAT to the session if the called party is considered ‘approaching network determined user busy’ as a network operator option. Alternatively, the AS providing the call party’s CAT shall not apply the CAT service and the Communication Waiting alert shall be applied.

4.6.12 Completion of Communications to Busy Subscriber

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

4.6.13 Customized Ringing Signal (CRS)

In following scenarios,

– both CAT and CRS is provided using early session model, calling party has CRS service and called party has CAT service;

– both CAT and CRS is provided using early session model, calling party has CAT and CRS service, and CRS has high iFC priority than CAT; or

– both CAT and CRS is provided using early session model, called party has CAT and CRS service, and CRS has high iFC priority than CAT,

if receiving a SIP PRACK request include two early session SDP, i.e. the early session SDP answer from originating UE for early session model CAT and the early seesion SDP offer from CRS AS for early session model CRS, CAT AS shall:

– recognize the SDP which includes an SDP a=content attribute with a "g.3gpp.cat" value for each media description is the SDP answer from originating UE for CAT service; and

– remove the selected SDP before forwarding the SIP PRACK request.

In other scenarios, neither service shall affect the operation of the other service.

4.6.14 Multi-Device (MuD)

No impact.

4.6.15 Multi-Identity (MiD)

In the terminating network, if identity D, as defined in 3GPP TS 24.174 [16], has CAT service active, and user B, as defined in 3GPP TS 24.174 [16], has CAT service active, based on operator policy, either:

1) the CAT service of user B shall be applied to the session by the AS providing the CAT service of user B; or

2) the CAT service of identity D shall be applied to the session by the AS providing CAT service for identity D, without the CAT service of user B applied to the session.

If identity D has CAT service active, and user B does not have CAT service active, based on operator policy, either:

1) no CAT service shall be applied to the session; or

2) the CAT service of identity D shall be applied to the session by the AS providing CAT service for identity D, without the CAT service of user B applied to the session.

In the originating network, no impact.

4.7 Parameter values (timers)

No timers for CAT service are defined

4.8 Service configuration

User configuration of CAT service is not specified in this version of the document.

Annex A (informative):
Signalling flows