4 Common basic communication procedures

24.6283GPPCommon Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS

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

4.1 Introduction

Services may need to send announcements for example to explain the reason for rejecting a communication request or to report the progress of a communication request. The announcement may be of any type of media e.g. an audio announcement or a video clip. Subclause 4.2 describes the announcement common procedure and annex A shows examples of signalling flows for some announcement scenarios. Services may provide an alternative ring tone to override local ring tones provided by the UE as described in subclause 4.3. Subclause 4.7.2.1 describes the procedure by which the UE can locally generate the communication progress information.

Some services are triggered by a user’s busy condition e.g. the Communication Forwarding on Busy service. The busy condition may be determined by the network i.e. the Network Determine User Busy (NDUB) condition or by the user i.e. the User Determine User Busy (UDUB) condition. Subclause 4.4 describes the network determine user busy common procedure and the annex B shows examples of signalling flows for some busy scenarios.

Some services are triggered by sending a REFER request, for example Explicit Communication Transfer. A receiver of the REFER request in some cases might not be able to process the REFER request. Subclause 4.4a describes fallback procedures to 3rd party call control. Annex E provides some examples for signalling flows.

4.2 Announcement

4.2.1 General

Announcements may be sent during the establishment of a communication session, when rejecting a communication request, during an established communication session or during the release of a communication session.

NOTE: An announcement can be triggered by various conditions such as other supplementary services or receiving an indication. However triggers by which the AS makes the decision to send an announcement is outside the scope of this specification.

4.2.2 Providing announcements to a user during the establishment of a communication session

A service may provide an announcement during the establishment of a communication. If an announcement is provided the service shall use one of the following methods:

– use an Alert-Info header field in the 180 (Ringing) response to the INVITE request; or

– use early media as described in annex G and using the P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [12] for the gateway model; or

– use multiple early dialogs as described in annex D and using the P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [12].

4.2.3 Providing announcements to a user during an established communication session

A service may provide an announcement during an established communication. If an announcement is provided the service shall use one of the following methods:

– use an Call-Info header field in a re-INVITE request;

– use the existing media stream. The media stream may have to be re‑negotiated by the service to a media type suitable for the announcement; or

– create a new media stream by SDP offer/answer mechanism for providing the announcement.

Mixing announcements into an existing media stream requires that the AS use the 3rd party call control procedure as specified by subclause 5.7.5 in 3GPP TS 24.229 [1].

4.2.4 Communication request rejected

A service may provide an announcement when a communication request is rejected e.g. in order to explain the reason for the rejection of the communication request in more detail. If an announcement is provided the service shall:

– use an Error-Info header field in the 3xx, 4xx, 5xx or 6xx response to the INVITE request; or

– use early media for sending the announcement in‑band as described in annex G and using the P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [12] for the gateway model and insert the Reason header field with the proper cause value in the 3xx, 4xx, 5xx or 6xx response to the INVITE request; or

– use early media for sending the announcement in‑band in an early dialog as described in annex D and using the P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [12] and insert the Reason header field with the proper cause value in the 3xx, 4xx, 5xx or 6xx response to the INVITE request; or

– accept the communication request and use the established session for sending an in‑band announcement.

4.2.5 Providing announcements to a user during the release of a communication session

A service may provide an announcement to the UE, who does not end the session, during the release of a communication, in order to, e.g. tell the charge information. If an announcement is provided the service shall:

– use the existing media stream. The media stream may have to be re-negotiated by the service to a media type suitable for the announcement; or

– change to new media for sending the announcement.

4.2.6 Providing announcements to a terminating user just after the call is answered and before establishing direct communication session between end users

When a call is established, a service may, before allowing media to be exchanged between the end points, provide an announcement to the terminating user after the call is answered.

When the session initiation request is sent from the originating UE, the AS will act as a B2BUA and modify the SDP offer so that it represents an MRFP handling the announcement, and a media stream will be established between the MRFP and the terminating UE once the called user answers the call.

When the announcement is completed, the AS will send a new SDP offer, based on the SDP offer initially received in the session initiation request, to the terminating UE, in order to remove the MRFP from the media path and allow media to be exchanged between the end points.

4.3 Alternative ring tone

A service may provide an alternative ring tone using the Alert-Info header field as specified by IETF RFC 3261 [4].

The intention with this alternative ring tone is to override local ring tones provided by the UE. It is recommended that the size of the referenced alternative ring tone is small in order not to delay communication establishment.

4.3A Voicemail server identification

When a voicemail server answers a call:

1. If the voicemail server is able to record a message, the voicemail server shall insert in the SIP 200 (OK) response to the INVITE request the media features tag automata and actor="msg-taker" in the Contact header as described in IETF RFC 3840 [19] and in IETF RFC 4596 [20].

2. If the voicemail server is not able to record a message, the voicemail server shall insert in the SIP 200 (OK) response to the INVITE request the media feature tag automata in the Contact header as described in IETF RFC 3840 [19] and in IETF RFC 4596 [20]. In that case, the media feature actor="msg-taker" shall not be inserted in the SIP 200 (OK) response to the INVITE request.

4.4 Network Determined User Busy (NDUB)

Deployment of some service may require the support of the optional service requirements for "network determined user busy" and "approaching network determined user busy" defined in TS 181 005 [7]. In order to support such requirements it is assumed that a network function/application server is deployed to track a user’s busy condition status from the perspective of the network.

The present document is applicable only in cases whereby the network operator has complete knowledge of the applications to which an end user has subscribed and assumes that those applications will furnish the network entity responsible for tracking "busy condition" with appropriate information to enable this determination to be made. This may require appropriate business arrangements between the network operator and the application provider.

NOTE: Tracking bandwidth availability in the customer network is out of scope of the current release. As such it is possible that a communication could be presented based on the network entity determining that the communication can be presented when in fact congestion in the customer network will prevent the communication being presented. This is a limitation of the present document.

Determination of "network determined user busy" by the network may restrict the ability to deploy and support end user devices which perform local services based on "user determined user busy" as part of their base functionality.

4.4a Special REFER request handling procedures

After the reception of a REFER request the AS may start 3pcc procedures under the following conditions:

– the Application Server acts as a B2BUA, so the AS has knowledge about the existing partial dialogs it is involved in, especially of the media user for this communication; and

– the REFER request is routed via this AS.

The 3pcc procedures shall be achieved by sending re-INVITE requests in existing partial dialogs and by sending INVITE requests to establish new partial dialogs.

Tables 1 and 2 give decision criteria when to start 3pcc procedures.

Table 1: Terminating party of a communication sends a REFER request

Content of the Allow header in the initial INVITE request from A->B	Action AS-B on the REFER request from B	Action that the AS-B does on the initial INVITE request
INVITE request with Allow header with no REFER token	Invoke the 3pcc procedure directly	AS-B adds the REFER token to the Allow header
INVITE request with Allow header with a REFER token	Forward the REFER request and if the 403 (Forbidden) or 501 (Not implemented) response is received, fall back to 3pcc procedure	No modification needed in the Allow header
INVITE request without Allow header	Forward the REFER and if the 403 (Forbidden ) or 501 (Not implemented) response is received, fall back to 3pcc procedure	No modification needed in the INVITE request

Table 2: Originating party of a communication sends a REFER request

Content of the Allow header in the 200 (OK) response on the initial INVITE request (A->B dialog)	Action AS-A on the REFER request from A	Action that the AS-A does on the 200 (OK= response on A-B dialog
200 (OK) response with Allow header with no REFER token	Invoke the 3pcc procedure directly	AS-A adds the REFER token to the Allow header
200 (OK) response with Allow header with a REFER token	Forward the REFER request and if the 403 (Forbidden) or 501 (Not implemented) response is received, fall back to 3pcc procedure	No modification needed in the Allow header
200 (OK) response without Allow header	Forward the REFER request and if the 403 (Forbidden) or 501 (Not implemented) response is received, fall back to 3pcc procedure	No modification needed in the 200 (OK) response

As a network option, an AS of the initiator of the REFER request that has prior knowledge that the remote party is not allowed to receive or does not support the REFER request, may initiate 3rd party call control procedures directly.

To avoid a longer re-negotiation of the media, the media information of the existing partial dialogs are used for the INVITE requests or the first re-INVITE requests during the 3pcc procedures.

4.4b Screening of 200 (OPTIONS) response content

Some services may use OPTIONS request to discover the UE capabilities. According to RFC 3261 [4], a UE receiving an OPTIONS request generates the same SIP response as if the request was an INVITE request. If a 200 (OK) response is sent, it will contain an SDP description of the UE media capabilities as well as a Contact header filed containing the supported media feature tags. This feature may be used by malicious entities to get relevant information about the reachability means and the capabilities of the user and, thus, to maliciously use this information; for spamming for example.

Screening the content of the 200 (OK) response allows to avoid delivering some information on the UE (and therefore on the user) to certain originators of OPTIONS requests.

4.5 Operational requirements

4.5.1 Provision/withdrawn

No special requirements for provision/withdrawn. Any requirements on provision/withdrawn belong to the service using the common basic procedures specified by the present document.

4.5.2 Requirements on the originating network side

There are no service specific requirements on the originating network side defined.

NOTE: If required by local policy the IBCF will remove an Error-Info header field, Call-Info header field or an Alert-Info header field.

4.5.3 Requirements on the terminating network side

There are no service specific requirements on the terminating network side defined.

NOTE: If required by local policy the IBCF will remove an Error-Info header field, Call-Info header field or an Alert-Info header field.

4.6 Coding requirements

The syntax for the relevant headers in the SIP requests and SIP responses shall be as follows:

– The syntax of the Alert-Info header field conforms to the requirements in 3GPP TS 24.229 [1] and IETF RFC 3261 [4].

– The syntax of the Error-Info header field conforms to the requirements in 3GPP TS 24.229 [1] and IETF RFC 3261 [4].

– The syntax of the Call-Info header field conforms to the requirements in 3GPP TS 24.229 [1] and IETF RFC 3261 [4].

– The syntax of the P-Early-Media header field is described in IETF RFC 5009 [12].

– The syntax of the Allow header field conforms to the requirements in 3GPP TS 24.229 [1] and IETF RFC 3261 [4].

4.7 Signalling procedures

4.7.1 Activation, deactivation

There are no procedures for activation or deactivation defined.

4.7.1A Registration/erasure

There are no procedures for registration or erasure defined.

4.7.1B Interrogation

There are no procedures for interrogation defined.

4.7.2 Invocation and operation

4.7.2.1 Actions at the originating UE

Procedures according to 3GPP TS 24.229 [1] shall apply.

Certain services require the usage of the Alert-Info header field, Call-Info header field and Error-Info header field according to procedures specified by IETF RFC 3261 [4].

If the UE detects that in-band information is received from the network as early media, the in-band information received from the network shall override locally generated communication progress information.

NOTE 1: In-band information received from the network overrides any locally generated communication progress information also when the most recently received P-Early-Media header fields of all early dialogs contain "inactive" or "recvonly".

NOTE 2: When multiple early dialogs exist with authorization as "sendrecv" or "sendonly", the mechanism used by the UE to associate the received early media with the correct early dialog is unspecified in this version of this specification.

The UE shall not generate the locally generated communication progress information if an early dialog exists where the last received P-Early-Media header field as described in IETF RFC 5009 [12] contains "sendrecv" or "sendonly".

If an early dialog exists where a SIP 180 response to the SIP INVITE request was received, no early dialog exists where the last received P-Early-Media header field as described in IETF RFC 5009 [12] contained "sendrecv" or "sendonly" and in-band information is not received from the network, then the UE is expected to render the locally generated communication progress information.

NOTE 3: According to 3GPP TS 22.173 [23] the UE for an MMTel session generates the communication progress information specified in clause F.2 of 3GPP TS 22.001 [24], with parameters applicable for the home network of the UE.

If the UE supports the P-Early-Media header field as defined in IETF RFC 5009 [12], and at least one P-Early-Media header field has been received on at least one early dialog, then the UE shall send any available user generated media, e.g. speech or DTMF, on media stream(s) associated with the early dialog for which the most recent P-Early-Media header field, as described in IETF RFC 5009 [12], contained a "sendrecv" header field value. If there is more than one such early dialog, the UE shall use the early dialog where the P-Early-Media header field was most recently received.

If the UE receives a re-INVITE request containing no SDP offer, the UE shall send a 200 (OK) response containing an SDP offer according to 3GPP TS 24.229 [1] indicating the directionality used by UE as

– "sendonly" if the re-INVITE request is received on a dialog where the associated communication session has been put on hold by the user or has been put on hold by both users at both ends; and

– "sendrecv" otherwise.

During the established communication, if a video stream is provided with a media level attribute "a=sendonly" and the media level attribute "a=content: g.3gpp.announcement-no-confirmation" as specified in 3GPP TS 24.229 [1], the UE should play this video stream without confirmation with the user if playing video announcement without confirmation is allowed based on UE’s local policy (e.g. configuration on the UE).

4.7.2.2 Void

4.7.2.3 Void

4.7.2.4 Void

4.7.2.5 Void

4.7.2.6 Void

4.7.2.7 Void

4.7.2.8 Void

4.7.2.9 Actions at the AS

4.7.2.9.0 General

The procedures in this subclause apply for the AS serving the originating UE and the AS serving the terminating UE.

An AS using the MRFC and MRFP to send in-band media for announcements shall use the 3rd party call control procedure as specified by subclause 5.7.5 in 3GPP TS 24.229 [1] and the media control procedure as specified by subclause 10.2 in 3GPP TS 24.229 [1].

NOTE: The AS can take the media feature tags into account to determine the UE capabilities (e.g. video) when providing announcements.

4.7.2.9.1 Providing announcements during an established communication session

The AS may use the Call-Info header field according to procedures specified by IETF RFC 3261 [4] to provide an announcement during an established communication session.

The AS may send an in-band message or media using an existing media-stream to provide an announcement during an established communication session. The AS may re-negotiate the media to a media type suitable for the announcement.

The AS may add a new media stream in addition to the existing media stream by SDP re-negotiation to provide an announcement using different media than in the existing media stream (e.g., providing video stream with audio stream) during an established communication session. In the re-negotiation for providing video announcement, based on the operator policy, the AS may include an SDP a=content media-level attribute as specified in RFC 4796 [25], with a "g.3gpp. announcement-no-confirmation" value as specified in 3GPP TS 24.229 [1] in the SDP offer.

NOTE: The "a=content" media-level attribute with a "g.3gpp.announcement-no-confirmation" value is not able to be sent to other operator’s network without inter-operator agreements to use the attribute.

4.7.2.9.2 Providing announcements during the establishment of a communication session

The AS may use the Call-Info header field according to procedures specified by IETF RFC 3261 [4] in order to provide an announcement, or may use the Alert-Info header field to provide an alternative ring tone, as specified in subclause 4.7.2.9.4, during the establishment of a communication session.

The AS may use the MRFC and the MRFP to send an in‑band announcement using early media according to the rules and procedures of the IETF RFC 3261 [4], IETF RFC 3262 [5], IETF RFC 3960 [6] and IETF RFC 5009 [12].

4.7.2.9.3 Providing announcements when communication request is rejected

The AS may use the Error-Info header field according to procedures specified by IETF RFC 3261 [4] in order to provide an announcement when the establishment of a communication session is rejected.

The AS may use the MRFC and MRFP to send an in‑band announcement using early media according to the rules and procedures of the IETF RFC 3261 [4], IETF RFC 3262 [5], IETF RFC 3960 [6] and IETF RFC 5009 [12].

4.7.2.9.4 Providing alternative ring tone during the establishment of a communication session

The AS may use the Alert-Info header field according to procedures specified by IETF RFC 3261 [4] in order to provide an alternative ring tone during the establishment of a communication session.

4.7.2.9.5 Early dialog procedures at the AS

The procedures for dealing with early dialog established between the AS and the originating UE is described in annex D.

4.7.2.9.6 Providing announcements during the release of a communication session

The AS may send an in-band message or media using an existing media-stream or changing to new media-stream to provide an announcement during the release of a communication session.

4.7.2.9.7 Starting special REFER handling procedures at the AS of the initiator of the REFER request

4.7.2.9.7.1 REFER is sent inside a dialog

4.7.2.9.7.1.1 Normal procedures

If the AS receives a 403 Forbidden or a 501 Not implemented in response to a REFER request forwarded by the AS, it shall send a 200 OK response followed by a NOTIFY request with a 100 (Trying) status line to the originator of the REFER request, according to the procedures of IETF RFC 3515 [13] as updated by IETF RFC 6665 [21] and IETF RFC 7647 [22].

The AS then shall perform third party call control procedures according to Flow III or Flow IV of IETF RFC 3725 [14], with the following additions and clarifications.

The AS should verify if it is involved in the dialogs between the originator of the REFER request on one side and the REFER target and the Refer-to target on the other side.

Then the AS shall send an INVITE request to the Refer-to target if it is not involved in a dialog with the Refer-to target (e.g. Blind ECT), or the AS shall send a re-INVITE request to the Refer-to target if it is involved in a dialog with the Refer-to target (e.g. Consultative ECT). The INVITE request shall contain if available a P-Asserted-ID header field with a valid identity of the REFER target and a Referred-by header field matching the P-Asserted-Identity of the REFER request. When including the P-Asserted-Identity the AS shall also include the Privacy header fields obtained from the request or response in which this P-Asserted-Identity was obtained. In addition the AS shall include a P-Served-User header field including a valid identity of the referor.

When the partial dialog with the Refer-to target is acknowledged following a 200 (OK), the AS shall send in the original partial dialog a NOTIFY request with a 100 Trying status line to the originator of the REFER request, according to the procedures of IETF RFC 3515 [13] as updated by IETF RFC 6665 [21] and IETF RFC 7647 [22]. After that the AS shall send a re-INVITE request to the REFER target. The re-INVITE request shall contain if available a P-Asserted-ID header field with a valid identity of the Refer-to target and a Referred-by header field matching the P-Asserted-Identity of the REFER request.

When the partial dialog with the REFER target is acknowledged following a 200 OK, the AS shall send in the original partial dialog a NOTIFY request with a 200 OK status line to the originator of the REFER request, according to the procedures of IETF RFC 3515 [13] as updated by IETF RFC 6665 [21] and IETF RFC 7647 [22]. If a Replaces parameter is included in the Refer-To header field of the original REFER request and it refers to the original partial dialog between the referrer and the refer-to target, the AS shall send a BYE request in the original partial dialog to the referrer.

When the 3rd party call control procedures were successful, continued processing procedures according to clause 7 of IETF RFC 3725 [14] shall be applied.

As a network option, the AS could send a 200 (OK) response directly and initiate 3rd party call control procedures without trying to forward the REFER request to the REFER target.

NOTE 1: For example, when UE-A and UE-B establish a session, they will exchange their own capabilities for SIP methods by using "Allow" header. If the AS lies in the signalling path between UE-A and UE-B, it knows whether the two UEs support REFER or not, and can initiate 3rd party call control procedures. Another example is that a network operator does not want to send REFERs to a user because of security reasons.

NOTE 2: The AS can enforce OIR privacy settings on OIR relevant headers carried in the generated INVITE request and/or reINVITE request, as specified 3GPP TS 24.607 [15] for regular INVITE requests originated by the served user.

NOTE 3: The AS can generate charging events for the generated INVITE requests, correlated to the initiator of the REFER request.

4.7.2.9.7.1.2 Exceptional procedures

If the 3rd party call control procedures fail because a media negotiation between REFER target and Refer-to target is not possible (e. g. the codes cannot be negotiated or the offered ports have changed in a subsequent SDP offer), or REFER target or Refer-to target answer the INVITE request with an error response, error handling procedures according to clause 6 of IETF RFC 3725 [14] shall be applied. Additionally the AS shall send a NOTIFY for terminating the original REFER request.

4.7.2.9.7.2 REFER is sent outside a dialog

4.7.2.9.7.2.1 Normal procedures

If the AS receives a 403 (Forbidden) response or a 501 (Not Implemented) response in response to a REFER request forwarded by the AS, it shall send a 200 (OK) response followed by a NOTIFY request with a 100 (Trying) status line to the originator of the REFER request, according to the procedures of IETF RFC 3515 [13] as updated by IETF RFC 6665 [21] and IETF RFC 7647 [22].

The AS then shall perform third party call control procedures according to Flow III or Flow IV of IETF RFC 3725 [14], with the following additions and clarifications:

The AS shall send an INVITE request to the Refer-to target. The INVITE request shall contain if available a P‑Asserted-ID header field with a valid identity of the REFER target and a Referred-by header field matching the P‑Asserted-Identity of the REFER request. In addition the AS shall include a P-Served-User header field including a valid identity of the referor.

When the dialog with the Refer-to target is acknowledged following a 200 (OK), the AS shall send in the REFER dialog a NOTIFY request with a 100 (Trying) status line to the originator of the REFER request, according to the procedures of IETF RFC 3515 [13] as updated by IETF RFC 6665 [21] and IETF RFC 7647 [22]. After that the AS shall send an INVITE request to the REFER target. The INVITE request shall contain if available a P-Asserted-ID header field with a valid identity of the Refer-to target and a Referred-by header field matching the P-Asserted-Identity of the REFER request. When including the P-Asserted-Identity the AS shall also include the Privacy header fields obtained from the request or response in which this P-Asserted-Identity was obtained.

When the dialog with the REFER target is acknowledged following a 200 OK, the AS shall send in the REFER dialog a NOTIFY request with a 200 OK status line to the originator of the REFER request, according to the procedures of IETF RFC 3515 [13] as updated by IETF RFC 6665 [21] and IETF RFC 7647 [22].

When the 3rd party call control procedures were successful, continued processing procedures according to clause 7 of IETF RFC 3725 [14] shall be applied.

As a network option, the AS could send a 200 (OK) response directly and initiate 3rd party call control procedures without trying to forward the REFER request to the REFER target.

NOTE 3: The AS can generate charging events for the generated INVITE requests, correlated to the initiator of the REFER request.

4.7.2.9.7.2.2 Exceptional procedures

If the 3rd party call control procedures fail because a media negotiation between REFER target and Refer-to target is not possible, or REFER target or Refer-to target answer the INVITE request with an error response, error handling procedures according to clause 6 of IETF RFC 3725 [14] shall be applied. Additionally the AS shall send a NOTIFY for terminating the original REFER request.

4.7.2.9.8 Voicemail server

When an AS acts as a voicemail server generates a 200 (OK) response to an INVITE request:

1. If the AS is able to record a message, the AS shall insert in the SIP 200 (OK) response to the INVITE request the media features tag automata and actor="msg-taker" in the Contact header as described in IETF RFC 3840 [19] and in IETF RFC 4596 [20].

2. If the AS is not able to take a message, the AS shall insert in the SIP 200 (OK) response to the INVITE request the media feature tag automata in the Contact header as described in IETF RFC 3840 [19] and in IETF RFC4596 [20]. In that case, the media feature actor="msg-taker" shall not be inserted in the 200 (OK) SIP response to the INVITE request.

4.7.2.9.9 Providing announcements to a terminating user just after the call is answered and before establishing direct communication session between end users

Services can provide an announcement to a terminating user just after the call is answered and before establishing a direct communication session between end users using the procedures in this subclause.

When an INVITE request is received from an originating UE, the AS shall

– act as B2BUA;

– modify the SDP offer received from the originating UE with the media parameters necessary for the announcement;

– indicate that resources at the MRF are available; and

– send an INVITE request to the terminating UE as specified in 3GPP TS 24.229 [4].

Upon receipt of an 18x provisional response from the terminating UE the AS shall indicate the progress of the call towards the originating UE, e.g. send a 180 (Ringing) response or start an announcement.

When the session between the AS and the terminating UE is established the AS shall start the announcement.

When the announcement is completed, the AS shall send a re-INVITE request or an UPDATE request towards the terminating UE as specified in 3GPP TS 24.229 [4]. The SDP offer:

NOTE: An UPDATE request can be used if the required bandwidth is the same or lower for the call as for the announcement towards the terminating UE.

– shall include the SDP offer received from the originating UE;

– if not included in the original offer from the originating UE, all media for providing the announcement shall be removed (i.e. media lines are set to port "0"); and

– shall indicate that the resources at the originating side are not available if preconditions are used.

For the rest of the call the AS shall:

– if needed, modify the sdp sent towards the originating UE so that the content of the sdp aligns with the offer/answer between the originating UE and the AS;

– forward SIP requests and SIP responses received from the terminating UE towards the originating UE without changing the SDP using the SIP dialog created above.

For the rest of the call the AS shall:

– if needed, modify the sdp sent towards the terminating UE so that the content of the sdp aligns with the offer/answer between the terminating UE and the AS; and

– forward SIP requests and SIP responses received from the originating UE towards the terminating UE without changing the SDP.

4.7.2.9.10 Screening of 200 (OPTIONS) response content

When an OPTIONS request is received, the AS shall:

1) identify the served user as specified in 3GPP TS 24.229 [1];

2) identify the originator of the OPTIONS request by the URI present in the P-Asserted-Identity header field of the request if present and otherwise by the URI present in the From header field of the request; and

3) if screening is required, by configuration data, act as a routing B2BUA according to 3GPP TS 24.229 [1]. Then:

– Upon receipt of any response different from 200 (OK) response, the AS shall generate the same response according to the procedures for a routeing B2BUA specified in subclause 5.7.5.1 of 3GPP TS 24.229 [1].

– Upon receipt of a 200 (OK) response, the AS shall generate a 200 (OK) response according to the procedures for a routeing B2BUA specified in subclause 5.7.5.1 of 3GPP TS 24.229 [1] without the information for which screening is required by the configuration data.

NOTE 1: The configuration data can be set the user or by the operator and can include the identity of the served user and/or the identity of the originator, How the user can configure the screening of its destined OPTIONS requests is out of the scope of this specification. Such configuration can for example be performed through a web portal.

NOTE 2: Screening of UE capabilities from the 200 (OK) response to an OPTIONS request can cause the originator not to attempt a session using the screened capabilities.

4.7.2.10 Action at the terminating UE

Certain services require the usage of the Alert-Info header field and Call-Info header field according to procedures specified by IETF RFC 3261 [4].

– "sendonly" if the re-INVITE request is received on a dialog where the associated communication session has been put on hold by the user; and

– "sendrecv" otherwise.

4.8 Interactions with other networks

4.8.1 Void

4.8.2 Void

4.8.3 Void

4.9 Signalling flows

Signalling flows are documented in annexes A and B.

4.10 Parameter values (timers)

No specific timers are needed.

Annex A (informative):
Signalling flows for announcements

This annex shows some example signalling flows for the procedures described in subclause 4.1.

These signalling flows are simplified in that,for in-band announcements, they do not show the AS to MRFC interactions.