4 Common basic communication procedures

24.5283GPPCommon Basic Communication proceduresProtocol specificationRelease 8TISPANTS

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. Clause 4.2 describes the announcement common procedure and annex A shows examples of signalling flows for some announcement scenarios.

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. Clause 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. Clause 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.

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 defined by RFC 3960 [6] and using the P-Early-Media header field authorizing early media as defined in 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 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; or
  • 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.

Mixing announcements into an existing media stream requires that the AS use the 3rd party call control procedure as specified by clause 5.7.5 in ES 283 003 [1].

4.2.4 Communication request rejected by AS

A service may provide an announcement when rejecting a communication request e.g. in order to explain the reason for rejecting 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 defined by RFC 3960 [6] and using the P-Early-Media header field authorizing early media as defined in RFC 5009 [12] for the gateway model and insert the Reason Header with the proper cause value; 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 RFC 5009 [12] and insert the Reason Header with the proper cause value; 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.3 Alternative ring tone

A service may provide an alternative ring tone using the Alert-Info header field as specified by 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.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: In the context of NGN release 2 there is no scope for tracking bandwidth availability in the customer network (see ES 282 003 [8]). 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 in release 2.

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 from A->B

Action AS-B on the REFER from B

Action that the AS-B does on the initial INVITE

INVITE with Allow header with no REFER token

Invoke the 3pcc procedure directly

AS-B adds the REFER token to the Allow header

INVITE with Allow header with a REFER token

Forward the REFER and if the 403 or 501 response is received, fall back to 3pcc procedure

No modification needed in the Allow header

INVITE without Allow header

Forward the REFER and if the 403 or 501 response is received, fall back to 3pcc procedure

No modification needed in the INVITE

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 (A->B dialog)

Action AS-A on the REFER from A

Action that the AS-A does on the 200 OK response on A-B dialog

200 (OK) with Allow header with no REFER token

Invoke the 3pcc procedure directly

AS-A adds the REFER token to the Allow header

200 (OK) with Allow header with a REFER token

Forward the REFER and if the 403 or 501 response is received, fall back to 3pcc procedure

No modification needed in the Allow header

200 (OK) response without Allow header

Forward the REFER and if the 403 or 501 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 method, 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.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

Void.

4.5.3 Requirements on the terminating network side

Void.

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 ES 283 003 [1] and RFC 3261 [4].
  • The syntax of the Error-Info header field conforms to the requirements in ES 283 003 [1] and RFC 3261 [4].
  • The syntax of the Call-Info header field conforms to the requirements in ES 283 003 [1] and RFC 3261 [4].
  • The syntax of the P-Early-Media header field is described in RFC 5009 [12].
  • The syntax of the Allow header field conforms to the requirements in ES 283 003 [1] and RFC 3261 [4].

4.7 Signalling procedures

4.7.1 Activation, deactivation and registration

There are no procedures for activation, deactivation or registration defined.

4.7.2 Invocation and operation

4.7.2.1 Actions at the originating UE

Procedures according to ES 283 003 [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 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.

4.7.2.2 Actions at the originating P-CSCF

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

The P-CSCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info header field.

4.7.2.3 Actions at the S‑CSCF serving the originating user

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

4.7.2.4 Actions at the incoming I-CSCF

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

4.7.2.5 Actions at the outgoing IBCF

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

The IBCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info header field.

4.7.2.6 Actions at the incoming IBCF

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

The IBCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info header field.

4.7.2.7 Actions at the destination P-CSCF

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

The P-CSCF may have a local policy to remove an Error‑Info header field, Call-Info header field and/or an Alert-Info header field.

4.7.2.8 Actions at the S-CSCF serving the terminating UE

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

4.7.2.9 Actions at the AS

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

4.7.2.9.1 Providing announcements during an established communication session

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

Services may send an in-band message or media using an existing media-stream to provide an announcement during an established communication session.

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 RFC 3261 [4] in order to provide an announcement or an alternative ring tone as specified in clause 4.7.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 RFC 3261 [4], RFC 3262 [5], RFC 3960 [6] and RFC 5009 [12].

4.7.2.9.3 Providing announcements when communication request is rejected by the AS

The AS may use the Error-Info header field according to procedures specified by 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 RFC 3261 [4], RFC 3262 [5], RFC 3960 [6] and 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 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

Services 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 202 Accepted response followed by a NOTIFY request with a 100 Trying status line to the originator of the REFER request, according to the procedures of RFC 3515 [13].

The AS then shall perform third party call control procedures according to Flow III or Flow IV of 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 on the 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 headers obtained from the Request or Response in which this P-Asserted-Identity was obtained.

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 RFC 3515 [13]. 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 RFC 3515 [13]. 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 RFC 3725 [14] shall be applied.

As a network option, the AS could send a 202 Accepted 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 and/or re-INVITE requests, as specified TS 183 007 [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 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 or a 501 Not implemented in response to a REFER request forwarded by the AS, it shall send a 202 Accepted response followed by a NOTIFY request with a 100 Trying status line to the originator of the REFER request, according to the procedures of RFC 3515 [13].

The AS then shall perform third party call control procedures according to Flow III or Flow IV of 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.

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 RFC 3515 [13]. 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 headers 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 RFC 3515 [13].

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

As a network option, the AS could send a 202 Accepted 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 and/or re-INVITE requests, as specified TS 183 007 [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.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 RFC 3725 [14] shall be applied. Additionally the AS shall send a NOTIFY for terminating the original REFER request.

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 RFC 3261 [4].

4.8 Interactions with other networks

4.8.1 Interaction with PSTN/ISDN

When a 180 (Ringing) response is received containing an Alert-Info header field the O-MGCF can instruct the T-MGF to play out early media available at the associated URL, to the PSTN leg of the communication. The interaction with PSTN/ISDN is described in ES 283 027 [9].

When a 3xx, 4xx, 5xx or 6xx SIP response to an INVITE request is received from the network containing an Error-Info header field, the O-MGCF can instruct the T-MGF to play out media available at the associated URL, towards PSTN.

When a reINVITE request is received from the network containing a Call-Info header field the MGCF can instruct the MGW to transport media available at the associated URL, to the PSTN leg of the communication.

An I-MGCF may as a network option generate a Call-Info header field, an Alert-Info header field or an Error-Info header field according to rules and procedures of RFC 3261 [4] to provide media instead of the in-band media received from the PSTN.

When a 183 (Session Progress) response is received the O-MGCF sends an appropriate message towards the PSTN/ISDN including an indication that in-band information is available. The interaction with PSTN/ISDN is described in ES 283 027 [9].

The O-MGCF authorizes early media as specified in RFC 5009 [12]. If early media is authorized the O-MGCF indicates that in-band information is available towards the PSTN/ISDN. The interaction with PSTN/ISDN is described in ES 283 027 [9].

The I-MGCF can include a P-Early-Media header field when in-band information is received from the PSTN/ISDN as specified in the RFC 5009 [12].

4.8.2 Interworking with PSTN/ISDN Emulation

When a 180 (Ringing) response is received containing an Alert-Info header field the O-MGCF can instruct the T-MGF to play out early media available at the associated URL, to the PSTN/ISDN Emulation leg of the communication.

When a 3xx, 4xx, 5xx or 6xx SIP response to an INVITE request is received from the network containing an Error-Info header field, the O-MGCF can instruct the T-MGF to play out media available at the associated URL, to the PSTN/ISDN Emulation side of the communication.

When a re INVITE request is received from the network containing a Call-Info header field the PSTN/ISDN Emulation Subsystem can instruct the T-MGF to transport media available at the associated URL, to the PSTN/ISDN Emulation leg of the communication.

A PSTN/ISDN Emulation subsystem may as a network option generate a Call-Info header field, an Alert-Info header field or an Error-Info header field according to rules and procedures of RFC 3261 [4] to provide media instead of the in‑band media received from the PSTN/ISDN Emulation subsystem.

The PSTN/ISDN Emulation subsystem authorizes early media as specified in RFC 5009 [12].

The PSTN/ISDN Emulation subsystem can include a P-Early-Media header field when in-band information is received from the PSTN/ISDN as specified in the RFC 5009 [12].

4.8.3 Interaction with external IP network

Depending on the external IP network and message direction, IBCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info header field.

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 clause 4.1.